Linus recently stated that Linux is "bloated and huge," but what does that really mean? He is, of course, talking about the code in the kernel itself, rather than the wider implementation as a desktop. Even so, does this really need fixing, and is it even possible?
Linus Torvalds, as we well know, is no stranger to controversial comments and his latest is sure to be quoted (and misquoted) for decades to come.
Speaking at LinuxCon 2009 Torvalds was asked whether features were being rushed too quickly into the kernel. This prompted Linus to admit that, “The kernel is huge and bloated.” He also stated that there are no current plans to address the problem.
No one would argue with Linus on the status and well being of the kernel, but it’s so easy to take “bloated” out of context. How does it compare to the Windows or BSD kernels? He’s not saying that the kernel is bad or inefficient, just that it’s not as neat and clean as it perhaps could, or should be.
Of course the kernel is huge, that’s what happens when more and more features are added at such a rapid pace. Parts have also been constantly developed over a long period of time, which can introduce issues. No doubt there is also bound to be lots of horrible code. Despite the criticism however, Linus also added that developers are fixing bugs very quickly and that the development of the kernel is working better and is more streamlined than ever before. So is it all doom and gloom?
Developers, Developers, Developers!
The current Linux kernel has over eleven and a half million lines of code. With each release more and more code is introduced which of course leads to new bugs. In fact, for the recent 2.6.30 kernel over twenty thousand lines were either added to, deleted or modified. Given the fact that a new kernel is released about every twelve weeks, that’s an amazing effort.
So how does the kernel manage to increase by this amount and still remain stable? Well it’s due in part to the open source development model. Certain maintainers control specific components of the kernel, such as SCSI or networking. Each maintainer is responsible for their part of the kernel and accepts patches from developers. Each patch is audited and so the quality of all these little changes is assured. Linus himself merges less than 3% of the patches for a new release, the rest come by way of these maintainers.
A publication by the Linux Foundation which reports on the development of the kernel states: “Since 2005, over 5000 individual developers from nearly 500 different companies have contributed to the kernel,” having doubled in the last three years.
Over one thousand one hundred developers contributed directly to the 2.6.30 kernel. So while the amount of code entering into the kernel has dramatically increased, so has the number of developers working on the project.
While the total number of lines of code has almost doubled between versions 2.6.11 (6,624,076) and 2.6.30 (11,560,971), the number of developers working on the release has increased by a factor of three. This shows that the number of developers has been scaling well compared with the amount of code increase. Of course, the number of lines is not necessarily an accurate measure of work.
As the Linux Foundation says in their report: “The ability to sustain this rate of change for years is unprecedented in any previous public software project. The Linux kernel keeps growing in size over time as more hardware is supported and new features are added.”
Actually, it’s a testament to the open source development model that Linux has remained so stable whilst introducing so many new features and drivers.
So while the kernel itself may be getting more and more bloated and badly in need of a trim, the community and development model surrounding it means that Linux is well placed to handle and required changes. There’s always room for improvement and while there may be no diet plan at the moment, that doesn’t mean one cannot be arranged down the track. If any project has the resources to do on a massive scale, it’s the kernel.
From a technical and engineering perspective, the kernel may be far from perfect. It is simply getting bigger and bigger as it adopts support for more and more technology. That’s only logical. Sure, it’s not the streamlined hyper-efficient kernel Linus may have envisioned fifteen years ago, but does that really matter? It does work, and it works very well.
Linux ≠ Linux
Does this mean that Linux is bloated compared to other operating systems? Well, no. Linus is talking specifically about the Linux kernel, not the wider implementation of the operating system (sometimes called GNU/Linux).
The Linux kernel is modular by design and allows users to build a unique and completely custom kernel, including whichever components they desire. This is exactly what distributions do for the users. Not only do they make these decisions, they also protect the user from buggy and potentially dangerous components in the kernel should they go undetected during testing. Companies like Red Hat are able to test the kernel and feed fixes upstream for the benefit of everyone.
Linux comes in all sorts of shapes and sizes. It runs on the fastest clusters in the world, as well as the tiniest micro computers. Even within the desktop sector the range of available distributions is enormous. Some are designed for older machines with minimal resources, while others offer the latest and greatest on modern hardware. The operating system itself can include a more heavyweight desktop like GNOME and KDE, something lighter like LXDE or Enlightenment, or even no desktop at all.
When Linux says that “Linux” is bloated and huge, he’s referring to the code within the kernel itself. Certainly, this does have a huge impact on the overall operating system because the kernel is a central component, but as the kernel improves so does the desktop. In the mean time Linux is still able to compete with the best.
The Magic Diet Pill
So how will this weighty issue be overcome?
Linus stated that there is currently no plan to fix the bloat issues within the kernel, but that doesn’t mean one can’t be worked out soon. The kernel has a massive development force behind it. Obviously the bloat has not yet gotten to the point where it simply must be fixed, else it would have already begun.
Over the last few years we have seen some major core changes to the kernel, such as the new scheduler and a replacement for the libata subsystem. These sorts of things are major operations and have the potential to dramatically increase the number of bugs. They do however, show that major re-factoring within the kernel is possible, so long as there’s some motivation to do it.
Currently there are just so many new features coming in, that more development time is spent implementing them and squashing bugs. That doesn’t necessarily leave much room for cleaning up the kernel.
As the famous adage goes, “Given enough eyeballs, all bugs are shallow.” Linus’ job is already much easier than it used to be thanks to the new development system, so perhaps the solution is to scale up the development team with more developers? Either way, certainly those close to the kernel will be able to make some wise decisions on how to proceed. It has to happen at some point, so perhaps now is a good time to begin.
A Little Perspective
While the state of the Linux kernel obviously plays a big part in the quality of Linux distributions, distros are able to trim down the kernel and focus on the most common components. They can also help to play a larger role in fixing issues within the kernel.
Theoretically, with enough people working on the kernel all problems can be resolved. Thanks to the move to Git, development on the Linux kernel is more streamlined than ever, but perhaps some further enhancements still need to be made down the track.
Even though the Linux kernel is getting bigger and weightier, it is probably in the best position of any other to manage this issue. As its popularity and more widespread adoption increases, so do the number of developers available to help. Perhaps the kernel does need a major overhaul, one piece at a time.
Amidst all of this, let’s remember that Linus is talking about the kernel itself which supports more hardware out of the box than any other in history. Indeed, even with all that bloat Linux can run on anything – yes even a dead badger.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62