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."
Whats wrong with `make menuconfig`?
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 had to use my own Makefile again (Rules.make is slowly driving me insane)."
all we got to do is use a free version control system and we're set.
Nero-burning ROM for Linux!
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
Webmin IS great, provided you secure it properly. But, Webmin cannot configure your kernel for compilation, which is what this tool does.
Nothing that is not wrong with Fortran...
You never know...
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...
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
Nero-burning ROM for Linux!
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
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.
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
You can find some screenshots at KernelTrap: http://kerneltrap.org/node.php?id=404
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!
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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.
I'll bet Linus will be pleased to find this out as well.
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?
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.
"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.
It's 10 PM. Do you know if you're un-American?
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.
May we never see th
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.
May we never see th
"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
Every expression is true, for a given value of 'true'
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?
The kernel maintainers see the kernel as a unique thing which has its own configuration tool. The truth is that a distribution needs a configuration tool which looks after the kernel and the applications. I would guess that it would be modular, sort of like a Microsoft Management Console where application and subsystems provide managemeny snap-ins. I'm sure something like this could be done but without the bloat.