Forgot your password?
typodupeerror
Linux Software

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."
This discussion has been archived. No new comments can be posted.

New Linux Kernel Configuration System

Comments Filter:
  • by Anonymous Coward on Sunday September 08, 2002 @11:50AM (#4215931)
    http://kerneltrap.org/includes/database.inc
    http: //kerneltrap.org/includes/database.mysql.inc

    There are probably more...

    For gods sake put stuff like that outside the web root if you can't set apache up properly.
  • Maybe other nuts ... (Score:3, Informative)

    by A nonymous Coward ( 7548 ) on Sunday September 08, 2002 @12:03PM (#4215985)
    I believe ESR got booe doff for two reasons. One, the new config required Python. Two, he wanted to change everything at once in ne huge patch, rather than bits and pieces which are easier to understand, back out and correct, and so on.
  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Sunday September 08, 2002 @12:07PM (#4216006) Homepage Journal
    The kernel developers are a pretty open-minded bunch. Eric's design was cool, he explained it to me a few years back, and it has seen use in other projects than the kernel. But I could see that it would be difficult for the kernel developers to accept:

    • 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

  • Re:Ironic... (Score:5, Informative)

    by _ganja_ ( 179968 ) on Sunday September 08, 2002 @12:12PM (#4216030) Homepage


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

  • 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.
  • Re:poor guy (Score:5, Informative)

    by ceswiedler ( 165311 ) <chris@swiedler.org> on Sunday September 08, 2002 @12:34PM (#4216146)
    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.
  • by Anonymous Coward on Sunday September 08, 2002 @12:46PM (#4216207)
    Does it scan your hardware and create a default kernel configuration with all ther drivers for your hardware pre-selected.

    for the curious, you can use dmassage for OpenBSD to get a kernel config file with only your hardware enabled (hardware that was enabled at boot time).

  • by Anonymous Coward on Sunday September 08, 2002 @01:03PM (#4216265)
    For people such as myself, it would mean that we now have to install Python on our systems - nothing major, just annoying. I'm not thinking that using C would be the best option either, but it makes sense in that the kernel is written in C, those who develop the kernel are familiar with C, so C should probably be used for a utility that configures the kernel.
  • by Idou ( 572394 ) on Sunday September 08, 2002 @02:30PM (#4216562) Journal
    are the marketing and PR departments to cover up or put spin on anything that could be even remotely considered a mistake.

    To parent poster: Do you honestly believe that worse things don't happens behind corporate walls!? Have you been living in a bubble!? The great thing about open source is, whatever happens, you will always have enough information to form your own opinion. As a corporate drone, I can safely assure you that you will NEVER get that level of detail from a corporation (even though the Internet has helped expose a lot). Personally, I think your shock is due to a lack of exposure to a REAL community (people argue all the time . . . that's how things get worked out), rather than anything having to due witht the Kernel developers. Goes to show how corporate our society has become . . .
  • by vadim_t ( 324782 ) on Sunday September 08, 2002 @03:08PM (#4216706) Homepage
    Nope, it makes perfect sense. Most CD drives and burners use ATAPI.
    From the google glossary at labs.google.com:

    Advanced Technology Packet Interface: a specification that defines device side characteristics for an IDE connected peripheral, such as CD-ROM or tape drives. ATAPI is essentially an adaptation of the SCSI command set to the IDE interface.

    ide-scsi is not really SCSI emulation. It is just SCSI over IDE. And Windows works the same, it just doesn't tell you about it.
  • by FreeLinux ( 555387 ) on Sunday September 08, 2002 @03:34PM (#4216790)
    Custom kernels are necessary because Linux is a monolithic kernel. That means that in order to use certain hardware or other features, the drivers have to reside in the kernel itself.

    Now, lets suppose that you just got the latest gee wiz device and you want to use it on your Linux box. You hook your "flux capacitor" up to the firewire port and nothing happens. Why, because either a firewire or a flux capacitor driver (or both) is required and the kernel doesn't have it installed. This means that you must rebuild the kernel with the appropriate driver in order for your new flux capacitor to work.

    Now, some may argue that the kernels should be pre-built with all the drivers and everything. Indeed, many distros do something like this for their stock kernels. But that still doesn't account for hardware that is yet to be invented. It also causes the kernel to grow into a giant that gives the term monolithic a whole new meaning. This large size means slow boot times and slower overall performance, in some cases. Surely, you don't want that?

    Indeed, many people want to trim the size of their kernel to an absolute minimum to improve the performance of their system, not to mention the security enhancement of removing unneccessary services. Do you really need HAM radio support? Most people don't, so why would most people want the HAM drivers loaded in their kernel? Do you need NTFS file system support, as I do? Probably not, especially with write access, so why include it? But at the same time, why prevent me from using it, as I need to?

    Even without the above reasons requiring the custom kernel, there is one more reason in favor of it. Part of the whole idea behind Linux is the ability to modify and customize it to your heart's content. That means if you want to modify your kernel you can. And this project will make such modifications easier than in the past. If you don't want to bother with customizing your kernel, then use the latest stock kernel from a major distribution, which will have mostly everything included. But, if it is slow or your flux capacitor isn't supported, you'll just have to wait and hope that the distro includes the support in its next release.
  • Comment removed (Score:2, Informative)

    by account_deleted ( 4530225 ) on Monday September 09, 2002 @12:04PM (#4221178)
    Comment removed based on user account deletion

Men of lofty genius when they are doing the least work are most active. -- Leonardo da Vinci

Working...