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.
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.
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?
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.
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.
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!
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".
Heh... That's a memorable quote... "CA's job is writing software"
I cant believe any such a debate emerges over quotes from one of the worst managed, maligned companies in enterprise software. Slashdot is doing them a favor by advertising this dude's comments...
I don't even see the punch cards anymore. I just see blonde, brunette, redhead...
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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!