What Linux needs is an operating system by Jesse Smith
Anyone who has spent any significant amount of time in the Linux community has heard the questions raised: “Why are there so many distributions? Why can’t the various projects get together and make one unified distribution?” Of course this is never going to happen, nor should it. One of the greatest benefits of open source software is that it gives people the ability to use their computers the way they wish to and modify their systems to work they way they want. This has given the Linux community a great degree of flexibility, letting it run anywhere, from extremely low-resource systems to super computers, from stable servers to cutting-edge desktops to niche administration tools like Clonezilla and KNOPPIX. The ideal of one unified distribution sounds nice to newcomers overwhelmed by choice and to third-party developers, but it won’t fly in a community where freedom, empowerment and flexibility are priorities. One might as well ask why the human race has so many languages when having one would seem so much more simple.
Another phrase that comes up frequently on technical forums is “Linux is a kernel, not an operating system,” and this is true. Linux, on its own, is a kernel. That kernel gets combined with various other pieces of software, usually the GNU userland tools, a package manager and a desktop environment in order to make a Linux (or GNU/Linux) distribution. And herein lies the real issue for newcomers to the Linux scene and for developers: each Linux distribution is, in effect, a separate operating system. Software built and packaged for one distribution often will not run on another, even if the two projects are closely related. This leads us to some ridiculous situations where not only will software packaged for Ubuntu not necessarily work on Fedora, but software built for Linux Mint's main edition may not work properly on Linux Mint Debian edition. It can be increasingly frustrating for developers and packagers because sometimes software which builds and runs fine on a handful of the major distributions will not even compile on another due to library incompatibilities. So, what is the solution?
A number of ideas have been put forward over the years. Merging distributions, which as already mentioned, isn’t practical (or perhaps even desirable). In days past lip service was given to standards by which all major distributions might be guided. However, if we look at the list of certified distributions conforming to the Linux Standards Base we find that very few distributions follow it and those which do often aren’t up to speed — either they are on an older version of the standard or only older versions of the distribution were certified. Why didn’t the Linux Standards Base catch on? I think it comes down to one simple fact: the Linux community follows working examples, not abstract designs. A person can put forward a design for the most robust video stack or the most flexible sound system or the most elegant packaging system, but the Linux community is interested in working examples, what is mostly functioning, now.
So now we’re faced with the question of what might be a unifying solution if abstract standards aren’t the answer and neither is trimming down the number of distributions? I think the Linux community might find its answer in the FreeBSD ecosystem. Looking at the FreeBSD project we find that, unlike Linux, FreeBSD is a complete, functioning operating system featuring a kernel, userland tools and package management. FreeBSD is a small OS on its own, but it can be expanded using a huge collection of packages, packages which are configured in such as way that they should work across multiple versions of the FreeBSD operating system. One practical way in which this separates FreeBSD from the various Linux distributions is projects based on FreeBSD share a lowest common denominator.
There are a number of derivative projects based on FreeBSD, including PC-BSD, GhostBSD, FreeNAS and DesktopBSD. What is interesting about these derivative projects is that, in sharing the FreeBSD base, they are mostly compatible. A program compiled and packaged for FreeBSD will work on GhostBSD. A program built on GhostBSD should likewise work on PC-BSD. This is because, despite their many differences, including separate installers, different desktop environments and different package management front-ends, they share a common foundation. Compare this scenario with FreeBSD to the situation we face with, say, Debian in the Linux community. A package built for Debian’s latest Stable release isn’t necessarily going to work on Ubuntu. A package designed to run on Ubuntu may or may not work on aptosid, despite the fact both Ubuntu and aptosid are derived from the Debian project.
The Linux community could greatly benefit from a common operating system. Not achieved by a merging of distributions, but rather by pulling a common base into each separate distribution. Right now most Linux distributions build and package their own version of the kernel, their own version of the compiler and of the GNU utilities and they are supplying their own low-level package manager. Having one central, minimal base with these key components would be of huge benefit to the Linux community. It would reduce duplication of effort, allowing each distribution to use the same base, it would reduce the need for building packages in multiple formats, it would help to insure software compiled on one distribution could be installed and run on another and it would provide a standard lowest common denominator without relying on an abstract third-party to write the standard. Furthermore, this approach does not limit the creativity and diversity of the Linux ecosystem as most distributions are, almost exclusively, using similar GNU/Linux bases, just with slightly different versions of software and configurations.
Each week I install a different GNU/Linux operating system and, while each one is different, most of them are using the same version of the Linux kernel, most of them are packaging similar versions of the GNU Compiler Collection and similar versions of the C library. Yet these distributions are rarely compatible in a practical sense. Meanwhile, when I venture into the FreeBSD community, I find they are using a common foundation of software and users are therefore able to trade software packages, scripts and configurations with a reasonable level of assurance their software will work on the various derivative projects. I hope we someday have that level of “interconnectedness” with Linux distributions. The flexibility we enjoy is empowering and wonderful, but to date it has come with the heavy price of fragmentation. The FreeBSD community is currently enjoying an expansion by way of new designs and is discovering more corners into which to grow without the same level of fragmentation and I think we, in the Linux community, should pay attention to what the FreeBSD community is doing right.
What Linux needs is an operating system by Jesse Smith