Slashdot Mirror
New Linux Kernel Configuration System
An anonymous reader writes "When Eric S. Raymond tried to replace the Linux kernel's configuration system with "something better", he got booed off the stage. Now Roman Zippel is bravely having his own go at it. Here's an interview with Roman and a look at his new configuration system, aimed for inclusion into the 2.5 development kernel. Also, find some screenshots of his new graphical configuration frontend."
that the kerneltrap topic id is 404...
Well the site is /.ed so what i want to know is.
Does it scan your hardware and create a default kernel configuration with all ther drivers for your hardware pre-selected.
It could even ask if you running a desktop or server machine and turn on/off low latency, pre-emtion and supermount for the desktop.
I usually have to enable evrything to get X piece of hardware working corrctly and then disable stuff to find out what the correct drivers/modules were.
thank God the internet isn't a human right.
Moreover, it's not like complete newbies are going to be doing kernel compiles. For anyone with enough experience to recompile the kernel, an ncurses-based system is adequate IMHO.
Sig (appended to the end of comments you post, 120 chars)
It's also broken.. kernel developers are constantly trying to work around it's limitations. The fact that config menuconfig and xconfig all have diffrent bugs doesn't help either.
We need something unified (same parser doffrent interfaces) and we need something less limmited. We need someone more sane than ESR to do it.
- It required Python to build the kernel.
- It was complicated. It included an entire theorem prover. This was sort of cool in that it would not allow you to generate a non-working configuration, but really more than was required for the job.
- Its language was arcane. The main language idiom is the suppress-unless statement, which is sort of the logical negation of if-then statements.
- And some folks questioned his motivation for getting this grandiose project into the kernel - was it just to help out, or was it primarily to establish additional hacker reputation for Eric? I'd be willing to give him the benefit of the doubt on this - he did the work.
I think he had a chance of getting it in, but he would have had to refactor the entire thing, write it over in C, make the language cleaner, and I guess that didn't come about. But to his credit, he didn't just talk about it. He generated a working software product with functionality that did not previously exist in Open Source as far as I could tell. His project is worth studying, and I'd encourage works derived from his ideas. I'm sure there's a paper about it online.Bruce
Bruce Perens.
Yet another thing to add to my list of "and people wounder why linux is not being readily accepted by everyone" items. I mean, come on, the guy just wanted to help make things better! Getting booed off the stage hurts!
... I can only ascribe that to politics and personal pull, which every group, no matter how altruistic and well meaning, falls prey to now and then.
:-)), but rather to point out their humanity and fallability, a trait they share with everyone reading this comment, the guy posting it, and probably with every sapient being, everywhere.
First, GNU/Linux will never be accepted "by everyone." Nor will FreeBSD, nor will BeOS, nor will Apple's OS X.
Nor will Microsoft Windows, unless Palladium and DRM is legislated into law by the likes of "Disney" Hollings, and even then Apple is likely to be kept around as a token "competitor," paying hefty patent fees to Microsoft for the privelege of being allowed to manufacture "legal" hardware in the US. Unless, of course, you get off your butt and do something about it, but I digress.
The problem is a simple and obvious one, and the solution as elusive today as it was the first time humans came to live together (and likely predates our ability to speak): Politics is ugly and banal, and people are fallible. This includes the Linux kernel developers and Linus Torvalds himself.
Example: The ggi project wanted to provide a kernel abstraction layer for video hardware in the same manner such abstractions are presented for everything else, from your ethernet adapter to your system's RAM and hard drive. Linus thought the idea sucked, then ended up doing a "poor man's" version of frame buffer support instead. How much better things would have been if the original vision of the GGI folks had been realized and supported we'll never know.
Example: PCMCIA. It is still a mess. The more capable userspace version got sidelined in favor of a broken and less capable rewrite
There are other examples, and perhaps Eric S. Raymond's effort is one (though I hesitate to make that assumption), but the purpose of this post is not to catalogue the mistakes Linus and others have made, or to air my own disagreements with them (but what the hell: when will we get XFS into the main kernel tree damn it!
Mistakes happen, everywhere, by everyone. The measure of a group or project's success isn't their perfection (as is so often implied in political discussions), it is by how much their mistaken decisions are outweighed by their correct decisions.
And using that metric, the Kernel developers, including Linus Torvalds, have done very well indeed.
The Future of Human Evolution: Autonomy
Bruce
Bruce Perens.
You want too see the beauty of Linux Auto detection possibilities boot into knoppix.
I booted of the CD, got fully configured X, working sound, Working Xawtv, Working network with DHCP enabled, and therefore working broadband, and a working CD burner. It took a whole of like one minute to boot and it was everything I neaded. I Actually use it instead of Debian now for my main distro, mounting my old hard drive as scrap space.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Just to add to Bruce's points above: from what I heard, the biggest problem wasn't technical, but rather ESR's refusal to negotiate. The userbase of the kernel config system is the kernel developers; they had several tried-and-true ways of configuring kernels. Many of them were in fact quite happy with the existing system, and didn't see a need to upgrade at all; there was a general consensus that there were some shortcomings in the existing system, but those were very specific.
ESR solved these problems very well with CML2. By he also added a dozen features and changed a hundred other minor things, simply because he felt it was better that way. ESR was solving problems which only he perceived. For example, he was very interested in making it easy for "Aunt Tillie" to configure a kernel. Unfortunately, Aunt Tillie doesn't have a say in whether something goes into the kernel. Linus was apparently OK with CML2, but most of the other kernel developers were very resistant. No one ever explicitly refused CML2, but it never went in either, and ESR eventually gave up.
The impression I got was that ESR should have minimized the changes to the UI in his first version. If he had built something exactly like the old config, but with a new language and backend, most of the objections would have gone away. He then could have submitted the other changes; they may or may not have been accepted, but at least the underlying system would have been improved.
Yeah. It certainly is. If you've ever done embedded work before and found oneself subject to the cosmic horror that is slaying $500 worth of flash hardware because the kernel configs made a booboo one will realise just how fantastic ESR's theorem checking autoconfigurator would of been. What a shame it's been beaten off by the anti-python mob.Stupid stupid stupid.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
GGI tried to do too much and it abstracted too far.
Userspace PCMCIA drivers? That's a new one. I can only imagine that you were refering to the external set of drivers that used to be the standard and where characterised as being so hard to install that Linus himself had trouble with it. I completly understand his reasons for wanting that mess replaced.
ESR's configureator was massive overkill and it made life harder for developers. On top of that what killed it in the end wsa not Linus but ESR's refusal to update the patches to handle changes Linus made to the core code.
Not everything gets to be black and white.
>Thus, when someone comes up with the brilliant
>idea that the average person should be able to
>actually use the system, they're booed off. Yet
>these boo-ers are the same people who bash the
>mass market for using Microsoft or Apple's OS X.
Let's see.. When I started running Linux way back when I had to manually partition my hard drive, manually configure X (including plugging in video timings for my monitor), manually configure sound (including plugging in I/O addresses and IRQs), had to edit a config file in vi to add icons to my windowmanager (Afterstep Classic), had no real GUI filemanager, took 4 hours to figure out how to get my printer working properly, etc, etc.
Now, I can stick in a CD, have it autopartition, detect all my hardware, configure X, and has a full desktop environment with a GUI filemanager, where I can simply drag an icon to the panel. I can hot plug USB and PCMCIA devices to my heart's content. I can add new hardware, and it will detect and configure it on boot. I can sit back and let my machine take care of keeping itself up to date with all the latest security patches.
I must have missed an AWFUL lot of booing somewhere.
>Right now, when you install pretty much anybody's
>distro,
Except for Lindows, Lycoris, Libranet, OEOne, Xandros...
Come the release of Red Hat 8.0, you can probably add that to the list, given the focus they've put into creating a rational, consistent desktop in the betas.
>you start up with an interface that has tons and >tons of menus, icons, widgets, and whatnot,
>already up and running. It's an overload, and
>instead of trying to learn it, newbies are
>balking at it.
Taken a look at Gnome lately? From an end user perspective, all of the changes in Gnome 2.0 are aimed at usability, accessibility, simplification, and consistency. To paraphrase Havoc, they're removing the "crack rock" features, and "proving one good way of doing things instead of six broken ones".
>So why not have an easy-to-use kernel
>configuration system?
Noone has objected to the concept, only to the implementation. At different points there were issues with the rulesets in CML2 differing from CML1 in ways that the developers didn't agree with. The frontends used a different UI. It globally loaded rules for all architectures.
It has long been Linus' policy not to accept patches which introduce more than one fundamental change. The proper course would have been to make CML2 a drop in replacement for CML1, with no changes to the rulesets, and with front ends that completely emulated the old ones. Then, and only then, discussions on rationalizing the rulesets and providing enhanced interfaces would be appropriate.
Did it solve the problem it set out to solve - i.e. providing a more flexible syntax and a single parsesr? Sure, but it bundled too many other changes, and when you come down to it, it was replacing a system known to work with an unknown one.
On a side note, the whole topic is moot. Does Windows provide you with an easy to use kernel configuration tool? Does MacOS? No, because the end user should NEVER have to configure a kernel.
>Why not have an independent object model, where
>any distribution or window manager can use each
>other's dialog pages?
Umm... what on earth is that supposed to mean?
Matt
First, as other posters have said, there were valid reasons ESR's system was rejected. They weren't because it was for wussies.
Second, configuring a kernel will never be easy. You have to make a lot of decisions that require technical knowledge. Whether you do that in a text-based interface or a fancy graphical one doesn't matter very much. That doesn't mean a fancy graphical interface shouldn't be made, but it shouldn't be made for the reason of making it easier for mom to use Linux.
The correct solution to make hardware configuration usable for the masses is not to make building a kernel easier but to make building a kernel unnecessary. The system has become more modular over time.[1] Hardware has become friendlier to autodetection. Distributions like RedHat come with a single kernel that will work for just about anyone. When you start up with new hardware, kudzu will recognize it, ask you about it, and load the appropriate driver.
[1] and is still becoming more modular. 2.5 was supposed to completely remove the idea of compiled-in versions of stuff that is modular. I believe this got canned due to time constraints; look for it in 2.7 maybe.
Further, people are working on the configuartion language but there are bigger problems to be solved, everyone knows it and still the efforts don't fully address them. Like how do you know the configuation options used on the kernel you are running? There is no reason to change just for the sake of change and compilation speed isn't a huge issue, my dual amd compiles kernels so fast I don't care if I cut the speed in half. Plus, when you're hacking you usually work on a module or two and don't rebuild the whole thing.
The process is good, they don't take crap. The VM system and the IDE system are other prime examples. Al Viro is kind of mean to people but everyone else makes it pretty clear what needs to be done, why things aren't accpeted, even Al has expectations that he makes clear. There are expectations for robustness, it's more important than performance. Hans Reiser has had issues with that, he can't explain the robustness or answers concerns but he can point to benchmarks; clue: they don't give a shit if it's not robust.
There have been a handful of people who just don't cut it. Believe me, they can be replaced. It sucks, it'll be a dark day when Alan Cox or Dave Miller quit, if they ever do but they also know the rules, they play by them and they have their own forks if they don't agree. If Linus or someone else don't like your code, it doesn't get in, fork and show that they are wrong or make it better. This isn't bullying or anything like that, it's not that they are elitests, they have real expectations that aren't meet some times. Are some people and some parts of the kernel more equal than others? Of course, we're all human.
I take exception to the suggestion that the kernel team is throwing out great stuff for non technical reasons. They aren't they throw it out because it doesn't do what it is supposed to, people are trying to get it in for non-technical reasons with non-technical means or because it's not robust. It's not easy to write a VM or IDE system, there are a ton of expectations, it's a hard job, there are working solutions already that you have to do better than.
My question is why custom kernels are needed anyways? Except for embedded applications, such as Tivo, why should the common user have to build a custom kernel to get certain hardware support? Is the Linux device driver model really flawed as many claim?
Certainly its nice for development, or experimental patches such as low-latency patches. However it often seems necessary to build a kernel to get certain modules or hardware functionality.
Any comments on the Linux device driver model?
I know what hardware I have in my computer. But Linux often either labels it strangely, or labels it completely wrongly because of its bizarre way of operating. For example, I have not a single piece of SCSI hardware in my system. Yet for my IDE CD burner to work, I have to load the ide-scsi module, because apparently CD burning in Linux has only been implemented for SCSI burners, so the only way to get IDE burners to work is to emulate them as SCSI burners. Not intuitive.
Not to mention the millions of chipset names. In Windows, you choose the name of your card, and it figures out the chipset (that's in the worst case; usually it just auto-detects it in the first place). In Linux, you have to figure out who made the chipset on your card, which often isn't labeled on the box or in the manual, so requires some guessing or googling. An easy-to-find example is the emu10k1 for Soundblaster Live cards (this is actually documented by Creative); a harder-to-find example is the tulip driver for LinkSys network cards (most of the $10 LinkSys cards don't come with a manual, and the box doesn't mention what chipset they use). And so on for ever.
The Debian way of solving this is by default to build almost everything in the kernel as a module. That way if you discover you need some functionality, you don't have to recompile the kernel; just load the required module. It makes kernel compiling take a bit longer (~20 mins on my Athlon 1.33 GHz), but it's worth it IMHO for never having to recompile it again (until the next kernel upgrade anyway).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
And some folks questioned his motivation for getting this grandiose project into the kernel - was it just to help out, or was it primarily to establish additional hacker reputation for Eric? I'd be willing to give him the benefit of the doubt on this - he did the work.
... was it just to help out, ...
What's wrong with being motivated by hacker reputaion points? Isn't that what was supposed to replace money in the open source motivational system?
So an open source developer is evil unless he's motivated solely by altruism?
(That humming sound you hear is the beat between the spin rates of Ayn Rand and Friedrich Hayek.)
C'mon, Bruce. You know better than that.
Regardless of how much we want to help out humanity and all that, SOME of us aren't the leisure class - with old money, idle time, and an indoctrination in the obligations of nobility to give us internal satisfaction when we do something "just to help out" the benighted masses of the common man. Some of us ARE those commoners, with a family, a mortgage, and (if we haven't been laid off in the latest recession) a paycheck that is all that stands between using a shopping cart for groceries and using it for a mobile home.
If we're to contribute time and effort to the open-source codebase we need a way to keep that paycheck coming. Like "reputation points" to put on a resume, to find work the next time the current project is over or the current company goes belly-up.
Maybe Eric doesn't need any more points. But let's not have a big name flaming him for maybe wanting some - and thus convince thousands of onlookers that working open source is a good way to get a BAD rep, so they'd be better off getting that MCSE instead.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Good comment. Easy is perceived as bad. Yes, some easy things (Microsoft Bob) are really bad, and some difficult things are good, but Linux, like Unix in general (sorry to generalize but it's a cultural inheritance), suffers from an "old boys' club" mentality in which earned knowledge of arcana is viewed as an entry point. Sort of like morse code has been to ham radio -- there aren't rational reasons to require it any more (though some of us actually like to use it, sportingly), but removing the requirement brings out all sorts of anger from old timers who had to learn it.
Where it currently bugs me the most: Gentoo looks like a swell distro. Installing from source ends dependency hell and optimizes performance; I can buy it. But the setup is dreadful, basically more Linux From Scratch than anything else. The topic of an installer came up on Gentoo Forums. The "consensus" of the Gentoo user base is that "Gentoo is a hard distribution, and so the installation should be hard too." What rot! Once installed, no distribution should be gratuitously hard to live with. And while Gentoo lacks some of the GUI tools of say Mandrake or Red Hat, it's basically a clean system that shouldn't be that hard to manage. But the install procedure basically consists of printing out a lengthy set of instructions and doing a lot of hand edits of files, step by step, and hoping your system is enough like the developers' to work right.
Personally I don't find the current kernel config (make xconfig) to be that hard, just a little nerve-racking where some new options show up that I don't understand. Which is what Bruce set out to fix. We can quibble about implementation details but his heart's in the right place. Linux won't prosper so long as it lives with the old boys' mentality. If I want to join the Freemasons, I will.