bytex64.net/blog

Recently my friend Alex brought uzbl to my attention. It's an extremely minimal webkit browser, and a rather clever one, to boot. It has a simple command language that it can read from a config file, stdin, or a socket. Arbitrary command strings can be defined to execute external scripts or run javascript inside webkit. It's designed around the UNIX philosophy of being a useful component rather than a total solution.

Of course, when I said "extremely" above, that means that it lacks everything other than webkit. It has no bookmarks, no history, not even persistent cookie handling. All of those features are expected to be handled by external scripts. That would be fine if it came with scripts that worked, but most of the supplied scripts depend on dmenu, or are unfinished. And even the lack of useful scripts would be fine if the interaction between helper scripts and uzbl were documented, but they aren't.

So in order to get anything done, you have to go diving into uzbl's source — a monolithic ~2700 line C file. The code is poorly organized, with poorly designed regexes and comments that have more questions than answers. It is, in my professional opinion, a huge glob of hacks. It brings me to an idea I thought up the other day, which I'd like to call "Black's Rule":

"For any programming language X, you should not have to understand X to use a program written in X."

After spending a day trying to write a persistent cookie handler, diving through poorly written C, and having no idea why it wasn't working, I've given up on it. I'll come back to it some time later, hopefully after it has matured. I like the idea of a web browser that acts like a tool, but only if the interactions with that tool are properly documented.

User: My MacBook has crashed!
Tech Support: What were you doing right before it crashed?
User: Oh, about Mach 6.

If you have an iPod or a Zune, you've probably got a tiny hard drive spinning inside. And if you've ever dropped it, you've probably noticed that it continues to work just fine. If it didn't, my condolences. :( The trick is that the device uses accelerometers to measure earth's gravity and detect when it is in free-fall. When the device detects a free-fall condition, it parks the hard drive, preventing damage when it impacts.

In order for this to work in all directions, a three-axis accelerometer is used. When a device is held against the pull of gravity, the accelerometers measure an acceleration of 9.8 m/s². When the device is in free-fall, however, it measures zero acceleration, triggering the hard drive to park itself. The trick, then, is to get the device to impact something while under acceleration equal to earth's gravity. (This could, of course, be accomplished by keeping the device stationary and hitting it with something that is moving, like a hammer, but that's not very interesting)

The answer is (as it usually turns out) the proper application of high explosives. If you attach a rocket to the top of the device so that it accelerates downward at 9.8 m/s², the accelerometers in the device will be fooled into thinking that it is stationary under normal gravity, and it will spin its hard drive merrily until it smashes into the ground. I think a diagram will illustrate this nicely.

Voila! Safety mechanism defeated. (Pedants will complain that the acceleration vector for gravity in the diagram above should point upwards — This is true, but irrelevant from the POV of the device, which only measures the magnitude of acceleration)

Then again, the device may also detect vibration, which the rocket will produce a lot of if it's hurtling towards the ground. As an alternative method, you could place the device in a centrifuge that exerts a force equal to that of gravity while the entire assembly is in free-fall. I think Mythbusters needs to test this.

Today I learned more or less how to do Silverlight 1.0 applications. Even though Silverlight is nearing on a 3.0 release, using 1.0 is important to me because Novell's Moonlight implementation only supports Silverlight 1.0 features. This may not sound like a big deal, but there is a pretty big functionality gulf between 1.0 and 2.0. The short version is that 1.0 is just a fancy presentation layer, and all the program logic works through your browser's JavaScript engine, much like a regular web page. In 2.0, there are not only more features, but the program logic can be compiled with the .NET framework, making it faster and a lot more feature-packed. Some day Moonlight will catch up, but that's a big concern if you want to do Silverlight content right now.

For my test I ported the trusty swarm.3 hack to use Silverlight as its display. I do have to compliment Microsoft on Silverlight's design; even though Canvas is procedural and Silverlight is declarative, porting was very straightforward. The result is swarm.Silverlight.

I had expected that Silverlight would provide a significant performance increase because of its more efficient drawing code. And indeed, that's what I found. Well, sort of. In Windows, Silverlight was over twice as fast as the Canvas implementation, but in Linux using Moonlight, it was significantly slower. On the plus side, swarm.Silverlight is the only JavaScript hack I've made that is 100% functional in Internet Explorer.

Moonlight's slowness is very puzzling, and does not look good for Novell. I hope that future releases are faster, but right now, it's really looking like the open source community got the short end of the stick. I suppose that's still an improvement over what has happened historically, where open source doesn't get any part of the stick and has to make their own stick out of compressed wood shavings and glue.

Oh, well. Back to the drawing board.

---

ADDENDUM: It turns out that Moonlight's slowness was due to a half-baked radeon driver I had to use in Ubuntu 9.04. Moonlight apparently uses GL for accelerated graphics, which was actually slowing things down in this case. On another linux machine with a GeForce, Moonlight is significantly faster.

A long while back, I started watching Naruto to see what the buzz was all about. The series was pretty far progressed at this point (episodes in the hundreds), so I got batches of ten episodes one after the other for about 40 episodes. And in that 40 episodes, pretty much nothing of note happened. There were a few fights, some slapstick humor, and the series was still trundling along. Facing at least another hundred episodes of pretty much pure filler, I realized that I was wasting my time, and I quit watching. For 40 episodes of nothing, I could have instead watched:

• The Melancholy of Haruhi Suzumiya - 14 episodes
• Samurai Champloo - 26 episodes

or

• Sayonara Zetsubou Sensei - 12 episodes
• Welcome to the NHK! - 24 episodes
• Paprika - 90 minute movie

or

• Evangelion - 26 episodes
• Read Or Die - 3 episode OVA
• FLCL - 6 episodes
• REC - 10 half-episodes

All of which are immensely superior to Naruto in every way.

So if your friends ask you if you want to watch Naruto, tell them "No. I'm going to go do something worthwhile," and then leave. You'll be glad you did.

Recently, I've tried a lot of different browsers in an attempt to find something that uses less memory than Firefox. After several days of use, Firefox will balloon to the point where it's eating into swap, slowing the system to a crawl. After careful consideration of alternatives such as Opera and Midori, I think I've found a solution:

Buy more RAM.

At best, all I saved was about 20MB, and that was a constant. No browser can keep from ballooning after you open 20 tabs. To explain it computationally, web browsing is an unbounded problem in terms of both CPU and memory. So I've done what any competent person with a bachelor's in CS would do: ignore the problem and hope it goes away. To that end, I've maxed out my ThinkPad with 1GB of RAM, and things are sailing smoothly now. :)

This is part of my larger "Netbook Refurbishment Plan." After looking at the available netbooks on the market, I realized that they're only marginally more powerful than my T23, but with smaller screens and horribly cramped keyboards. The T23's keyboard is (and I'm quoting Wikipedia here) "acknowledged by many as having the best keyboard on any laptop computer^{[citation needed]}." So instead of getting a netbook, I'm going to improve my T23.

After getting the most immediate improvement by upgrading the RAM, the next step is to get things portable again by buying a couple of new batteries. For durability and extra energy savings, I'm going to replace the HD with Compact Flash or an SSD, whichever seems to be the better choice when I have the money. If I can find a wifi kit, I'm going to add internal WiFi for extra portability.

With all these improvements, my ThinkPad will become INCREDIBLY AWESOME. :D

Hatsune Miku is the well-known Vocaloid, but she wasn't the first. In 2004, Crypton Future Media released Meiko, a female voice for the original VOCALOID engine. Later, in 2006, a male voice named Kaito was released.

Meiko is usually seen wearing red (and not much of it), and Kaito seems to like blue. Their voices are not as refined as the later VOCALOID 2 series voices, but they are also more versatile. Where Hatsune Miku was designed to sing cutesey anime theme songs, Meiko has a more mature voice that is adaptable to anything from rock to R&B to vocal trance. Kaito is often seen singing duets with Meiko and Miku, with whom his voice pairs particularly well.

Here are a few songs from Meiko and Kaito:

Meiko

• Various Feelings - Meiko recalls her troubled past
• Human Genome - A broken family, a kid in a tube, and Meiko in the computer.
• Color - Relax.
• Trash Pop Night - Bring out the big band.
• Nostalogic - Some high energy music to show off Meiko's... talents.

Kaito

• Another: World is Mine - Kaito's version of Miku's World is Mine.
• Old Radio - WARNING: May contain trace amounts of creepy soulless automatons.
• Byakkoya no Musume - A surprisingly good adaptation of the theme from Paprika.

Duets

• To Dream of a Dove
• Cantarella
• Cold, Wintry Winds

And because I'm a sucker for romanticism, I leave you with this wonderful video of Kaito proposing to Meiko.

Fun fact of the day: A stick of deodorant will lose all its potency after five years.

Toradora finally finished, and I just have one thing to say about the ending:

Weeeeeeeeeeeeeeeak.

Moving on to greener pastures, I found a rather unique mecha anime called RideBack. The mecha are a sort of half-motorcycle half-humanoid robot, called RideBacks because you sit on their back. They have wheels for feet, and are highly mobile due to their ability to switch between a humanoid stance and a "spread leg" motorcycle stance. The hook is that the main character is a former ballet dancer who, due to her extremely developed sense of balance, turns out to be an expert RideBack pilot. In trying to save her friends and family, she becomes embroiled in a fight against a totalitarian regime that rules Japan through oppressive force. It's an interesting story, if a bit fast-paced. If you like two out of three of ballet, mecha, and motorcycles, you'll probably like RideBack.

No, I didn't do anything for April Fools Day, which is regrettable, but I don't have a lot of exposure, anyway. Perhaps next year.

In other news, I think I'm in love.

Toradora is either getting really good or really bad. I've been watching anime so long, I can't tell anymore.

EOH was last weekend, and it was really good this year. There was a large focus on energy technology — even the ACM had a booth that explained how to make your computer more "green." The rest of ACM was, of course, more concerned with making things look pretty. There were some pretty neat projection mapping demos, some indie games, and SigMAC had something trivial and pointless. SigMIL, ever interested in information control, demoed a fun application that finds as much as it can about you from just your name using UIUC records, Facebook information, and public voting records. The robot competition was excellent, too, even if the top two places were from Valparaiso and UIC. Perhaps someday, we'll have a UIUC team that is as well-funded and experienced as they are.

Alex's older brother Pete is coming to visit next week; that should be fun. Very shortly after he arrives, Erickson will be leaving for India for a whole month. That leaves me more or less by myself. I look forward to getting very sick of Alex and Andrea.

And in the department of "becoming everything that you hate," Firefox (which some of you may remember as the "lite" version of Mozilla) has spawned Fennec, a version of Firefox devoted to reducing memory footprint and speeding up load times (for use on small systems like cell phones and netbooks). Nowadays, Chrome is faster on Javascript, Opera renders faster, and reportedly even IE8 loads pages faster than Firefox. (No, nobody cares about Safari 4 and their retarded folder view) Firefox has truly become the Emacs of web browsers. But hey, you can't make any other browser work like Vim!

I've heard that Chromium (no, not that Chromium) will compile in Linux these days. Perhaps I'll give it a try.

It's been a common claim of Gentoo types that you should compile all your software for your native architecture because it will go faster. Now, as someone who spends most of the day staring at a cursor, my personal belief is that it's not worth doing this to everything on your system, since most of it's waiting on the fleshy bit behind the keyboard. But for a few specific instances, I've often pondered how much of an advantage can be had. So, while I have a Core 2 Xeon Quad sitting in my basement, I decided to do a few tests.

The Core 2 is a 64-bit architecture, but for the purpose of this test, I'm compiling things for 32-bit. This is for two reasons: One, 64-bit hasn't been around long enough for there to be significant departures in functionality between revisions, and two, I'm running this on a USB drive with Slax, which is 32-bit only by virtue of being a Slackware derivative. :)

Rather than use a synthetic benchmark or something useless like a digits-of-pi-generator, I've decided to use a practical benchmark. I'm using FLAC 1.2.1, encoding Everclear's "So Much For the Afterglow" album (which, incidentally, I legally own). FLAC already has some hand-tuned assembly in it, but that's fine. Most of the stuff you'd want to optimize already does. I'm testing actual results for actual programs, not theoretical improvements for contrived tests.

I'm timing the encode time for the full album from WAV files to compression level 8 FLAC. All files are stored on a tmpfs ramdisk to minimize I/O wait, and all times are the average of three runs.

I've chosen the architectures to test based on their added features. i386 is the baseline. i686 adds the Pentium Pro instruction set. Pentium3 adds MMX and SSE. Pentium-m adds SSE2. Pentium4 is also SSE2, but I'm interested to see if it exacts any performance penalty for being scheduled for a very different implementation. Prescott adds SSE3, and nocona is the latest Intel architecture that GCC 4.2.4 supports.

The results:

Architechture	Time (s)	Improvement
i386	75.071	0%
i686	71.771	4.3%
pentium3	72.310	3.7%
pentium-m	71.884	4.2%
pentium4	74.436	0.8%
prescott	72.584	3.3%
nocona	72.734	3.1%

The Core 2 definitely shows its roots here, with i686 and pentium-m showing the biggest improvement over vanilla i386. Also, the Pentium 4 didn't fail to disappoint, being nearly as slow as i386 code. So if you're running 32-bit code on a Core 2, compile it for i686 (which is what most distros do these days, anyway). Of course, this all means jack when you use a Core 2. You should be using x86_64. :)

None of these improvements are what I'd call worthwhile, though. If you can stare at 75 seconds of encoding and get a tangible feel for a 3.6 second improvement, then by all means, go ahead. Do keep in mind, though, the work required to recompile in the first place. Even on a Core 2 Quad, where compilation of FLAC takes about a minute, it just doesn't add up.

Pop quiz! You have five minutes to complete this test.

1. What does the following vim regex do?

   /^\@<!^I\@<!^I/
   

2. Write a single-line shell command that moves every file older than three weeks to another directory and gzips it. Please specify which UNIX flavor you are using.
3. Without running it, what is the output of this perl script?

   #!/usr/bin/perl
   
   $" = "\", \"";
   @_ = ("Horse", 3, ["One", "More", "Time"], \$_[0]);
   print "$$_[3]\"@{[map{substr($_,0,3)}@_]}\"\n";
   

...Pencils down! Hand your papers forward.