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 options1.
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.
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.
- This same complaint can be leveled at just about every product under the GNOME umbrella; that’s what you get for trying to out-Apple Apple[↩]