What Is a Free Operating System Release?
Originally published on LiveJournal, 3.12.08
The next version of the free Ubuntu operating system, code-named “Hardy Heron,” is coming up next month, and I’m excited about the good stuff that’ll be coming my way. Canonical, the company behind Ubuntu, has committed to a pretty rigorous schedule of releasing every six months, which is one of the things that make Ubuntu stand out among free operating systems. Windows and Mac OS users have to wait years for new releases, and sometimes it ends in horror (Vista) or just a yawn (Leopard). The way free software is accelerating, every Ubuntu release contains something cool and useful, and plenty of bug fixes and security patches.
There’s something else going on here, too. Ubuntu, like most free operating systems, is package-based. This brilliant architecture means that the whole operating system, including everything “inside” and the applications you run “on top,” is made of packages. Want to install OpenOffice? Add the OpenOffice package. Support for MP3? Add that. The Linux kernel itself is a package, and not a particularly big one at that. You add packages from an online repository, with just a few clicks, and the operating system makes sure to check this repository occasionally, and let you know if there are any newer versions of any of the packages you have installed. The whole “download and run the installer” process in Windows, which exists to an extent in Mac OS, only very rarely happens in Ubuntu.
With this in mind, it doesn’t make much sense to have an operating system “release.” Why not just improve one package at a time, and have the operating system continuously released? This is, in fact, what happens. However, there is a boiling point beyond which this becomes a nightmare for testers, and packages are frozen. That’s right: releases for package-based operating systems are not about software development, as they are for Windows and Mac OS; they are all about quality assurance.
Packages exist in an ecosystem: they depend on each other. For example, there’s a package called Pango which arranges text, intelligently handling various languages and mixing them in paragraphs. Both Firefox and OpenOffice depend on Pango. So, when a new version of Pango comes out, they both benefit. This is OK until at some point an improvement in Pango is incompatible, in some ways, with the old Pango. So, if we get the new Pango package, both Firefox and OpenOffice might stop working. While it’s possible to have both versions of Pango packages together (and this type of solution is used in some cases), this creates a testing nightmare. You would have to test every single package that depends on Pango (there are hundreds) to see whether it would work with the new version or the old. And meanwhile, all the developers of these packages will be scrambling to release newer versions that support the new Pango. You’ll be constantly testing. At some point, you have to draw the line and say that the new Pango, and all packages that depend on it, will have to be tested together.
That’s actually a simple case. A lot of these packages have very complex inter-dependencies.
A “release” schedule thus allows the repository maintainers time to test a certain baseline of packages, carefully selected ahead of time for having a good change of passing tests. “Too new” packages are often rejected, asked to wait for the next release. Because this is only six months in Ubuntu, as opposed to years, the delay is acceptable (although still a cause for fiery debate for those clamoring for the latest and greatest).
And so, though my current Ubuntu (Gutsy Gibbon) has been continuously updating itself over the past six months, Hardy Heron will introduce a whole new baseline of packages. It’s one big update, all at once. That’s exciting.