Fixing Linux: What's Broken And What To Do About ItFixing Linux: What's Broken And What To Do About It

Despite the fact that it's been around since 1991, Linux remains a work in progress. It's not perfect, nor does anyone pretend it is. The places where it needs the most immediate improvement are also a matter of debate: what's crucially important to some is only marginally important to others.

Still, there's no question that there are key areas where Linux is lacking -- not just missing individual features, but things that are actively dysfunctional and which need immediate attention. I'm going to run down several major areas where Linux, as an operating system and as a platform, needs work.

The software that goes into a Linux distribution is dealt with in chunks called "packages" -- whole applications, support libraries for apps, programmer's tools, and so on. Firefox and OpenOffice.org, for instance, are present in most every Linux distribution's software repository as package sets.

Package Management

The way packages are managed within any individual distribution is entirely up to the maintainers of that distribution. Red Hat uses its own RPM system, the Debian distributions have their own .DEB format; and so on. Within the context of any one distribution, this isn't a problem: if you're using only Red Hat or Debian, odds are you obtain the software you need from that distribution's repository and are done with it.

This is one of the many fragmentation problems that makes it difficult for commercial software vendors to offer their products for Linux. No one package format will do the trick across distributions -- not without hassle, anyway.

To that end, potential program vendors have three choices: 1) devote time and effort -- and money -- to ensuring that their program installs, runs, and stays cohesive on a variety of distributions (maybe just Red Hat, Ubuntu, and SUSE to keep things simple); 2) make their programs available in a given distro's repositories; or 3) provide source-code packages so that the user can compile the code on any target platform.

Option #3 is pretty much out of the question for any proprietary software vendor. #1 multiplies the amount of work involved to get any given program out the door -- not to a degree that makes it wholly unfeasible, but it does add more work. That leaves #2, which has the advantage of making applications immediately available to the user of any given distribution, and cuts down on the amount of work needed by an end user to get something installed.

Because the demand for commercial apps on Linux is relatively slender right now, the problem isn't as pronounced: most people just get their offerings from their local repository. In the long run, though, if commercial apps take root on Linux, it will become that much bigger an obstacle to making Linux a platform for same, especially where downloading apps freely from the Web is concerned. One thing that might help is a kind of meta-package format: a file which, when downloaded, is run by a client native to the given distribution. The client then goes to the software repositories for the program maker and obtains all the right packages to make that program run on that particular machine. The folks at BitRock have something vaguely like this, where you can package a given open source application in such a way that it will run natively across multiple platforms, Linux included.

Another major way this is being addressed is through the Linux Standards Base. In order to be LSB-compliant, a Linux distribution must either use Red Hat's RPM natively or have support for RPM. Given that the most popular distribution out there right now is Ubuntu -- a Debian-derived distribution that doesn't have much support for RPM -- there's been criticism that the LSB is "too Red Hat-centric" for this to work.

Configuration Files

Any given Linux distribution is an agglomeration of components from thousands of different programmers, projects, and architectural initiatives. To that end, there's little or no centralized configuration: everything in the system is controlled through a welter of files, and there's no guarantee that the syntax of any one configuration file will apply to any other.

The problem is not as pronounced if you limit your exposure to only a few files and follow their internal formatting, but that's not a sustainable solution. A lot of this is due to retention of compatibility with legacy UNIX applications. One of the worst offenders has been sendmail, whose configuration files traditionally reached new lows of complexity and obscurity.

There needs to be a consistent -- and whenever possible, self-documenting -- configuration system throughout, from the kernel to userland tools and user applications. Aside from making it easier for the user (and the programmer) to deal with, it might also simplify central administration issues.

Dictating something like that by fiat is probably impossible; a better approach would be to popularize the use of a toolset that makes it easy for applications to have a unified configuration approach. The GNOME project's Gconf is a good example of this sort of thing; even if the current iteration is intended for user preferences rather than system-wide configuration options, it's still a good real-world example for how to create such a thing.

Kernel Application Binary Interfaces

If there is one complaint that comes up more often than any other about developing for Linux, it is the way the kernel application binary interfaces are a moving target.

The Linux kernel has been designed from the perspective that what's inside the kernel can change, but what's available to user applications through the ABIs cannot and must not break. The problem is not only philosophical, but also practical: the sheer breadth of kernel interfaces means it's entirely possible for something to break (or "regress") in a way that might not even show up in a fairly rigorous code review.

To that end, when something does break, it creates two problems: it means the exact source of the problem is sometimes a matter of argument (i.e., is this a kernel issue or a user-application issue?), and time and effort is lost in the process of fixing it.

There are a few ways to work around the problem in the short term. One of the most immediate and promising workarounds for certain projects is FUSE -- short for "Filesystem in Userspace" -- which allows file systems, normally the domain of the kernel, to be set up in the same space where user applications run. In the long run, though, Linux needs an ABI set that's not only stable but capable of handling long-term growth without becoming a rat's nest of potential compatibility issues. Native File Versioning

Native file versioning is another feature that can be added to Linux distributions, but does not yet exist by default. The concept is simple: an earlier iteration of a file can be produced on demand in case the current version is overwritten, damaged, or sabotaged. Windows users have this in the form of shadow copies, but no default incarnation yet exists in the standard-issue Linux file systems (e.g., ext2/3/4). It's obviously not intended as a substitute for file backups, but the ability to roll back a file to a given point in time as a default piece of functionality isn't a frivolity.

It is possible to add this functionality to a Linux distribution after the fact. That said, the different projects that provide this each use a slightly different implementation: Wayback, ext3cow, copyfs, Tux3, and so on. Having a standard, "kernel-approved" methodology for versioning would provide a solid base on which to build and branch out, although a good argument can be made for providing these features as a non-kernel add-on.

I should also add that future iterations of the Linux file system (probably the forthcoming BTRFS) are intended to do all this and more -- but for now, there's no one direct solution that can serve as a starting point.

Audio Application Programming Interfaces

Look no further than Linux's implementations, plural, of audio for an example of how too many cooks can spoil the broth. The diversity of audio APIs and subsystems means that, yes, you can pick and choose one that suits your needs best -- but it also means a rat's nest of incompatibilities.

The kernel-level audio API, ALSA, is where most everything begins, but there are others -- primarily PulseAudio (used mainly to mix audio from multiple applications) and JACK (for pro-audio, low-latency settings). And then there are a slew of other audio tools for developers -- Gstreamer, PortAudio, and so on. Don Marti, at the Linux Plumber's conference in September, wrote a good summary of how conflicted and confusing the whole issue is. The quote that sums it up best: "If someone comes and says, 'I want to write an audio application. Which API should I use?' I don't have a good answer." (This fellow does, to some degree, but the fact that the whole jungle exists at all is depressing.)

In short, the audio API issue affects programmers more than end users. That said, everything that affects programmers also affects end users in the long run. PulseAudio is probably the best general-purpose solution and has enjoyed wide adoption. But in the long run, what's needed is a single kernel-up approach to audio that does not require use-case analysis on the part of an application developer. Graphical User Interface

With the kernel, there's little if any doubt about who's in charge: Linus and the kernel developers. With the Linux desktop -- maybe better to say free and open source software, or FOSS, desktop -- it's far more anarchic.

Before I go any further, let me define my terms. "Desktop" doesn't just refer to "whatever GUI conveniences make Linux/FOSS easier for non-technical users," but rather a graphical user interface that makes using and managing the system all the easier no matter what your level of technical expertise.

This is not a matter of integrating the GUI completely with the system; no one is foolish enough to advocate that. Part of the problem is that kernel and desktop development in Linux took place in a highly parallelized fashion, and it was a one-way street to boot. There was no guarantee the kernel developers would implement features useful to desktop developers, but desktop devs had to hew to whatever happened in the kernel if it affected them.

To that end, what's needed is a single steering committee for all GUIs that work on Linux, so that whatever GUIs are created -- be they GNOME, KDE, or not-yet-invented -- will have a consistency of implementation on the backend, and make it possible to have tight integration of features with the kernel, a la BeOS. The kernel would publish a generic series of hooks that a GUI could make use of, and the GUI would be free to represent them to the user in any number of ways.

Another important thing Linux needs is clearer guidelines for how to implement default behaviors on the desktop, which requires people with UI design experience to make decisions that have lasting weight. This isn't about "dumbing down" the UI: what's often needed is not simpler controls, but better default handling of those controls so that the user does not have to make endless adjustments to achieve something comfortable.

Integration Of X11 With Apps

Most people who have used Linux for some time have probably encountered this problem: an X11 application, or the whole of X11 itself, freezes, and the only way to get things back is to kill and restart X11. The good news: it isn't hard to do that. The bad news: killing X11 means every other X11 application, problematic or not, dies along with it.

What would be useful is the option to have applications running under X killed along with it, so that if X needs to be killed and restarted, you don't wind up losing your entire user session. Failing this, it would also be useful to have a window-manager API that allows for the easy storing and resuming of a session in the event of a crash -- something that does happen on an app-by-app basis (Firefox, for instance, does this), but which would be useful to have available in a global implementation. Commercially Hosted Backup And Restore

If Linux will continue to draw regular PC users away from Windows, it'll need to have many of the same features as Windows. That includes for-pay network services that require Linux clients, such as remote backup.

Windows and Mac users have endless choices: the native file- and system-level backup and restore tools in both OSes are also complemented by a slew of commercial backup solutions. Services like Mozy and Carbonite perform silent, encrypted differential backups to a remote host, so a user's data is protected consistently and stored off site. But neither of those services offer Linux clients (at least, not yet).

A Linux user who wants to perform offsite backups generally has to resort to using a native Linux application (such as the Simple Backup Suite in Ubuntu) to back up to a remote server that isn't specifically for data protection. There's no shortage of Linux backup clients that can speak to a remote server, like the Simple Backup Suite that's available in Ubuntu, but again, integration with a commercial backup provider for regular users is what's missing.

One very likely possibility is that as things become that much less platform-centric, the idea of needing a platform-specific client to perform robust backups (not just data, but whole system states) may become as quaint as, say, only being able to access specific Web sites with specific types of Web browsers. The other, more likely possibility, is that full-state backup services dedicated to supporting Linux clients will step up.

Conclusions

Most of what's wrong with Linux isn't fatal: if it was, Linux would scarcely have achieved the degree of adoption it now enjoys (with the general exception of consumer computing). But there's little question these problems need to be fixed, and that doing so may require some challenges to the conventional Linux way of doing things and defending the results.