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."

Comments

Roman's system is realy great...

[frankske]

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...

Re:does it pre-configure

[oliverthered]

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.

Re:They weren't without reason

[Anonymous Coward]

Python wasn't the problem, a few people didn't like it. I don't even remember anyone trying to veto it for it's complexity or anything either. There were 2 issues. It didn't do what Linus wanted it to do, namely decentralize a few thing, Eric simply ignored the requests for that. And then he tried to slide it in some how without peer review by trying to get developers closer to Linus to endorse it an include it rather than doing it in the open.

Eric was playing games and his solution was technically superior. Done deal.

why are custom kernels needed?

[mrm677]

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?

missing the point

[g4dget]

I'm sorry, but tinkering around with another graphical configuration app isn't going to fix the fundamental problems with Linux kernel configuration. (In fact, if anything, I find a single window application with a tree widget worse than xconfig.)

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

[Trepidity]

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).