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 supported1, 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
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 families2.
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 18.104.22.168, for instance, came out a week ago, but has yet to appear in the updates3. 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.
- 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.
- 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.
- 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.
- ClamTk, which I pulled from Guru’s repo, doesn’t seem to want to launch, complaining about a missing object method in
Gtk2::Window. From what little I could find, there seems to be a changed API in the latest gtk2/glib that may have something to do with it.[↩]
- For more on this, see my post “A font of fonts“[↩]
- This may be in part because a 22.214.171.124 update is coming down the pipes pretty soon to fix a showstopper regression related to streaming media[↩]