March 16, 2012 § Leave a comment

Why is Chrome included with Google Earth? That might explain why the Mac download was significantly larger than the Windows one.

Why? Seriously, why?


Sleep Issues and CUPS

February 1, 2012 § Leave a comment

It’s a good thing I depend on CUPS for printing.

Lately, my Mac has been having some issues with sleeping. Any time I tried to put it to sleep, it would just sit there mocking me. I’d close the lid and it would continue about it’s merry way all the while I was angry because I wanted to go to sleep.

I tried fixing this by repairing permissions in the hope that some file responsible for sleep (such as my sleepimage file) had problematic permissions set. Alas, that didn’t work so I continued my search. I eventually came across this blog post which solved my problems.

I did as the post recommended – I ran “pmset -g assertions” (pmset is a tool to manage power management) and saw the following:

The cause of my grief revealed!

I killed that process (using the kill command here was a little cathartic) and voila!

I have no idea why CUPS would need to prevent my Mac from sleeping because I can guarantee that it won’t be “sleep printing.”

Content Injected CSS

January 22, 2012 § Leave a comment

I’ve been fooling with content injection and how to do it with Chrome extensions lately, primarily as a way of overriding what I deem to be poor design choices by web developers. So far, I’ve managed to tackle the one page that I despise the most: my school’s library website. Here’s what it looks like before I get to it:

Oh god, my eyes!

Here’s what it looks like after I took a “CSS sword” to it so to speak:

Much, much better.

Can you tell that my aesthetic preference is minimalism? More of the internet awaits!

Fork Bomb

December 28, 2011 § Leave a comment

I recently learned about fork bombs and I find myself intrigued by the simplicity behind them.

For those who are unfamiliar with them, I quote the Wikipedia article which provides a nice succinct definition:

A fork bomb works by creating a large number of processes very quickly in order to saturate the available space in the list of processes kept by the computer’s operating system. If the process table becomes saturated, no new programs may start until another process terminates.

Here’s the Python example from the article:

import os
while True:

Pass those three lines to the Python interpreter and you’ll crash your machine. This isn’t even the shortest example – the Windows batch example is five characters (%0|%0). You can even (apparently) create one in HTML and JS which would allow you to lock a computer (independent of OS) just by visiting a website.

I don’t bring this up to suggest that this is something you should do. Far from it in fact. Rather, I find this simplicity quite elegant (this is what intrigues me). With such a limited input, you can lock up an OS. I’ve tried it (using the Python example above) and the results were interesting. The virtual machine I tried this in slowly sucked up the RAM available to it to the point of locking up. When I say lock up, I mean it in the old ‘Windows 98’ style when nothing was responsive.

Moral of the story: simplicity can still beat complex OS design.

JS Speeds and HTML Performance – December 2011

December 21, 2011 § Leave a comment

So I’ve decided to do a test of the major browsers available for the Mac to see how they’re doing. Before I show you the results, one thing to note about my browser habits is that I use nightly/dev builds. I like to get new features as soon as I can so I don’t actually use stable builds. As such, the following is a list of browsers that will be tested with the corresponding version and/or build numbers.

  • Firefox Nightly (12.0 a1 2011-12-21)
  • Opera Next (12.00, build 1213)
  • Webkit (r 103402)
  • Chrome (17.0.963.12 dev)


What is most surprising about this is Firefox’s performance. For the first time (in my experience), Firefox has the best SunSpider score. What’s even more surprising is Chrome’s relatively poor performance. For a browser focused on JS performance, it’s disappointing to see it finish in 3rd.

HTML5 Test

Chrome and Opera’s performance here is not at all surprising. Both Google and Opera put a lot of work into adding as much support as they can to their browsers. The Webkit and Firefox nightly results are not surprising with respect to placing but I’m surprised at how low Firefox’s score is comparatively.

Modernizr Test

This is a custom test that I designed (you can view it here). It tests a variety of things but primarily, it tests HTML5 and CSS features. Opera’s last place finish here is a little disappointing but other than this, the results are rather unsurprising.


Peacekeeper tests a variety of JS and HTML features including the performance of each browser in video playback and WebGL (I think). Chrome’s far greater score here was expected and to be honest, none of these scores is all that surprising.


Chrome finished first in three of the four tests that I did which might lead one to think that Chrome was far superior. When you consider that it has a healthy extension ecosystem (not quite Mozilla large but sizeable enough), has built in PDF support and has a built in Flash plugin that is automatically updated (thus preventing problems that might come with old Flash installations), it seems harder to believe that it isn’t the best out there. That said, it has some serious flaws including (and this one is big for me) its inability to handle multiple tabs. I can’t tell you the number of times that Chrome has comes to its knees trying to open twenty tabs while something like Opera can handle that task with ease.

As always, not only are these tests relatively meaningless to the average user but browser choice should be based on personal comfort with each.

Firefox 1 vs. 8 Build Time

November 22, 2011 § Leave a comment

On November 9, 2004, Mozilla released version 1 of Firefox. At this time, I was about two months into my B.A. and was getting into Linux. During this time, I tried a lot of Linux distros, one of which was VidaLinux. This distro is built on Gentoo and in case you didn’t know, Portage (Gentoo’s package manager) is source based. In other words, installing new software meant it was compiled from source.

At the time, I was using my first ever personal notebook – a Dell Inspiron 1150. This had a 2.66Ghz P4 with 512MB of RAM (it was also heavier than a house). At the time, I used it for everything including my Linux experiments. This included my short time with VidaLinux which also gave me an appreciation for how long some programs take to compile from source. For me, Firefox took about an hour to compile from scratch. A simple “emerge firefox” from the command line started the process whereby the Firefox source was downloaded and compiled.

At the time, I felt that an hour was a long time just for a browser. I still do. That’s why I wanted to try this process again to see if I could do it any quicker. Here’s what I found:

My current machine is a 2.1Ghz C2D with 4GB of RAM running OS X 10.7.2. I didn’t want to download the Firefox 1 source and compile that because that test would be irrelevant for many reasons. Instead, I wanted to see if I could compile a working build of a current version of Firefox in less than an hour. In other words, had the ability for machines to compile code outpaced the growth in bloat that is Firefox.


Before I began, I looked up the build instructions. I chose the simple build – I don’t want anything fancy here. As the instructions note, you have to setup an environment first by ensuring that you have all the appropriate tools. This required the building of a few tools. I already had Mercurial installed but I had to install libidl, autoconf and yasm. I downloaded MacPorts and started the build process. Building these tools/libraries alone took quite a while. In fact, it took 31 minutes and 42 seconds.

real 31m41.689s
user 18m10.658s
sys 7m59.471s

Getting the Source

The next step was to get the source. This was a simple Mercurial command and doesn’t require any compiling or installation so it went much quicker. It took 5 minutes and 10 seconds to get the 67.1MB bunzipped tarball of the Firefox 8.0.1 source from Mozilla’s FTP server.

real 5m9.637s
user 0m0.981s
sys 0m3.640s

Decompressing the source took another 1 minute and 1 second.

real 1m1.336s
user 0m26.413s
sys 0m9.748s

Building Firefox

This is the longest part by far (which, of course, is expected). It took surprisingly long: 1 hour, 46 minutes and 52 seconds.

real 106m51.707s
user 84m6.868s
sys 11m56.574s


It’s slow. Still. The whole process took a total of 2 hours, 24 minutes and 45 seconds. Now, to be fair, you you’d only have to install the “pre-build” tools once but even then, I’m still looking at close to two hours to build Firefox. Ugh.