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."
I can see why some people would have a problem with this, such as those that see Linux as a networking OS or for more of an embedded system. But if Linux folks ever want to see Linux as an OS for the masses, you have you cater to the average joe, and offer all of these features for games and video and the like, if it's ever to compete with the media abilities of Windows and Mac.
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.
We're all entitled to our opinions. While CA isn't interested in more drivers or game support, other users are. Conversely, things CA will want are less important to other users.
I myself would like better multimedia drivers, good solid and easy to install and configure drivers for my PVR-250 and pcHDTV tuner cards in my MythTV box. CA may not give a darn about those at all, but this is my primary Linux goal and getting my particular MythTV rig running is the only application I myself presently give a darn about in all of Linux land.
I myself do not give a darn about gaming support either right now. That may change in the future if I decide to expand on MythTV and turn the thing into a high-end game console as well. But for the moment I'm not interested, just as many gamers may not be particularly interested in TV tuner drivers.
Though keeping stability and efficiency as primary goalsagreeably is a good idea. But I think high-quality (ie. NOT alpha or beta) drivers for more hardware should also be important.
Which is exactly what Andrew Morton said. I think that the underlying issue is a human resources one. CA wants Linus and Andrew to spend all of their time working on "Enterprise" features and none of it on things like improving Linux's real-time performance and integrating drivers for non-server hardware. I think that they're being selfish and unreasonable, but that seems to be par for the course for CA.
There's no point in questioning authority if you aren't going to listen to the answers.
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
So then don't build them you insensitive clod. Why do people seem to then that the kernel is ONLY for them and their market. Just because there is a driver doesn't mean it needs to bloat your kernel. With simple config options you can build a very small tight kernel.
If anything the extra junk benefits them because the folks developing those drivers are likely to find bugs in the kernel proper.
To further expand on this, if CA thinks the kernel is unstable because developers are working on game drivers instead of stability, then they should hire some developers themselves. Part of your contract with open source is that you can't tell a guy working for free that he is working on the wrong thing. If you want a certain feature, here is always a price. There are plenty of examples of open source developers being hired by employers to work on feature the employer is specifically interested in.
Spencer Ogden
If you don't want it, don't compile it in.
It gets better. If someone says "but I use a stock kernel," remind them that they don't have to load every module under the sun.
This guy would be better off going off to tell hardware manufacturers to quit making new hardware. Yeah right! Also, why does he not complain about bloat in the Windows kernel? IIRC, there is a much larger segment of hardware supported in Windows than in Linux. Mehtinks his statement should be modded -1 Flamebait.
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.
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.
This is true of any software system. As it grows, complexity increases. The answer isn't (can't be) to stop growth. The answer is to manage the complexity by using well-designed and well-defined interfaces and minimizing side effects.
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
This is why there are kernel modules. As much as linux ricers like to argue otherwise, there's virtually no reason a normal end user should ever build their own kernel. Nor should their be. The idea that compiling a kernel should ever be optimized for average joe end users is stupid.
As much as linux ricers like to argue otherwise, there's virtually no reason a normal end user should ever build their own kernel.
So that loading the kernel on 100s of machines is as easy as distributing a single file rather than a distribution of files.
Personally? I never used modules when I could just compile it all in. It's easier to transport that way.
How embarrassing for CA.
;P. The last thing I'd want is to NOT have to go scouring the net for some obscure driver.
;)
Yeah, I personally find increased driver support a real problem
If he wants an OS for which you can't optimise the kernel in anyway try microsoft.com. I hear there are a couple there.
They should then hire them and pay their accounts. It is as aimple as that, if you expect to be able demand them how they should expend their time, hire them. But good luck expecting that they will stay as maintainers if they sudenly forget about a hole part of the comunity who expect to run linux on their desktop.
[]'s Victor Bogado da Silva Lins
^[:wq
Going to the trouble of removing sections from the kernel would only bring us back to the days when it was quite difficult to get all your hardware working and you had to search for drivers.
If you're going to run a typical "server" for a business then a 20-50mb download isn't that much. combine it with it's source so you can build a different kernel for each server (if needed).
Yes there are large sections if the kernel I've never touched (and I doubt I ever would), but I for one still want to see it in the source.
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!
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
1. Modprobe/insmod/rmmod.
2. The OpenVMS kernel is written in VAX assembler (http://research.compaq.com/wrl/DECarchives/DTJ/DT J807/DTJ807SC.TXT). It was not written in "languages like" Ada. Jesus christ.
For one, this is CA, their job is writing software. But I think you realize that.
As for other situations. If you are going to get a certain level of support for a product (new features, custom installations), that is going to cost you a certain number of dollars, whether it be licensing costs (you need to be a large enough customer to have that level of influence with a vendor), or it be in hiring developer time to work on an OS project.
I would love to see some sort of feature wishlist where smaller companies could vote with their dollars on certain bugs or features. I've heard of bounty systems like this being tried, and I would love to hear more about why they haven't really worked yet.
You are right about the OS community being quick to jump on the "code it yourself" excuse. But that is reality of dealing with volunteers. Some are motivated by competing with commercial products, and will work on features to make that happen. Others are totally unconcerned with what corporations think about their work. At the end of the day, many developers are scratching their own itch and shouldn't be expected to care about what other people want their software to do.
At the same time as some people are quick to jump on this excuse, others are quick to assume that the goal of OS should be to beat proprietary software. This is simply not many peoples goal.
Spencer Ogden
Who cares ? Distros will take care of kernel choices for you.
Slashdot anagrams to "Sad Sloth"
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.
...
But isn't most of that code base specific drivers for specific hardware, maintained by individuals who wrote that code? Are you saying that instead of including possibly buggy drivers, it would be better to leave them out and give no support at all to people who happen to have that hardware??
Remember, any potential bugs in drivers won't affect anyone who doesn't have that hardware - these drivers are compiled in default kernel distributions as modules and never get loaded unless they're needed. All it means is that the kernel modules take up a bit of disk space, which is trivial compared to the sizes of current hard disks. They don't impede performance and they don't do any other harm. I really can't work out what all the fuss is about
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.
The problem is choice. Some people would say that choice is good, but from a business perspective, choice is expensive too and sometimes the benefits of choice do not outweigh the costs.
So now instead of paying Microsoft to make your choices for you, you pay Red Hat or Novell to do it. You can even hire a consultant that will tailor the kernel to your specific needs if it's that big of an issue, and if it is, I doubt that Windows would suffice anyway.
Choice alone is a good thing, and when your choices are open it's even better. Find someone to do what you want well for as cheap as you can, or take one of the prepackaged solutions. It's not that big of a deal.
I don't hear anyone complaining about DirectX 9 being included in WinXP pro.
you're still not thinking like a developer...
code in the tree, even if it's perfectly disconnected from the rest, still has to be modified when an API changes. With the 2.6 the de facto development codebase, that's not something to ignore.
Somewhere along the way, the kernel devs seemed to have dropped 'high reliability' as one of their requirements, and Linux is suffering badly for it. I've had trouble with 2.6 just on my toy servers at home... APIC problems interfering with the md driver, for instance. It directly cost me quite a bit of money to buy hardware, troubleshoot, and eventually realize it was the kernel at fault, not the hardware. I shudder to think of what small businesses must be spending to fix 'hardware problems' that aren't.
.. but one of the senior kernel devs said, approximately, that getting 1 out of 3 stable kernels actually stable was an acceptable outcome.
It's my belief that the kernel won't really stabilize until they branch off to 2.7. They're too focused on adding new features for the code to ever really shake out and get stable. They're shoveling new stuff in there way way way faster than it can really be debugged.
And they just wave their hands in the air and say that it's up to the distros to make this mess usable.
Until they get over this phase, in which they're pushing the hard work of debugging onto everyone else in the world, the kernel is not going to stabilize. And we will be held hostage by particular vendor kernels, instead of being able to track the 'one true Linux'. If we start with Redhat, we're stuck with Redhat. In the past, we were able to fall back on the One True Kernel if Redhat or Mandrake made a mistake. But that's not really an option anymore... tracking the One True Linux is now dangerous, because the kernel devs don't really care if it works right.
I can't find the precise quote right now, because I can't see my old comments on Slashdot... apparently I now have to pay for the privilege of seeing my OWN old comments
Until that mindset changes, Linux is just not trustworthy. It needs to be made right BY THE PEOPLE WHO WRITE IT. You can't hack reliability in as an afterthought, it has to be a major focus all the way along. This is exactly the sort of crap we always derided Microsoft for... ship it buggy and then fix it later. I hated this behavior in Microsoft. I hate it just as much in Linux. I switched to Linux because it was, first and foremost, reliable. It no longer offers me that, and I am starting to switch machines over to the BSDs now.
Waving one's hand and expecting 'the distributions' to do the grunt work of actually making the kernel stable is just wishful thinking... it's expecting other people to do the job that should be the very first one on their list. Reliability is THE MOST IMPORTANT FEATURE. It's not fun, it's not glamorous, but it's what got Linux so popular that these guys actually get paid to do it. If it doesn't return to relatively bulletproof status, then people are going to use other solutions instead, and there won't be as many Linux jobs available.
It's the reliability that creates the jobs. I wonder if they really grok this?
"The real problem is too many options, and not enough testing of the combinations. That is what CA is complaining about."
Is it? Because in the article Greenblatt snivels about "too many game drivers!@" and then breaks down completely and starts complaining that Xen "doesn't do enough." I'm not sure which side of the fence he's on. I do know that if I don't have an ATI Radeon in my system I'm not going to be totally baffled by the vast array of ATI driver options. But I don't work for CA.
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!
So what? It's not like OSS's number one mission is to beat out commercial software. Company A choosing a proprietary piece of software has zero impact on Linux. F/OSS by definition isn't a profit game, it's a freedom game. For those players in the space who are making money, more power to em. If a $10K proprietary solution is more cost efficient, then they should use it.
"CA wants Linus and Andrew to spend all of their time working on "Enterprise" features and none of it on things like improving Linux's real-time performance and integrating drivers for non-server hardware."
And this points to the real evolution in linux that has Microsoft sweating: what CA wants is a kernel that works better for businesses. Why? Because businesses have come to rely on linux.
Business (in general, I'm not talking about CA specifically but about all the businesses that now use linux in their operations or, even more, in their firmware) to linux: "Linus, we didn't pay you to write the kernel, we didn't give you much help in writing it, we've often appropriated it and ignored our legal responsibility under the GPL while at the same time keeping out own drivers closed-source and binary only. But, ah, now that we use -- for free -- what started out as your hobby project, we expect you to give up your hobbyist ways and toe the line, because it's now our bottom line."
This really isn't all that much different from the RIAA's "buggy-whip manufacturers'" outlook on file-sharing: "we've always made buggy-whips, and we loved it when Linus and the rest of the OS community were producing free leather for us to make buggy-whips, but now that you're producing those infernal auto-mobiles, we'll, you better stop before you threaten our profits."
The one thing I've never liked about the GPL was that it gave the same rights to a for-profit business as to a fellow hobbyist. I'm more than glad to share my code with a fellow, who like me, is coding for the love of it. I'm a bit less happy to share with someone who just sees my uncompensated work as a way for him to parasite off it.
Linus should tell CA that businesses have gotten far far more -- just in dollars, I'm not talking intangibles -- from Linus than they can ever repay, and that he's going to go on doing what makes Linus happy. After all, that attitude worked out pretty well for the parasites last time around.
As for the rest of us, maybe those of us who can and do code should ask ourselves why we're so happy to give our work away for free to businesses that do their level best, day in and day out, not to give away anything for free.
Is the GPL really our best answer?
Opinions on the Twiddler2 hand-held keyboard?
But how about sharing it with a multinational company that is able to throw massive resources into helping you to develop your program? If you shut out all companies you shut out the freeloaders, but you also shut out companies that would otherwise be helping your project. The Linux kernel isn't mostly the work of hobbyists, and it hasn't been for a long time. For many years Linus worked for Transmeta, who hired him in part because they wanted to use Linux with their chips, and now he works for OSDL, which is funded by big corporate Linux users. Alan Cox works for Red Hat. Marcello Tostatti works for Conectiva (now Mandriva or whatever they're calling it). The list goes on and on.
And then there are the direct corporate code contributions. SGI has contributed XFS and a lot of work on NUMA. IBM has contributed a boatload of code including JFS, NUMA, and RCU, and they've tried to contribut more things that were eventually passed up because others came up with better solutions. Namesys developed ReiserFS. Many vendors have contributed drivers for their hardware. The Linux kernel wouldn't be nearly what it is today if those companies hadn't been contributing.
The key thing to understand is that freeloaders don't actually cost anything, except for the bandwidth they use for downloads, but contributors help to build the software. It's smart to let anyone use the software because then anyone can be a contributor. Help from the IBMs and Red Hats of the corporate world more than pays for all the freeloaders.
There's no point in questioning authority if you aren't going to listen to the answers.
Andrew and Linus have been doing a fantastic job on the linux kernel. CA apparently has their knickers in a knot because they expect someone else to build the enterprise kernel that they need/want. F/OSS is great in this regard, especially the kernel. Build it in, or leave it out -- how hard is that?
And major F/OSS projects like linux aren't artificially hampered by the commercial OS vendors that want to sell a "desktop" version and a "server" version, or worse yet charge per client licenses (WTF!) Linux is imminently tweekable, runs on everything from embedded ARM7 to supercomputer cluster IA64. Stable linux distributions like Slackware offer far more compatability from desktop to server than RedHat's offerings (okay, FC4 is a "committee" project, not unlike the proverbial horse that became a camel).
Perhaps CA just needs to hire some F/OSS consultants -- they could get on the cluetrain just by lurking on the forums like slashdot. So to CA, I say "Quit you're mewing!".
I agreed with you up to this... This is just FUD.
Many commercial vendors are famous for leaving serious open bugs, and not fixing them for a LONG time.
Now, it's true that OSS/FS developers aren't compelled to fix the problems you are having, but that doesn't mean you're screwed. If you are having a problem, you can fix it yourself, you aren't stuck if the company decides they aren't interested in fixing it. With plenty of developers using it, small bugs like yours get unoffical patches pretty quickly.
As I said, I agreed with you up to that point. Linux does seem to be very poor at stability testing before releasing. I would suggest switching to on of the BSDs if you want a rock-solid system... I know comments like this get marked as trolls here on
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
"Google has a strict policy of "Don't be evil" and they are for profit."
Yes, and the US Pledge of Allegiance ends with the words "with liberty and justice for all". Just because you say something doesn't mean it's true.
Where did you get the idea that hobbyists have customers? Corporations have customers and if they want changes in the kernel or another open source application then they can code it themselves. Hobbyists don't care if Linux "takes off" because they make no money off of it and don't care to. For most of us hobbyists Linux is good enough as it is and if we want something more then we'll code it for OURSELVES. It's nice when big corporations contribute code but we don't owe them a damn thing, they are using our free code after all.
Time makes more converts than reason