Slashdot Mirror


New Linux Configuration Tool

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

8 of 171 comments (clear)

  1. just a kernel tool by Squarewav · · Score: 4, Insightful

    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

    1. Re:just a kernel tool by Speare · · Score: 4, Insightful

      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.

      --
      [ .sig file not found ]
  2. Owww. by Pig+Hogger · · Score: 4, Insightful
    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...

  3. Re:menuconfig by Zakabog · · Score: 5, Insightful

    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.

  4. Re:menuconfig by Micah · · Score: 4, Insightful

    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.

  5. Re:Who cares? by aardvarkjoe · · Score: 5, Insightful

    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.

    --

    How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
  6. Re:just a kernel tool(well Linux is just a kernel) by dozer · · Score: 5, Insightful
    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.

  7. Re:Who cares? by Sivar · · Score: 5, Insightful

    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

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra