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.