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."
Quit using my schtick!!!
Besides, it's version 18, and I missed. A patched Version 18.0.1 will soon be released.
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!
Where's the screen shots? It is GUI, isn't it?
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
That's all I can say.
Wow!!
so you can sign up with a nearly text browser
Unix makes easy tasks hard and hard tasks possible. Windows makes easy tasks easy and hard tasks $29.95.
oh! they mean kernerl config tool.....
Webmin IS great, provided you secure it properly. But, Webmin cannot configure your kernel for compilation, which is what this tool does.
Who is still using Linux 0.8?
I'm using version 8, so I think LC has a long way to come.
The aforementioned software can be found here, at least until it is /.'ed.
It's a GNU/Linux/Linus Torvald's Kernel configuration tool. Get it right. ;)
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
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.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
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
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.
One of the reasons that I became a lawyer was to avoid ever having to hire one. -SPYvSPY
Richard Stallman and Bdale Garbee (the current Debian project leader) and others have already mentioned these important legal problems.
RMS
DPL
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.
...right?
Infuriate left and right
okay, I don't know much 'bout the extendibility of linuxconf, but that what this post made me think of.
1-How does a "compiling" distro like Gentoo do it?
2-How much of a gain will a user have verses the effort towards that gain?
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?
How about auto detection of hardware and pre-config of a static kernel with no modules and then you can go through and make the changes you wish... I'd like that. Might save me a reboot or two...
X Modelines have nothing do to with the kernel, they configure the X Server which runs in user space. Kernel level auto-detection is about the distribution not having to use insmod and modprobe to load drivers for hardware.
:)
Every distribution comes with a program to auto-detect what devices exist on the PCI bus and load the proper kernel module for it. Users have no interaction with this feature. If I understand this right he's talking about taking this automatic functionality from user space programs that run at boot and moving it into the kernel. There really isn't any user benefit to doing that so therefore: "Nobody wanted it"
Popularity is both the best and the worst thing that could ever happen to Linux. It's like the old days of the internet. "Oh crap, here comes the Prodigy people" and the internet as I knew it was gone. Luckily, it'll be harder for the AOL users of the world to pollute Linux 'cause you can't participate if you can't program.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
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'
Joe User deserves to get as much out of his computer as the beowulf people.
He can right now. I don't recall ever seeing an option like "Boewulf Expert, increase bogomips" in any of the current kernel build tools.
When it comes to painting, I am your typical, probably even less, Joe User. Simply because I go to the local Home Depot and buy the "professional" grade tools (paint brushes, rollers...) should I then be able to paint a house with the expertise of a seasoned professional?
Hypothetically, I have enough money to buy the Ferarri Formula-1 team, cars, pit crew, the whole shebang. Does that mean I have now acquired the driving skill and acumen of Mike Schuemacher?
So why does "Joe User" get a free ride?
If VISTA is the answer, you didn't understand the question
Agreed, this is a problem. I can think of two solutions:
-
Have someone (you?) spend over a year developing a very complex database of rules and interactions. Drivers are constantly changing so you're going to have to maintain the database daily. Expect breakage. You're going to have to be very good at answering email and dealing with inexperienced users.
-
Use the modular kernel provided by your distribution.
Which sounds like the better idea?Have you ever benchmarked a modular kernel vs. a statically-linked one? It's really easy: do some work reconfigure, recompile, and then do the same work. Measure the times before and after. Notice any difference?
You haven't done this, though, have you? Because if you had, we would not be having this conversation. You would know that -- except for pathological work loads (super high volume network servers, etc) -- there is no noticeable performance difference between static and modular kernels. And, for the pathological work loads, you've already spent so much time researching and patching your kernel that autoconfig really won't save you much time.
Joe user is getting as much out of his computer as the Beowulf people right now.
Compiling stuff is actually an advantage Linux has. If you don't want to you don't have to, just use any distribution. It's an advantage because it lets you try unfinished or unsupported stuff. When was the last time you could try an experimental file system or driver on Windows? I'm pretty sure you never did that. On Windows most of the time you can only try software when the developer lets you, and I've never heard of experimental Windows features being available with source code.
If you don't like compiling it's just fine, you can just use Linux just as if it was Windows and install only compiled software. You don't need to compile the kernel either, just use the one that comes with your distribution
By getting rid of all the modules you DON'T need, you can save a lot of Megabytes in /lib/modules. Plus you can tweak the kernel into being smaller, or optimize it for your processor / architecture.
.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
You said: "I'm happy to say that all that work was thrown in the garbage."
Actually I feel quite sorry for ESR. He put a lot of effort into coding something he believed in, got trashed quite a bit for it even though he was listening to end-user input, and eventually had his code given the boot from the main Linus kernel. Not to mention the public humiliation that goes with that.
Put yourself in his shoes; I bet you would feel pretty hurt and PO'd if that happened to you.
Code on, Eric... Better luck next time.
.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
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.
Yes, there is. I haven't used Linux very much in a few months now, but I had to rebuild my kernel to support my IDE CD writer. It is a ridiculously convoluted process involving emulating a SCSI device and "excluding" the CD writer from the IDE driver's knowledge.
Now, because I had to enable that one thing, I also had to go through the entire configuration tree. There are two ways this can be improved:
- The kernel source tree from a distro
should contain the configuration that is
used to build the distribution's kernel,
so I don't have to start from scratch.
- Autodetection.
Am I the most important customer? No. Could I spend the time doing it? Yes. However, there's a reason I'm running Mac OS X right now.Now, please feel free to tell me that the problems have already been solved, because your next problem is that I wasn't able to find it.
If this all sounds demanding and arrogant, that's because I like Linux, and I will not use a double standard for it just because it's free. It is time for Linux to "grow up", and coddling it from any of the best aspects that Microsoft or Apple can offer is only hurting it.
USB will load a module based upon the Vendor/product ID of the USB device.
Individual modules will check what hardware variant you are running.
etc.....
What you mean is that there is no way to automaticly configure a kernel to meet you system requirements which include hardware performance and stability.
Just a simple script,
Are you using this machine as a desktop or server?
Desktop gets a time slice freq boot,
pre-emption turned on.
etc......
some you might need these modules turned on..
server get's all unstable components turned off and more modules compiled into the kernel
You hardware is scanned and drivers and there deps for everything you have are enabled (The tool could even search for patches on the web using the Linux hardware DB and other [stuff])
And your correct, it's fucking stupid that such an easy tool hasn't been put into the kernel configuration yet...... and modulatrity has been dropped from 2.6 because it 'takes too long' I'd do some kernel development if it was modular but not in the state that it's currently in/.
thank God the internet isn't a human right.