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."
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.
- 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.
How is that Ironic? I blame Alanis for this total misuse of the word... That's just a coincidence.
While I'm at it, will the people that insist on using the word "literally" to mean metaphorically give it a rest: "That was so funny I literally shit myself" or "That last tackle literally ripped his head off".
A journey of a thousand miles starts with a brutal anal raping at airport security
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.
>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.
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