Slashdot Mirror
Kernel Changes Draw Concern
Saeed al-Sahaf writes "Is the Linux kernel becoming fat and unstable? Computer Associates seems to think so. Sam Greenblatt, a senior vice president at Computer Associates, said the kernel is 'getting fatter. We are not interested in the game drivers and music drivers that are being added to the kernel. We are interested in a more stable kernel.' There continues to be a huge debate over what technology to fold into the Linux kernel, and Andrew Morton, the current maintainer of the Linux 2.6 kernel, expands on these subjects in this article at eWeek."
Even if you don't compile it and rely on your distro for it, don't they usually make everything that's not required for booting as a module? So if you don't have the hardware and you don't need the driver, the module is never loaded and you don't waste the memory.
There've been concerns about kernel bloat since the 1.3 kernel. I recall there was quite a ruckus when the compressed kernel tarball went over 10mb. But yanno it's gotten more robust and added support for a lot of modern features (Especially in networking) that I really do appreciate having the choice of compiling in. And I'd be surprised if the source was anywhere near the size of the commercial UNIX kernels much less Windows or one of the mainframe OSes. The build system seems to be pretty well capable of containing the bloat as well.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
This proud owner of an AMD K6 300 MHz has compiled and runs Linux 2.6.11.7 without a hitch, and continues to not see the problem.
yes but NT does not have an option to remove those drivers from the system. the linux kernel allows you the opportunity to omit whatever you want at compile time.
you have options and one of those options is to not use stuff.
[ disclaimer: I'm a Xen developer ]
I'd say the parent is a fair question, not a troll.
Morton's point appears to be this:
* x86 is notoriously unco-operative to full virtualisation
* trying to fully virtualise it (as VMWare and Virtual PC do) is a work around for the fact you can't modify the guest OS because it's closed source
* fully virtualising x86 in software results in rather painful performance hits for many workloads and a very complex hypervisor
* for open source OSs, it therefore makes sense to use paravirtualisation. This involves porting the OS to a special virtual machine-oriented "architecture", closely resembling the real hardware but without the costly-to-virtualise parts.
* paravirtualisation can be argued to be better than full virtualisation because (esp. on x86) the performance hit is much lower.
Porting of open source OSs is happening: Linux 2.4 and 2.6, NetBSD, FreeBSD 5.3 and Plan 9 can run on Xen (although currently only the Linuxes are supported as "host" or "Dom0" operating systems).
At the risk of getting flamebait or troll, I'll speak my mind anyway.
.config, you can unbloat YOUR products.
How about trying out this GREAT utility called "menuconfig"...then you can unbloat your kernel. In the time it saves you from manually editing your
n the other hand if you cannot download 40 megs buy a distribution on cd/dvd or use windoze
...
Or just download the patch instead. That's what those patches are there for, you know
* fully virtualising x86 in software results in rather painful performance hits for many workloads and a very complex hypervisor
;-)
Something I think Sam missed is that Xen also supports VT which provides full-virtualization on the x86 (which makes Xen undeniably a true-hypervisor).
Compiler-driven para-virtualization is an interesting emerging area of research too that should make porting OSes to Xen much simplier.
All we need now is a really cool hypervisor-aware file system.. like a XenFS
There is no reason that these "experts" can't tune a 2.6 series kernel to around 1 MB (maybe less). Kernels with modest support for lots of hardware are still around only 1.5 MB at best. Anyone complaining about it is simply talking out of their asses.
You don't want "game drivers and music drivers", then exclude them. There is no science to it. But I *want them* in my kernel, and many other people do as well.
Additionally, if Greenblatt and co. want more "enterprise features", they're certainly welcome to add time and money into developing these components.
This e-week article is misleading. It's not drawing "concern" for anybody, especially not the "open-source community". Computer Associates is not the "open-source community".
http://technovia.typepad.com/technovia/2004/05/lon ghorn_specs_.html
In a nutshell, it comes from a slide at a developer's conference, indicating the kind of machines that may be around for Longhorn's lifetime, and that the OS should be able to take advantage of such high specs, not that it will require such high specs.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
That seems unlikely. Embedded Linux is a big deal, and embedded systems are far more squeezed for memory than even quite old desktop systems. That keeps pressure on Linus and Co. to keep the compiled kernel (though not the sources) from getting too bloated. If you read summaries of the LKML (like Kernel Traffic) you'll find that there is a set of developers who are constantly looking for ways of trimming fat out of the kernel. There's also some pressure from the high performance end, since a slow, bloated kernel will steal memory and processor cycles from running applications. Between those two groups, there's enough pressure that we can reasonably hope for the kernel itself to resist excessive bloat.
There's no point in questioning authority if you aren't going to listen to the answers.
We are not interested in the game drivers and music drivers that are being added to the kernel. We are interested in a more stable kernel.'
No offense, but he sounds pretty clueless here - not to mention the fact that there is no "game driver" or "music driver", perhaps he is referring to device drivers and/or low-latency features, which allow for a better gaming/multimedia experience...
In any case, he completely misses the point that the kernel, as shipped by the distros, is modular. That means, if a device isn't present, or isn't used, the driver for that device never gets loaded into memory. So it doesn't really matter how many devices are supported, the only device drivers affecting the size of the kernel are the ones loaded into memory on the machine in question.
I find Greenblat's attitude ridiculous, since he seems to be saying that the kernel developers need to focus on what Sanm Greenblat is interested in, and to hell with people who want to do cool and interesting things with linux, which aren't part of CA's business plan.
I could go on, but that's enough for a first impression.
Anthony's point was that it will be able to run unmodified guests using Intel's Vanderpool / VT-x extensions and using AMD's Pacifica extensions. VT-x is shipping some time this year, IIRC. I'm not sure when Pacifica is shipping.
You are allowed to do that. For example, the Galeon developers explicitly added an exception to their GPL license to allow linking to Mozilla, which was MPL at the time. The MySQL developers added an exception to the GPL license to allow the non-GPL'ed PHP to link to the GPL'ed MySQL libraries.