Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Software

New Linux Configuration Tool 198

Posted by timothy from the usable dept.
paul.dunne writes "Looks like we are finally well on the way to getting a replacement for the old Linux configuration tools. Details in a thread on the linux-kernel mailing list. Basically, Linus likes it; it's written in C, so there are no "language issues"; and feedback on the mailing list so far seems positive and constructive."
This discussion has been archived. No new comments can be posted.

New Linux Configuration Tool More

New Linux Configuration Tool

Comments Filter:

  • menuconfig (Score:2, Insightful)

    by Kyeo ( 577916 )
    Whats wrong with `make menuconfig`?
    • Nothing that is not wrong with Fortran...
      • Down with the Linus Dictatorship. But seriously though, Linus should take into consideration the fact that he is not mortal, and he should either a) set up a chain of command or b) start an online feature election where people vote in changes to the kernel. What Linus has done is great and all, but he is a human like the rest of us. I would hate to see Linux die tomorrow because Linus did too.
    • its 20 years younger than make xconfig
      and make xconfig is already 10 years too old

    • Re:menuconfig (Score:5, Insightful)

      by Zakabog ( 603757 ) <.moc.guamj. .ta. .nhoj.> on Saturday October 12, 2002 @03:23PM (#4438059)
      Ok picture this scenario, it's 2030, the linux kernel config hasn't been touched, and you FINALLY got your, spouse/parents/relatives/neighbor/friend/whoever to install linux. They need to recompile their kernel for USB support. You tell them "Well just open a console go into the /usr/src/linux directory and type make menuconfig.", they say "Console? Type? Make menuconfig? Wha?" Linux is in dire need of a kernel config that's easy to use, easy to update, expandable, whatever. This seems like it's going to be just that. Oh yeah, I have no problems with make menuconfig, it's mostly for kernel developers and people who don't know much about configuring kernels.
      • You honestly think we'll be using USB in 2030? I very much doubt it. We'll probably be using some sort of wireless connectivity for all devices by then.

        Most recent distributions have built-in USB support anyway (RH7.3 does, as do the Gentoo kernels), remember almost no users should have to recompile their kernel, ever.

        If your distro doesn't include USB support, you shouldn't be forcing it on your friends/relatives/whatever.

        --Jon

      • Re:menuconfig (Score:4, Insightful)

        by Micah ( 278 ) on Saturday October 12, 2002 @03:54PM (#4438164) Homepage Journal
        End users should never, EVER have to recompile a kernel. Linux distros ship highly modular kernels that work with pretty much anything. Although slight performance or efficiency improvements can be had by compiling specifically for your hardware, for the most part it just isn't something that will be worth doing for the kind of user you describe.

        • Re:menuconfig (Score:1, Insightful)

          by Anonymous Coward
          in that case, when are kernels going to come pre-configured so that cd burners work?
          although figuring out cdrecord is probably far too confusing for your usual (l)user. same with scanners...

          • Re:menuconfig (Score:3, Informative)

            by buysse ( 5473 )
            Redhat: add hd[x]=ide-scsi to the kernel command line in lilo or grub. Run lilo (if necessary) and reboot. Done.

            No recompile necessary. Since 6.x.

          • Good point.

            Red Hat needs to *stop* compiling ide-cd support into their damn kernels. IDE-CD is not sexy, it doesn't support burners, and it causes more support problems than anything else.

            They should use ide-scsi by default.

        • Why? (Score:3, Insightful)

          by Slashamatic ( 553801 )
          make all modules, etc is hardley what I would want my poor aged aunt to do, certainly not not make menuconfig or even make xconfig. On the other hand, what is wrong with a question:

          Do you want to make an optimised system for your hardware (warning, this maky take some time)?

          If the process is transparent and without alarming and misleading little warning messages, where is the problem?

      • Honestly, I think make xconfig is SIMPLE. Click what you need...not sure? Click HELP (If you're not sure, say YES here)
        Honestly, configuring the kernel is easier then compiling software with missing libs that you thought you had..is it because it doesnt LOOK pretty? It gets the job done.

        • Re:menuconfig (Score:3, Insightful)

          by fault0 ( 514452 )
          > Honestly, configuring the kernel is easier then compiling software with missing libs that you thought you had..is it because it doesnt LOOK pretty? It gets the job done.

          No, the current system is being replaced mostly because it's fairly counterintuitive when it comes to dependencies and other things, and is fairly inflexible in other aspects. Remember that there is a backend behind the frontends. The most important thing with Roman's new config system is that the backend will be significantly more powerful.
      • An easy to use kernel config tool? There is one, its is called "make xconfig".

        There is a point where tools go beyond ease of use and step into "too easy to be dumb". There is nothing wrong with asking and expecting users to think. A system which allows users to remain clueless forever is not properly designed, contrary to popular belief. The point of tools, computers expecially, is to empower people, not let them wallow in their own ignorance but with a pretty GUI.

        • > The point of tools, computers expecially, is to empower people, not let them wallow in their own ignorance but with a pretty GUI.

          Ugh, I think you've missed the point of lkc completely. The current config system is being replaced mostly because it's too inflexible for the current kernel. Remember that there are backends behind these frontends, and lkc is significantly more powerful than the current config system. Even ESR agrees that it should be changed; after all, he set this whole thing going with his overly complicated replacement for the old one.

          lkc is a pretty good compromise, imho. It's probably why linus supports it.
      • That is the problem in and of itself. In Windows or MacOS, you'd just plug in your digital camera and be ready to go!

    • it blows (Score:5, Funny)

      by ArchieBunker ( 132337 ) on Saturday October 12, 2002 @03:28PM (#4438076)
      make xconfig is much nicer and has a better layout. I still have nightmares about make config Y Y N N Y N N oh shit ^C make config Y Y N...

    • The parent may be a troll, but I'll bite...

      The problem with the current kernel configuration process is not really the interface itself. ``make xconfig'' is not perfect, but it gets the job done well enough. The real problem is that none of the kernel developers really know the syntax used in this configurator. Thus, the code behind xconfig, etc., has become a sloppy mess of cut-and-pasted crap. I imagine the obfuscation is approaching a critical level where maintenance becomes nearly impossible.

      Good news, IOW.

    • Re:menuconfig (Score:5, Informative)

      by LinuxGeek8 ( 184023 ) on Saturday October 12, 2002 @03:46PM (#4438131) Homepage
      There's nothing wrong with "make menuconfig". I find it actually better to navigate then "make xconfig".
      The problem is that "make config", "make menuconfig" and "make xconfig" each use different methods. Roman Zippel now made a seperate backend and frontend. There's one backend, and there can be several frontends, like "make config", "make menuconfig" and "make xconfig".

      The new xconfig uses Qt, but there could just as wel be a Gtk+ frontend, or a Tcl/Tk (ugh) frontend.
      But from what I read, it seems that the frontend needs to go with the kernel itself. I hope I picked that up wrong, and that it is possible to use a xconfig (Qt) frontend with different kernel versions. That way the backend, and the 2 console frontends can ship with the kernel, and the gui frontends can be shipped by the distributors.

      • Re:menuconfig (Score:4, Informative)

        by Anonymous Coward on Saturday October 12, 2002 @05:52PM (#4438501)
        http://kerneltrap.com/node.php?id=455

        Linus answered, "Too ugly. I actually think QT is a fine choice, I just suspect that it's going to cause political issues." Fortunately, Roman has designed his new configuration system in such a way that the subsystem could be distributed with the kernel, and the graphical configuration portions could be offered separately.

  • Whats good for linux is good for open source (Score:4, Interesting)

    by jormurgandr ( 128408 ) on Saturday October 12, 2002 @02:44PM (#4437929)
    It's nice to see productive discussion (rather than the oh-so-common flame wars) taking place to the benefit of linux/open-source. Hopefully this will provide a much-needed improved configuration tool for linux, and will also demonstrate to the "closed-source" community just how beneficial open-source really is.
    • I think a lot of what may seem a flame war is actually productive discussion. The LKML has a really pretty nice way of having productive conversations that sometimes border on flame wars. Between Linus and Alan Cox, things usually seem to head in reasonable directions, even if they start out badly. Of course, any one message taken out of a thread may seem pretty bad, but it's important to follow the threads through to the end to get the whole picture.
  • "I had to use my own Makefile again (Rules.make is slowly driving me insane)."

  • now (Score:3, Insightful)

    by anonymous coword ( 615639 ) on Saturday October 12, 2002 @02:46PM (#4437938) Homepage Journal
    all we got to do is use a free version control system and we're set.
    • we should also try to get rid of the non-free firmware code included within the Linux project. 'Pragmatic' Linus is somewhat short-sighted here in my view with his "best-tool" approach.

      Richard Stallman and Bdale Garbee (the current Debian project leader) and others have already mentioned these important legal problems.

      RMS [www.linuxworld.comhttp]

      DPL [debian.org]

    • Re:now (Score:3, Funny)

      by aardvarkjoe ( 156801 )
      Great idea! Why don't you write one so Linus can use it?

  • Screen shots? (Score:1, Interesting)

    by Anonymous Coward
    Where's the screen shots? It is GUI, isn't it?

    • Re:Screen shots? (Score:5, Informative)

      by Anonymous Coward on Saturday October 12, 2002 @03:52PM (#4438153)
      You can find some screenshots at KernelTrap: http://kerneltrap.org/node.php?id=404 [kerneltrap.org]
    • Where's the screen shots? It is GUI, isn't it?

      Not that having a GUI is bad, but I am sure that the kernel crew wouldn't put out a graphical-only interface. I'd be willing to bet that a majority, or at least a significant amount of the linux boxes out there with custom kernels don't have X. Think of all the servers and such. You would be screwing a vast majority of admins and really f'ing up command-line installs like gentoo. I'd be down for a nice graphical interface, but one that was only a front-end to the real program.

  • just a kernel tool (Score:4, Insightful)

    by Squarewav ( 241189 ) on Saturday October 12, 2002 @02:49PM (#4437947)
    when I saw the headline I was thinking a universal way of configuring a linux system buts its just a kernel config tool, its not much of a tool ether, if the thing were to auto detect my hardware and compile for it I would be impressed. what I found funny is they claim "make xconfig" as a new tool, I used that like 7 years ago on slackware.

    what linux needs is a universal way of configuring a linux system so that you can pick any disto you want without worrying about how hard will it be to configure
    • Perhaps you want a universal linux distribution tool?

      Sorry couldn't help it... :)

    • Re:just a kernel tool(well Linux is just a kernel) (Score:5, Informative)

      by wikki ( 13091 ) on Saturday October 12, 2002 @03:24PM (#4438066)
      Not that I really want to get the whole GNU/Linux debate and flame war going, but Linux is just a kernel, so technically the title is correct. I Linux configuration tool can't really be much more than a kernel configuration tool.

      As far as needing a new tool goes, I really don't see the need. make menuconfig works great for me, but there might be some underlying problems when adding new functinality to the kernel and whatnot. Having it detect my hardware and build a static kernel with no modules would be pretty damn cool.

      • Re:just a kernel tool(well Linux is just a kernel) (Score:5, Insightful)

        by dozer ( 30790 ) on Saturday October 12, 2002 @05:29PM (#4438435)
        I really don't see the need. make menuconfig works great for me

        The current CML is a heinous mess. It's a strange , mix of shell syntax and cusom declarations, making it difficult and error-prone to express even moderatly complex dependencies. Kernel configuration needs a purely declarative language, which is what Roman has made.

        It won't make your life much easier so I'm not sure why this story made Slashdot. But it will probably make kernel developers' lives much easier. And, OK, it might make your life slightly easier. No more weird questions like "why do I have to statically link the framebuffer driver just to use SiS DRI?" Answer: it was too hard to express the correct dependencies in CML1.

        Having it detect my hardware and build a static kernel with no modules would be pretty damn cool.

        No, it really would not. If you're compiling a super tight kernel for a beowulf cluster, you've already got the expertise needed to compile your own kernel. You don't need hardware detection. And, if you're Joe User, then please, for pity's sake, use one of the nice, modular kernels that comes with your distribution. Do not cause yourself grief.

        There really is no middle ground. Aunt Tillie is a purely fictional character. When he wrote CML2, ESR for some reason burned huge amounts of time on autodetection. I'm happy to say that all that work was thrown in the garbage. Nobody wanted it. Kernel-level hardware detection is simply unneeded complexity.

        Module-level hardware detection is desperately needed, however. It's coming in various forms, like the PCI hotplug scripts and driverfs. I can't wait.

        • If you're compiling a super tight kernel for a beowulf cluster, you've already got the expertise needed to compile your own kernel. You don't need hardware detection. And, if you're Joe User, then please, for pity's sake, use one of the nice, modular kernels that comes with your distribution.

          Joe User deserves to get as much out of his computer as the beowulf people. And what if Joe User is using a CD-RW drive, or something else that the nice modular kernel doesn't handle?
        • "Nobody wanted it."

          Who the heck are you talking about? I sure as hell would like it! Why the hell would you NOT like autodetection? Do you LIKE clicking widgets for no reason or something? I suppose you ENJOY writing your own X modelines? If things can be made easier without any extra effort (it is already done!), why the heck would you NOT want this? Of course there is middle ground. In fact, I'd argue this "middle ground" is the majority user base of Linux - because anybody now has the freedom of throwing Linux on an old machine and running a server. These are above power-users, but below kernel hackers - a really BIG middle ground. And if you ever hope for Linux to be viable to the masses, this stuff certainly needs to be easier...if only to make life easier for VARs. I don't understand this "if it is hard it must be better" mentality.
        • "Having it detect my hardware and build a static kernel with no modules would be pretty damn cool."

          No, it really would not.

          Yes, actually it would. Note that he isn't saying it should be the only way available, ofcourse you may need to crosscompile or not compile drivers for a soundcard in your server that you are not using anyway - but, if there would be an option like 'make detect-hardware' which would do the same as make menuconfig, but only select the hardware you have and some common stuff that most people use anyway, I think that would be great for 'newbies'.

          Maybe you could even edit that configuration using 'make menuconfig' - at the very least it would have saved me the occasional hassle of grabbing a rescue CD because I stupidly forgot to turn on support for IDE harddisks, or somesuch equally stupid mistake :)

      • Sorry... Sorry, pardon me and excuse me, apologies for what I'm about to say... But, the tools used to compile kernels are crap and are one of the main deterrents to new users adopting Linux.

        I've been running Linux for about 1.5 years and love it, considering myself a novice but a very literate one at that. I've compiled my own kernels but NVidia and other binary RPMs prevented my ever using one.

        But really, I've been in computers for 15 years and as much of a Linux goof as I am I can talk carrier signals and user contexts and the OSI model and blah blah... But compiling a kernel is still a frightening chore. While many distros help to resolve this with nicely compiled binary kernels it doesn't help us when tonnes of web pages out there suggest we compile our own kernels and as inexperienced goofs we try.

        What I'd really like to see is something seamless, that does not die unexpectedly, with explanations in human language. Not sure if this tool is it but I've gotta concede there is tonnes of room for improvement.

    • They're not saying that "make xconfig" is new, just that they have changed what it means into a frontend for this new configuration system.

    • The title of the article is correct; remember that the kernel is Linux, and the OS is GNU/Linux. So this is a Linux configuration tool. So what you want is a universal GNU/Linux configuration tool (I know, I know, now you all hate me and want me to die). The problem with writing this universal tool is that every program uses a different configuration syntax, so you would have to write each sub-tool separately. Alternatively, all configuration done with the tool could be stored in a special format and translated to the real config format by a conversion program.

      • Re:just a kernel tool (Score:4, Insightful)

        by Speare ( 84249 ) on Saturday October 12, 2002 @05:03PM (#4438357) Homepage Journal

        The kernel is named Linux.

        The OS is named whatever the OS-bundler wants to name it. Debian developers and RMS zealots may enjoy the name "GNU/Linux" but not everyone agrees. Those who want to call it GNU/Linux, fine, have fun but don't expect to change everyone else's perception.

        To fully name a distribution by what makes it tick, the name should just as visibly represent XFree, Perl, Apache, and other non-GNU components which are key selling-points. A log cabin isn't called a log, mud, spackle, plaster, lead pipe, steel rod, ceramic tile cabin, and likewise many distributions focus on the one word which captures the typical buyer's attention.

        Red Hat does not call their product GNU/Linux. They could decide to call it Swiss Cheese if they wanted. However, the word Linux has plenty of press attention and the product is built with much of the same ideals as the Linux kernel project: good technology to be put to use by anyone. So the name stuck. Red Hat Linux 8.0, for example.

        • I don't think you understand. Without GNU Linux is nothing. Linus didn't just wake up one morning and write a C compiler, C library, editor, debugger, etc. He wrote a kernel. And then he and others adapted the GNU system to run on his kernel. The GNU in GNU/Linux isn't about how much code GNU contributed; it is about giving credit to the GNU project that has spent that last twenty years working on writing a UNIX compatible OS. You can run GNU without the Linux--just grab the latest Debian Hurd images. The Hurd works today. Pure GNU may not work as well as GNU/Linux, but it works. Explain to me what you would call a system running the Solaris kernel but with all of the Sun tools replaced with GNU ones. Would that still be Solaris? Just think how you would feel if you were RMS and spent so long working on GNU, only to have Linus come along and not give your life's work any credit. RMS suggested Lignux before, I think that was perfectly reasonable. But Linus wouldn't agree to adding one silent letter...I also dislike the Open Source movement and just wish everyone would put their egos away (so now you'll call me a hypocrit).

          (on a side note, today was the first time since I started reading /. three years ago I was moderated down, and I'm going to guess this comment will be moderated down too). I'm cold, wet, and tired. Don't take what I wrote the wrong way.

          • I do run a Solaris system with many tools replaced with GNU equivilants because I like uniform or near uniform behaviour across the platforms I support. You know what I call those systems, Sun or Solaris systems, not GNU/Solaris systems.
          • I don't think you are living in any kind of realistic world here.

            It all comes down to common usage. People associate the kernel with the OS. Whether this is not is mostly is irrelevent.

            Also, the word "GNU" sounds quite unprofessional. RMS, as a big beirded hacker type, probably doesn't care. I would never say to my clients that they getting ordering hosting on computers running 'GNU' software. Linux has a lot more brandname power, and just sounds more professional.

            Perhaps the FSF should think of a new name for 'GNU'. Currently, it's too unprofessional and nerdy.
          • Linus didn't just wake up one morning and write [snip]. He wrote a kernel.

            Which, from looking at HURD, Stallman's folks can't do very well.

            That isn't the point. Linus came up with "Linux" after someone else suggested it. He didn't run around promoting the word "Linux" as the name for the distros -- it just happened. If Stallman wanted to influence the name, he should have done something long, long ago, back before the name fell into common usage. Now, he'd be trying to change the behavior of the world, and it's just not going to happen, any more than the terms "hacker" or "Free Software" will be used the way Stallman wants.

            Furthermore, I really, *really* hate Stallman's name choices. They're difficult to pronouce, and don't fit with standard English (their logo is a gnu, so why the hell isn't "GNU" pronounced the same way?) He wanted to name it "Lignux"? Ugh, no. I'll skip it.

            Besides, what GNU tool can you think of, with the possible exception of grep, that has as stunning performance in its field as the Linux kernel does?

            • He wanted to name it "Lignux"? Ugh, no. I'll skip it.

              Remember the 'G' is silent so it would have been pronounced the same way as 'Linux'.

              Which, from looking at HURD, Stallman's folks can't do very well.

              The Hurd isn't a kernel; gnumach is. Gnumach does suck, and a few of the Hurd developers are porting the Hurd to L4. I think the Hurd would have gotten more attention if Linux hadn't come along. But anyway, that doesn't really matter. The Hurd works. Gnumach 2 will be released soon, and the Hurd will finally have support for things like large file systems. Eventually the Hurd will be ported to L4, but right now development on l4hurd is stuck because a new version of L4 is going to be released in February, and the Hurd developers would have to sign an NDA and not release their code until february (this is what wolfgang told me).

        • I agree wholeheartedly. I've felt much the same way through the whole series of "Linux" and "GNU" naming complaints, but I've never been able to phrase it this well.

          Frankly, a Linux system would suck pretty much (at least as a main workstation) without any of a large number of components. X, the kernel, the UNIX utilities, a text editor, initscripts...

          So if someone wants to credit the GNU folks for their software, great. If someone wants to credit Linus for his kernel, great. But don't try changing the names of the distros -- the distro, the collection of tested and documented things, is their *own* production with immense value of its own. The distro names shouldn't be dependent upon their components in any way.

          I can see the argument for calling Linux systems in general GNU/Linux systems. The problem is that that's longer, and lots of *other* systems happen to use GNU tools -- using Solaris w/o the GNU tools sucks. Saying GNU/Solaris is just a pain. Yet there *is* no other toolset (that I know of) for Linux other than the GNU toolset.

          What Stallman is missing is that names aren't there to give credit. Linus just came up with "Linus" after someone else suggested it. Names are meant to be a useful, unique, recognizable, *short* identifier. Not a credit-granter -- that can go inside the product on about boxes, (Microsoft and Netscape slapping their company names on their products notwithstanding). Names are for the user.

          So all in all, I think that Linux boxes should be called "Linux boxes" rather than "GNU/Linux boxes". The two have equivalent effective meaning, and one is easier to use (yes, you can go around like Stallman and explain what you mean to every blasted person by "Free Software", "GNU/Linux", "hackers", and so on, or just use the common definitions).

          There's GNU grep, the Linux kernel, and Red Hat Linux. All make sense, and I wouldn't want to see any change.
    • Good post (sorry, no mod points.) The LSB, or Universal/Galactic/Pan-Galactic linux, might be the ground prep necessary for stimulating the development of such tools.

    • Re:just a kernel tool (Score:5, Funny)

      by Anonymous Coward on Saturday October 12, 2002 @03:41PM (#4438115)
      There is a universal linux configuration tool. It's called vi

    • Re:just a kernel tool (Score:4, Interesting)

      by LinuxGeek8 ( 184023 ) on Saturday October 12, 2002 @03:55PM (#4438165) Homepage
      what linux needs is a universal way of configuring a linux system so that you can pick any disto you want without worrying about how hard will it be to configure.

      If you don't mind, I'd like to say "NO".
      I prefer it the way the Linux distro's do it now. Like Mandrake, which even recognises printers, and sets up xawtv for your tvcard during install. These are not kernel issues, but userspace issues. Most distro's ship nowadays with every driver as a module. If the installer detects everything, you should be fine.
      There are just a few issues, where it would make sense. I really like the way FreeBSD handles network card drivers. It seems to detect them fine, and load the right driver. I'm not sure how it can be done, but it happens. That's something in kernel-space, and I hope it will get included in Linux too.
    • when I saw the headline I was thinking a universal way of configuring a linux system buts its just a kernel config tool
      Uhh, the name of the kernel is Linux. So "New Linux Configuration Tool" is correct. It didn't say Linux distribution configuration tool.
    • This is actually a replacement of the internal code for figuring out how the kernel can be configured (what options there are and what effects they have on the code); the existing code is an incredible mess, with at least 3 separate implementations that generally give the same results, but aren't necessarily identical. The good thing about this tool is that it will make writing a configuration tool only require dealing with the interface aspects, and not with the kernel configuration scripts and file format.

      This means that it will be a lot easier to add a version that will configure the kernel based on autodetecting your configuration, and to integrate a version with configuration tools for other packages. There's already plans to have gtk and qt versions of xconfig that don't need to be in the kernel tree.

  • What this is about (Score:5, Informative)

    by Anonymous Coward on Saturday October 12, 2002 @03:08PM (#4438014)

    This is about how the linux kernel is configured and built. At the moment there are a mess of makefiles and shell scripts that provide make oldconfig/config/menuconfig/xconfig etc.

    LKC is a new configuration file format/language for describing how the configurations options interelate and which are set, and a parser for this language that interfaces with the build system and tells it how to build your kernel. See this [xs4all.nl] if you're interested.

    This is all probably A Good Thing (it should make maintaining the the build system easier), but people who don't maintain linux makefiles probably won't find this the world's most fascinating feature. make menuconfig still does basically the same thing. Your .config files in 2.6.x/3.0.x will be in a different format to those from 2.4.x if you look. That's about it.

  • Owww. (Score:4, Insightful)

    by Pig Hogger ( 10379 ) <pig DOT hogger AT gmail DOT com> on Saturday October 12, 2002 @03:08PM (#4438015) Journal
    Now, those who don't know what the kernel is will fiddle around with it.

    I wonder what kind of horror stories we'll see...

    • Re:Owww. (Score:3, Insightful)

      by gimpimp ( 218741 )
      i thought that was the whole point of oss?
      people can play with the source, if they're interested. it's not like there's not enough documentation for them to get ir right.

    • Re:Owww. (Score:2, Insightful)

      by webprogrammer ( 518832 )
      Saying that something shouldn't be made easier because it would let dumb users use it is not going help linux's adoption.

      Being able to recompile a kernel is a major advantage that linux has over other operating systems. This should be brought to the forefront instead of hidden. It would be nice if a non-technial user could recompile a kernel without archaic commands and worrying about bzImage, etc.

      Most modern distributions come with a kernel that supports the lowest common denominator, and support for tons of peripherals that the user never needs. Wouldn't it be nice if they came with a stripped down kernel, and the user used a simple configuration program to "enable USB" or "optomize my computer for the home-office."?

      Obviously this wouldn't be the offical kernel configurator, but it would be nice if the new system allowed exapandability in this area.

    • Re:Owww. (Score:2, Funny)

      by hickmott ( 122356 )
      Good grief! I wouldn't be running Linux in the first place if I didn't want to fiddle around with things I don't understand.

      What kind of horror stories will we see? Amusing, instructional ones.

      --Andy Hickmott

  • What about kde? (Score:3, Informative)

    by anonymous coword ( 615639 ) on Saturday October 12, 2002 @03:09PM (#4438016) Homepage Journal
    Kde contains a very good kernel congiurator in the control center. Now if they could take that, make it stand alone (no kde needed) and bundle it with the kernel then it could be great

    • Re:What about kde? (Score:2, Informative)

      by gimpimp ( 218741 )
      the kde one is just a frontend to the current configuration tools.
      i think this one checks module dependancies in the kernel.

    • Re:What about kde? (Score:4, Informative)

      by cornice ( 9801 ) on Saturday October 12, 2002 @03:46PM (#4438132)
      Remove KDE and you get xconfig (menuconfig for X).It's not so much about a spiffy end user interface as much as a tool set to accomodate the various interfaces into the future (spiffy and not so spiffy).

      From the website [xs4all.nl]
      The important changes which come with LinuxKernelConf are a new configuration syntax and a single parser for this language. Multiple utilities can be build on top of this, right now only the old configuration utilities are reimplemented which make use of it. The console utilities ("make config" and "make menuconfig") preserve their old behaviour for all the kernel hackers which loathe drastic behaviour changes. :-) The new X interface ("make xconfig") shows a bit how kernel configuration could be done in the future.

    • Yes, but the problem is that the KDE kernel configurator is just a frontend for the current config system, which is old, icky, and inflexible.

  • to tell you the truth.... (Score:2, Insightful)

    by Anonymous Coward
    i've been using linux's make menuconfig since i switched from windows. i been using make xconfig for a while now. They are both intuitive tools and i don't know why there's such a upraor on replacing it. I like it. If you create even easier ways to screw up your system, guess what will happen
    • See, it's not the tools that are the major problem. It's the backend that powers them that is (it's quite inflexible for kernel developers). This is what lkc is mostly replacing.

      lkc can use a wide variety of frontends, including rewritten versions of the current make menuconfig (ncurses) and make xconfig (tcl/tk), including many others, including the new make xconfig.

  • Detailed summary of the LKML thread... (Score:5, Informative)

    by rimdo ( 160461 ) on Saturday October 12, 2002 @03:29PM (#4438079)
    may be found here [kerneltrap.org].

    -rimdo

  • Who cares? (Score:2, Interesting)

    by LordNimon ( 85072 )
    The Linux kernel still doesn't have a hardware detection/configuration, and probably won't get one for years at this rate. Building a kernel still requires you to know the manufacturer and model of every freakin' piece of silicon in your machine, this "new" utility doesn't make anything easier. How hard can it be to write a utility that scans /proc/pci and creates a kernel config file from it? Hello, Linus?!?!?! It's the 21st century! Wake up!

    • Re:Who cares? (Score:5, Insightful)

      by aardvarkjoe ( 156801 ) on Saturday October 12, 2002 @04:21PM (#4438246)
      If it's not so hard ... then why don't you write it? Linus is busy working on the kernel, the portion that he wants to work on, the one where he has the most experience and expertise. Complaining that OS software doesn't have the features you want is generally pointless. It doesn't happen until somebody who actually wants it goes ahead and implements it.

    • Re:Who cares? (Score:3, Insightful)

      by thefogger ( 455551 )
      Yea, right. I mean, when I rebuild the Kernel for my Windows machine I have all this hardware detection - oh, wait, no. Well anyway, last time I rolled my own OSX Kernel there was this tool - d'oh! But still, just think of the BSDs they all can build their kernels through automatic hardware detect.. ah, crap. Linux just needs this feature, it's standard in all OSes of the 21st Century ;-)

    • Re:Who cares? (Score:5, Interesting)

      by tubabeat ( 605286 ) on Saturday October 12, 2002 @04:35PM (#4438289)
      Hmmm, but isn't this new tool a backend which permits new interfaces to kernel configuration to be built which interact with it?

      Surely then, it is a logical step for someone (with __lots__ of time) to build a frontend which scans the machine's hardware and automatically makes the right choices? Perhaps even preventing configurations which would prevent the kernel from booting?

    • Re:Who cares? (Score:5, Insightful)

      by Sivar ( 316343 ) <charlesnburns[ AT ]gmail DOT com> on Saturday October 12, 2002 @07:39PM (#4438746)
      Building a kernel still requires you to know the manufacturer and model of every freakin' piece of silicon in your machine, this "new" utility doesn't make anything easier.
      1) If you can't figure out what hardware is in your own computer, use a distribution like SuSE or any of the others that do have hardware detection.

      2) No, actually you need know only some parts, such as the video card, sound card, and others that do not have a universal driver like hard drives.

      2) If you are going to use Linux, you should probably at least know the most important parts in the computer you are using. It isn't difficult. If Grandma doesn't know, she can either use an easy distro, or not use Linux. Even with an "easy" distribution, Linux is probably not for her (nor should it be, says many)

      3) Unless you use the default drivers that Microsoft provides, which usually suck, you need to know the same information about your hardware in Windows. Say you want to upgrade your video driver. Well, if you haven't a clue what video card is in your system, what website are you going to visit to download those drivers?

      I agree that it would be nice in the eyes of many people if Linux, the kernel, could autodetect the installed hardware, but it wouldn't be that great an advantage. If Windows detects hardware that it doesn't have a driver for... Now what? You still have to know where to go to get that driver, since the ones that come with the hardware are almost always buggy prerelease bugware. Even if you would know, half the time Windows will say "Unknown PCI device" or some other incredibly useful piece of information. With Linux, you have all drivers for all supported hardware Right Now(TM), and can simply enable those modules on most distributions (oh, and then NOT have to reboot).
      I would have to stretch the facts to say that one system is better than the other once you are used to both.
      Seriously, it sounds like Windows is right up your alley. If Linux doesn't have a feature that is very important to you, and Windows does, that is a perfectly legitimate reason to use Windows (not that you need one), and not a perfectly legitimate reason to say "It's the 21st century! Wake up! to a person who has spent a good deal of his life working for the common good, and not charging a dime.

      --Sivar
      • Nice FUD.
        I recently bought a USB HID mouse, and had to get it working in both Windows XP and Linux 2.4 (some version of gentoo).
        Linux:
        - Recompile kernel -- add usb and hid support.
        - Reboot && pray
        - Update gpm config to read from usb mouse instead of old ps2 mouse.
        - Update X config, same.
        - Update SVGALib config
        - Add lines to X config to map the mousewheel and other buttons properly, and to get a decent sensitivity

        Windows XP
        - Plug in mouse. Wait aprrox. 3 seconds. It works.

        The same is true with most hardware. and no, you don't need to know what hardware is installed in windows, because it will automaticly search microsofts site for the latest compatable drivers. What you said was true maybe 4 years ago, but much has changed.

        I agree with the original poster that Linux needs something to automaticly detect hardware installed.
        All you would have to do is parse dmesg and /proc/*, then feed the device info into a CGI script that will regexp match it and return the url for the download script. (I realise the insecurities in this, but signing everything should help)

        • Re:Who cares? (Score:2, Informative)

          by A Life in Hell ( 6303 )
          it exists, it ships as a part of many distro's (debian, mandrake, probably everything else), and it's called hotplug. apt-get install hotplug on debian, but I can't speak for anything else. works flawlessly here.

          (you probably want to apt-get install discover, too, which detects PCI/PNP hardware automatically each boot. it makes linux MUCH MUCH more comforatble :)

          - jj

      • Re:Who cares? (Score:2, Interesting)

        by LordNimon ( 85072 )
        1) Distributions with hardware detection don't help if you need to add support for hardware that was created after the distribution was installed. What if I upgrade to a new network adapter that was just released? The "easiest" way way to add support for that hardware is download a new kernel with that driver and rebuild it. I can't just add the driver to my current installation.

        2) If I upgrade to a new piece of hardware under Windows, that hardware will come with a floppy or CD-ROM that has the drivers on it. Windows drivers, but never Linux drivers. All I need to do is stick the disk in the driver, and Windows takes care of the rest. I don't need to know what kind of hardware it is.

        3) If I install a new piece of hardware, Windows has the capability to go out to the Internet to look for a new driver. Linux will NEVER have that capability.

        Look, I hate Windows as much as the next time. I don't use it, and I'm not going to, but I still think Linux could improve a great deal when it comes to the driver model.

  • .config file formatting nitpick (Score:5, Insightful)

    by ortholattice ( 175065 ) on Saturday October 12, 2002 @05:35PM (#4438456)
    When recompiling the kernel, I find it convenient to interchangeably use any of make config, make menuconfig, or make xconfig as the need/mood arises. Sometimes I want to diff the .config to see what actually changed in response to some checkbox. Or I want to see what the difference is in the .configs of two different machines for troubleshooting or whatever. The problem is that each tool produces a slightly different (though equivalent) format of .config, rewriting the entire .config to its own taste, so diff'ing is not so simple. I wish the config tools would agree on a common formatting standard so that diff would produce zero differences. Barring that, at least not touch the .config lines the user did not change. Does anyone else find this a nuisance, or am I the only one?
    • Do what I do to solve this exact situation. After using either make menuconfig or make xconfig, run make oldconfig. That will take any .config and output it the way make config does.
    • Yeah, it annoys me too.

      I always finish off with a 'make oldconfig' so that I can compare apples with apples. This is made much easier for me because I build with Debian's make-kpkg which does the 'make oldconfig' for me and saves the .config within the package as well.

      Andrew.
  • Is subjecting the kernel source tree to autoconf/automake possible? One obvious benefit of the current scheme is that it allows three different front ends to the process. Would that be why CML1 was written in the first place?
    • I think that's a pretty cool idea. However, it's a lot easier to just say "make sure you're using these specific versions of these specific tools when you compile your kernel". That way, nobody has to spend weeks trying to figure out all the possible software permutations (is your compiler environment sane? good. how about your libc? good, good. how about your GCC version -- is it a known good version? etc.)

      It's a lot easier to just tell people what versions to use, then heckle them when they use non-supported versions.

      If I had infinite patience, I'd try to do something like a kernel autoconf with all sorts of checks and dependencies, but... whoa... this is a project for a better man than me.

    • Re:Naive Question (Score:3, Informative)

      by sfraggle ( 212671 )
      autoconf/automake is useful for user space programs where you're depending on various other libraries and tools and need to detect where they are located and set up the right compiler options for them automatically. As the kernel depends on very little (gcc, make, a few standard Unix tools) it wouldnt be appropriate in this case.

      Besides, autotools are horrible.

  • From a newbie.. (Score:2, Offtopic)

    by rosewood ( 99925 )
    I really liked Redhat's implementation of Linuxconf. For a lot of setup things, it was very tight and very easy to naviage. I liked that it had CLI, GUI and web interfaces and it was modular.

    I never understood why it was so disliked -- Ive never found something that can get sendmail working quicker :
  • New Linux Configuration Tool

    I try to make a point to differentiate between GNU/Linux and Linux in my posts since that article was posted, but considering that most people (as measured by my personal experience perusing slashdot) still don't, I thought it was talking about a new GNU/Linux configuration tool.

    A single backend for kernel configuration sounds great. As long as it's easy to write for and a billion crappy frontends don't spring up from people that think they have a great idea but are really just polluting free software users' systems with difficult-to-use, inconsistent, buggy software, this could lead to a truly user-friendly kernel configuration tool.

    I must admit, though, that I'd be far more enthusiastic about a new GNU/Linux configuration tool that makes it unnecessary to read a new man page and 10,000 screens of documentation just to learn how to write a textual configuration file to get one small feature of my GNU/Linux system working. Then again, I'm one of those people that would like to see the total number of linux distros in the world cut down to three or two or better yet one. Don't get me wrong, I'm all for choice, I recognise that all GNU/Linux distros have their good point(s), and I think Linux is great, but unity is important as well. It's just my opinion that we have more choice than we know what to do with at the expense of a unified, strong, and sensible GNU/Linux architecture and I'd like to see the balance swing the other way.

    </flamebait>?
  • I am rather confused by the choice of C as the language - Eric R. did have the right idea when he decided to use Python, simply because it is easier to maintain, easier to read, and eliminates a whole bunch of C mistakes like memory leaks that will undoubtedly turn up in the comming weeks and months and be the usual hell to find. Why use C instead of a high-level scripting language?

    • Wish I knew! (Score:3, Insightful)

      by Balinares ( 316703 )
      That's an excellent question. I've got no answer for you, unfortunately.

      I think I read a troll saying that the Linux kernel shouldn't require an external interpreter for its configuration, but that was especially stupid (even for a troll), since Python code can be turned into C code (that you can distribute on its own, of course -- all it'll need to work then is gcc).

      I have an idea that the average kernel hacker doesn't feel Python is, well, hackish enough (which is true, BTW -- I doubt you could play Python golf like you play the very hackish Perl golf game, for instance). Whether that's a good reason for dismissing it, however...

      Oh, and there's the fact ESR didn't handle the whole issue too diplomatically, too. *g*

      Still, it's really too bad. CML2 was a step in the right direction. The Linux kernel configuration is SUCH a mess right now. There's no distinction between device driver modules and service modules (filesystems, for example). Esoteric options that very, very few people will ever need to tweak have the same weight/visibility in the configuration system as commonly important ones. In short -- it's a mess. And I really, really don't buy the argument that "users shouldn't recompile the kernel anyway." A mess is still a mess even when fewer people are looking at it.
    • I don't understand either, especially as make xconfig invokes the wish interpreter. I guess, as make xconfig is not mandatory (you can still do make menuconfig), that it isn't so much of a problem.

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close