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.'"
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.
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.
bp
"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.
Slashdot is entertaining like pro wrestling is entertaining
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.
/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).
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
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.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README