CML2 Coming in Kernel 2.5

MrHat writes: "Eric S. Raymond's CML2, or 'Configuration Menu Language' -- part of the next-generation Linux kernel build system -- is now officially ready for 2.5. CML2 includes a compiler for a domain-specific configuration language, used to configure kernel subsystems and resolve dependencies between them. CML2 and Linux 2.5 will 'ship' with several different configuration interfaces, including an adventure game, whipped up by ESR during an extended flight. The story from the horse's mouth (or LKML, if you prefer):'This release resolves all known logic bugs and rulebase problems. The only things left on the to-do list are convenience features and some minor improvements in the test/coverage tools. This code is now officially ready for the 2.5 fork.'"

Comments

why no LL1 talk?

[brlewis]

ESR was previously going to be talking about this at the Lightweight Languages Workshop, but he's not on the agenda now. What happened?

Re:why no LL1 talk?

[the_2nd_coming]

I am not trolling or flaming, I am actualy passing on info I heard.

From what I have heard from LUGs that want him to give a speech at, He is very high mantainance. He requires a nice hotel and good food, as well as a stipent in some cases, otherwise he will not come to talk....I have also heard that he gets a bit pissy over little problems in plans

Re:why no LL1 talk?

[Anonymous Coward]

Actually, if you look at his website, (somewhere under getting him to speak for you), he says first hand what you've said.

His web site is quite funny. Like where he claims to have guided VA Bankrupt through the most successful IPO ever. *snicker*

Re:why no LL1 talk?

[jbellis]

I know that when he was in Utah on some other business, he was happy to come talk at our LUG for free, even though it was somewhat out of his way.

Re:why no LL1 talk?

[Anonymous Coward]

I think the sponsors came to their senses and realized that the words "Eric S. Raymond" and "lightweight" don't belong in the same city together.

Re:why no LL1 talk?

[nvainio]

Well, many want him to speak in their conference or similar and he's travelling quite a lot. I think it's just fair that he wants good sleep and proper food. See esr's travelling rules. Calendar is also available.

Re:why no LL1 talk?

[Anonymous Coward]

Everybody Hates Raymond.

Re:why no LL1 talk?

[cha0sadddddddd]

how do i get in touch with this lug in utah? im in salt lake city and interested in getting involved.

Re:why no LL1 talk?

[msalib]

I'm Mike Salib, one of the two organizer's for LL1. Basically we had a miscommunication with ESR. Combined with the fact that he's scheduled to be at other conferences both right before and right after LL1 a good distance away, he had to cancel.

We're disappointed and so is he, but there's always LL2 next year ;-)

Seriously, if you're in boston on saturday, you should come over. The whole thing will be videotaped and put on the web by DrDobbs and we'll also do a live audio webcast (probably) so everyone can watch.

More info is available at LL1.mit.edu

I have to go fail a signal processing exam now, but i'll be back later ;-)

Re:why no LL1 talk?

[Anonymous Coward]

Glad to see you are back at MIT. Just don't work too hard.

Other Projects

[aridhol]

The other examples posted on ESR's page are for kernel-oriented projects. How hard is it to stick this in another project? Something slightly smaller-scale than the kernel?

Also, this seems to only be concerned with compilation-time configuration. Although pre-compilation config is important, how hard is it to adapt this to work after compilation? If another app could use this configuration engine after it's been compiled and distributed, it may make it easier to customize pre-compiled packages (RPMs, DEBs, etc).

Re:Other Projects

[Telex4]

Post compilation, configuration can only really be done with configuration files, like those used by LILO, XFree86 and various other apps. At the moment, you're right, there's no standard for the layout and internals of config files, and no standard program to interpret them. Some of the biggest steps forward have been made in this area in GUIs like KDE and GNOME, where configuration has been made simple and accessible. Although it would be a mammoth task given the number of config files in any OS already, it would be a good project to try and extend ESR's idea to formalise config files for compiled packages.

Re:Other Projects

[aridhol]

it would be a good project to try and extend ESR's idea to formalise config files for compiled packages.

OK, so this thing reads a menu-definition file and spits out--what? A Makefile? An .c file? Something else?

What I'm thinking is to have it read your menu-def file, and spit out a config-file creater and a parser.

For example, you tell it you have a configuration option "FOO", which is a boolean value, and "BAR", which is a string. These are put in the menu somewhere. You run this through the config-generation app, which spits out two modules: one to create a config file, one to read it.

Now you create the config file using whatever front-end you want (standard menu, graphical, Zork, whatever). Then in the app, you say something like getconfig("BAR"). The library is able to validate the entry (it knows that "BAR" is a string), and set a default (also from the generation script).

Is this what CML does, or am I completely mistaken?

Re:Other Projects

[arkanes]

Isn't this pretty much what the Windows registry is supposed to be, minus all the worthless bloaty crap that gets stored there by ill-behaved applications? A central, OS managed place for applications to keep thier configuration info?

Re:Other Projects

[Telex4]

Yes, it is. Making a GNU/Linux registry would have its ups and downs - the downs probably outweighing the ups. The up would be that it would make using the OS a lot easier for newer users. The downs would be that it would be hell to implement, it would put a lot of developers off, and it would make cross-platform compatability harder to achieve.

Re:Other Projects

[rgmoore]

How hard is it to stick this in another project?

Actually, this is discussed explicitly in his paper on the topic. It sounds as though broad applicability to the general problem of complex configurations was one of his goals:

Another decision I made early was to have no information or constraints specific to the Linux-kernel configuration problem in the code of the system. Thus, a CML rules file contains not just the menu declarations, visibility predicates, validity constraints, and derivations derived above; it includes various auxiliary declarations including the locations of help files, a common prefix to be added when writing out symbols, and even the image to be used when the configurator iconifies under X.

Thus, CML2 is designed to conveniently be used for a much larger class of configuration-management problems than just Linux kernels. It could be used, in particular, for configuring systems from libraries of programs or libraries with `requires' dependencies on each other. All this would require would be a custom rules file expressing the dependencies.

Re:Other Projects

[Sludge]

Telex4, maybe you can tell me the answer to this: Does the Windows registry allow fine grained access priveledges? It seems to me that you have either allow every user full write access(unacceptable) or no access at all(unacceptable).

adventure

[Ace Rimmer]

take nife
[ but what with it? it's gross ... ]
2 hours later, bitching, trying everything on everything
sharp knife with grass
[ found scanning through the game files]

---
This is from Larry. What would one solve in CML2?

And we ripped on Microsoft

[CptnKirk]

for including flight simulators in spreadsheet programs. Now we have adventure games in our kernel configuration system? I would hope this would be an optional add on.

Not that I'm against this per se, I actually kind of like the idea, but only as a novelty. I kind of liked the easter eggs in MS programs too, but when they get to the point of introducing (noticable) added overhead either to disk, memory, or program maintainability I have a problem.

So while it may relieve some of the tedium of kernel configuration. The first time make adventure causes a problem, I'd expect to get back some of the dung the linux community has flung over the years.

Re:And we ripped on Microsoft

[FatRatBastard]

I think the adventure game is a front end for it, not in the actual code itself.

Re:And we ripped on Microsoft

[CptnKirk]

I think so too, and I'm sure there will be lots of front ends which spin off of this. I'm waiting for the OpenGL front end with acceleration and an Unreal engine.

What I don't want to see is this being bundled with every kernel. IMHO the kernel distro should be a small streamlined product with enough in the way of configuration for people to get their job done easily. I think that while cool, adding a game front end is over the line of what's needed and wanted by the typical sysadmin.

Re:And we ripped on Microsoft

[return 42]

Well, it is optional, but as a gedankenexperiment, let's suppose it weren't. If something gets into the kernel (or any other open project), it's because people want it there. If it isn't made optional, and no one forks a version without it, it's because not enough people dislike it enough.

Contrast this with the flight simulator in Excel. It went in because some people at Microsoft wanted it, and it won't come out because no one else can make that decision. It would take a major effort by millions of irate customers to make Microsoft take it out; it just wouldn't be worth their while for less. Hell, the irate customers can't even make them fix real bugs. It's all they can do to make them fix security holes (sometimes *cough* Outlook *cough*). And now Microsoft wants people to shut up about the security holes. It's too much trouble for them. Why are you people bothering us about security? Can't you see we're busy writing the next version to take another billion from you?

Hmm, that transformed in midstream from an essay on development paradigms to an anti-MS rant. I must be in Slashdot :)

Re:And we ripped on Microsoft

[Anonymous Coward]

The last time the linux kernel was a small streamlined product was 6 years ago.

Re:And we ripped on Microsoft

[Anonymous Coward]

for including flight simulators in spreadsheet programs. Now we have adventure games in our kernel configuration system? I would hope this would be an optional add on.

You aren't an emacs (or xemacs), user, are you ? :-)

Re:And we ripped on Microsoft

[mmol_6453]

The basic idea of CML2 is to let someone of any skill compile the kernel easily.

Hmmm

[einhverfr]

I read the article and I was immediately impressed at how much MORE readable CML1 was... Perhaps because I know enough shell scripting to follow it in my head. CLM2 was impossible for me to quickly follow what was going on and I had to think about it quite a bit more.

I think the basic idea of CLM2 remains sound, but I wonder if it will result in more "cutting and pasting" rather than direct editing...

Re:Hmmm

[Telex4]

I would say that you're right in thinking your reaction was due to your knowing shell scripting already. I suppose old hands will find this language either pointless or too much effort to learn, whilst those nearer the newbie spectrum will find it a godsend (assuming it's well written). IT'd be good to find a compromise though.

Re:Hmmm

[tao]

The problem with CML1 isn't readability, but expressibility. The language suffers sane ways to define dependencies. CML2 provides this. Of course, it's likely to take some time for people to get used to CML2, but then again, people still make a lots of mistakes with CML1...

Re:Hmmm

[Oo.et.oO]

what i never got, nor investigated, was why the config didn't use an autoconf, et al. TYPE of system. obviously it would have to be different.
but i get really annoyed when each time i config i have to go into every single damn section to make sure shit i don't need is turned off. now of course i know how to move my .config files around. but i still have to check.
i hope CLM2 can/will provide some structure to allow one global file that will provide my basic system structure and will turn off all the crap i don't want (am radio for instance i prolly won't use in the near future).

Re:Hmmm

[psamuels]

I read the article and I was immediately impressed at how much MORE readable CML1 was... Perhaps because I know enough shell scripting to follow it in my head.

This is both an advantage and a disadvantage to the current kernel config language (which I don't call CML1 for the same reason that I don't refer to SunOS4 as Solaris 1).

It uses shell syntax for historical reasons, and two of its three parsers are implemented in bash, but a Config.in file is not a shell script. That means: sure, you can read config files just fine, but try to edit them and you can easily start generating syntax errors by assuming you can use all shell constructs. (You can't, because xconfig does not borrow a shell for its parser.)

Re:Hmmm

[psamuels]

what i never got, nor investigated, was why the config didn't use an autoconf, et al. TYPE of system.

You mean an autoconf system with about 800 '--with-*' options? Thanks but no thanks....

I suppose you could use Metaconfig (the config engine used by Perl), which is interactive so it doesn't require 800 command line options, but Metaconfig produces a user experience not unlike 'make config', so what's the point?

There are ways to reduce the number of answers the computer has to get from you at config time:

• keep a profile of settings you have used before - this is trivial, with Menuconfig's facilities to load and save your config to an alternate file, or with 'make oldconfig'.
• probe your current hardware - this is perhaps what you meant by "an autoconf type of system". Giacomo Catenazzi (sp?) has implemented such a system and it will probably go in as an option with CML2, but it is limited in at least two ways: First, do you want to build a module for (e.g.) your sound card, or build it in to your kernel? Second, it only works if you are configuring your build on the same machine your kernel is intended for. (Not a good assumption for me - I generally compile on my fastest machine.)
• Compile with a "default" set of options, and possibly give the user one or more "profiles" to choose from. The ARM tree has something like this - various defaults based on your machine sub-type. It is also something you could implement on top of CML2, since one of ESR's design goals was to support progressive disclosure.

Something similar for BSD?

[chrysalis]

Is there a similar kernel configuration GUI for OpenBSD/FreeBSD/NetBSD?

Editing BSD kernel configuration files has always been lousy and very archaical compared to Linux menuconfig and xconfig. I still can't understand why nothing was developped for BSD.

Re:Something similar for BSD?

[Anonymous Coward]

> I still can't understand why nothing was developped for BSD

BSD is designed by a committee.
I guess there are many users who would have added this feature if "the one true unix way old boys network" would have let them.

Re:Something similar for BSD?

[agshekeloh]

Because nobody's submitted the code for it.

If you feel like writing this, go right ahead. Submit it as a PR. If it works, and it's reliable, it'll get picked up.

Re:Something similar for BSD?

[Anonymous Coward]

What a backwards way of looking at things.

Seriously - what configuration program could possibly be more friendly than your favorite editor?

Re:Something similar for BSD?

[Null_Packet]

Primarily because the BSD's maintainers seem to prefer the configuration file. There are several things that distinguish BSD from Linux, and the Kernel Config file is a big one. You may find that not all OS quirks are due to technical roadblocks but to particular people's preferences.

To use an analogy, Directors of movies like to step into the editing booth and make sure certain scenes/footage stay in the movie- sometimes not because they have merit on their own, but because the director wants them there.

An often-overlooked aspect of the kernel community of the open Unices is the lack of true central authority. Before you flame, some OS's have stronger leadership than others, and some are ruled more by a group concensus than others. It seems a it obvious that this question came from a user who hasn't spent much time in the BSD 'community'. Spend more time there and I think this and many other questions will be answered, just maybe not the way you expect.

Re:Something similar for BSD?

[Watts Martin]

Yet even with that "archaicness" I find kernel configuration in BSD to be easier. This isn't because I'm a canonical GUI-hating Unix guy; it's probably because I'm not. XConfig and particularly MenuConfig are excruciatingly tedious compared to opening your own kernel configuration file in one window in a text editor and the LINT file in the other. My FreeBSD configuration generally is a matter of commenting out a bunch of lines (mostly SCSI stuff) and adding two at the bottom for my sound card.

I've honestly been very impressed with how logical the BSD configuration "system" is; it's not pretty but it's straightforward and easy to make changes to. The /etc/rc.conf file changes or overrides many things that Linux distributions tend to scatter around the system (often in places that change from distribution to distribution, no less).

Re:Something similar for BSD?

[Anonymous Coward]

XConfig and particularly MenuConfig are excruciatingly tedious compared to opening your own kernel configuration file in one window in a text editor and the LINT file in the other. My FreeBSD configuration generally is a matter of commenting out a bunch of lines (mostly SCSI stuff) and adding two at the bottom for my sound card.

This only means that you have a good default config. Linux has the same: copy some .config from elsewhere/previous compile, then "make oldconfig", and "make xconfig" to change one or two things. Ideally, you would only have to do the full "make xconfig" once in your life. Last time I used *BSD, long ago, compiling PCMCIA (PAO), and QoS (ALTQ) support wasn't that easy, and I had to triple check every line if what I cut and paste wasn't doubly defined, useless or uselful. I even managed to fail to compile the kernel 3 times in a row IIRC.

The /etc/rc.conf file changes or overrides many things that Linux distributions tend to scatter around the system (often in places that change from distribution to distribution, no less).

Yes and no. Some don't. When a change the config of a stock daemon on Linux, I only have to type "/etc/init.d/theDaemonName restart" ; last time I used BSD, I wondered how to do. Different Linuxes really give you a choice of how to administrate your machine (You don't know Unix? Use RedHat clickized administration tools. You know BSD? Use Slackware. You want to edit all config by hand/scripts ? Use Debian, etc...).

A promising step

[Telex4]

It's good to see some high profile hackers putting their minds to making GNU/Linux easier for people. This language should make it easier for hackers to fiddle with their kernel, and to get into kernel hacking, which is a great thing considering how daunting a challenge it is at the moment. It will also help people who have been playing with GNU/Linux for a short while start setting their systems up properly, instead of running on a hastily preconfigured kernel that came from their distribution installer.

It was promising then to see ESR say that he wanted this language to help GNU/Linux newbies. There's been a lot of good work recently on making the first steps more accessible, but there's been little progress in helping people who have completed the first challenge and who then want to get their OS running smoothly.

Re:A promising step

[rhekman]

For those of us more experienced at building kernels, there is another project that is looking to make building kernels much better. That is Keith Owens' new kbuild architecture. He has rewritten the makefiles to make readability better, put compile time dependency checking in the right place, and make creating patches easier. It will work wonderfully with ESR's system and have the effect of making repeated compiles much faster. Anyway, I can't wait.

http://kbuild.sourceforge.net/

Regards

Re:A promising step

[wrinkledshirt]

It's good to see some high profile hackers putting their minds to making GNU/Linux easier for people. This language should make it easier for hackers to fiddle with their kernel, and to get into kernel hacking, which is a great thing considering how daunting a challenge it is at the moment.

I don't know that I agree. What we've essentially got here is yet another language that a user needs to learn in order to take advantage of something that's supposed to make the user's life easier. It's like forcing a student to study thermal dynamics so that they can learn to put gas in the car tank. It's this approach to making things user-friendly that Linux has been taking for a long time now, and it's only making things worse the more applications and tools show up.

Windows may have it's sucky points, but it's pretty much always click-point-click-scroll-click to get something set up. You can't get easier than that. Yes, it limits the interface for the user. For a potential hacker, I know that's a problem. For an end user and help-desk technician, it is a wonderful boon.

In my opinion, a completely radical approach should be taken -- all config and setup scripts as XML files. That way, you've got one DTD binding you to whatever you're trying to set up, and a protocol that you only need to learn the nuances of once.

Re:A promising step

[psamuels]

What we've essentially got here is yet another language that a user needs to learn in order to take advantage of something that's supposed to make the user's life easier.

Are you referring to "regular" users, or developers?

"Regular" users, who don't hack their own kernels, will never see the guts of CML2 - any more than they ever see the current Config.in files.

Developers, on the other hand, will certainly have to learn esr's new language, or at least be astute enough to be able to cut and paste existing code in to add support for their new drivers.

Windows may have it's sucky points, but it's pretty much always click-point-click-scroll-click to get something set up.

The analogy to CML2 in Windows would be creating the OEMSETUP.INF file for a new driver. I have never done this, but I assume it's a lot more than click-point-click-scroll-click.

Re:A promising step

[Telex4]

You miss the point. Windows gives a standard interface to end users, and on the whole asks the developers to understand the more difficult aspects of programming and setup. That is the same case with ERS's proposed idea. It will create a standard language for developers, which will mean that a standard end-interface can be created for end users, who will not need to know a thing about the language.

Windows now uses .MSI packages. Some GNU/Linux distros have tried this with .deb and .rpm packages. They're all really good if they can be standardised throughout the distro, and made easy to use, because the newbie isn't then confronted with a compile, or a version of an app with loads of options he/she doesn't want. Developers still have to learn how to set-up these packages, but it's not that much effort considering it's one consolidated "language".

The same will now apply to kernels, with a bit of luck. Developers will learn this one language (and escape a mess of Perl/Tcl/etc), and end-users will have a nice standard way of configuring their kernel!

Kernel configuration as a game?

[Araneas]

Very cool idea. Hmmm... now to screen out the L class users:

In order to install bind you must complete level 25, please try again.

Re:Kernel configuration as a game?

[cperciva]

Shouldn't that be
In order to install sendmail you must complete level 25
and
In order to install bind you must completey level 53?

You can tell he's from the 80s

[Anonymous Coward]

Adventure games are soooo passe. I would prefer a Quake style interface with hidden buttons for config options. And maybe you could shoot all those stupid options that no-one ever uses. Like "Amateur Radio Support" and so on.

Re:You can tell he's from the 80s

[tercero]

It seems like this would be possible. But in order to make it worthwhile there would have to have something fun like shooting monsters or racing other 'players' or whatever.

BTW, I have and use Amateur Radio Support! I would not use a new kernel without it.

Re:You can tell he's from the 80s

[SnarfQuest]

Wans't there someone who set up a version of Doom where processes on the system were represented by monsters. Killing a monster caused the process to terminate. It worked ok, except when the monsters started fighting each other...

Re:You can tell he's from the 80s

[Anonymous Coward]

This is more doable than you might think. Quake 1 is open source now. All someone needs to do is make a "level" where you configure the kernel.

Re:You can tell he's from the 80s

[Bilbo]

This is for real hackers bro. If you don't recognize all the commands, then you shouldn't be using the interface.

(Ever read, "The Soul of a New Machine"? Starts out with someone going through, "You are in a maze of twisty passages that all look the same...")

Re:You can tell he's from the 80s

[noweb4u]

Yep, I loved to play that game on my laptop when I was bored. It was great until I shot my login shell with a rocket launcher, then it was game over ;-)

But...

[Anonymous Coward]

But ... but ... but it's written in Python! How useful can it be? :)

(and here I sit, shamelessly hiding behind an AC post)

Re:But...

[rave77]

I was hoping, since it was meant to be humorous, that they write it in .NET

Re:But...

[Anonymous Coward]

Python is a great language for implementing things like duck-balancing services, SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM, and lumberjack instant messaging. Of course, noone expects the Spanish Inquisition.

An adventure game

[spectrum]

And if you configure your kernel wrong you end up in the Oops room with Colonel Panic. ?

Could be worse.. you could end up in the blue-fluffy-cloud room with General Protection-Fault.

Re:An adventure game

[Accipiter]

And if you configure your kernel wrong you end up in the Oops room with Colonel Panic.

Of course not.

You have removed all disk support. It is dark. You are likely to be eaten by a Grue...

> _

Wish we had this in Windows...

[Tsar]

_________________________

General Protection Fault
_________________________

> Kill fault

With what -- your bare hands?

> Yes

Congratulations -- you have just made Windows a stable OS with your bare hands!
Unlikely, isn't it?

> Format c: /y

You are in a maze of unallocated sectors, all alike.

Re:Wish we had this in Windows...

[Anonymous Coward]

> open Internet Explorer

You are suddenly surrounded on all sides by a dense blue fog.
You are dead.

Re:Wish we had this in Windows...

[Anonymous Coward]

> write os

With what -- your bare hands?

> yes

congratulations, linus! you have just written an operating system! unbelievable, isn't it?

Kernel Naming Rules _AGAIN_

[SirStanley]

Hey... I thought I made this clear a few weeks ago. Its the "Linux Kernel" NOT "The Kernel" Dammit tack Linux infront of it.. Or if you're one of those PInko Commie Socialists GNU/Linux . Not all of us run Linux and sometimes freak when we are very tired and we see things like "Kernel 2.5" dammit... Once again im at 4.4!!!!!

yikes

[Anonymous Coward]

My first thought was, "what kind of moron writes a new command language in 2001, when GUI has been standard for seventeen years?" Then I looked at the language.

menu netsched # Traffic control configuration
NET_SCH_CBQ? NET_SCH_CSZ?
NET_SCH_ATM NET_SCH_PRIO? NET_SCH_RED? NET_SCH_SFQ?
NET_SCH_TEQL? NET_SCH_TBF? NET_SCH_GRED?
NET_SCH_DSMARK? NET_SCH_INGRESS?
NET_QOS {
NET_ESTIMATOR
NET_CLS {
NET_CLS_TCINDEX? NET_CLS_ROUTE4? NET_CLS_FW?
NET_CLS_U32? NET_CLS_RSVP? NET_CLS_RSVP6? NET_CLS_POLICE
}
}
require NET_SCHED implies NETLINK==y and RTNETLINK==y

Holy fucking christ, what a load of crap. Even for command languages this is total gibberish. It's like JCL or something.

Why not XML?

[Anonymous Coward]

If it's a tree then why not use XML? I mean there are hundreds of tools available right now on every platform - why bother making your own language?

Re:Why not XML?

[Black Perl]

Well, you'd still have to create a DTD or Schema representation; you just wouldn't have to create a new syntax.

But I agree. There's no reason why he had to invent a new syntax, when CML2 could have been defined as an XML application. Like you say, there's plenty of tool support.

Re:Why not XML?

[Anonymous Coward]

Everything that's in Linux has already been done. The Linux mantra is "embrace but don't extend". Whether this is better or worse than "embrace and extend" is your choice.

Sometimes, however, some people get so bored of doing nothing but copying the work of others that they just have to reinvent the wheel.. which is like copying the work of others, only the end result is incompatible.

Hm, hang on a sec, isn't that what the "extend" bit of "embrace and extend" is all about?

Oh well, we can't expect much more from ESR The Fraud...

Re:Why not XML?

[Styx]

He could probably have used XML, but that wouldn't have helped with the real problem, since the kernel config isn't really a simple tree:

"(...) the kernel-configuration process has grown excessively complex. The configuration system's job is to turn the user's answers to configuration questions into a file of #define constructs used to condition features in or out of the C code. As Linux has grown more features and more driver support, the number of menus and prompts one must navigate to choose the appropriate subset of those features has become forbidding even to expert users, and outright impossible for the novice users Linux increasingly seeks to attract. To properly manage the complexity we have created, we need a configuration interface that can support better chunking and progressive disclosure. Ideally, novices building kernels should see only the choices they need to make. As they gain competence and cue the configuration system that they are ready, they should see more options for tuning and exotic hardware. The full process should be accessible to expert kernel hackers, but not inflicted willy-nilly on everyone else as it now is."

(from the CML2 paper)
So, the tool ensure that only sane kernel configs are built is where the real meat of the problem is. XML wouldn't be much help there.

Re:Why not XML?

[Black Perl]

So, the tool ensure that only sane kernel configs are built is where the real meat of the problem is. XML wouldn't be much help there.

Why do you say that? That's the whole point of XML validation. You define up front what a sane config is (THIS is the meat of the problem) and express it in a DTD or Schema. Then you could use your favorite validator to determine if it was a sane kernel or not. In fact, you could use a standard XML IDE that could enforce the DTD/Schema to make sure you CAN'T create anything but a sane kernel!

Instead, he's created another non-standard format and tool writers will have to create kernel config tools from scratch.

Re:Why not XML?

[Styx]

Yes, but how would you express all the different valid/sane configurations in a DTD?

Have you looked at http://tuxedo.org/~esr/cml2/cml2-paper.html#AEN96 ?

IMO, you would end up with something that generated a new DTD for each kernel version. And then the real work would be in keeping this tool up to date, so again, XML wouldn't get you anything spectacularily useful.

Re:Why not XML?

[Splork]

XML is human -readable- but not easily human -writable-

Re:Why not XML?

[crealf]

You define up front what a sane config is (THIS is the meat of the problem) and express it in a DTD or Schema.

You can't.

Re:Why not XML?

[Lathi-]

This seems like "arm-chair" programming to me.

Re:Why not XML?

[tricorn]

Next, just create a DTD for Web pages to validate spelling, grammar and requires a visually pleasing layout. Just define those up front and let a standard XML IDE enforce it, and the Web would look so much better.

I'll bet you could come up with a good XML DTD for Slashdot articles as well; just select one for Troll, Flamebait, Funny, Insightful, or whichever you're going for, and the DTD would validate the article and we could get rid of this silly moderation system altogether!

Re:Why not XML?

[Samrobb]

So, the tool ensure that only sane kernel configs are built is where the real meat of the problem is. XML wouldn't be much help there.

It couldn't do the job completely by itself; but it could help simplify the process.

Instead of building a DTD that expresses every potential ascpect or relationship that describes a "sane" kernel, you could build one that describes 95% of the configuration relationship information. Then, make sure that the DTD includes definitions for hooks into executable code (shell scripts, most likely) that are hand-written to handle the inevitable unusual or impossible-to-model situations.

I'll admit that I'm making some assumptions here - I've never delved into the kernel config code, so I'm just guessing that you would be able to express enough of it consistently in XML to make this type of approach work. Still, that seems like a safe assumption; if it was all special case code, then something like CML wouldn't really be of any use at all.

Not "GNU/Linux kernel"

[brlewis]

Taking the questionable step of inserting a fact into what will likely be a flamacious thread: RMS' insistence on "GNU/Linux" relates to entire distributions. He doesn't complain about "Linux" referring to just the kernel.

Re:Not "GNU/Linux kernel"

[maxpublic]

Yes, he does complain about it. He told Linus ("Just For Fun") that the kernel should be called GNU/Linux because Linus used some free software tools (e.g., gcc) to create it. This is a matter of record, and not just in Linus's autobiography.

He wasn't referring to any bundled distribution, just the Linux kernel itself. By RMS's definition, anyone creating any software which might remotely be connected to an FSF tool, like the aforementioned gcc, should put "GNU" in front of the name.

Max

Re:Not "GNU/Linux kernel"

[brlewis]

I hadn't actually heard of the incident you refer to. Even if it did happen, RMS' stated position is that the kernel is called Linux.

Re:Not "GNU/Linux kernel"

[Trisk]

In actuality, Linux itself is not GNU software (that is, part of the GNU project), so there's no real reason to name it differently. A GNU/Linux system, however, consists of Linux and the GNU utilities, in order to actually have a working OS.

Re:Not "GNU/Linux kernel"

[maxpublic]

It did indeed happen. It was common knowledge at the time that it happened because RMS made something of a stink about the fact that Linus blew him off. I believe the page number for the reference is 133 in "Just For Fun", but I don't have it here in front of me so that's just a guess.

Regardless of RMS's stated position those are the actions he took concerning the Linux kernel. It appears at RMS's actions are in contradiction to his stated opinion.

Max

another language?

[krokodil]

Why people keep inventing new pet laguages?
Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.

Re:another language?

[ethereal]

I'll point out that GnuCash has a Scheme-based user preference setting which does handle a lot of this, including different kinds of options, specifying defaults, etc. It doesn't really do prerequisite handling the way that CML does, though. But if I were going to rip off a user preferences config system from somewhere, I think I would start there.

Re:another language?

[Anonymous Coward]

GUILE is a joke. There are much better Scheme
development environments, and there are better
configuration languages.

Congradulations on gobbling up RMS-based
propaganda, hook, line and sinker...

Re:another language?

[S.Gleissner]

> Why people keep inventing new pet laguages? Top 10 reasons why people are inventing new languages: 10. BASIC sucks. 9. C is too much limitated. 8. Assembler programs are too complicated - for most applications. 7. Perl... hmm, if You do not write scripts?? 6. PHP? Ok, if You don't program web servers. 5. Fortran: Hey, stoneage is over since several thousand years... 4. c# ? hohahahahaha 3. SQL can't do everything. 2. Java is too much standartisized. 1. Because they can. (c) simon@gleissner.com

Re:another language?

[psamuels]

Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.

Uh -- CML2 is not a programming language, per se, but a language for representing a dependency graph for configuration options.

I fail to see how either XML or Scheme would be at all useful there. You would still have to invent conventions for how to store the graph, so instead of a language invented out of the blue, you get a language in XML or S-exp syntax invented out of the blue.

If anything, you should be advocating Prolog, which (unlike Scheme or XML) is a rule-based language, somewhat similar in semantics to CML2 data files. What's that, you say? Not enough people know Prolog? You can't be expected to install a Prolog compiler just to build a kernel? My point exactly.

Kernel Configuration Adventure

[djhankb]

My biggest fear is being eaten by a Grue in the SCSI catacombs!

-H

I'd like...

[SnarfQuest]

to configure a +5 ethernet so I don't need to use the -60 WinModem.

Re:another language? Why

[Anonymous Coward]

Ego.

Thanks and have an Afghan opium filled day.

Better, I hope.

[rice_burners_suck]

It would be great if this makes Linux kernel configuration easier and more flexible. With all the things Linux is designed to do nowadays (that is, operate on pretty much everything from a wristwatch to a computer the size of a building and everything in between), with so many different processor types and kernel configuration options, it must be a nightmare to configure a kernel from scratch. Hopefully CML2 will make this process easier for everybody.

Re:Better, I hope.

[Anonymous Coward]

The term for it is 'Baroque'. It's original meaning, not the one assigned by musicologists.

Baroque means with all kinds of goo gaas bolted on. A hideous kludge, to use a computer science term.

Look at how you configure and build a NetBSD kernel if you want to see how cross platform kernel configuration should be done.

Re:Better, I hope.

[psamuels]

it must be a nightmare to configure a kernel from scratch.

Takes me about 2 or 3 minutes, and is a much pleasanter experience than most nightmares I've had.

Granted, if you haven't done it before, you probably have to read through a lot of help text and maybe make some semi-educated guesses about what all the options mean. CML2 does not help much in this regard -- the options do not magically get less confusing.

And really, if you are daunted by a few screenfuls of options to tick or untick, perhaps you should stick with a kernel compiled by someone else. (Plenty of distribution vendors are more than happy to do this for you, free or for a fee. Even Debian, the "hacker's Linux", provides binary kernel images every few version numbers.) I don't mean to be patronizing, but it's true -- building your own kernel is not something everyone can or should do himself. It is too easy to get a kernel that doesn't work properly because you didn't know a specific option was needed for your setup. No amount of automated handholding completely removes the need to know, at least somewhat, what you are doing.

OT

[SubtleNuance]

From the LKML like above, included as the tag on ESR's email is this:

.. a government and its agents are under no general duty to
provide public services, such as police protection, to any
particular individual citizen...

-- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)


Is he asserting case law does not support the government offering public services (police)? Meaning, that the government is violating case law in doing so. Meaning, people dont have a right to public services? Meaning, the government's public services are "illegal" (or not a legal obligation)?

Am i understanding this correctly...

Sorry, this is very OT.

Re:OT

[Dielectric]

"to any particular individual citizen"

It's well known that ESR is a huge supporter of the gun lobby, and he's showing that the police are not necessarily there to protect the individual, but rather to protect the general populace. He's trying to show that case law has proven the individual is responsible for their own personal protection, and further that laws restricting gun ownership are dangerous to the individual.

I write this from a community which has banned handgun ownership altogether, but there has been no apparent reduction in firearms deaths or injuries.

But I'm not bitter...

Re:OT

[Anonymous Coward]

Visit here http://www.mcrkba.org/w19.html for the explanation.

ESR is believes that, you should protect your right to self-defense and your right to protect your property by protecting your 4th amendment to the right to bear arms, since courts have always ruled that the police are NOT obligated to protect you as an individual (and you can't sue for damages).

Re:OT

[flink]

What this decision says is that the police don't have to stop a crime in progress. i.e.: They are under no obligation to stop you from getting mugged, mudered, etc. Their job is to investigate crimes and arrest criminals, not provide protection (although they often do). If memory serves, (and IANAL) this was a case where some one was suing the police dept. because some officers witnessed a crime and did not offer assistance.

Re:OT

[Anonymous Coward]

it means while the government may provide the above mentioned services, it is not obligated or required to do so.

Social Security springs to mind...

Re:OT

[update()]

IANAL, IIRC, etc.

This case involved a woman who was suing the DC police becuase they failed to show up in time to prevent her from being raped. The ruling held that government services are not responsible to help out in any specific instance, and that they are not liable if your house burns down or you get mugged and they fail to prevent it. The primary responsibility for protection falls upon oneself.

I assume the invocation here is to argue that if individuals have primary responsibility for their own defense, they should be allowed the tools to do so.

(Actually, that's a pretty good point. And, despite the horrificness of its syntax, it looks like this CML2 means I won't have to hit 'n' 5000 times as menuconfig asks me if I want support for every sound card on the planet. It's rare that I have one positive thought towards ESR, let alone two at once.)

Re:OT

[Anonymous Coward]

Regarding that aspect of cml2: I'll believe it when I see it. It looks like it makes describing correct dependencies easier, but that part is invisible to the user. So IMHO it is good for kernel developers but not directly for average joes like me who just compile the thing every now and again.

Re:OT

[Anonymous Coward]

Has there been an increase in injuries? Just curious.

Has crime skyrocked?

I'm not gun nut, but it sounds weird. I'd probably try to leave. I'm sure it's perfect for you or you are trapped.

Kernel getting too large?

[Anonymous Coward]

With all the recent modifications to the kernel coming out, it makes me ask: Is the kernel getting too big? Does it have too many options?
FreeBSD's core kernel team doesn't implement alot of stuff in the kernel by default. Oh, you can compile it in with it, but it doesn't come with a zillion options by default. I think it's great - sticks to the whole K.I.S.S. idea, and give you the complete control to put in the options you might need that everyone else might not. I just would hate to see linux go from a nice sleek, clean kernel build to bloated oversized core with a billion options that i won't use day-to-day.
How large are these options? Do they bloat the source very much?

KernelQuest

[rlangis]

Somewhere along the line, somebody, somewhere, will drop some networking code into the kernel config module, and hook up with other 31337 h4x00rz...

You: Damnit, I've been waiting 2500 clock cycles for this damned PCI_BUS to spawn.

n00b: Hi! I'm new here. OooOoo, can I have that?

You: Have what?

n00b: Your uber-leet PACKET_FILTER sword of destruction!

You: *eyes narrowed* I thought you said you were new here?

PCI_BUS spawns, and aggros the n00b.

n00b: Take that, PCI_BUS_00! I'll configure you!

You: Hey, I've been camping that!

n00b: victorious in configuration - it aggroed me first, 10053r. Go camp the EISA_BUS instead. *snicker*

You: *grumbles*

Python ?

[Anonymous Coward]

Sorry ESR, but I don't want to install Python to be able to configure and compile the kernel.

Re:Python ?

[Anonymous Coward]

Well, I guess you're in luck - you won't need python installed to configure the kernel.

You'll need it to compile the kernel configuration tool, but that's probably not going to be needed too much.

Re:Python ?

[joib]

Well, nobody forces you to use anything. If your anti-python feelings go far enough, you could certainly edit the makefiles yourself (in principle, that is). Or rewrite CML2 in your favourite language (there are imho projects more worthwile to spend your time on than this though). Or use the distro-supplied kernel. Or use 2.4.x kernels until Linux 42.0 with yet another kernel configuration system (not written in python) is released in, say, 2050. Or switch to windows. I don't really care.

Re:Python ?

[Anonymous Coward]

You better read ESR's paper:

Python, unlike other scripting languages, can be (effectively) compiled to pure C using the freeze facility. The translation is not pretty, and produces rather large C programs from even small Python sources, but it does meet the problem of portability head-on. Kernels could be shipped with a precompiled rulebase and a frozen C version of the CML2 interpreter to avoid the requirement for Python.

Re:Python ?

[Anonymous Coward]

and if you had read his whitepaper you would have seen that python is _not_ required simply for configring/compiling the kernel.

sheesh...

Re:Python ?

[Balinares]

And yet you didn't mind having to install Tcl/Tk to be able to configure the kernel before?

Re:Python ?

[dduck]

Well, this issue is addressed on his CML2 page, which is linked in the top level article. One feature of Python is the ability to generate C source code that implements your program, thus making it possible to distribute CML2 without Python.

Re:Python ?

[Anonymous Coward]

I never installed Tcl/Tk (and FYI, Tkinter uses Python). I jusr make menuconfig and then use oldconfig all the time.

Re:Python ?

[Anonymous Coward]

As a matter of fact, yes I do object to it. How does your comment justify the installation of a yet another shitfest like Python for kernel configuration?

Re:Python ?

[Balinares]

How does your comment justify the installation of a yet another shitfest like Python for kernel configuration?

It doesn't. In the past you needed either Tcl/Tk or the curses lib, now you need either Python or a version of CML2 frozen to vanilla C, but in both case you can edit the makefiles by hand if you prefer. Whee, aren't we happy now. Unhappy? Take it up to ESR and try to contest his choices if you can (if you really can, which I kind of doubt, considering you're an AC of the ilk that uses words such as 'shitfest' apparently for the sheer trolling value of it, please let me know -- I'd sincerely be most interested to hear of it).

Re:Python ?

[Balinares]

Yep, I know what Tkinter is, but thank you. This said, make menuconfig does need stuff installed too, namely the curses lib, to compile the interface. Does compiling the C file generated from a frozen CML2 differ majorly?

How about the Inverse Problem?

[Anonymous Coward]

One issue for newbies with the current linux kernel configuration is the "inverse problem:"

I want feature X, what requirements will enable me to select it?

A trivial example: 2.4.0 required "experimental features" to allow resiserfs to be selected.

I hope that CML2 will alow for searching for and selecting choices anywhere in the decision tree, and "pushing-up" the requirements imposed by the decision (or pointing out problems).

Re:How about the Inverse Problem?

[MikeBabcock]

If you select a network card, networking would get enabled, etc. because of the built-in dependancy tracking -- you can download versions of CML2 for kernels 2.4.x and try it yourself.

Re:How about the Inverse Problem?

[Anonymous Coward]

Yes, that is great. Please re-read my post.

The "inverse problem" is that you know you need a particular feature (say reiserfs support), but you don't realize that you needed to have selected an option earlier on in the configuration ("experimental" was required in 2.4.0).

I did (quickly) read the article on CML2, but was not sure if this concept was supported.

BTW, there is no "future work" section.

Exactly!

[Weird Dave]

I imagine if I could switch places with ESR, I'd be much pickier than him. He's a living, breathing, person with real needs. Love him! Adore him! Stalk him! Wait, nix that last one. But above all, let ESR be ESR!

What's wrong with xconfig?

[RelliK]

I've used xconfig (and to a lesser extent menuconfig) and I found them more than adequate. My only gripe is that the help text is not defined for all the options (though all the major options have excellent documentation that you can display by pressing the help button). So, I don't mean to knock CML2 but what's in it for me? And are there screenshots anywhere?

Re:What's wrong with xconfig?

[the_2nd_coming]

I think CML2 includes the ability to build and install the kernel and modules in one nice neat package....but I am not sure

Re:What's wrong with xconfig?

[Anonymous Coward]

The old kernel config system was inadequate because it didn't resolve all dependencies well in some cases.

Re:What's wrong with xconfig?

[kevinank]

The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool. The idea was to stop maintaining xconfig (and brethren), and move wholesale to CML.

That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python which a number of kernel hackers refuse to install on their systems (originally because it wasn't GPL compatibly licensed, and these days probably ostensibly because it isn't GPL'd, but more likely because it has icky syntax and they don't want to learn it or reconfigure their editors to edit it.)

Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.

Re:What's wrong with xconfig?

[aridhol]

As a user, there appears to be no difference. The kernel maintainers see the difference.

CML is a way for the kernel hackers to tell the config system what options you see when you type "make xconfig".

The kernel-hacker writes some CML code, which he then compiles into a config file. Then, you run xconfig, menuconfig, advent, or any other frontend that gets created, and you have a configured tree. And when the kernel-hacker adds a feature, there's less chance that he'll break configuration dependencies.

Re:What's wrong with xconfig?

[Anonymous Coward]

My only gripe is that the help text is not defined for all the options

2.4.15-pre4 Configure.help has 579 more help texts than 2.4.14 did. Linus got the more complete Configure.help from Alan which Eric and I and others have been working on for the past eight months. Eric just posted a request for 171 missing items to the list today, and one person has responded so far. So, things are getting better, but we still have a lot of work to do.

Re:What's wrong with xconfig?

[MikeBabcock]

The current configuration system is really bloated and hard to maintain, especially for new module coders. The main thing that CML2 did first was to organise the configuration dependancies and information into a logical system that's consistent across the kernel. More importantly to me though is that it has a 'solver' if you will in it. It can 'prove' that a given configuration is valid before you go through the rigors of a 'make bzImage'. This keeps you from selecting options that unselect others (without telling you first) and makes it easier for module maintainers to code in these dependancies themselves.

Re:What's wrong with xconfig?

[Anonymous Coward]

Icky sintax in python?

Which python are you talking about?

Re:What's wrong with xconfig?

[MSG]

I know, I know.... "Don't moderate, reply."

The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.

The current configuration tool *is* CML. The tool that ESR has produced is CML2. CML does its work with a mix of shell, perl, other tools. It's nasty. CML2 is pure Python.

That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python

No, it hasn't happened yet because it's not material for a *stable* kernel series. It'll go into the development kernel, and all of the stuff that needs to be updated to make it work will get updated in the devel tree.

because it wasn't GPL compatibly licensed

Python has had a few releases that the FSF thought were not compliant, but Guido and co. thought that they were. Python has always tried to be GPL compatible. 1.5.2 and lesser are compatible, and so are all of the current newer branches of Python.

Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.

The idea was to create a uniform set of configuration tools that got dependancy checking right and were easy to maintain. CML was none of those things.

Re:What's wrong with xconfig?

[Anonymous Coward]

The current configuration tool *is* CML. The tool that ESR has produced is CML2. CML does its work with a mix of shell, perl, other tools. It's nasty. CML2 is pure Python.

FACT: CML1 does not require PERL. The only significant program in a small linux system which requires PERL is openssl, and groff is the only important package which requires C++.

Before CML2 neither Python nor PERL were needed to build a linux system from scratch if you could live without openssl and openssh.

It is downright stupid to make a package as large as python an essential system component. If anything we should reduce the number of base dependencies.

Bootstraping and porting Linux is already tricky enough. Look at groff: It is an essential component of most free unix systems, but maintaining it is no fun and unglamerous. The same might happen to python. Only worse: You can get a system to boot without manual pages.

Random Ad Hominem: Another crap design decision by ESR. Abused his fame to lobby for a technically unsound decision.

Re:What's wrong with xconfig?

[psamuels]

I think CML2 includes the ability to build and install the kernel and modules in one nice neat package

No, that would be Keith Owens's kbuild-2.5 work. Both are scheduled to be added to Linus's tree very early in the 2.5 cycle. (Linus already agreed to this, although who knows, he could change his mind..)

Re:What's wrong with xconfig?

[psamuels]

The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.

No, actually the project was started when ESR figured the current configuration tool was too hard to maintain and enfeaturate. Basically, he was bored, had nothing better to do, and decided to produce a new language and tools to replace it. He claims that designing "domain-specific mini-languages" is a favorite hacking activity of his.

Early on, he sought input from the current maintainers, asked if he would be stepping on any toes, etc. Some of us were less than enthusiastic, but none of us were willing to claim that the current system was actually beautiful or easy to maintain. (It's not!) Some of us also griped about Python, but (a) Linus Has Spoken and the new tool requirement is officially Not An Issue, and (b) we are generally agreed that he who writes the code decides on the language. (And really, it's not theoretically limited to Python - someone tried to reimplement the tools in C. I'm not sure of the current state of that project.)

Re:What's wrong with xconfig?

[MSG]

FACT: CML1 does not require PERL.

Perl is not only required by the build system, but by several drivers:
$ cd /usr/src/linux-2.4
$ find . -name '*.pl' -print
./drivers/net/starfire_firmware.pl
./drivers/scsi/script_asm.pl
./drivers/usb/serial/ezusb_convert.pl
./scripts/checkincludes.pl
./scripts/checkconfig.pl
./scripts/checkhelp.pl

In ./Makefile, three rules requiring perl:
checkconfig:
find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkconfig.pl

checkhelp:
find * -name [cC]onfig.in -print | sort | xargs $(PERL) -w scripts/checkhelp.pl

checkincludes:
find * -name '*.[hcS]' -type f -print | sort | xargs $(PERL) -w scripts/checkincludes.pl

In ./drivers/scsi/Makefile, four rules require perl scripts.

It is downright stupid to make a package as large as python an essential system component. If anything we should reduce the number of base dependencies.

Uh... you've never heard of cross compiling, have you? Getting linux to scale down, and work on minute devces is certainly a goal that a lot of people are working on. However, using Python to build the kernel isn't going to present a greater barrier to overcome. Any system for which Python is too much of a barrier, a compiler is going to be *way* over the top. Compare the relative size of gcc, supporting libs, headers, devel packages to the size of Python. On my system, gcc *alone* is larger than Python.

Cross compiling is how those systems has always been done, and always will be done.

I think you (and the AC you quote) do injustice to ESR AND to Linus. ESR's been developing software for a sight longer than you, I'd wager, and Linus is not swayed by "fame". He makes decisions based on technical merits. If CML2 makes it into the kernel proper, then Linus has decided that it's the best thing for Linux. Who are you to disagree?

Configuring Evrything

[senfman]

As far as I recall one of ESRs objectives in designing CML2 was to make the configuration process more intuitive. Some people even questioned here to include this into their projects. So I ask myself how configuration systems should look like in future.

Regarding desktop Systems there are quite a few things the Users seem to want:

• Fast configuration
  
• Ease of use
  
• Similar configuration mechanisms for all Aps
  

Some of these points were met by Automake/Autoconf/Make in our todays Apps, but there is a further point, a clear structured development. This is something, which was not possible with Automake/conf and make, because you had several levels, which could be affected by errors.

I haven't had the time to investigate CML2, but some people seem to believe it to meet this needs. after having most Linux distributions have unique Package Management by now, we might have reached a point which enables us to realise the need of unique and clear configuration Systems in all OpenSource Software.

recompiling the kernel is silly anyway

[Anonymous Coward]

Most of the time it's to include features which could have been architected as modules, or to set defaults which could be made configurable at run/boot-time (sysctl -w anyone?)

Granted, a new *platform* needs a fair bit of kernel tweaking, but not just the addition of firewalling support.

Grandmother: I like surfing the Internet, and this new Linux thing you installed on my computer is quite fast, but I read somewhere that I should run some firewall software.

You: Well, just recompile the kernel with ipfwadm sorry ipchains sorry iptables support and write..

Grandmother: Could you install XP please? I hear that has a firewall I can enable by checking a single box.

Re:recompiling the kernel is silly anyway

[ethereal]

That's a bad analogy - if your kernel came with firewalling compiled in, and your distribution had a nice checkbox, you could do the same thing. The only difference is that you can entirely remove the firewalling code from Linux (not just turn it off, actually make your kernel smaller) if you want to. You can't get into the internals of Windows XP and do that as easily.

Hint: don't tell Grandma what you're going to do, just ssh in and tell her it will be fixed in a half hour. Recompile, install, reboot, add firewall rules, and you're done.

Re:recompiling the kernel is silly anyway

[spectecjr]

That's a bad analogy - if your kernel came with firewalling compiled in, and your distribution had a nice checkbox, you could do the same thing. The only difference is that you can entirely remove the firewalling code from Linux (not just turn it off, actually make your kernel smaller) if you want to. You can't get into the internals of Windows XP and do that as easily.

The difference being that the firewall isn't built into the kernel in XP; it's a filter-driver.

Much easier for end users.

Re:recompiling the kernel is silly anyway

[ethereal]

I guess I still see it as a non-issue; users wouldn't even notice that firewalling was compiled into their Linux distribution's kernel either, check the box and a script would echo "1" to all the appropriate /proc/sys/net/ipv4/* fields. It's true that you would have to rebuild and reboot the Linux kernel to go from non-firewall to firewall; but on the other hand I'd be surprised if Windows can turn this on without a reboot either.

It is a good question as to why this can't be a Linux kernel module, though. Or maybe it can in 2.4; I'm still sticking with 2.2 here so I wouldn't know.

Re:recompiling the kernel is silly anyway

[spectecjr]

It's true that you would have to rebuild and reboot the Linux kernel to go from non-firewall to firewall; but on the other hand I'd be surprised if Windows can turn this on without a reboot either.

Yep. No reboot necessary.

Adventure Game

[doob]

I believe my .sig is appropriate here...

Simple intelligent kernel config for newbies

[2Bits]

Why can't we have a very simple but intelligent suggestion for newbie kernel config?

For example, the utility starts by doing a hardware diagnostics first, to see what does the system has. Then ask a few simple questions on the normal usage patterns, like

- Do you have any plug-and-play hardwares that you plug in on run-time?
- what kind of pnp hardwares?
- do you do multimedia?
- ...

Then base on the user answers, just come up with an "optimal" configuration, and ask for the user's approval (you may want to tell the user the reason behind this config, e.g. put the sound module as loadable module, because the user said s/he is using sound only once a while). Then compile the kernel for optimal performance for the user's specific hardware configuration and usage patterns.

Re:Simple intelligent kernel config for newbies

[jfunk]

90% of the time I configure a kernel, it's for a *different* machine.

Thanks to modules, regular users do not generally need to configure kernels. CML is most often used by people like me, who play with esoteric hardware and regularly apply various kernel patches, messing with the code in the process.

Re:Simple intelligent kernel config for newbies

[Devil's Avocado]

"""
Thanks to modules, regular users do not generally need to configure kernels. CML is most often used by people like me, who play with esoteric hardware and regularly apply various kernel patches, messing with the code in the process.
"""

So you would be welcome to continue using CML and the rest of us regular users could use the more friendly version. Yes, even regular users need to compile kernels.

I think the original poster's idea is first-rate.
The current configuration tools for the kernel are *not* helpful to the average user.

-DA

Re:Simple intelligent kernel config for newbies

[jfunk]

No, no ,no. You didn't totally get what I meant. I am very glad that CML2 will make an appearance. Hell, I'm a very happy professional Python programmer. Even I want a system that handles dependencies.

What I mean is that regular users no longer need to compile kernels regularly. Modules were available for at least 3 years before I started bothering with them, and it has only been the past year that I haven't bothered compiling kernels on my desktop/laptop machines. This is mostly due to the way SuSE handles everything for me (I'm an ex-Slackware user and old habits die hard).

What I really mean is that Joe Blow ex-Windows user doesn't need to configure kernels. If I don't, then he/she doesn't need to, either.

If you're, say, a Debian or Slackware user, then you're used to doing these things. I'm strange in that I put myself into Joe Blow's position whenever I'm normally using a computer (I try to to think as a user). You're talking to somebody who actually migrated from vi to SciTE. Seriously. I was actually a die hard vi user. Nowadays, I forget most of that stuff and I like hitting F5, having code-completion, etc.

To sum up: Easier-to-compile kernels: good. The need to do so: not-so-good.

I hope that clears it up, but I'm quite drunk right now, so...

Re:its easy

[Anonymous Coward]

that's because there's so little to configure in bsd. there's nothing there. sheesh, use a real os.

(OT) Re:Not "GNU/Linux kernel"

[Anonymous Coward]

Hey it's mister Lewis!

Your brl package rules, I'm studying it's use for a commercial app right now, fun to see you around on /.

this is waste of resources

[Anonymous Coward]

The Kernel next phase should focus on speed and stablity. Not configurability. If you want configurable install enlightenment

Re:its easy

[Anonymous Coward]

Look through LINT and just try to tell me there is nothing there. How about the large number of gigE drivers FreeBSD has that have no linux support? Oh, but I forgot, BSD is dying, and linux is for data centers, right?

Please return to under the bridge from which you came, troll.

Non-Linux Uses?

[artwells]

A site I maintain ( http://rejuvenation.com/ - a lighting manufacturer ) has hundreds of products that have separate configuration with their own constraints and logic. Though I'm squeaking by with our current online solution (PHP translations of configuration files created by a proprietary product), I've been looking around for a good standard in which to create an alternative solution. This might be it? I'm not sure, but it certainly looks like it could be.

ack. i meant 2nd amendment!

[Anonymous Coward]

ack. i meant 2nd amendment!

Widespread acceptance

[Moooo Cow]

"Well, it is optional, but as a gedankenexperiment, let's suppose it weren't. If something gets into the kernel (or any other open project), it's because people want it there. If it isn't made optional, and no one forks a version without it, it's because not enough people dislike it enough."

That statement is only true if 'people' == 'developers compentent enough to maintain kernel code'. If Linux is to gain widespread acceptance, then for 99.9%+ percent of the population, it will be equally difficult to remove an easter egg from the Linux kernel as is to remove the flight simulator from Microsoft Excel.

I believe it is the development paradigm you are espousing here that is one of the largest roadblocks to mainstream acceptance - you've implicitly excluded the large majority of the 'people' who could be using Linux, without even noticing that you did.

Re:Widespread acceptance

[smittyoneeach]

The other piece, besides the skill to which you allude, is source code availability.

Re:Widespread acceptance

[ichimunki]

Except that any developer wants to can fork the project so that it does not include the easter eggs, thereby gaining all those users who are upset about such things. Whatever benefit that might have to such a developer I leave as an exercise for the reader.

Re:Widespread acceptance

[return 42]

That statement is only true if 'people' == 'developers compentent enough to maintain kernel code'.

Or people who can hire or persuade such developers.

If Linux is to gain widespread acceptance, then for 99.9%+ percent of the population, it will be equally difficult to remove an easter egg from the Linux kernel as is to remove the flight simulator from Microsoft Excel.

99.9% of mainstream users will be unable to change the source directly, true. But follow the math here: if as few as 1,000 people want something changed, and 99.9% of them can't do it, that leaves one who can. Meanwhile, many of the other 999 will be bitching about it in various fora, which will probably influence others, especially if they have a legitimate complaint.

Also, I would expect a certain positive correlation between inclination to be annoyed at a misfeature, and ability to do something about it. So I think your 99.9% figure is high.

It is also at least possible for many sufficiently motivated people to learn how to program and influence an open project they care about. In any case, 99.9% unable to change open software is certainly better than 100% unable to change closed software.

I believe it is the development paradigm you are espousing here that is one of the largest roadblocks to mainstream acceptance - you've implicitly excluded the large majority of the 'people' who could be using Linux, without even noticing that you did.

Given that most people can't program, can you suggest an alternative paradigm that would increase participation?

Finally, it must be said: people who have paid for software, and are forbidden to fix it themselves (or hire someone to fix it), have legitimate cause for complaint if their vendor doesn't fix it for them. People who have gotten software for free, and are free to change it in any way they like, have no claim at all on the developers. "If it breaks, you get to keep both pieces."

Feeling lazy, but...

[twilight30]

I had the impression that the inverse is an eventual goal for ESR and Owens. I think it's stated in the future goals' section of ESR's paper.

You are correct in saying that this would make newbie use of the kernel much simpler. However, one step at a time, my son...

clueless moderation

[brlewis]

Somebody thinks that a talk ESR was going to give on the topic of CML2 is off-topic re. CML2. Go figure.

Thanx to ESR

[farrellj]

I new adventure game!

And I thought "make config" was enough like a adventure anyways!

ttyl
Farrell

But will Linus accept it?

[Needlejaw]

CML2 may be as ready for Linux 2.5 as it can be, but that doesn't matter one bit if Linus doesn't want to take it. It seems to me ESR is taking it for granted that this will be the next kernel configuration scheme, but what's the word from the main man himself? I haven't heard a word about CML1 being replaced, but then I really don't follow the LKML too closely.

I imagine there would be quite a few oposed to this, especially if Linux now needs to ship with Python as well.
Would it perhaps be feasible to to compile the CML2 parser, and just ship that binary for those that don't want to install Python as well? Or does someone have other tricks up their sleeve?

Re:But will Linus accept it?

[Oswald]

Would it perhaps be feasible to to compile the CML2 parser, and just ship that binary for those that don't want to install Python as well? Or does someone have other tricks up their sleeve?

In the cited document (I know, it's a long, technical, and only semi-interesting read), The CML2 Language, ESR says this about that:

Python, unlike other scripting languages, can be (effectively) compiled to pure C using the freeze facility. The translation is not pretty, and produces rather large C programs from even small Python sources, but it does meet the problem of portability head-on. Kernels could be shipped with a precompiled rulebase and a frozen C version of the CML2 interpreter to avoid the requirement for Python.

Re:But will Linus accept it?

[psamuels]

CML2 may be as ready for Linux 2.5 as it can be, but that doesn't matter one bit if Linus doesn't want to take it.

Actually, word on the street is that Linus has already decided to take it. (He is reported to have said as much at the last Kernel Developers' Summit.)

I imagine there would be quite a few oposed to this, especially if Linux now needs to ship with Python as well.

Yes, there were (I was one of them), but again, Linus has said that the new tool requirement is Not An Issue.

One thing has to be said - if we're getting a new language / tool requirement, at least we're dropping TCL! Much as I dislike Python, I'd rather hack in that than in TCL any day of the week.

Would it perhaps be feasible to to compile the CML2 parser, and just ship that binary for those that don't want to install Python as well?

ESR proposed exactly this idea, when confronted with the objection to requiring Python. It seems Python has a mode where you can ship your code as byte-compiled data inside a Python bytecode interpreter as one big C program. The problem with that is, since Linux is distributed as patches, any time the config system were changed, someone (Linus) would have to regenerate the C program and include the binary-looking changes in his patch files, bloating them.

It's like those SCSI firmware file updates which sometimes take up 80% of a kernel patch, long lines of hex digits that don't mean a thing to anyone except the card vendor. Those are necessary, because usually the firmware is closed-source. CML2 doesn't have that excuse.

This'll make kernel builds more fun

[rnturn]

If memory serves, there was a column in DEC Professional years ago (obviously) that jokingly likened the RSX-11 SYSGEN process as an adventure game. Now something like that's finally available!

I'm sort of wondering how long it'll be before I see ``Munging the SCSI adapter has no effect or what ``Hello, sailor'' does to the kernel. And, yes, I know, those are more from the Zork games. Just can't remember any of the good funny responses from adventure any more. Other than the one about the maze of twisty passages, of course.

An even better interface

[theLime]

While Adventure is amusing, a Nethack/Angband-style configuration could be far more useful. The same room/object analogy could be used (town-level: different stores as sub-menus), you can check your inventory for current config, choose your race/class (arch/proc), etc etc etc.

When you are suited up and ready to battle, the compilation process could be initiated by entering the dungeon and watching gcc slay the demons of .h and hordes .c ! Return victorious with the Amulet of bzImage!

Well, maybe that's taking it too far.

But if it got popular enough, maybe Blizzard would re-hash it in a fully-graphic real-time game for Windows.....

Re:Brain damage

[fredlwm]

Moderate this up.

Complete drivel

[Friendless]

OK, so ESR has invented a new language with an awful syntax. I would think in the 21st century we could say "and" or "&" instead of "-a". The language is a disaster.
As for the adventure game, I don't understand kernel configuration and I don't understand the adventure game. It makes it harder for me to see what options I have. How did ESR know to go north to get to CPU choices? Adventure games are only fun because of the process of discovery. GUIs are popular because more options are in your face and you can see what you can do. When I am doing something as potentially tricky as configuring a kernel, I want as much information as possible presented to me, and I want the consequences of those actions to be bleedingly obvious. I don't want to have to grovel for every piece of information.
I applaud all those who are tackling this problem, but this is a very poor solution.

Re:Complete drivel

[Fastolfe]

Lighten up! Don't use the "adventure game" front-end for the configurator if you don't want to. The new default front-end is geared towards non-technical users, but this isn't that front-end. Are you assuming that he's really intending this adventure game to be the configuration tool he expects people to use?

Re:Complete drivel

[gigi]

Yes, it's pretty sad the he invented a new language. This will now need to get validation tools and processing libraries, etc, whereas something XML-based would have that for free.
Not to mention the learning curve.
I wish he used XUL from mozilla instead:
http://www.mozilla.org/xpfe/xptoolkit/xulintro.htm l
Then you could display make xconfig directly in moziila...

Alan Cox vs RMS

[Anonymous Coward]

I like the ideas behind CML2 but wouldn't Alan Cox be a better person to create the MUD interface?

ESR may have a lot of experience playing MUDs but I don't know how much experience he has being a builder or an admin.

Alan Cox, on the other hand, has a proven track record for coding MUDs.

A lot of MUD coding is more complicated than it may seem at the first glance. The mobs have to be easy enough for newbies and still hard enough for oldbies. Also the player classes have to balanced for PK purposes.

It's all very complicated.

XML is a syntax, not a language

[MenTaLguY]

They'd still have to learn the semantics of the tags. XML _only_ provides a common syntax/metasyntax, and not even that pleasant a one (although it does have a lot of nice features).

CML2 make python a requirement to compile a kernel

[harimandir]

If CML2 is interesting from the very technical point of view, for its benefits, his flexibilty and his scalability of the configuration language itself, the fact that it requires Python2, just SUCKS.
The linux kernel needed CML2 to solve some known problems, and to ease the build of new kernels, but didnt needed a requirement of 50 additional Mbytes (python 2), that all of the Linux vendors will have to ship now (I also think about embedded systems on this issue).
This packages is very NON-standard, except maybe on Debian, and a port of CML2 in C would be way more logical IMHO (or at least, in Perl, because it's much standard these days (autoconf needs it too)).
I'm curious to see the arguments of "Mr ESR the hacker, author of amazing software from kernel space to user land like fetchmail or the insane gif2png" on the real tech needs to use Python2 over something else on this issue.

Re:Ugh

[harimandir]

Actually i share your opinion. ESR may have written a couple of successfull books, he may have done a couple of speechs, and so on ... But, the fact is that his contribution to the free software world, the actual amount of _code_, is just ridiculous. The biggest of his projects is, afaik, fetchmail, it says it all. And the rest is an amount of small python scripts, FAQs, documents, and useless stuffs. CML2 is just an opportunity for him, to do the project that would give him a real dimension of HACKER (hahaha). He wants to be the voice of the opensource community, and it makes me sicks. Not because the guy has theses known views on the possession of weapons, anarchy etc ... i dont give a damn after all, he can politically and ethically think whatever he wants. But the problems comes when he writes documents like the Jargon, the hackers FAQ, and stuffs like that that describes our free software world. Where he speaks like a 10 years old kid, and therefor makes people of 'his community' just ridiculous. Oh by the way, if you feel bored, i just recommand checking this URL out, where you can watch the specimen in all its splendor. Now next time you meet a lesbian, dont ask her why :-)http://tuxedo.org/~esr/photo-gallery.html you can find the same kind of pics here : http://www.uglypeople.com/

come wipe the vomit off ken [thompson]'s keyboard

[Anonymous Coward]

A special program is needed to configure the Linux kernel?

It's run interactively, like a computer game?

Wow. It's astonishing how alike the Linux and Windows communities are becoming.

Why a new language?

[dreamsinter]

Wouldn't datalog be better? A prolog/database derivative, it manages to look enough like english to pass muster with the non-digitally-literate, and can be learnt quickly.

Oh, yes, doesn't have the parentheses lisp is (in)famous for ...

You could use it for all sorts of object configurations - make /etc a set of files with different permissions, add another level to the system permissions (kernel to root, bin, and all the rest) - I'm probably talking about something completely different than the standard Linux/Unix whatever, aren't I?

Maybe I should just shut up and get on with it;)

Re:CML2 make python a requirement to compile a ker

[joib]

Get a fscking clue. How many embedded developers do you think compile the kernel for their device on the device itself (Hint: About 0)? Ever heard of crosscompiling? And for that matter, python is available on all the big distros (big in the sense of lots of users, not installed size). And yet another point, python is available on PalmOS, if you're scared that you'll run out of hd space.

Re:CML2 make python a requirement to compile a ker

[psamuels]

I'm curious to see the arguments of "Mr ESR the hacker, author of amazing software from kernel space to user land like fetchmail or the insane gif2png" on the real tech needs to use Python2 over something else on this issue.

Thankfully, I am not ESR, but the answer is roughly:

The design requires (well, "wants") a language good at string handling and dynamic data. That means Perl or Python, not counting more obscure candidates like Ruby or Visual Basic. [(:]

So why not Perl? ESR prefers Python. It's that simple. (And yes, he used to be a Perl hacker, so if he's a Python bigot, at least he's an informed Python bigot....)

Re:CML2 make python a requirement to compile a ker

[harimandir]

Get a fscking clue
^^^^^^^ set SLASHDOT_LAMER="YES"

How many embedded developers do you think compile the kernel for their device on the device itself

How many ? Probably more than what you think. Actualy i think that having the power of compiling a kernel and modules on the localhost is more important than what your small sized brai n might imagine.

Now on the availability of Python2 over the current linux distros, i think you missunderstood what i meant. I dont say it aint available, i say it aint standard at all. Perl is default these days, so why using python ? I like the fact that i can compile a kernel with only binut ils, a C lib and an compiler.

Python is supported on PalmOS ? OH my god i dont care at all !

why yet another format?

[Anonymous Coward]

this may be completely displaced, but why not use an xml-based approach? build a framework, that offers at least the remote chance that the config tool could be used in more projects than the kernel?

Re:CML2 make python a requirement to compile a ker

[joib]

Oooh, looky looky!! I see a flame war brewing...:)
About PalmOS and python, to be frank, I don't really care either since I don't own a Palm and I'm not interrested in acquiring one. I just wanted to point out to you that if necessary you can fit python into a pretty small environment. Hell you can even run a version of Java on a friggin smart card! So if you for some reason I don't really get despite all your excellent explaining (look! ooh! it's powerful! your small sized brai n is unable to understand this!) are going to cram the kernel source, gcc, binutils, make and a few other necessary things onto your "embedded" device adding a scripting language (be it perl or python or whatever) isn't going to make much difference in terms of disk space used.
And python is not _that _non-standard. The last time I used a linux distro where python was not packaged was with slackware 2.something back in 1995.
As to why to use python, and while we are on the subject of ESR:s CML2, he wrote a nice article explaining his choice of python visible at
http://www2.linuxjournal.com/lj-issues/issue73/3 88 2.html

Not XML, RDF

[mnot]

XML wouldn't be a good alternative for CLM2, but it's squarely in scope for RDF and the Semantic Web.