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."
When Eric S. Raymond tried to replace the Linux kernel's configuration system with "something better", he got booed off the stage.
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!
GoatPigSheep, the 3 most important food groups
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.
Right now, when you install pretty much anybody's distro, 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.
So why not have an easy-to-use kernel configuration system? Why not have an independent object model, where any distribution or window manager can use each other's dialog pages?
The only answer we seem to get is: "because it's for wussies!"
-- We live in a world where lemonade is artificial and soap has real lemon.
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.
Its not like they are saying "Lets ditch menuconfig and replace it with this!". For you and whoever else there is still make menuconfig. But I for one would welcome a better GUI than make xconfig, which I find pretty honkey. Since when are more options bad? It's not like they are forcing you into switching.
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.
[Eric's design] 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.
I grasp the significance of the other three points of contention you mention, but the fourth (above) doesn't jump out and grab me as an issue in and of itself. On the one hand, it may be that the method was overly complex (evidenced in part by the Python requirement and an unfamiliar idiom). Disallowing an unworkable configuration doesn't seem unreasonable, though. Is there a down-side to building that safety into the configurator apart from any flaws [heightened complexity] in Eric's particular implementation?
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.
After finally being able to get the page, I think that it is a great start and a tremendous improvement over Xconfig.
That said, I think he still needs to go further. Most users don't have a clue what all the options are or mean. Even with the descriptions and recommendations they will quickly become overwelmed.
I feel that users should be presented with a very basic and lean initial configuration screen. One that lists generic features for them to enable and disable. For example a single check box for IDE and SCSI HD support or a single checkbox to enable HAM radio support with generic or "standard" options preselected for those devices. Then there should be an advanced button that brings them to the complete configuration options, such as Roman's example.
This, combined with some form of modprobe hardware detection, would make kernel configuration a breeze, even for MCSEs. Also, the fact that this configurator reads the existing config, rather than starting with a blank slate everytime, is great!!
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.
KDE 3 does this via it's configurator with the current kernel/module system.
Here's a screenshot.
Really, I see no problem with the current system. It works well, and is totally modular. You never really even have to recompile your standard, vanilla kernel.
But hey. This new system should be given a chance, I suppose, though I see no use for it personally. I would prefer that it wasn't forced upon me in 2.5.
I've never needed more than vi to configure, make and install my kernel on BSD:
/usr/src
vi MYKERNEL
cd
make buildkernel && make installkernel
phew! I'm done.
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