New Linux Kernel Configuration System 370
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."
Roman's system is realy great... (Score:3, Interesting)
Linux Kernel developers are schoolyard bullies (Score:3, Interesting)
This is a pretty strong statement, and needs to be qualified. The Linux kernel developers are a very talented group of programmers that have written some impressive code which is helping stop the Microsoft machine control all of computing.
These programmers are doing professional-quality work, oftentimes on a completely volunteer basis.
We have lost a lot of good code which the kernel could have used because of some of the bullying that the kernel developers have engaged in. The lost of Eric's excellent CML2 is the most highlighted case, but we also lost a lot of improvments to the ugly IDE subsystem [lwn.net]. The IDE developer finally had enough [alaska.edu] of the schoolyard bullying games; and so Linux lost another developer.
I wonder how long Linus Torvalds will allow his "inside circle" to continue to mock and belittle attempts to improve the kernel code. If these actions continue, the kernel code will languish and become more unstable. Is Linus even considering adding next generation pthreads [ibm.com] to the kernel? I really want to see the Linux kernel become a real competitor to Solaris and AIX in the enterprise, so I hope that Linus fires some of the more nasty bullies from kernel development (I don't care how good Viro's code is; he comes off as being one of the bigger flamers) so that new ideas are truly welcome in to the kernel again.
- Sam
Re:does it pre-configure (Score:3, Interesting)
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.
Re:They weren't without reason (Score:3, Interesting)
Eric was playing games and his solution was technically superior. Done deal.
Re:If it ain't broke... (Score:1, Interesting)
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.
why are custom kernels needed? (Score:4, Interesting)
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?
missing the point (Score:3, Interesting)
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.
Linux is often misleading (Score:5, Interesting)
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).
This is a great idea, but it's not that new. (Score:2, Interesting)
Control Center->System->Linux Kernel Configurator
Re:poor guy (Score:2, Interesting)
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.