What’s come up since the last time I did any sort of Javascript performance comparison? Well, Google Chrome and its JS engine (“V8″), for one. Also, something of a new era in Javascript handling that attempts to optimize how browsers handle it by converting it to bytecode (or, in the case of JavaScriptCore/Squirrelfish Extreme/Nitro, directly to native machine code). In addition, there’s been some new benchmarks arrive on the scene, which allows us to tease out bias from any particular one.

It’s amazing, really, to compare these numbers against the linked benchmark from a mere 1.5 years ago. Opera went from being the top of the heap with 9.5 to being a lazy 3rd or 4th place. And Chrome, of course, decimated the competition (so far). Read on for the testing methodology and the results.

The tests

I chose four different benchmarks, three of which are entirely Javascript and one of which is mostly Javascript.

1. Dromaeo is a large, comprehensive benchmark that optionally incorporates some of the other benchmarks we’re looking at today. It was created by the Mozilla Corporation. It offers several test suites, but the one used here was the Dromaeo subset of tests
2. SunSpider is a benchmark created by the folks behind WebKit. It quickly became and remains one of the most popular and venerated Javascript benchmarks available.
3. V8 Benchmark is a benchmark application designed by Google to test its V8 Javascript engine. It’s actually a very short and simple benchmark that fantastically favors Google’s browser (and Safari).
4. Peacekeeper is a new browser benchmark by FutureMark. It’s supposed to test not just Javascript performance, but some rendering performance as well. As you will notice below, the numbers seem a little funny, as it appears to favor Safari (WebKit + Nitro) by a significant margin

The Hardware

All tests were run in Safe Mode (where applicable; meaning that no additional plugins or widgets were loaded) on the following hardware:

• Intel Core2 Quad @ 2.4GHz
• 4GB RAM
• Windows 7 build 7229, x64 Ultimate Edition

The Data

What follows is the raw data table. Jump down for the summary.

The Conclusion

So what does this data tell us?

For starters, it means that the much-vaunted but long-developed Tracemonkey javascript engine in Firefox 3.5 is already a distant third-place player, if not fourth-place. Chrome’s V8 engine outperforms it by no less than a factor of 2 on just about every test. In fact, Chrome 3 on Windows 7 is the fastest browser available, period. Now, Chrome is a very simplistic browser (not even a print preview) and it remains to be seen if its competitive edge in terms of rendering and javascript speed will hold true when it’s got other things to worry about (i.e. plugins).

Safari 4 is a combination of the WebKit rendering engine (like Chrome) and JavaScriptCore, which is the umbrella project name for WebKit javascript engine. While the SquirrelFish engine in Safari 3.1 was fast (doing the JIT bytecode compiling that Firefox 3.5 is doing now…), the new SquirrelFish Extreme engine actually compiles to native machine code. It pulls respectable performance across all tests, usually ranking just behind Chrome…. with the notable exception of the Peacekeeper benchmark, where it takes the lead score. Unfortunately for Safari, its greatest accomplish with version 4 is only managing to not look completely horrible on other platforms, so needless to say it isn’t going to be a contender for the Win32 crown anytime soon.

How far Opera has fallen from grace. Whereas a couple of years ago it sported the fastest rendering, some of the greatest features, and a great javascript stack, it was quickly eclipsed by the flurry of development happening in other browsers recently. The beta of version 10.00 improves javascript performance significantly, although Opera’s own efforts toward bytecode-based javascript handling aren’t scheduled to land until well after 10.00.

Internet Explorer is, well, still Internet Explorer. While version 8 is a remarkable improvement over version 7, just as 7 was a spectacular improvement over 6, it is still the last shriveled pickle at the bottom of the jar, limping by in each and every benchmark. Microsoft, in their latest FUD to paint IE8 as a wunder-browser, correctly point out that javascript speed isn’t everything, but both benchmark and simple user testing are enough to point out that Microsoft’s browser team is working hard just to stay in the race; they’re not gaining ground at all.

It’s been close to two years since I wrote GNOME Audio Player Shootout, a visual and textual comparison of some the best available audio players for the GNOME desktop.

As is usually the case in the world of free software, a lot has happened since then (and yet, in a strange way, things have stayed exactly the same). I decided to revisit some of those players and see how they’ve progressed. Some of them listed last time haven’t seen any appreciable development, and have been left off.

I realize that I am totally ignoring the daemon-based players (read: Music Player Daemon, XMMS2); this is by design, since those players open up a whole new can of worms. Suffice it to say that if you’ve decided on and XMMS2 or MPD-based player and successfully configured it, you probably don’t need any advice on choosing software.

The following programs will be covered in this review (development versions):

• BMPx (0.40.14)
• Rhythmbox (0.11.6)
• Exaile (2.99.1-svn)
• Banshee (1.4.1)
• Quod Libet (2.0)
• Decibel (1.00)
• Songbird (1.0)
• Listen (0.6~svn1044)

All of the testing was done on a fresh install (and update) of Ubuntu 8.10 in VirtualBox, using a small representative sample of my music collection (some modern, some classical, in Vorbis, MP3, and FLAC).

I personally think the friendly rivalry between the open-source Webkit engine (which powers Safari, among other things) and Mozilla (the Gecko engine, actually) is one of the best things to happen to browser development in years. The constant one-upsmanship can only lead to better browsers. Well, Internet Explorer will constantly be the limiting factor, but we can dream, can’t we?

The latest thing to hit browser source repos is javascript engine improvement based on something called “trace trees”: essentially, javascript gets translated into native bytecode. The Webkit engine made the announcement a few months ago, with code codenamed “Squirrelfish,” promising massive improvements. That article’s also got a pretty good writeup.

Open Source being what it is, it was only a matter of time before Mozilla announced their own version of a trace-tree-based javascript engine. John Resig has a good writeup, as done Brendan Eich.

So, disregarding for a moment all talk of trace trees and JIT, what the hell does this all mean? I am entirely in agreement with Jeff Atwood about the importance of javascript in the contemporary web. Whether you’re using rich sites like Netflix or GMail, or you’re working with Flash files, or you’re getting into the RIA arena with Flex or similar technologies, you’re essentially relying on javascript and javascript engines to get anything done. Good HTML specs get the browsing experience much of the way there, but a truly compelling web technology relies on client-side scripting. Even in the last 3 or 4 years, javascript has gone from superfluous UI tricks to the heart and soul of the user’s end of a web experience. It’s a bit unfortunate, really, since javascript (properly “ECMAScript”) is an old technology that’s single-threaded and doesn’t scale very well. That browser-makers have managed to squeeze this much performance out of it is a testament to geek creativity.

There’s been a lot of reason to switch away from Internet Explorer in the last few years. Microsoft made big steps with IE7 to improvement performance, rendering quality, and security, but Internet Explorer is still the bastard child of the browser world, dog-ass slow compared to its brethren. If the difference between user experience in the javascript-heavy web becomes so great that a Webkit browser or a Gecko browser or Opera provides an entirely different level of satisfaction, then maybe we’ll finally see a real shift in browser usage.

Mozilla, particularly, is posed to reap some real reward. These JIT trace tree improvements will start showing up in 3.1 (I think), and much more so with the new Tamarin engine schedule for Firefox 4. The only viable Webkit browser in Windows, meanwhile, is Safari, which looks and feels alien in Windows, as Apple has a strange insistence upon keep the OSX look, regardless of platform. I don’t know offhand the market slice that Safari for Windows occupies, but it must be infinitesimally small, even compared to Safari on Mac. Firefox, then, is the only truly compelling browser on the Windows platform to take advantage of this right now.

About 2 years ago I wrote a piece called Five things that Desktop Linux really needs, attempting to air out my five biggest grievances with Desktop Linux. If you follow FOSS news, every year is heralded as “The Year of the Linux Desktop,” although such a thing clearly hasn’t happened yet. Now, two years later, I thought it would be interesting to revisit those five problems and see what kind of progress has been made in two years.

Linux needs a good CD ripper

When I last wrote, the favorite CD ripper for the GNOME environment was grip, which had the benefit of being extremely customizable, even if its ripping was plain-Jane cdparanoia. Grip is still used, I imagine, but the default ripper with the GNOME desktop is Sound Juicer, which is a gstreamer-based ripper/encoder that abstracts everything quite heavily and gives damn few options.

The good news is that the semi-abandoned cdparanoia project at least saw a maintenance release that fixed some bugs; the bad news is that the promised further revisions have failed to materialize, meaning that there’s still no compelling cd ripper available for Linux. The Exact Audio Copys and the dBpoweramps remain Windows-only tools.

Also in these past two years, however, a new ripper has emerged: RubyRipper, a Ruby/GTK2 program that tries to emulate EAC’s approach to ripping; that is, it reads segments multiple times and compares them using Ruby’s checksum matcher. While there are some audiophiles at HydrogenAudio who insist that this isn’t a perfect approach to ripping (of course it isn’t), it’s still far more than any of the desktop-standard rippers can come up with. Ideally, it will eventually feature AccurateRip support, though this is tentative.

So, I’m happy to report that some progress has been made in this area, though Linux is still a second-class citizen when it comes to CD ripping.

Linux needs good and consistent font rendering

You wouldn’t think it, compared to issues like multimedia codecs, but font rendering is awash in legal issues. Be it Apple’s patent for BCI (byte code interpreter) or Microsoft’s patent on TrueType (both of which are legally dubious), it’s legal threats and not technical problems that keep the default font smoother for most distros from producing nice, clean, antialiased fonts. The code already exists in the upstream source code for TrueType, but it’s disabled by default. Ubuntu finally made the decision to enable it by default in their distribution, for which I applaud them. Packages exist for many other distributions, which is still a damn sight better than the typical “compile it yourself” response, which always strikes me as utterly absurd.

In my previous post, I highlighted the discrepancy between various types of programs in Linux when it comes to font rendering. I can say without hesitation that the situation has improved since then, though I’m not entirely sure where the responsibility for the fixes lie.

What you see is my blog in Firefox 3.0, some source code in Netbeans 6.1, and the template picker in OpenOffice 2.4. Notice that the font rendering is pretty similar in all three of them. I can tell you that Netbeans looks that good because I’m running it with the Java 6 JDK, which finally added decent font antialiasing. Running it with Java 5 produces some pretty obnoxious font quality. As to OpenOffice, they either fixed font rendering on their end, or else OpenOffice benefits from the larger system font smoothing included in Ubuntu.

Linux needs better inter-distro compatibility and less dependence on repositories

My choice of Linux is Ubuntu; this decision is spurred largely by some æsthetic choices, and the truly orgasmic package management system. If it were not for this, I might very well be running OpenSUSE, which has greatly improved its package management with v11.0. One of OpenSUSE’s more compelling features is that they’re more willing (and the community is more willing) to add new software to the repositories. It’s significantly easier for me to get the latest and greatest software for openSUSE, often by dint of either Pacman’s wonderful repository or the openSUSE build service, which Ubuntu has responded to with the Personal Package Archive (read: build service).

The one benefit of the Ubuntu’s approach is that packages tend to play nicely with each other, whereas with openSUSE and it’s build service, there are sometimes overlapping dependencies.

But there are still a bunch of different package types and packages managers; even among package types, there are incompatible versions. And because of the shared nature of Linux libraries, each distribution’s release will likely have a narrow slice of software versions that will work for that particular library. Say what you will about the Windows approach, but when I install the latest FileZilla on Windows, I don’t get bitched at by my system for needing newer wxWidgets libraries (and therefore necessitating that I either compile my own version or wait 6 month until somebody does it for me). Similarly, installing new graphics drivers doesn’t mean I have to also set up the latest kernel headers and reconfiguring my display configuration file so that it doesn’t fail spectacularly when I reboot.

Initiatives like LSB, FreeDesktop, and PackageKit have made bold steps to make Linux play well with itself. But there’s no middle ground with Linux: you either let distributions do all the work for you, and limit yourself to the particular software, and the particular versions, that they feel like offering you, or you can do everything yourself, compiling and installing your software manually.

Linux needs better multimedia

OK, multimedia on Linux still sucks, and it still sucks hard. Even providing that you’ve enabled extra (legally dubious) repositories for your installation and downloaded all of the plugins and codecs that are available to you (after, of course, you’ve decided to use either GStreamer or Xine as a video engine), you still have the unfortunate issues of video in Linux being slower and of an inferior quality to video on Windows. Is there a reason that rendering with Totem-GStreamer is blocky and awful, and rendering with The KMPlayer is picture-perfect? Even xine is far from perfect.

Then there’s the age-old problem of the X server and the graphics stack on Linux being shit to begin with. Compiz is great, and I’ve spent a fair amount of time watching my windows wobble and painting fire on my screen, but is there a reason that emulators perform so much worse in Linux? Is there a reason that I can’t switch tabs in Firefox with a several-second delay before the page contents are written to the screen? Is there a reason that the X server breaks at the slightest provocation? Is there a reason that the graphics stack offers so little to developers when compared to DirectX on Windows? Is there a reason that all the good-looking audio players on Linux can’t offer me anywhere near the same functionality that foobar2000 does on Windows?

I see individual programs making great progress, but there are fundamental flaws in the Linux approach to multimedia that aren’t going to be solved no matter how many widgets we give our apps. Multimedia on Linux still has a long way to go.

Linux needs disk image mounters

I’m pleased to report that since I last talked about this issue, there have been a couple of programs written to provide just this functionality. Programs like Daemon Tools or Alcohol 52% on Windows provide a way to mount virtual copies of CD or DVD images, allowing the computer to interact with them as though they were physical discs sitting in the drive.

On Gnome, there’s the Furius ISO Mount; on KDE, there’s AcetoneISO, which is also gaining burning support a la Alcohol 120%. Both of these programs function pretty much exactly how you would expect them to. Of the five issues I highlighted last time, this appears to be the most completely resolved; unfortunately, it was also the least important of the issues, and has gotten even less important to me personally since my previous writeup.

Conclusion

My biggest problem is that although the open source community continues to produce extremely compelling software, it suffers from the same fundamental flaws it did years ago: its X server and graphics layer are slow and difficult to work with, which is why you’ll find much better software emulators, games, and video playback on Windows than you will on Linux; its distro-centric repositories are both a boon to the end-user and a version lock-in that eliminates the “Go to the vendor site and download an .exe” ease of Windows. Linux is still a “Do It Yourself” operating system, meaning that despite all of the work being done, there’s not necessarily a complete and versatile environment for developers to program against. Certainly, there isn’t a consistent environment, and things are constantly changing in the world of Linux.

My hypothesis, before performing the tests, was that the 64-bit compilation would have little or no effect on the Javascript engine performance. It’s so difficult to optimize Javascript rendering, which is inherently single-threaded, and it seems likely to only benefit from a faster CPU clock than bigger memory registers. Afterward, I felt vindicated: Internet Explorer is likely the best test, and the difference was not statistically significant. In Firefox’s case, the 64-bit build was actually significantly worse, though this could easily be due to some other factor I have not taken into account; I have assumed that the source was compiled on the same date. See below for more details.

The Data Tables

The Raw Data

Internet Explorer x86 7.0.6001.18000
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  21972.4ms +/- 6.2%
--------------------------------------------

  3d:                    1233.0ms +/- 1.1%
    cube:                 346.6ms +/- 4.7%
    morph:                415.2ms +/- 2.7%
    raytrace:             471.2ms +/- 1.9%

  access:                1834.6ms +/- 2.5%
    binary-trees:         443.0ms +/- 3.9%
    fannkuch:             739.4ms +/- 1.5%
    nbody:                346.4ms +/- 7.3%
    nsieve:               305.8ms +/- 5.8%

  bitops:                1610.0ms +/- 3.7%
    3bit-bits-in-byte:    409.0ms +/- 2.0%
    bits-in-byte:         405.4ms +/- 4.8%
    bitwise-and:          446.2ms +/- 5.0%
    nsieve-bits:          349.4ms +/- 6.3%

  controlflow:            493.0ms +/- 2.2%
    recursive:            493.0ms +/- 2.2%

  crypto:                1051.4ms +/- 4.6%
    aes:                  374.2ms +/- 5.2%
    md5:                  330.8ms +/- 4.9%
    sha1:                 346.4ms +/- 6.2%

  date:                   873.6ms +/- 2.3%
    format-tofte:         433.6ms +/- 2.0%
    format-xparb:         440.0ms +/- 3.7%

  math:                  1186.0ms +/- 1.6%
    cordic:               465.0ms +/- 4.6%
    partial-sums:         327.6ms +/- 0.2%
    spectral-norm:        393.4ms +/- 4.1%

  regexp:                 387.0ms +/- 4.2%
    dna:                  387.0ms +/- 4.2%

  string:               13303.8ms +/- 10.4%
    base64:              7298.0ms +/- 6.8%
    fasta:                464.6ms +/- 3.5%
    tagcloud:            1391.4ms +/- 4.0%
    unpack-code:          461.8ms +/- 3.7%
    validate-input:      3688.0ms +/- 25.4%

Internet Explorer x64
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  19955.4ms +/- 1.2%
--------------------------------------------

  3d:                     938.6ms +/- 2.3%
    cube:                 262.0ms +/- 6.2%
    morph:                311.8ms +/- 6.3%
    raytrace:             364.8ms +/- 2.9%

  access:                1450.6ms +/- 2.8%
    binary-trees:         321.2ms +/- 3.3%
    fannkuch:             586.6ms +/- 3.7%
    nbody:                258.6ms +/- 6.6%
    nsieve:               284.2ms +/- 3.1%

  bitops:                1154.0ms +/- 1.7%
    3bit-bits-in-byte:    290.0ms +/- 3.7%
    bits-in-byte:         290.0ms +/- 7.6%
    bitwise-and:          284.0ms +/- 5.8%
    nsieve-bits:          290.0ms +/- 6.0%

  controlflow:            349.4ms +/- 3.0%
    recursive:            349.4ms +/- 3.0%

  crypto:                 786.2ms +/- 2.8%
    aes:                  296.4ms +/- 4.6%
    md5:                  243.2ms +/- 7.1%
    sha1:                 246.6ms +/- 10.3%

  date:                   664.6ms +/- 6.0%
    format-tofte:         315.0ms +/- 11.6%
    format-xparb:         349.6ms +/- 3.1%

  math:                   845.6ms +/- 2.5%
    cordic:               340.0ms +/- 2.5%
    partial-sums:         228.0ms +/- 4.5%
    spectral-norm:        277.6ms +/- 6.0%

  regexp:                 302.6ms +/- 3.5%
    dna:                  302.6ms +/- 3.5%

  string:               13463.8ms +/- 1.4%
    base64:              8527.2ms +/- 0.9%
    fasta:                334.2ms +/- 5.2%
    tagcloud:            1145.0ms +/- 2.6%
    unpack-code:          346.6ms +/- 6.2%
    validate-input:      3110.8ms +/- 2.4%

Firefox x86 Firefox 3.0b5pre (20080322 nightly)
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 3750.2ms +/- 1.4%
--------------------------------------------

  3d:                   432.8ms +/- 9.8%
    cube:               147.2ms +/- 17.4%
    morph:              137.8ms +/- 1.2%
    raytrace:           147.8ms +/- 22.7%

  access:               598.8ms +/- 2.1%
    binary-trees:        60.6ms +/- 5.5%
    fannkuch:           261.6ms +/- 1.7%
    nbody:              173.2ms +/- 6.0%
    nsieve:             103.4ms +/- 1.4%

  bitops:               493.6ms +/- 5.4%
    3bit-bits-in-byte:   85.6ms +/- 2.2%
    bits-in-byte:       123.0ms +/- 6.4%
    bitwise-and:        136.4ms +/- 11.9%
    nsieve-bits:        148.6ms +/- 9.2%

  controlflow:           57.0ms +/- 3.1%
    recursive:           57.0ms +/- 3.1%

  crypto:               271.4ms +/- 7.3%
    aes:                105.0ms +/- 19.4%
    md5:                 78.4ms +/- 3.8%
    sha1:                88.0ms +/- 2.0%

  date:                 331.4ms +/- 12.3%
    format-tofte:       202.2ms +/- 16.2%
    format-xparb:       129.2ms +/- 8.3%

  math:                 432.2ms +/- 3.9%
    cordic:             186.2ms +/- 7.6%
    partial-sums:       149.2ms +/- 7.0%
    spectral-norm:       96.8ms +/- 1.4%

  regexp:               255.6ms +/- 8.3%
    dna:                255.6ms +/- 8.3%

  string:               877.4ms +/- 4.7%
    base64:             119.2ms +/- 6.0%
    fasta:              205.2ms +/- 10.4%
    tagcloud:           152.2ms +/- 6.2%
    unpack-code:        272.8ms +/- 4.1%
    validate-input:     128.0ms +/- 10.3%

Firefox x64
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  7421.4ms +/- 1.2%
--------------------------------------------

  3d:                    807.8ms +/- 2.0%
    cube:                312.6ms +/- 3.5%
    morph:               230.8ms +/- 7.8%
    raytrace:            264.4ms +/- 6.5%

  access:               1135.0ms +/- 1.9%
    binary-trees:        126.6ms +/- 11.7%
    fannkuch:            540.6ms +/- 2.3%
    nbody:               282.8ms +/- 2.9%
    nsieve:              185.0ms +/- 10.4%

  bitops:               1040.8ms +/- 2.3%
    3bit-bits-in-byte:   213.6ms +/- 5.8%
    bits-in-byte:        271.0ms +/- 4.5%
    bitwise-and:         246.2ms +/- 6.8%
    nsieve-bits:         310.0ms +/- 6.1%

  controlflow:           140.8ms +/- 6.6%
    recursive:           140.8ms +/- 6.6%

  crypto:                533.8ms +/- 4.3%
    aes:                 195.0ms +/- 5.8%
    md5:                 175.2ms +/- 11.5%
    sha1:                163.6ms +/- 3.5%

  date:                  664.6ms +/- 4.5%
    format-tofte:        406.4ms +/- 4.6%
    format-xparb:        258.2ms +/- 6.3%

  math:                  818.8ms +/- 3.8%
    cordic:              367.4ms +/- 3.2%
    partial-sums:        257.2ms +/- 10.5%
    spectral-norm:       194.2ms +/- 4.9%

  regexp:                652.8ms +/- 2.7%
    dna:                 652.8ms +/- 2.7%

  string:               1627.0ms +/- 3.1%
    base64:              220.6ms +/- 4.7%
    fasta:               388.8ms +/- 4.4%
    tagcloud:            294.8ms +/- 5.2%
    unpack-code:         489.4ms +/- 2.9%
    validate-input:      233.4ms +/- 11.1%

Continuing the tradition of my previous post about Safari, I thought I would revisit Firefox’s performance on the SunSpider benchmark.

Clearly, Firefox has also made drastic strides in its Javascript engine, which is an entirely new piece donated by Adobe (and is the same engine, or so I understand, which powers the Actionscript interpreter of Flash). These results put the new Firefox 3 beta at four times the speed of the latest 2.x series. The newly released Safari/Webkit build narrowly outperforms the latest test build of Firefox, but clearly there’s a lot of progress being made (and perhaps more before its final release).

The tests were done on a Windows XP SP2 machine; it has a Pentium 4 and 2GB of RAM.

Firefox 2.0.0.12
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 23493.8ms +/- 6.3%
--------------------------------------------

  3d:                   2865.8ms +/- 1.3%
    cube:                812.6ms +/- 3.0%
    morph:              1562.2ms +/- 2.0%
    raytrace:            491.0ms +/- 4.5%

  access:               1874.4ms +/- 3.0%
    binary-trees:        243.6ms +/- 14.6%
    fannkuch:            571.8ms +/- 1.8%
    nbody:               721.6ms +/- 2.2%
    nsieve:              337.4ms +/- 3.2%

  bitops:               4709.2ms +/- 1.3%
    3bit-bits-in-byte:   362.4ms +/- 7.0%
    bits-in-byte:        381.2ms +/- 2.8%
    bitwise-and:        3406.2ms +/- 0.9%
    nsieve-bits:         559.4ms +/- 1.5%

  controlflow:           153.2ms +/- 13.9%
    recursive:           153.2ms +/- 13.9%

  crypto:               1150.0ms +/- 2.8%
    aes:                 356.2ms +/- 6.0%
    md5:                 393.8ms +/- 5.3%
    sha1:                400.0ms +/- 5.5%

  date:                 4769.0ms +/- 0.9%
    format-tofte:       1294.0ms +/- 1.3%
    format-xparb:       3475.0ms +/- 1.0%

  math:                 1868.8ms +/- 3.0%
    cordic:              940.8ms +/- 4.8%
    partial-sums:        546.6ms +/- 2.4%
    spectral-norm:       381.4ms +/- 8.5%

  regexp:               1400.4ms +/- 81.1%
    dna:                1400.4ms +/- 81.1%

  string:               4703.0ms +/- 9.4%
    base64:              928.2ms +/- 2.3%
    fasta:               640.8ms +/- 3.1%
    tagcloud:           1025.0ms +/- 46.6%
    unpack-code:        1512.2ms +/- 10.5%
    validate-input:      596.8ms +/- 6.7%

Firefox 3.0b4
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  6102.8ms +/- 2.3%
--------------------------------------------

  3d:                    842.0ms +/- 4.8%
    cube:                301.0ms +/- 5.3%
    morph:               245.8ms +/- 1.7%
    raytrace:            295.2ms +/- 10.5%

  access:                910.4ms +/- 2.9%
    binary-trees:         95.6ms +/- 2.4%
    fannkuch:            412.2ms +/- 5.6%
    nbody:               282.2ms +/- 3.2%
    nsieve:              120.4ms +/- 8.5%

  bitops:                782.2ms +/- 5.8%
    3bit-bits-in-byte:   120.4ms +/- 22.1%
    bits-in-byte:        143.0ms +/- 21.1%
    bitwise-and:         267.2ms +/- 4.3%
    nsieve-bits:         251.6ms +/- 3.1%

  controlflow:            89.0ms +/- 1.7%
    recursive:            89.0ms +/- 1.7%

  crypto:                500.8ms +/- 5.5%
    aes:                 148.8ms +/- 17.2%
    md5:                 171.4ms +/- 2.0%
    sha1:                180.6ms +/- 1.9%

  date:                  560.0ms +/- 4.2%
    format-tofte:        329.6ms +/- 6.8%
    format-xparb:        230.4ms +/- 2.1%

  math:                  815.2ms +/- 5.5%
    cordic:              321.0ms +/- 1.1%
    partial-sums:        310.4ms +/- 9.2%
    spectral-norm:       183.8ms +/- 16.1%

  regexp:                295.6ms +/- 6.4%
    dna:                 295.6ms +/- 6.4%

  string:               1307.6ms +/- 3.7%
    base64:              157.8ms +/- 16.5%
    fasta:               280.0ms +/- 9.8%
    tagcloud:            249.6ms +/- 3.9%
    unpack-code:         412.2ms +/- 7.9%
    validate-input:      208.0ms +/- 4.5%

The world of Javascript is an interesting one right now; it seems like most major browsers are on the eve of a major new release, many with new (& improved JS engines). With WebKit’s porting to Windows in Safari (and eventually Konqueror, I imagine), yet another player has thrown his hat into the arena. Javascript is, as Jeff rightly says, the lingua franca of the web: everything is javascript-[based|dependent] today, and rich interfaces are now the norm, rather than a pleasant surprise.

As a web applications developer, I’ve banged by head against javascript and various and sundry browser implementations at work, and worried about performances, both now and in the future. Standardizing on a common library (cf. jQuery) helps, although the performance or functionality of jQuery plugins don’t always match those of home-grown counterparts. For instance, Brian McAllister’s Unobtrusive Table Sort Script far outpaces the popular TableSorter script for jQuery. I ended up implementing the latter at work, simply because of the sheer size of tables we render, and the relative slow speed of many of ours users’ browsers.

Due to time constraints, I hadn’t gotten around to performing my own benchmark until today. I don’t have any fancy (or controversial) graphs like Jeff, but here’s the data anyway, followed by the raw result text. The first table is high-level summaries listing only the sum times for groups of test. The second table lists all the tests.

Somewhat to my surprise, the much-touted improvements to Firefox 3′s javascript engine weren’t consistent across the board. In some cases, it performed worse than 2.0.0.11. The clear winner was Opera’s upcoming 9.5 release (codenamed ‘Kestrel’), followed closely by Apple’s port of the WebKit engine. With respect to the latter, it’s clear that the WebKit/KHTML engine is a good one, though I look forward to an inevitable Konqueror port, since Safari on Windows is just about the ugliest interface I’ve ever seen.

The Results

SunSpider 0.9 Benchmarks
Performed on 15 January 2007
Ben Gunnink | http://heliologue.com/

- Intel Q6600 Quad-Core
- Windows XP SP2 32-bit
- 4GB RAM

All browsers were tested with extensions and plugins disabled.

Firefox 2.0.0.11

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 14032.0ms +/- 2.4%
--------------------------------------------

  3d:                   1909.0ms +/- 4.1%
    cube:                531.4ms +/- 7.6%
    morph:              1078.0ms +/- 3.6%
    raytrace:            299.6ms +/- 10.8%

  access:               1275.0ms +/- 2.3%
    binary-trees:        140.6ms +/- 9.7%
    fannkuch:            422.0ms +/- 0.0%
    nbody:               484.6ms +/- 2.8%
    nsieve:              227.8ms +/- 4.6%

  bitops:               3340.6ms +/- 0.9%
    3bit-bits-in-byte:   253.2ms +/- 3.5%
    bits-in-byte:        256.4ms +/- 4.2%
    bitwise-and:        2459.4ms +/- 0.7%
    nsieve-bits:         371.6ms +/- 4.4%

  controlflow:            94.0ms +/- 0.0%
    recursive:            94.0ms +/- 0.0%

  crypto:                694.4ms +/- 5.2%
    aes:                 215.6ms +/- 7.7%
    md5:                 244.2ms +/- 7.0%
    sha1:                234.6ms +/- 6.0%

  date:                 2049.8ms +/- 0.4%
    format-tofte:        693.8ms +/- 3.1%
    format-xparb:       1356.0ms +/- 1.2%

  math:                 1281.8ms +/- 10.7%
    cordic:              665.8ms +/- 17.3%
    partial-sums:        375.2ms +/- 3.6%
    spectral-norm:       240.8ms +/- 9.2%

  regexp:                784.2ms +/- 5.4%
    dna:                 784.2ms +/- 5.4%

  string:               2603.2ms +/- 7.1%
    base64:              565.8ms +/- 3.8%
    fasta:               415.6ms +/- 4.3%
    tagcloud:            512.4ms +/- 34.7%
    unpack-code:         718.8ms +/- 7.9%
    validate-input:      390.6ms +/- 8.7%

Firefox 3.0.0 beta 2

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 11195.2ms +/- 5.9%
--------------------------------------------

  3d:                   1821.2ms +/- 5.4%
    cube:                543.6ms +/- 12.5%
    morph:               921.8ms +/- 2.2%
    raytrace:            355.8ms +/- 11.9%

  access:               1632.4ms +/- 8.6%
    binary-trees:        160.6ms +/- 34.5%
    fannkuch:            629.2ms +/- 8.5%
    nbody:               568.4ms +/- 6.2%
    nsieve:              274.2ms +/- 13.1%

  bitops:               1759.0ms +/- 6.6%
    3bit-bits-in-byte:   280.8ms +/- 12.8%
    bits-in-byte:        286.0ms +/- 8.8%
    bitwise-and:         808.0ms +/- 5.1%
    nsieve-bits:         384.2ms +/- 9.8%

  controlflow:            93.4ms +/- 27.3%
    recursive:            93.4ms +/- 27.3%

  crypto:                615.6ms +/- 3.2%
    aes:                 276.0ms +/- 6.3%
    md5:                 166.6ms +/- 6.2%
    sha1:                173.0ms +/- 5.5%

  date:                  628.2ms +/- 4.4%
    format-tofte:        409.4ms +/- 3.7%
    format-xparb:        218.8ms +/- 8.1%

  math:                 1121.8ms +/- 3.8%
    cordic:              527.6ms +/- 3.8%
    partial-sums:        383.8ms +/- 4.0%
    spectral-norm:       210.4ms +/- 6.4%

  regexp:                947.0ms +/- 57.3%
    dna:                 947.0ms +/- 57.3%

  string:               2576.6ms +/- 14.3%
    base64:              466.4ms +/- 5.7%
    fasta:               443.2ms +/- 10.0%
    tagcloud:            396.8ms +/- 10.0%
    unpack-code:         942.0ms +/- 35.9%
    validate-input:      328.2ms +/- 8.9%

Internet Explorer 7.0.5730.13

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  26676.8ms +/- 0.8%
--------------------------------------------

  3d:                    1212.8ms +/- 2.4%
    cube:                 334.6ms +/- 5.3%
    morph:                412.4ms +/- 2.6%
    raytrace:             465.8ms +/- 1.8%

  access:                1731.6ms +/- 1.0%
    binary-trees:         409.4ms +/- 2.1%
    fannkuch:             687.6ms +/- 0.1%
    nbody:                343.8ms +/- 0.2%
    nsieve:               290.8ms +/- 3.6%

  bitops:                1552.8ms +/- 1.7%
    3bit-bits-in-byte:    368.8ms +/- 2.9%
    bits-in-byte:         387.2ms +/- 2.2%
    bitwise-and:          450.2ms +/- 1.9%
    nsieve-bits:          346.6ms +/- 2.7%

  controlflow:            447.0ms +/- 2.4%
    recursive:            447.0ms +/- 2.4%

  crypto:                 934.4ms +/- 0.9%
    aes:                  343.6ms +/- 0.2%
    md5:                  297.0ms +/- 0.0%
    sha1:                 293.8ms +/- 3.0%

  date:                   796.6ms +/- 2.9%
    format-tofte:         390.4ms +/- 3.5%
    format-xparb:         406.2ms +/- 3.4%

  math:                  1075.6ms +/- 0.9%
    cordic:               453.6ms +/- 0.2%
    partial-sums:         281.2ms +/- 0.2%
    spectral-norm:        340.8ms +/- 2.6%

  regexp:                 350.0ms +/- 5.0%
    dna:                  350.0ms +/- 5.0%

  string:               18576.0ms +/- 0.9%
    base64:              9212.6ms +/- 0.4%
    fasta:                438.0ms +/- 0.0%
    tagcloud:            1740.6ms +/- 5.7%
    unpack-code:          453.2ms +/- 0.1%
    validate-input:      6731.6ms +/- 1.2%

Safari 3.04 beta

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  8583.4ms +/- 1.7%
--------------------------------------------

  3d:                   1184.4ms +/- 4.6%
    cube:                353.0ms +/- 3.1%
    morph:               490.6ms +/- 5.2%
    raytrace:            340.8ms +/- 6.4%

  access:               1668.2ms +/- 2.5%
    binary-trees:        143.4ms +/- 6.1%
    fannkuch:            703.2ms +/- 0.1%
    nbody:               331.2ms +/- 2.5%
    nsieve:              490.4ms +/- 7.7%

  bitops:               1465.0ms +/- 2.0%
    3bit-bits-in-byte:   302.8ms +/- 5.8%
    bits-in-byte:        387.2ms +/- 2.2%
    bitwise-and:         303.0ms +/- 3.6%
    nsieve-bits:         472.0ms +/- 1.9%

  controlflow:           212.4ms +/- 5.0%
    recursive:           212.4ms +/- 5.0%

  crypto:                815.8ms +/- 3.1%
    aes:                 218.6ms +/- 10.9%
    md5:                 297.0ms +/- 0.0%
    sha1:                300.2ms +/- 3.0%

  date:                  621.8ms +/- 3.5%
    format-tofte:        259.4ms +/- 4.1%
    format-xparb:        362.4ms +/- 4.6%

  math:                 1012.4ms +/- 1.6%
    cordic:              559.4ms +/- 1.5%
    partial-sums:        228.0ms +/- 5.0%
    spectral-norm:       225.0ms +/- 5.0%

  regexp:                337.6ms +/- 3.2%
    dna:                 337.6ms +/- 3.2%

  string:               1265.8ms +/- 2.2%
    base64:              300.0ms +/- 2.8%
    fasta:               297.0ms +/- 4.7%
    tagcloud:            237.6ms +/- 6.8%
    unpack-code:         193.8ms +/- 5.4%
    validate-input:      237.4ms +/- 3.7%

Opera 9.5 beta 1 (build 9613)

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  6501.0ms +/- 1.2%
--------------------------------------------

  3d:                    572.0ms +/- 2.9%
    cube:                162.8ms +/- 6.4%
    morph:               231.2ms +/- 3.7%
    raytrace:            178.0ms +/- 5.7%

  access:                775.4ms +/- 2.8%
    binary-trees:         50.0ms +/- 16.7%
    fannkuch:            365.8ms +/- 2.9%
    nbody:               197.0ms +/- 5.5%
    nsieve:              162.6ms +/- 6.6%

  bitops:                803.2ms +/- 5.6%
    3bit-bits-in-byte:    65.6ms +/- 13.2%
    bits-in-byte:         97.0ms +/- 8.6%
    bitwise-and:         425.0ms +/- 6.0%
    nsieve-bits:         215.6ms +/- 4.1%

  controlflow:            65.6ms +/- 14.2%
    recursive:            65.6ms +/- 14.2%

  crypto:                319.0ms +/- 7.0%
    aes:                 153.0ms +/- 5.9%
    md5:                  81.4ms +/- 10.8%
    sha1:                 84.6ms +/- 12.6%

  date:                  734.2ms +/- 1.9%
    format-tofte:        272.0ms +/- 4.0%
    format-xparb:        462.2ms +/- 3.7%

  math:                  456.0ms +/- 3.4%
    cordic:              197.0ms +/- 5.5%
    partial-sums:        171.8ms +/- 0.3%
    spectral-norm:        87.2ms +/- 12.0%

  regexp:                747.0ms +/- 2.2%
    dna:                 747.0ms +/- 2.2%

  string:               2028.6ms +/- 2.9%
    base64:              140.8ms +/- 10.0%
    fasta:               390.6ms +/- 6.1%
    tagcloud:            365.8ms +/- 8.0%
    unpack-code:         965.6ms +/- 1.7%
    validate-input:      165.8ms +/- 6.4%

As I said in a previous comment, the problem with having content about a new theme is that it won’t be relevant when the theme goes away or changes. So this post is to both exhibit and archive this theme so that there is some record of it.

Hooloovoo

toggle thumbnails

It’s a different creature than I’m used to—I’ve never not had a sidebar, but I decided that perhaps a sidebar wasn’t the best way to do things. I moved that sort of ancillary data to the top, but I used a pull-down menu á la Foliage mod. Since sidebar data tends to not be particularly important to the content anyway, it doesn’t need to take up real estate.

Metadata, while displayed more or less inline on the index page, is moved down into a content footer on the individual post pages. This kind of graphical metaphor is actually very common now, but I’ve wanted to do it ever since I saw it in Hemingway about a year and a half ago. Like the upper menu, I’m dividing into thirds, and iterating with lists.

In general, I’ve tried to round off a lot of corners. This involves more images than I’d normally like, but I’ve tried to take shortcuts wherever possible, combining multiple images and simply changing their positioning: I managed to reduce the number of server requests significantly from the early phases of the design, but I still have some more to go.

Which brings me to another thing: I’ve used some 24-bit PNGs, not only as icons but as background images as well. I made a half-hearted attempt to use ifixpng to resolve display issues for IE6, but when it didn’t work satisfactorily, I decided that I spend enough timer catering to IE6 users and work, and I’ll be damned if I’m going to expend any extra effort on my hobby site. So let me make myself clear:

Attention IE6 users: there is no good excuse to be using IE6. Either upgrade or use a different browser. Firefox is good, as is Opera. Or go away.

On with the tour: I’ve heavily incorporated the jQuery javascript library into my redesign, and attempted to make it as performance-tuned as possible by including the extra plugins in a common file, and gzipping everything on the fly.

Beyond that, the theme is pretty unremarkable, really, but (I hope) aesthetically-pleasing and useful. I’ve completely removed categories from the template, since I think that tags have much more utility.

Comments? Questions? Suggestions? Venom?

That’s what Brent Roos’ tagline asks. I’ll answer you: he’s a troll with an inflated sense of his own importance. Think I’m being a little harsh? Maybe, but read on, and maybe it’ll take only his first few sentences to sway you.

My Ubuntu machine totally crashed –motherboard and all! I was able to save the memory and cd-r/rw drives. Besides that it is a total loss. In a related story, my brother also had a similar experience, although not nearly as severe. What does this mean? Hello XP! That’s right. I’m back on Windows. I think Ubuntu has something to do with these crashes, since both mine and my brother’s were similar, and we were both running Ubuntu. Or, it could be a total coincidence, but I doubt it.

Where to even start?

There are a lot of different parts in a system. Roos claims to have only saved his system memory and optical drive, which means that his motherboard, his hard drives, any peripheral cards (if he had them), his processor, and anything else he might have conceivably had in his box is apparently broken beyond repair. Think about the kind of catastrophe it would take to kill almost everything in a computer box. What comes to mind? Lightning? Water? Dropping the damn thing while moving it? Did “Using a reliable piece of software used by millions of computer enthusiasts and network managers throughout the world” ever come to mind as in the list of possibilities? Roos admits that it may be a coincidence that both he and his brother experience hardware failures and they both used Ubuntu, but he doubts it. Why is that, Brent? Did Miss Cleo tell you otherwise?

But what I really love is why Brent thinks Ubuntu is to blame, and I will blockquote it just to highlight the inanity.

I think Ubuntu was over-stressing my hardware.

Let that sink in for a bit. Then consider that Roos claims to be a computer expert, with years of experience using both Windows and Linux. Now, I don’t care about Ubuntu, per se: it’s my distribution of choice, but I understand that it’s not for everybody. But, when Roos says “Ubuntu,” he really means “Linux,” as though Linux is still some alpha-quality piece of software notorious for crashing system and frying hardware—if you doubt for even a second the depths of Roos’ idiocy, consider that he also seems to think that Windows XP is not only a wonderful operating system, but completely stable as well (because he’s never had a hardware failure in the five years he used XP! Conclusive, rock-solid proof!).

So, certainly Roos overestimates his technical knowledge (he has two degrees, he says, which I think reflects rather poorly on his alma mater) and his capacity to make qualified judgement. That fulfills the latter part of my initial statement. But why do I think Roos is a troll, rather than a simpleton? Because in announcing to the world that he is switching from Ubuntu back to Windows XP, he also takes considerable time to let loose some old, tired canards about Windows v. Linux, and just about have an orgasm singing the praises of that which is Windows, while at the same time of course villifying Linux as though it had killed his firstborn child instead of (ostensibly) his hardware. So, here we go:

There are some in the Ubuntu forums, but not many, who can be considered professionals –as far as having any official credentials of being a professional in the computer field. I happen to be one of those people with official degrees and certifications.

Certifications don’t mean anything—just because Roos got his silly A+ cert, or an MS cert., doesn’t mean he knows anything important when it comes to computers. If he did, he might know better than to say things like “I think Ubuntu was over-stressing my hardware.”

It is my professional opinion that Ubuntu is not even close to as polished of an operating system as Microsoft Windows XP. Not even close, especially for new users. The Linux desktop will never be what the fanboys want it to be, because of companies like Microsoft –who make better software. Sorry.

Perhaps in other parts of the world this may not be the case. However, in America, we prefer to use the best –which happens to be Microsoft.

I think it’s clear that Ubuntu has plenty of polish—it and Novell’s SLED are probably the two most polished Linux distributions there are. What Linux in general still doesn’t have is comparable third-party driver support (for certain things like Wifi or Gfx cards). Linux is also very user-friendly, but it depends on how deeply you need to delve into the system. As I’ve noted before, mid-level users are stuck between knowing exactly what they are doing, and not needing or being able to do anything.

Furthermore, what do differing countries have to do with anything? I don’t know if Roos is aware, but both Microsoft and Linux are available globally. And what the hell does “[I]n America, we prefer to use the best” mean? Some vague attempt at turning the issue into one of nationalism? But notice that Roos conflates “ubiquity” with “quality.” Here in America Brent, as in most of the rest of the world, people tend to use what’s popular, not what’s best. Just like the Billboard Top 40 isn’t a good indicator of the best music being made, neither is Windows being the dominant operating system any indication of its quality. I noticed that Roos uses Firefox and Flock—doesn’t he know that Microsoft’s browser, Internet Explorer 6, must be a better piece of software?

The fanboys complain about insecurity with Windows. This is another myth. With an anti-virus, a firewall software (or preferably a router), an anti-spyware software, and a decent HOST file, it is very easy to keep a Windows system very clean and secure. All of this software will cost you nothing. It is all free.

First, calling Linux proponents “fanboys” is textbook trolling. Secondly, Windows insecurity isn’t a myth, and to say “Windows isn’t insecure! After you install this, this, this, and this, it’s perfectly secure!” Sorry, Brent, but that means that your firewall, antivirus, and antispyware apps are secure—and Windows isn’t. Your logic is that 5=7 because 5+2=7. It doesn’t work that way.

Even though Windows is despised by many (who coincidentally hate capitalism), I have never had any single sort of hardware issues with the OS.

Ah, the old Linux=Communist canard. Serious, Brent: are you for real? Could you possibly be any more of a flailing caricature?

I can’t even go on—Roos pumps out a steady stream of horseshit for another 10+ paragraphs. Here are some highlights, which I think can stand without comment.

• I happen to find Windows to be much more stable than any Linux distro.
• I think [Windws is] great, and so does the vast majority of the rest of the world.
• [S]ince [Ubuntu] you killed two computers that I know of, I must terminate [it]
• Windows is by far a superior desktop/office operating system, by leaps and bounds.
• I have a lot of experience with many OSes, and software. The bottom-line is that Microsoft rocks.
• Most commercial apps are commercial for a reason. Most free apps are free for a reason.
• Yes, FOSS is great, and it helps standards, and all, but –standards are truly set by the products which offer the most productivity. [...] There is a reason for .doc and .xls being the standard format. Everyone uses MS Office formats, because MS Office is the best Office software[.]
• The software built for Microsoft Windows is the best.
• To say that Linux holds up to Windows, in terms of productivity, is an absolute joke!
• You shouldn’t have to tweak your operating system, just to have functionality. Sure Windows takes a few tweaks, but they are very simple, and uncomplicated.
• By the way, why do so many people hate Microsoft? I have never understood this.

I just don’t have the strength to talk about all of these. Let the idiocy speak for itself. If you’re truly that dumb, Brent Roos, then by all means enjoy Windows XP: you two deserve each other.

Let no one say that Linux hasn’t been making drastic leaps forward in the usability race. Things have been happening at breakneck pace, with full-featured, user-friendly distributions like Ubuntu and OpenSuse making big eyecandied splashes in the OS world. I personally have been running OpenSuse 10.1 lately with Xgl and Compiz, and besides a few problems with programs not officially supported, it’s been a smooth ride.

And yet, each time I spend any sort of time in a Linux desktop—that is, a long enough time that I invariably find myself faced with tasks that I’m used to doing in Windows—I cannot help but notice some rather glaring shortfalls that plague Linux qua Desktop OS. So, without further ado, I shall highlight what I perceive to be some of the most enormous deficits facing Linux as a force on the desktop.

1. All the best audio encoders are open-source, but Linux doesn’t have a good ripping engine

The de facto standard for CD ripping is Exact Audio Copy, a freeware utility that is truly excellent at making bit-perfect extractions from optical disks. A quick glance at Hydrogen Audio reveals that audio enthusiasts really use nothing else. But EAC doesn’t work on Linux—sadly, it’s still a closed-source project and will remain so for the foreseeable future.

On Linux, the choices are less robust. My personal favorite, grip, is an old standard, but despite its customizable interface (don’t even get me started on the gstreamer-based Sound Juicer, which is godawful), its ripping engine is cdparanoia, a library that hasn’t seen any significant updates since 2001—the Trac for Xiph reveals mostly spam and the occasional bugfix or ticket for one of the many projects hosted there. If cdparanoia was as good as EAC, there’d be no problem, but unfortunately it tends to create errors on cached audio data, and so trying to rip scratched or otherwise challenging CDs will likely frustrate most users. When I talk about Linux needing to be pervasive on the desktop, Joe Q. User probably won’t care about it because he or she currently uses something stupid like Windows Media Player anyway, but there’s a dedicated legion of audiophiles or reasonably well-informed people who want good rips.

You may be thinking, “What a wanker! Just run it with Wine!” And that is the standard response, and I know that it is possible to do so. But there are a number of problems with that approach.

Wine currently has no GUI. If Desktop Linux is ever going to succeed, the average user should never need a command line. Even assuming that EAC was emulated perfectly and beautifully, it’s ridiculous to expect that someone will run winecfg and then wine /path/to/EAC.exe.

EAC often has difficulty seeing optical drives when it’s run with wine. Ideally, the user running wine would be part of the ‘cdrom’ group and would be given access appropriately. In my case, even when I change ownerships of the optical drives to myself, EAC comes up blank.

If the recent ballyhoo over proprietary video drivers has shown us anything, it’s that being beholden to closed or proprietary code is a bad, bad thing. It makes distribution impossible, it makes support difficult, and user results will vary. Hence, even in a pie-in-the-sky scenario where EAC could be emulated perfectly, it would still be better for the FOSS world to have access to a top-of-the-line extraction library upon which to build good-looking GUIs.

2. Linux has the capacity for excellent-looking fonts, but the end result is inconsistent and often terrible

Apple’s OS X may win hands-down when it comes to nice-looking fonts, but by now it should be obvious that the Linux Desktop should be more than capable of doing some nice anti-aliasing for screen fonts. Windows introduced Cleartype in 2001, and it hasn’t changed much since then—even Vista doesn’t appear to build very much upon Cleartype’s abilities, despite a lot of work on Typography for Microsoft’s upcoming software families.

For the most part, both the Gnome and KDE desktops have been incorporating font smoothing, but the success depends on a number of things, not the least of which is the font being smoothed, as well as the program itself. Take the following partial screenshot [click for a larger version], for instance, which is OpenOffice’s document creation dialogue next to my blog displayed in Mozilla Firefox.

Notice the disparity? OpenOffice doesn’t use the same font-smoothing as anything else, but instead relies on its own internal algorithms to do so…. and they suck. Java is a culprit, too, but inconsistently: Azureus looks fantastic, but Groupwise 7 looks like hell.

If fonts are handled differently by N number of engines, then there’s no way for the user to get a consistent UI experience. If Linux hopes to catch emigrants from Windows, it needs to make itself as visually appealing as OS X, and right now it’s not doing that.

3. A wide choice of distributions is good, but crippling incompatibility and limited availability is not

I’m currently running openSUSE 10.1, which is an RPM-based distribution. Abou likes Ubuntu, which is deb-based. Fedora Core is also RPM-based, but Fedora Core packages are generally not compatible with Suse systems. Even Ubuntu, which is based upon Debian, can’t always share packages with its parent distribution.

The bigger distributions try very hard to have all the packages that their users will ever need conveniently located in their packages repositories (except for patent-encumbered packages, which can generally be found in semi-official repositories run by interested third parties). But a given distribution’s staff is only so large, and can only handle so many packages. If I want to use the latest beta of Gaim v2, I can look on the SourceForge page and find a number of RPMs for Fedora Core and Mandrake releases, none of which are compatible with Suse. In order to run Gaim v2, I had to check out the latest code from the project’s SVN, install some development packages, and compile it myself. Good enough for me, maybe, but no way to win any hearts and minds, given that in Windows it’s as easy as downloading an executable and running it.

What’s more, turnaround time can be slow for updated packages. Mozilla Firefox 1.5.0.5, for instance, came out a week ago, but has yet to appear in the updates. I can get it from a separate Mozilla repo on the Suse server, but it would otherwise not get pushed to me. And I consider Suse to be better about such things (except that Gnome 2.14 might not ever be available to 10.1 users)—other distributions are not, especially when it comes to major version jumps. Until Dapper Drake came out in June, Breezy users were stuck with the 1.0.x series of Firefox, because Ubuntu very strictly draws lines between release versions.

I know that some effort has been made to make various distributions play nice with each other. The Linux Standard Base project has attempted to unify some of the framework, but this is a bone tossed to network admins and corporate customers—it has nothing to do with allowing users to install arbitrary programs without waiting for them to appear repositories or compiling them from source.

4. Even with third-party repos, video and audio support across the desktop is less-than-exemplary and not at all consistent

With the usual repos enabled in openSUSE 10.1, my major options for video playback are Xine (the program xine-ui), Kaffeine, gxine, VLC, MPlayer, and Totem. For the record, all of these except VLC and MPlayer use the Xine engine. What’s more, every single on of them has a plugin that purports to play video within a browser—to date, not a single one has worked successfully except for Totem ((When I say “successfully,” I mean it in the sense of actually playing within the browser. The Kaffeine plugin just launches the external player for embedded media. MPlayer actually tried to play embedded media, but always futzed out while supposedly “buffering.”

But even though Xine is a great little engine for many many things, it’s far from perfect, as evidence by the awful rendering job it does on Quicktime movies at Apple’s trailer site [screenshot at left]. And Totem, while a decent player, lacks the power and customization that Kaffeine and VLC and MPlayer offer.

I say all this, of course, assuming that the required repositories are already enabled. You see, the non-crippled version of xine-lib required to even play more popular formats, or the entire programs of VLC and MPlayer, are all patent-encumbered and have to be specially enabled.

But as bad as video might be, I think audio is in an even worse situation for Desktop Linux.

To be sure, there are a number of wonderful audio programs, but sadly the ways to power said programs are fragmented and don’t play well. There are three primary media engines.

1. GStreamer • This is a favorite of the Gnome people, and in theory, it’s wonderful: it’s a modularized framework that supports not just playback of video and audio, but its manipulation as well: you can use it to power CD burners, media editors, and jukeboxes alike. The problem is that its API/ABI is constantly changing, and its usage in distributions is lukewarm. For SuSE, the available files don’t allow for the playback of things like MP3s, even though the the ‘gstreamer-plugins-bad’ package should take care of legally-questionable playback. It doesn’t. The gstreamer guys don’t like people using anything else, but I fail to see the incentive to use a product that no one can get to work correctly.
2. Xine • You may remember this from earlier in the article. It not only plays video pretty well, but audio as well, and it currently powers my Amarok and my gxine. I cannot, however, get it to be used by any of the Gnome-integrated apps that use gstreamer, and that’s a pity.
3. Helix • The Helix framework is a newer engine on the scene, but fairly advanced in its capabilities. RealNetworks uses it to power RealPlayer for Linux, and the Real version has support for MP3 and the like.

Banshee, a new audio player written for Mono, supports gstreamer or Helix. Amarok, the ever-popular KDE application, supports Xine or gstreamer (but everyone always chooses Xine). Rhythmbox, the default music player for Gnome, is gstreamer-only. XMMS is a perennial favorite, and doesn’t use any multimedia framework, and neither does its offspring, Audacious. Beep Media Player and its successor, bmpx, use gstreamer. Of course, you can always use many video apps to play sound, but they don’t offer the music-specific features that the listed players do.

So, as with many things, Linux offers a variety of feature-rich programs which are powered by a few crippled engines, and none of which do everything that the user needs them to do. Certainly, a hindrance to adoption if there ever was one.

5. Linux needs a reliable way to mount virtual images besides ISOs

One of my most-used tools in Windows is Daemon Tools, a virtual CD/DVD-Rom that allows one to mount disk images as if they were physical copies of those disks. The result is transparent to applications. Granted, this is most helpful for games, but I can imagine a wide variety of scenarios where it would come in handy in Linxu—especially if more and more games keep coming out for the platform.

This trick is possible after a fashion, but only for ISO files, and only via the command line, by entering

mount -o loop -t iso9660 filename.iso /mnt/iso

which mounts the image as a loopback device, but without any handy shell integration or support for bin/cue, nrg, or other file types.

It would also be nice if applications like K3B had a way to write to image files like most Win32 apps do—it’s a tool I’ve used many a time to make sure that my compilations turn out OK. It’s not a big deal, but it’s one of those little things that one gets used to in Windows that has no substantially analogous counterpart in FOSS, and once you lose it, you miss it.