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."
Members of the open-source community are expressing concern over rapid feature changes in the Linux 2.6 kernel, which they say are too focused on the desktop and could make the kernel too large.
"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."
If you don't want it, don't compile it in. Thats the best part about having the kernel opened and so easy to manipulate. With the GUI available for modifying the kernel as well as a detailed set of instructions built right in, anyone can sit there and remove support for the latest gaming joystick if they so choose to. No one is making you keep it. If the kernel didn't have the option of supporting it, or if they discontinue the building of, then Linux will never be ready for the desktop. Just because Morton or Linus decides to add/accept support for the desktop community doesn't mean that the kernel won't be any more stable. Who is to say that adding gaming support took time away from stabilizing the kernel? If I'm strictly a game hardware designer and send my contribution to support the latest device does not mean that I could have spent my time improving the kernel. I may not be comfortable doing that. In other words, maybe I can't stabilize the kernel but I can write new drivers for it. And if I spend my time doing that it doesn't mean that I take time away from those improving and stabilizing the kernel.
The part that really caught me off guard is the inclusion of the Xen virtualization technology. Big changes are coming to the kernel that are really going to improve Linux and its functionality in the buisness and home world.
I'm a virgo and on Slashdot. Coincidence? Yes.
A real step towards the desktop is for the average user to be able to build a sleek customized kernel, right?
That lets you not have ISDN, USB Dildo, and/or Ham radio support.
I think it's laughable that Computer Associates talking about other people's bloated software.
"We are not interested in the game drivers and music drivers that are being added to the kernel."
..we want text, orange, perhaps green on a black background. We want large buzzing metal boxes that only we are allowed access to. We want to store our data on large spinning reels of magnetic tape, or better yet punch cards.
also we want a sandwich.
That is all.
Starsucks
The problem, I think, is that developers tend to be people who love computers. And people who love computers tend to have nice rigs, just as people who enjoy cars tend to spend a disproportionatly large amount of their income on cars (ever see the parking lot at a lan party--complete with people pulling multi-thousand dollar machines out of the hatch of a Hyundai?).
Perhaps Linux needs more developers from third world nations; the kid from a rural village with intermitant electricity getting his hands on an old, but useful machine and learning that he, too, can tell it to do all sorts of things!
An effective signature identifies a particular user amongst a base of thousands.
I worked for a UNIX computer mfg in the late 80's. Even then there were arguments about kernel-bloat.
What would be cool is if the linux distros had default kernel options, much the way some of the majors have Workstation, Server, etc... that would adjust the kernel based on how the machine was being used.
Yes, I know one can reconfigure the kernel by one's self, but it then requires personal care and feeding for patches, upgrades, etc... It becomes one more thing one has to do. Personally, unless I really need it, I'm not goign to bother... too much of a PITA
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
I have never heard of there being a problem with too many music drivers in the Linux kernel....Or any music drivers in the Linux kernel....In fact, I have never heard of music drivers at all
CA have contributed so much to the Linux kernel, so they know what they're talking about. NOT.
What is CA's motive in saying this ? They have no real experience in developing operating systems, nor are they producing data and a testing methodology to backup their opinion.
It seems to me they might be talking through their hat.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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?
I suspect that all long-lasting, end-user OSes tend toward bloatware. Macintosh went through this with OS 7 through 9. Windows appears to be doing this as it progresses to Longhorn. It's just the natural evolution of software to accumulate cruft on the basis of yet another nifty feature that must be added into the bowels of the OS until the development effort becomes so constipated that the next version never appears or is so complication/unstable that people abandon it.
The trick, for Linux, will be to do what Apple did in moving to OS X -- create a new, "from-scratch" (yes, I know Apple borrowed a lot from others), OS with some form of compatibility-creating layer or old-kernal box. Incrementalism only takes an OS so far before revolution is needed to build a new, better system from the ground up.
Two wrongs don't make a right, but three lefts do.
I'm perfectly content with compiling a kernel to suit my own needs, however many distros aimed at newbies tend to go for the "support every device possible" approach for a default install. For example, I recently installed mandrake on a machine for a friend (simple default install) to find it loading support for pcmcia, bluetooth, and many other completely unnecessary modules and services. What newbie knows how to disable services or build a more customized kernel? To be fair, this is not a problem with the official kernel source but with the way many distros make use of its capabilities.
Why must all criticism of anything open source must be labeled "bashing"? Every single time someone dares utter a single word of "dissention" about Linux or anything else, they must be "shills" spreading "FUD". Every single time. Hell, even when ESR rants about how CUPS sucks, he's branded a retard. A lot of things in free software suck to high heaven. Just like a lot of commercial software does. But the FOSS unwashed masses really need to get a grip. Not everything is perfect just because it comes with source and a bill of rights.
Because there arne't default kernel options for various tasks and because it's not exactly user friendly to configure and compile your own kernel people end up compiling in crap that they don't need.
The kernel is fine it's the setup that sucks.
I don't know what to think about this. On one hand, I used to brag about how Linux never ever crashed on me (not ONCE), despite my heavily tinkering with it. This was, I think, way back in the 2.0 days. Ever since, with a few generations of kernels, I had to eat those words far too often.
I really miss the days when I could run on a P166 with 32 MB of RAM, and KDE ran not too badly (as long as you don't try to open Netscape or StarOffice). I don't think this kind of performance is attainable at all anymore.
But on the other hand, I'd be loth to run a kernel that didn't at least support USB! I love having ALSA instead of the old mishmash of sound drivers. Ext3 was a relief. I must say that for me at least ip[tables|filter|chains] was confusing, but I trust that the best choices were made... Going back to a kernel that didn't have those features would be simply unnaceptable.
Has the kernel reached a level of complexity where the ol'time stability isn't likely to happen anymore? We just need to react with patches, just like the other OSs out there?
SYS 64738 NO CARRIER
[ 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).
I already have a third part driver, from linux-wlan-ng, and every time I upgrade the kernel I have to remember to recompile it again.
The kernel should have everything. Obvious, for licensing reasons, only GPL stuff, but everything that's GPL, and is a kernel driver, and is up to minimal code standards.
In fact, having to track down third party drivers has been a much more valid complaint than 'Too many drivers', which is just idiotic.
If corporations are people, aren't stockholders guilty of slavery?
saying "just don't compile the options you don't want."
Problem is, that doesn't affect the main problem, which is that 3 million lines of options code is a LOT harder to keep bug free among all the different combinations than 1 million loc.
All bugs may be shallow given enough eyeballs, but the difficulty of debugging the linux codebase may well be increasing faster than the number of eyeballs.
You're right, genuine criticism is not bashing. Bashing is what happens when people crap all over something with no intent other than to sling mud. For example, "Linux is currently not a suitable desktop operating system for most users" is a criticism. "It would be impossible to turn the bloated Linux kernel into a desktop operating sytem because of it's rampant IP issues" is a bash. The statements CA made in Autralia were a bash because they were made in conjunction with Sun to puff up Solaris and put down Linux, but done so under the guise of an educational rather than promotional event. Consequently, that's a bash.
Leave the gun, take the cannoli -- Clemenza, The Godfather
Actually, that's not the case at all according to this new NY Times Article
...the Purdue researchers say the real explosive secret lies in the hull, or pericarp ... In some varieties, the pericarp becomes more moistureproof as it is heated, sealing in the steam until the pressure gets so high that the hull fractures and the kernel goes pop.
In other varieties that don't undergo heat-induced change, the moisture escapes, the hull never breaks and then the kernel goes pfffft.
Of course, you conveniently ignored the "2.6.10 is looking much better" part as well as the fact that we are at 2.6.11.7 by now (which is incidentally rock-solid over here). I also seem to have heard a thing or two about FreeBSD 5.x problems and that many are sticking to 4.x for that reason. As fir Apple, they finally fixed a well-known, trivial root exploit last week which was discovered back in fscking January! Try again.
Because it may encourage people to just go to a commercial alternative. If you tell a company "We don't care about feature X, if you want feature X, hire a dev and code it yourself," they may do an analysis on it and determine you know what? It would cost us $50,000 to have a contractor develop this whereas we could buy a commercial solution that does what we want for $10,000.
This is espically true for companies who's core bussiness isn't IT or engineering or the like. If a company just uses computers as a means to an end and they don't really have a tech staff, it can be expensive, difficult and risky to contract someone to do the development they need. Better to just get a commercial solution.
I'm not saying this means OSS devs need to jump up and meet every request from every person that whines, that's clearly impossible. However I find that the OSS community in general is way to fast to say "It's open, if you want the feature, write it yourself!" Rather the merit of the request should be weighed, it may be worth your while to work on. If it's not, then you should give reasoning as to why not, and not just say "Do it yourself."
Have you ever installed a late version of Windows?
Watch the installer load device drivers for every known weird form of RAID before it even begins to ask you how you want to install the OS?
And then how long does it take to do "hardware detection" - versus Knoppix that does it all in the three minutes or so it takes to boot from CD?
Yes, Windows is bloated - bloated with (so-called) "features", not drivers. If Linux makes THAT mistake, we can complain. Having a bunch of drivers and support for oddball subsystems loaded into the kernel is not serious and until somebody DEMONSTRATES a stability problem, it's bullshit.
So far I've heard nobody say the 2.6 kernel is in FACT unstable because of x, y, z drivers or subsystems.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
You need a license for the host OS, and a license for the hosted OS. It's also having to provide fake hardware.
With Xen, maybe it's not that extreme. With the same OS inside and out, and it knowing about itself, it might not be running two copies at all, acting like a really extreme version of chroot instead. Hence the licencing being better.
And it would seem to be a lot saner. I mean, think about disk files. With VMWare, VMWare takes the file, fakes a device from it, and Linux accesses the device, but that's rather goofy when you think about it, because Linux can already mount files. With kernel support, the host kernel could let the hosted OS have direct disk access to that file, and only that file.
In the Linux kernel, there are a lot of 'loopback' and 'fake devices' concepts like that. There's the loopback mounter, there's SCSI emulation, there's fake network devices, there's the fake PS/2 mouse in /dev/input/mice, there's all sorts of pretend hardware. With Linux-on-Linux support in the kernel, that fake hardware could trivially turn into 'real' hardware for a hosted machine, where the hosted kernel know it's accessing something fake, and the host kernel just needs to restrict access.
Hopefully this will be extendable enough that the 'devices' the hosted kernel use can be shared with Linux-on-other-platforms, like coLinux on Windows. And the devices exposed to the hosted machine could be exposed to other emulators.
If corporations are people, aren't stockholders guilty of slavery?
Menuconfig is just the window to the maze that is the kernel ifdefs. You have no idea of the size or speed impacts of the options you through if the help doesn't tell you. You have no idea of the component interactions.
Menuconfig is just a parking place for problems. The real problem is too many options, and not enough testing of the combinations. That is what CA is complaining about.
"This mission is too important to allow you to jeopardize it." -- HAL
Yeah. If you really wanna have some fun, do a "cat /dev/urandom > /dev/dildo" for hours of fun!
Linux drivers can be, and normally are, modules. Just don't ship the modules you don't want to support, there is no need to re-certify anything.
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".
So far I've heard nobody say the 2.6 kernel is in FACT unstable because of x, y, z drivers or subsystems.
I'll say it: the 2.6 kernel is unstable on x86_64 platforms with USB 2.0 mass storeage devices. There are bug reports everywhere. The response? "It's fixed." The reality? The system locks up like Fort Knox whenever it's booted with a USB 2.0 mass storeage device attached.
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.
I think people are missing the real issue in their anger over someone criticising the Holy of Holies. In case you missed it, the issue is that Linux is getting fat and bloated.
linux-2.6.11 is forty four megabytes. Gzipped up. I don't want to waste my bandwidth downloading it to see what it is unzipped, but trust me, it's massive. Where does all this bloat come from? Drivers. Drivers are good, but the current kernel paradigm (and Linux isn't alone in this) is that every driver has to be included with the kernel. So we end up with huge packages and huger repositories where everything is required to reside.
Imagine the size of Linux when we finally get to the goal of having every past and current device with a dedicated driver in the source tree. You're talking possibly ten gigabytes uncompressed. Even if you're not using 99.9% of those drivers, they're still there. The day may come when you can actually build the kernel faster than you can make its dependencies.
Could you imagine a KDE or GNOME where every core, addon, auxiliary and experimental component was all part of one single tarball? Even if you only wanted GTK+ and GIMP, you still have to download and configure the entirety of the GNOME repository to get it. That's what it's like with the Linux kernel.
It's time non-core drivers got split off from the main Linux project. If you don't need to add anything into the kernel to get driver to work, then put it in the driver subproject and don't bug the big guys with this penny ante crap.
Don't blame me, I didn't vote for either of them!
The linux-tiny patchset is your friend here. Using it, I've gotten a relatively full-featured kernel booting on x86 weighing in at under 800K... and that's without doing any agressive trimming, and without module support. According to his OLS 2004 presentation, Mackall has achieved a linux 2.6 kernel weighing in at a mere 363K, and others have reportedly managed a kernel as small as 191K.
Some of the linux-tiny ideas have been making their way into the mainline kernel, so this isn't just a special-purpose patchset - it's really a proving ground for kernel size minimization techniques.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9