Archive for the ‘OS X’ Category
Monday, May 30th, 2011
As many of you know, I've had an on again, off again, and then on again affair with Meego. I love that lil' guy! You may have expected me to be quite excited about the recent release of Meego 1.2, including a netbook refresh. Since I was running Meego on a netbook, you may have then also expected me to be super excited about the very recent announcement of the ASUS Eee PC X101. This is a 2lb laptop that runs Meego and is expected to cost $200. Sweet!
However, as you may have guessed from the title of this post, I'm not running Meego any more. I'm running OS X on a MacBook Air 11". I had crossed the threshold of tinkering around on a laptop, to wanting to commute with one every day. Indeed, 2lb was my sweet spot for a laptop. I wasn't that stuck on the OS as my apps are all cross platform enough. I seriously considered many different netbooks and then the MacBook Air came out. The 11" was just over 2lb, included a full size keyboard, had a 1366 x 768 screen and a 5 hour battery. It was also insanely small. For a relative paltry $1000, there was simply no laptop, regardless of OS, that had had all of the above features. Period. Though I think the new Eee X101 will be very cool, it lacks the screen resolution of the Air. I briefly considered the Sony Vaio X (no longer available) which met all my requirements, but it was a pretty penny to pay for an Atom processor.
"But if you want something super light, what about a iPad?", you ask? I do agree, an iPad's insanely long battery life coupled with 1.3lb weight has some handy uses: a cross country plane ride, long regular commutes where you want to read the news and browse email or need a super light weight video conference rig. But what about when you want to run an IDE? What if you want to compose a 3 page (7,500 character) long email? What if you want to flip back forth between the 3 browsers you have open to check how your code renders? The answer is clear: you need a laptop.
I've been super happy with my Air and I wish the best of luck to Meego.
Saturday, February 27th, 2010
A bit ago I wrote a post about using command line tools to get stats of this blog. I recently wrote another version of this to get the most popular posts here, sorted by the most popular at the top. I love that this can be done in all in one command.
Here's the command:
tail -1000000 access_log|grep 'GET /blog'|cut -d" " -f 7|egrep -v '\.png|\.jpg|wp-includes|\.css|/page/|/category/|xmlrpc|wp-trackback|/feed/|wp-login|/wp-content/|/trackback/|wp-comments|wp-app.php|wp-admin|comment-page|index.php|?p=|page_id|comments|feed'|sort|cut -d"/" -f 3|uniq -c|grep -v ' 1 '|sort -nr>plip.blog.tops.txt
This breaks down into the following:
- get the last 1000000 of the blog access log
- look for requests to "/blog"
- split by space, and get the 7th field, the URL being requested
- exclude a ton of items
- sort the results
- split by the "/" slash and get the 3rd field, the blog name in the URL
- get the unique list of blog names with a count for each URL
- remove the singletons
- reverse sort so the most popular is at the top
- write it all to a file called plip.blog.tops.txt
The results are in! The winner is currently chocolate-crinkle-cookie-photos! W00T
Friday, February 19th, 2010
This is nothing but a repost of a slightly older fix, but this is AWESOME!
Fixing ZDE 5.5 in Snow Leopard
Thursday, January 28th, 2010
A problem with online security is that there's no standards for passwords. You may come up with the silly simple single password you use for all site. This works well, until you encounter a site that wants one that is, say, 2 characters longer than the one you use. What then? Or, maybe you're a bit better and use a scheme where you "encrypt" the domain name into your password. Again, this works fine until a site forces you to break this scheme, and then you're shit out of luck. The net result is that you either A) have extremely simple passwords or B) forget the passwords often or C) write them down next to your computer.
In case you didn't think so, options A, B and C suck. Don't do it. Be smart and be safe.
The way to do this involves some pain in the ass security, which I've said before different levels are acceptable. I feel that protecting your passwords are critical, so I'm willing to accept a somewhat higher PITA level. My PITA of choice for passwords is KeePass. Being an open source project (W00T!), some of the execution of the user interface is left to the developer, so you may find some ports are better than others. However, the vanilla OS X and Windows flavors I use at work and home respectively, simply rock. The Android port I use is the icing on the cake. I can download a copy of my password file and have all my passwords on the go.
KeePass, much like TrueCrypt, has really thought about how to store passwords. Here's a list of some of the great features:
- generate a secure password based a given site's rules (8+ letters, 1+ number etc.)
- hot keys to quickly copy username and password
- android version puts the username in alert menu so you can easily copy and paste it into a web form
- encrypt notes for extra info like security question you also won't remember and wrote down next to your password
- ported to just about every platform, including iphone and android
The net result of this is that you never forget a password, you use secure passwords and no one can get at your passwords. This is secure and this is how you should do it! For the forward thinking, store your password file on a USB cary with you or, if you're like me, you'll put it on your dropbox account, and then you can seamlessly use it on all your computers. Doubly handy!
Wednesday, October 14th, 2009
Hi there way too powerful desktop, why don't you distribute a high load across more cores? I know your authors would have to work to make the process multithreaded and who would have thought that a lil' mp3 player would every be networked and asked to download the XML library of 5 remote mp3 collections simultaneously, but still?! I want me fast computer now. Thanks.
Wednesday, July 29th, 2009
At work we've been working on a good way to roll our own videos. We initially started with the generic off the shelf swf player + flv to make our videos go. This was OK, but was lacking some key features folks were used to, primarily full screen play back and the ability to seek to a specific spot in a video. Additionally, for videos that were over 20 minutes being viewed over slower connections, precious apache children would be chewed up potentially causing a slow down for the web head doing the serving.
Enter JWPlayer! This is a great, easy to configure, free for non-commercial use, flv player that offers the features we're looking for. Further, we could offload the flv's to our image server, lighttpd . (By the way lighttpd is extremely awesome; I can not recommend it enough. I first learned about from my friend over at WikiSpaces where they had dropped apache entirely in favor or lighttpd. Noteworthy is that lighttpd was first concieved as an attempted answer to the c10k problem. I've personally seen it handle over 2000 connections per minute and the server load didn't go above 0.5 (though the full meaning of load average is a curious one (sorry for the double, now triple parenthetical statements )).) Simply add a little flv streaming foo to lighttpd, and you're good to go.
At this point, we hit a stumbling block. In order for JWPlayer to seek, it would send a request for the FLV to the web server and give it a starting point, like so:
10.1.6.221 lighttpd.domain.dom - [29/Jul/2009:12:46:37 -0700]
"GET /web_assets/video/your.flv?start=17038076 HTTP/1.1" 200
17765145 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
en-US; rv:18.104.22.168) Gecko/20090715 Firefox/3.5.1"
However, if the flv you were serving didn't have key frames then the web server would simply ignore the query string, and indeed, the click all together.
We do most of our development and video authoring on a mac and then serve our files off a load balanced linux server. At first, we used flvtool2 on linux to embed the key frames on our flvs. This kinda works, but it'd be easier to have the video author be able to add them himself with out needing to download and install ruby and rails and all that crazy server scripting foo. As his flv creator/codec/authoring app/chumpy wasn't playing nice, I was given the task to find a simple solution.
Now, finally, we get to the point of the post. If you've gotten this far and wanna know how to embed keyframes with out ruby, get thee to the multi-platform, command line tool called flvmeta and go home happy!
Update: This post would not be complete without mentioned our use of swfobject to render the flash HTML.