Apparently, Linus himself has come out and said that Linux is getting bloated and huge.

“We’re getting bloated and huge. Yes, it’s a problem,” said Torvalds.

Asked what the community is doing to solve this, he balked. “Uh, I’d love to say we have a plan,” Torvalds replied to applause and chuckles from the audience. “I mean, sometimes it’s a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago…The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse.”

I can’t help but wonder how much of the reason for this bloat is a general aversion among many Linux kernel hackers to stable kernel interfaces in favor of getting code into the mainline Linux tree. Greg Kroah-Hartman has written eloquently on the subject, but I stand by my own dissent from almost two years ago. In addition to the objections I raised before, I believe that the “only one download” attitude is also part of the reason the kernel is bloated. Everyone pays not only to download and configure/build code for platforms and devices they’ll never see, but also to run core-kernel code that’s only there to support environments that they’ll also never see. For example, a lot of core changes have been made to support various kinds of virtualization. Virtualization is a very valuable feature on which I myself often rely, but is it really fair to make everyone carry the baggage for a feature they don’t use? Might that be an example of an anti-patch philosophy contributing to the bloat Linus mentioned?

The problem is that, if you can’t do something as a completely separate module (and BTW it’s pretty amazing what you can do that way), then you have two choices: maintain your own patches forever, or get them into the mainline kernel where they’ll affect users in every environment all over the world. Both approaches are unpleasant. Maintaining your own patches across other people’s random kernel-interface changes is a pain. Dealing with all the LKML politics to get your patches accepted can be a pain too. What if there were a middle ground? What if the community were more patch-friendly, so that functionality requiring patches weren’t treated quite so shabbily. That would mean more stable kernel interfaces – not infinitely stable, but not allowing unilateral change every time one of those senior folks learns a new trick. It would also mean better ways of distributing patches alongside, rather than in, the kernel, such as having a well-known area on kernel.org for real-time and virtualization and NUMA and similar major-feature patches. I recognize the problem of maintaining every possible combination, but shouldn’t users at least have a choice between well-tested “plain” and “everything” kernels? Wouldn’t that help address the bloat, with a minimum of pain for all involved? Shouldn’t we at least discuss alternatives to the model that led to things being so bloated that even Linus has commented on it?