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."
It's a shame that Linus doesn't want to change, becuase Roman's system is realy great: faster, easier, and at the moment it still leaves the old system as default...
Here's how it works.
1: Run the kernel configuration program.
2: Select detect my harware option.... It sets up a 'default' configuration for you.
3: You can then go through and select/de-select anything you want.
You don't have to run step 2 if you don't want to you still have the choice you had before.
Now on the auto detection thing, if the script is wrong you can correct it, report a bug or whatever, just like you can with kudzu or USB driver autoloading.
It could even notify you that you hardware isn't fully supported and look here for an updated driver.
thank God the internet isn't a human right.
Eric was playing games and his solution was technically superior. Done deal.
I get the impression that Linus doesn't like side-effects. If you send him a patch that touches two completely different things, he'll probably reject it. So, I'd expect a new kernel config tool with the side effect of requiring Python to be rejected.
If it had been written in some other language that was actually available (as in installed - the system already has a C compiler, obviously) everywhere, it would have probably seen a lot more action.
But that's just me.
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?
We shouldn't have to decide for hundreds of packages whether we want them or what options they should be pre-configured with in the first place. Almost everything should always be dynamically loadable and should always be dynamically loaded. Modules should be independent between minor kernel versions. There should be very few options, and those that are there should be configurable at runtime. The few remaining compile-time options shouldn't require some complicated interface. If we want single-file kernel distribution, we should be able to create a single file archive of the kernel and the required modules in a way that the bootstrap loader understands.
While parts of the Linux kernel are great--the variety of kernels and file systems, for example--I think overall kernel architecture and configuration is by far the weakest part of the Linux operating system. It's not the GUI that inhibits Linux adoption by the masses--Linux GUIs are up to par with other platforms--it's the fact that a large number of people end up having to recompile the kernel to get things like audio, FireWire, power management, cameras, and USB working, even with the modularized kernels in some distributions.
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
It looks surprisingly similar to the KDE Kernel Configurator.
Control Center->System->Linux Kernel Configurator
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
The biggest problem wasn't technical, but rather ESR's refusal to negotiate.
I was the CML1 maintainer for two years, and I had a front-row seat for the CML2 fiasco.
ESR went for a big incompatible rewrite, in a new not-universally-deployed language, with a lot of paradigm shifts. Technically, this was okay. It's good to broom things out every now and then and the existing system is a mess. (The hardest part is dealing with module symbol versions, which are truly bletcherous).
Socially, this made CML2 a big pill to swallow. And ESR didn't help things. In my opinion, he never acknowledged that lots of smart hard-working people were using the existing system to get a lot of work done. He came across as a bad advocate ("your system is stupid, and you are stupid for using it") rather than a good advocate ("this new system will fix the two things that you are bitching about the most").
Also, it hurt a lot that there was a big mismatch between ESR's priorities of caring and the user's priorities of caring. To ESR, it was unimportant that the system was implemented in Python. To most other people, it was very important. To ESR, a correctness prover was very cool. To most other people, it wasn't very important.
One notorious mismatch was between Linus's strong desire to break up the monolithic help text into hundreds of files, and Eric's assessment of that task as minor.
Eventually it turned into a pissing contest, with a lot of people pissing on ESR because he was clueless about making his software work in its social/ecological niche. And when lots of people piss on a guy, of course he pisses back. And then the debacle happens, where no useful software happens, no useful ideas happen, a lot of people waste a lot of time in flame wars and stop listening to each other.
During this time, Alan Cox was one of the few people who stayed calm and looked at CML2 technically, without getting into the ad hominem battles. I respect Alan very much for his ability to do that. Alan had a negative opinion and gave good reasons why he didn't like it -- reasons that ESR should have listened very carefully to, I think.
Perhaps the worst part is that CML2 has lots of cool ideas, but we got into a position where the cool ideas can't even serve as experience for the next generation of people who want to take a crack at the problem, because of the ad hominem poisoning.