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.
Isn't that why you compile your own kernel?
FP?
Rick B.
Bullcrap. Who likes installing zillions of extra drivers when updating the kernel?!
And about "fatter": I don't get it. You will probably use ONE sound driver, ONE (or perhaps two) network drivers, etc. Just the fact that the *amount* of drivers is gettling bigger, does not mean the kernel "is getting fatter".
-- The Online Photo Editor - http://www.phixr.com
We are not interested in the game drivers and music drivers that are being added to the kernel.
That's cool.
Conversely, we are not interested in what interests whiny bloviating assholes who go on record to offer unsolicited unconstructive criticism.
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
On the other hand I was screwed so badly by CA that my automatic reation to anything they say or do is to discount it as coming from that Den of Thieves and Liars.
Too lazy to create a sig...
I hope I don't get a troll rating on this, but I think that as any kernel grows, it becomes exponentially more difficult to project all of the possible interactions between components. Some of the ones that get missed or go untested simply because they weren't foreseen cause problems. Any kernal is going to become more unweildy as it grows. Especially when it starts to encompass so many diverse tasks and support multitude of dedicated roles. I think to attribute problems such as this article talks about as specific to Linux is biased.
Please don't mod me as a troll. I just don't understand what Morton ment by that?
Can someone explain it to me or is this just a badly written article that is referring to the license of other virtualization technologies.
--fatboy
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.
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
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.
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.
Part of the beauty of free software is that, if you have the capacity, you can modify it to your needs. So my first responce would be, if you don't need a feature don't compile it into your kernel. Some however, who don't have the capacity to modify thier kernel, might benifit is distributions included multiple kernels, say one optimized for a server, desktop, or laptop. I think that this is an issue for distributions (Redhat, Suse, and friends) and not the kernel team.
The way to a man's heart is through the left ventricle
Yes, Intel has contributed code to Xen to support their Vanderpool extensions (now called VT-x) already. This will (eventually) allow you to run Windows in a Xen virtual machine.
AMD have also indicated their support for the Xen project.
Note that performance using (at least a degree of) paravirtualisation (guest OS porting) will likely still be better (at the very least equal) to that of hardware supported virtualisation, so there is still a point to Guest OS modifications and specialised drivers.
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."
what's the advantage to the kernel of moving the interfaces to be more external and require expensive marshalling?
Ah, but they only require marshalling when you cross a protection boundary. Without that, they can be as efficient as the Amiga message primitive which was four instructions long.
The C function interface does not suffice. That's the same problem that RPC mechanisms have. The C function interface is synchronous, messages can be asynchronous, they can be buffered and queued, they make concurrency implicit and invisible rather than forcing every component to be explicitly and painfully aware of it, lest they become a bottleneck.
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?
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?
The only loaded modules would be ones for the hardware your friend actually had, I should think. That's the beauty of modules - they won't load unless they're needed.
As for services, yes, there's many services installed in any distro, in any OS, that most users don't require. And it's usually fairly easy to stop them (there's generally a GUI to change which services are run automatically; the last time I looked at Mandrake it was in the main Mandrake control panel software, so pretty easy to find). But that's not a kernel issue and it's not even an OS issue, so it's hardly relevant here.
I agree with the other people who responded to this post. The older hardware really isn't being left behind at all. I have a Celeron 400 MHz computer and not only do I have no problems running it as a server, but I let my sister use it for her desktop computer and she can still play XVID movies and I get a full featured server. The key is to make sure you have ram (256 MB for me). BTW my sister uses either gnustep or xfce which are semi light on memory
Can be safely ignored as it is likely a lie. Please note this quote from an article at Red Herring:
Last April, CA restated $2.2 billion in sales that it had improperly reported. Chairman and CEO Sanjay Kumar stepped down, and three CA executives pleaded guilty to fraud. In September, Mr. Kumar was indicted for securities fraud, conspiracy, and obstruction of justice in connection with accounting practices while he was CEO of CA. The company has also footed a $225-million restitution fund for shareholders.
This extraordinary mendacity and outright fraud when coupled with a long history of predatory business practices that would make Bill Gates blush means I will totally ignore anything anyone associated with CA ever says, never buy their products, point out thier failings to anyone who will listen and advise others to do the same.
To some degree, laziness is probably involved.
With Windows, the issue is different - it is "featuritis".
"We need a complicated Group Policy system because we have to lock down the desktop!"
"Why?"
"Because our users will screw up their machines if we allow them to do anything!"
"Why?"
(Because we designed the system wrong in the first place - giving users the ability to screw up their machines by doing anything at all...)
As a result, Windows has built "system management" into a totally unmanageable mess that hardly any sys admin can figure out anymore.
As an example, last night in my Server 2003 class, we did a SIMPLE exercise that created an Organizational Unit, assigned a Group Policy to it, and used it to control the behavior of a user assigned to that OU. Worked for most people in the class.
Didn't work for several people in the class.
Teacher couldn't figure out why it didn't work.
It just didn't. The appropriate permissions were assigned to the user account, gpupdate was run, the permissions showed as established in the Security tab - then you reboot as that user: nada. Zip. Zero. Default permissions. Everything done just as the textbook instructed - didn't work. Why? Who knows? Some sys admin who would have to spend an hour or ten to find out - or call Microsoft at $275 to ask them.
If Linux (and the desktops and system management tools layered on it) follow this course, then, yes, Linux will turn into a disaster. Fortunately, there is a treatment (if not a cure) - forking.
Try and fork Windows - or even Solaris.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
What exactly are game and music drivers?
like, maybe for instance sound and video drivers?
Isn't calling these game and music drivers a bit misleading, and a bit discrediting at that? It's not like those things don't have their own group of developers taking care of them. It's not as if the alsa guys are stealing kernel developers away from their precious stable-code-writing-tasks, or anything.
As for video drivers...well if you're any bit of a serious gamer on linux and using one of the latest cards this most likely means you're using the ATI or nvidia closed source drivers, which again is not exactly relevant to any work that the lead kernel developers are probably doing...
It seems like this guy is completely clueless and is just making a big fuss over nothing. Or maybe they're just bitter that their favorite feature didn't get into the kernel but a new sound driver did? Hrmm...
If you don't want someone to copy something, don't give it to anyone.
What do you mean by "full virtualization"? Xen cannot run windows or any other "unmodified" OS as a guest, so I don't think it provides full virtualization at all, to me that means that you can run an unmodified OS as if it were a full x86 system.
The fastest way to kill a good product is to let CA buy it.
Hurd fanatics' usual argument against Linux.
Though Linus calls Linux modular, it isn't actually modular because at run time the kernel runs as one big program( it is called modular because of the modules aspect of Linux). The disadvantage of this being, as the kernel gets bigger it is going to be more difficult to maintain it. On the other hand, the microkernel as such is small. The modules are in user space, and are separate programs, which helps in maintaining them.
Look ahead 5 years and see how Linux kernel would be experiencing more bloat and Hurd getting better each time
- srid
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
The point is that by pushing features to install packages you expose things that can't be installed as indicators of kernel design flaws.
I was just suggesting Greenblatt pick some dependency management system into which to push features he finds superfluous to the kernel and then ask real hard questions about why the kernel can't support some drivers being installed from such a dependency manager -- why they must be compiled into the kernel.
Seastead this.
It sounds like a market to me, compiling kernels that only do what the customer wants to use them to do, I was under the impression that's why you have an IT staff, but what do I know? Apparently CA only wants to use default distro kernels, or doesn't know how easily a kernel compiles. Of course, he may be criticizing the fact that gamer types and other non-enterprise programmers write what *they want*, instead of what *he wants*, that's easy, put a couple of those guys on the payroll, or was free beer the only reason CA got on board? Am I wrong or are they CA the ones that bought the Linux license from SCOX? So many questions.
Is this the same Computer Associates that was caught up in the whole SCO Linux license thing?
I'm not saying that he doesn't have a point, but what I am suggesting is that he might not have the Linux community's best interest in mind...
if your kernel is so big, perhaps you should .. recompile it. The distro's and even kernel defaults tend to support a lot more than most people need, thus its going to be bigger. I never really understood this argument- I mean of course as development chugs on core functions are gonna change and as a result most likely get bigger- but seriously if your server has 'the latest game drivers' then you are not doing your job correctly.
I never understood this out-of-the-box obsession, i mean seriously what type of admin puts an os into production 'out-of-the-box'?
The only part that really bothers me about this, and I say this as someone who has built a career off of programming under the unices, especially Linux- what bothers me about this is that its not the tech-heads that read this and go 'whoa we better find a better solution', its the management- and as a result I have to deal with what some guy who is a journalist and quite probably not really that qualified to talk on the subject has to say, but now its coming from my boss.
"To install Linux, one has to check out the hardware, or at least experiment with some of it, try out a few sound cards, graphics cards, etc."
No. It's 2004. I want to do the following:
Give me a model number and a vendor for the following items:
1. An 802.11g cardbus or PCI card as appropriate, known to work without resorting to extreme measures, with the current kernel version.
2. A 3D accelerated video card known to work with the current version, which also supports one or more high-resolution modes on the console.
3. A multi-channel sound card with digital I/O which is fully supported by Linux Audio and MIDI applications, and has driver support in the current version.
4. A voice modem which is fully supported in the current version.
I don't want to "try 10 different ones and return them." I want the vendor to assure *ME* that they work.
Start with the 802.11g PCI card. Which one should I get? Turns out you need more than just a catalog number, because that doesn't guarantee the chipset.
-fb Everything not expressly forbidden is now mandatory.
Is it possible to enable Sysrq without enabling CONFIG_DEBUG_KERNEL?
I don't particularly want debug info, but I do want Sysrq.
My kernel is 1.6 MB, and I only have support for my hardware compiled in.
It really does not make any sense at all for anybody in a developer position to complain about the kernel being bloated when it can be pruned to suite their needs. If I were to take the article at face value it means Sam Greenblatt is a complete moro^H^H^H^H purist who thinks along the lines of 640K ought to be enough for everyone. I wouldn't like to think of him that way because if thats true the implications would be far ominous than I could imagine.
So I'm guessing the real agenda is hidden between the words. I have several possible lines that makes sense.
!! Warning !!
What follows are wild speculations.
Use your own judgement on this.
CA might be wanting to change how the kernel is distributed and about who is going to pay for it. In other words CA wants to pass on the buck onto Linus to produce a server branch and a desktop branch of the kernel, because they don't want to hire an extra worker to do the job. Hence their gripe.
Or
I got this idea from this quote from TFA.
For some unknown reason CA don't want to have Xen embedded into the kernel. Not because of the bloat. Remember the kernel can be pruned. Also its assumed in this case hiring an extra hand isn't a problem. Maybe Greenblatt has a friend working at VMware.
Or
This is a promotion for Xen meant to improve its awareness amongst the community. disguised as a a controversial statement.
I did a word count on the two portions of the article. First half of the article about bloated kernel and the second half of the article about Xen. The results are quite revealing.
$ wc -c first_half
1621
$ wc -c second_half
2030
OMG! more than half the article is about Xen!
Not that its a bad thing to promote Xen. I actually like it. Although I don't think a good software needs to do any kind of covert promotion to be particularly popular.
Anybody else have a better explanation that makes sense?
BTW my kernel is just over 2 Megs on Gentoo.
$ du -h kernel*
2.1M kernel-2.6.11-hardened-r1
I don't see what the problem is.