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?
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
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.
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.
Drivers that are not compiled are not taking any additional space. Drivers that are not used all the time can be compiled as modules...
So I guess I do not understand the criticism here.
On the enterprise front, Morton said he expects to merge code from Cambridge University's Computer Laboratories' Xen virtualization technology into the Linux kernel within the next few months. Xen "does the right thing technically," unlike other technologies, which are mainly workarounds for the fact that the operating system is not appropriately licensed, Morton said.
Huh????
--fatboy
"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
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.
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...
What the heck is up with CA? At the same time they praise Linux, they seem to turn around and bash it. If they have an agenda it's not clear. Criticism like this doesn't smell right, especially after the flack they gave Linux in Australia. Something's fishy but I can't seem to see what it is.
Leave the gun, take the cannoli -- Clemenza, The Godfather
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
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.
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.
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.
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.
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
I bet the same people bitching about not needing "game or music" drivers are the same people who wonder why linux cannot fully displace windows.
sheesh. as many others have said already - if you dont want/need the driver - don't compile it.
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.
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
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.
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.
Would it simplify the kernel, though? There already are interfaces; what's the advantage to the kernel of moving the interfaces to be more external and require expensive marshalling? Perhaps it moves the modules out of the kernel, but that's moving complexity around and could be done right now without any kernel changes.
of separate interfaces for every kind of object a single regular interface could be used at least as a starting point
There is; the C function interface. Abstract as much as useful, but no more. Again, whether or not this is a microkernel or not, the interfaces can be made, and have been made to the extent that they were felt useful.
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.
Linux on the other hand has a sound design (no design is ideal).
Further if you think Linux sucks because [chose your reason] there is most likely already an OS project running to address your issue.
In short MacOS needed a restart worse then windows 3.1, Linux does not.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Yeah. If you really wanna have some fun, do a "cat /dev/urandom > /dev/dildo" for hours of fun!
The size of 2.6 isn't the problem - the crazy policy of not having a development branch and throwing everything at 2.6, on the other hand, is.
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.
We are not interested in the game drivers and music drivers that are being added to the kernel.
He might or might not have a point but things like music and game drivers do not make a good example of kernel bloat. It's not like it hurts that those drivers exist in the kenrel. Such drivers are usually shipped as loadable kernel modules. If you don't need them, they won't be loaded. They're only using up your disk space (which shouldn't be a concern these days)
# cd /usr/src/linux
# make menuconfig
Then locate
Configure standard kernel features (for small systems)
This option allows certain base kernel options and settings to be disabled or tweaked. This is for specialized environments which can tolerate a "non-standard" kernel.
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".
Umm, could you clarify that? There is something called an initial ramdisk which loads critical drivers required to boot. So you can have a smaller kernel image by making these critical drivers loadable modules. No matter what, you still have to compile them.
I must be missing your point Mr AC.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
No, you're both right. The OpenVMS kernel was written in VAX Assembler, but components of OpenVMS were written in a variety of languages. Like someone we all know and [love|hate] likes to say about what is popularly called Linux, OpenVMS is much more than just a kernel.
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!
-rw-r--r-- 1 root root 808295 Mar 24 2004
-rw-r--r-- 1 root root 1458226 Mar 28 15:19
I suppose it is a little bigger. I did compile scsi support into the second one for a usb keydrive though.
:wq
Try this:
If it asks you any questions, those are new features that you weren't using before so just answer "N". when it's done, proceed to build your kernel, and it will be no more bloated than it was before.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 it will stop is rootkits. Things that alter files on disk to install backdoors, and then install a kernel module to hide said changes. Sometimes this kernel module will also hide the listening ports, or even keep them closed until it detects a special knock. It will had backdoor processes. It can do anything, and you'll never find it.
So completely disabling them? Yeah, that's a good idea for a server that isn't going to see much hardware changes. I've done it for a router before. It won't keep crackers out, it will just make them slightly more visible. Or at least keep them from being completely invisible. (Barring, of course, their patching and compiling a new kernel, but that requires, at least, a reboot.)
Merely limiting the number of modules, however, while having them enabled, doesn't help anything at all. A rootkit modules can load and then remove itself from the list and you'd be no wiser.
If corporations are people, aren't stockholders guilty of slavery?
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.
All you have to do is recompile one time and then just transfer the kernel you want to all the machines, change the boot loader and voila. In the Windows world you have 3 choices: You can download and install the updates by sneakernet, you can set up a patch management system for them or you can get a company image up and going and then reimage all the machines
(I am sure there are other ways, but these come to mind in my cough syrup infused brain quite readily)
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!
Microkernels, and messaging, were an academic fad of 1988-1997 by which time Tanenbaum/CMU/Inria were shown to be wrong, and classic Unix e.g. Solaris; Linux correct
Well, you sure have the Official Linux Policy down pat. It's a good line of patter, pointing at a small bunch of academic systems that came along fairly late and acting as if all the earlier and still in production real-time microkernels didn't exist... or tat they're somehow "not microkernels" because they don't fit the Official Linux Policy definition of a microkernel.
The ones I've had most experience with are RSX-11 and AmigaOS, but pretty much all hard real-time systems have a similar structure. There is a huge history of successful microkernels and, no matter how much Linus was soured on them by his experience with Minix, it's an effective and efficient way to build a system. The problem with Microkernels is you have to make sure that you haven't built in single-threaded bottlenecks that every process has to work through, like the Minix file system. Monolithic kernels largely avoid this issue, at least up to the point where they have to deal with a multi-CPU environment and the simple "single kernel lock" becomes the same kind of bottleneck.
See, concurrency is hard. Both designs force you to work through concurrency problems. Microkernels hit the concurrency wall earlier, but you only have to climb over it once. Monolithic kernels have to keep adding more and more heuristics to work around it, and that itself is a cause of kernel bloat.
Which is where we came in.
The fastest way to kill a good product is to let CA buy it.
Its an Idea which has been mentioned in the past and its time it got serious consideration.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
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.
I'm surprised the kernel's as big as it is:CA may have a point.
...spike
Ewwwwww, coconut...
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.
Great, now I have to go grep my kernel tree for 'dildo' just to see if there really is a kernel driver for a USB Dildo. Thanks.
"You never know when some crazed rodent with cold feet might be running loose in your pants."
-Calvin
"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.
A lot more work needs to be done to make modules work with various kernel versions.
This way binary driver modules can be placed on company websites and then installed.
Sure, this is more microkernel like, but Microkernels are a lot more modern and easier to manage.
Bah, "640k should be enough for everyone" ..well at least for 2.4.x, for normal desktop use. :)
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
"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."
Disclaimer: I am not a linux geek, but I am an engineer, so I understand technology and the reasons why geeks do what they do.
That being said, my initial reaction to this story was: "oh man, the fact this is even an issue means linux has a long way to go". Why do I say that? Because it's obvious if linux wants more desktop share, they need to be working on the features that most people are interested in. Namely, games, music, etc. The fact is, games sell machines. Multimedia features sell machines. Look at apple: people are buying macs just to use their iLife programs. Last I checked, a stable kernel was not high on their list of reasons why they made the purchase.
I'm not discounting clean, organized code. Stablity and speed are important. But my general impression of the linux community (from the outside looking in) is that it's one big crab theory gone bad. As soon as one part of the community realizes the truth, that they only way to sell linux is to build into the system features that people actually will buy, the geeky half of the community steps in and whines that linux no longer has clean code and has become "feature bloated".
Look guys, I'd hate to put a lightbulb right up to the obvious, but consumers are not geeks. No matter how clean or efficent the code is made, the average person is simply NOT going to get excited unless the operating system has the FEATURES they want. Ultimately, it comes down to what they heck you can do with the operating system at the user level. If the user's experience is not "doing it" for them, then no amount of "clean code" is going to solve that problem.
And I know that comes as a complete downer to most geeks. We spend 10 hours a day tweaking our setups, getting everything just "perfect", and expect to be rewarded comparably. The sad thing is, most people don't care. They don't care what the code looks like, they don't care about how much time it took, and they don't care about our "brilliant" hacks. The important thing to them is what they can do with it.
So what is the solution? Easy: split up linux for the different markets. One market is for geeks, like the above gentleman who want a stable kernel and nothing else. The second market is for consumers that play games, listen to music, etc. Geeks get their geektoy, and consumers get what they want. But the community is not going to be able to make a version of linux that will appeal totally to both markets, since the markets are COMPLETELY different. (Again, geeks aren't consumers.)
I don't see what the problem is.