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."
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.
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
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 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.
I wonder what kind of horror stories we'll see...
But seriously though, Linus should take into consideration the fact that he is not mortal...
Now lots of Linux fanboys are going to mod you up because they won't get any further than that line in your comment.
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.
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.
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...
Only the State obtains its revenue by coercion. - Murray Rothbard
may be found here.
-rimdo
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.
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
From the website :-) The new X interface ("make xconfig") shows a bit how kernel configuration could be done in the future.
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.
You can find some screenshots at KernelTrap: http://kerneltrap.org/node.php?id=404
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.
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?
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?
"Linux is a serious competitor"
- Steve Ballmer, Chief Executive Microsoft Corp.
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.
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.
Linux is NOT different; if you build the kernel with everything enabled (as most distributions do), then the kernel does not need to be recompiled to add hardware. A tool to build a kernel customized for your hardware solves the wrong problem; you shouldn't have to rebuild the kernel at all.
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