Slashdot Mirror
New Linux Kernel Configuration System
An anonymous reader writes "When Eric S. Raymond tried to replace the Linux kernel's configuration system with "something better", he got booed off the stage. Now Roman Zippel is bravely having his own go at it. Here's an interview with Roman and a look at his new configuration system, aimed for inclusion into the 2.5 development kernel. Also, find some screenshots of his new graphical configuration frontend."
that the kerneltrap topic id is 404...
When Eric S. Raymond tried to replace the Linux kernel's configuration system with "something better", he got booed off the stage.
Yet another thing to add to my list of "and people wounder why linux is not being readily accepted by everyone" items. I mean, come on, the guy just wanted to help make things better! Getting booed off the stage hurts!
GoatPigSheep, the 3 most important food groups
Well the site is /.ed so what i want to know is.
Does it scan your hardware and create a default kernel configuration with all ther drivers for your hardware pre-selected.
It could even ask if you running a desktop or server machine and turn on/off low latency, pre-emtion and supermount for the desktop.
I usually have to enable evrything to get X piece of hardware working corrctly and then disable stuff to find out what the correct drivers/modules were.
thank God the internet isn't a human right.
Right now, when you install pretty much anybody's distro, you start up with an interface that has tons and tons of menus, icons, widgets, and whatnot, already up and running. It's an overload, and instead of trying to learn it, newbies are balking at it.
So why not have an easy-to-use kernel configuration system? Why not have an independent object model, where any distribution or window manager can use each other's dialog pages?
The only answer we seem to get is: "because it's for wussies!"
-- We live in a world where lemonade is artificial and soap has real lemon.
It's a shame that Linus doesn't want to change, becuase Roman's system is realy great: faster, easier, and at the moment it still leaves the old system as default...
Moreover, it's not like complete newbies are going to be doing kernel compiles. For anyone with enough experience to recompile the kernel, an ncurses-based system is adequate IMHO.
Sig (appended to the end of comments you post, 120 chars)
It's also broken.. kernel developers are constantly trying to work around it's limitations. The fact that config menuconfig and xconfig all have diffrent bugs doesn't help either.
We need something unified (same parser doffrent interfaces) and we need something less limmited. We need someone more sane than ESR to do it.
I believe ESR got booe doff for two reasons. One, the new config required Python. Two, he wanted to change everything at once in ne huge patch, rather than bits and pieces which are easier to understand, back out and correct, and so on.
Infuriate left and right
Its not like they are saying "Lets ditch menuconfig and replace it with this!". For you and whoever else there is still make menuconfig. But I for one would welcome a better GUI than make xconfig, which I find pretty honkey. Since when are more options bad? It's not like they are forcing you into switching.
- It required Python to build the kernel.
- It was complicated. It included an entire theorem prover. This was sort of cool in that it would not allow you to generate a non-working configuration, but really more than was required for the job.
- Its language was arcane. The main language idiom is the suppress-unless statement, which is sort of the logical negation of if-then statements.
- And some folks questioned his motivation for getting this grandiose project into the kernel - was it just to help out, or was it primarily to establish additional hacker reputation for Eric? I'd be willing to give him the benefit of the doubt on this - he did the work.
I think he had a chance of getting it in, but he would have had to refactor the entire thing, write it over in C, make the language cleaner, and I guess that didn't come about. But to his credit, he didn't just talk about it. He generated a working software product with functionality that did not previously exist in Open Source as far as I could tell. His project is worth studying, and I'd encourage works derived from his ideas. I'm sure there's a paper about it online.Bruce
Bruce Perens.
After looking at these two pages I see nothing that could be classified as a security compromise. No passwords, no ports, no UID's, nothing. They are just files with some functions in them. Sure it maybe neater if they had named them .php so visitors couldn't view them, but its not a security issue.
Yet another thing to add to my list of "and people wounder why linux is not being readily accepted by everyone" items. I mean, come on, the guy just wanted to help make things better! Getting booed off the stage hurts!
... I can only ascribe that to politics and personal pull, which every group, no matter how altruistic and well meaning, falls prey to now and then.
:-)), but rather to point out their humanity and fallability, a trait they share with everyone reading this comment, the guy posting it, and probably with every sapient being, everywhere.
First, GNU/Linux will never be accepted "by everyone." Nor will FreeBSD, nor will BeOS, nor will Apple's OS X.
Nor will Microsoft Windows, unless Palladium and DRM is legislated into law by the likes of "Disney" Hollings, and even then Apple is likely to be kept around as a token "competitor," paying hefty patent fees to Microsoft for the privelege of being allowed to manufacture "legal" hardware in the US. Unless, of course, you get off your butt and do something about it, but I digress.
The problem is a simple and obvious one, and the solution as elusive today as it was the first time humans came to live together (and likely predates our ability to speak): Politics is ugly and banal, and people are fallible. This includes the Linux kernel developers and Linus Torvalds himself.
Example: The ggi project wanted to provide a kernel abstraction layer for video hardware in the same manner such abstractions are presented for everything else, from your ethernet adapter to your system's RAM and hard drive. Linus thought the idea sucked, then ended up doing a "poor man's" version of frame buffer support instead. How much better things would have been if the original vision of the GGI folks had been realized and supported we'll never know.
Example: PCMCIA. It is still a mess. The more capable userspace version got sidelined in favor of a broken and less capable rewrite
There are other examples, and perhaps Eric S. Raymond's effort is one (though I hesitate to make that assumption), but the purpose of this post is not to catalogue the mistakes Linus and others have made, or to air my own disagreements with them (but what the hell: when will we get XFS into the main kernel tree damn it!
Mistakes happen, everywhere, by everyone. The measure of a group or project's success isn't their perfection (as is so often implied in political discussions), it is by how much their mistaken decisions are outweighed by their correct decisions.
And using that metric, the Kernel developers, including Linus Torvalds, have done very well indeed.
The Future of Human Evolution: Autonomy
Well, it doesn't have the password/usernames in there, so it's not as bad as it seems... but you're right, it's a bad idea to leave it out in the open.
Bruce
Bruce Perens.
This will happen more and more. I really do expect that at some point someone will just say fuck it and branch their own version of Linux. I see this as possibly a good thing. If this branched version gets all the cool patches that Linus and co are turning down, and they work, it may prove to be a catalyst for change. Either that or the branched version will become better than the original. It happened with XEmacs (which IMHO is much better than Emacs), I see no logical reason it couldn't happen here aswell.
You want too see the beauty of Linux Auto detection possibilities boot into knoppix.
I booted of the CD, got fully configured X, working sound, Working Xawtv, Working network with DHCP enabled, and therefore working broadband, and a working CD burner. It took a whole of like one minute to boot and it was everything I neaded. I Actually use it instead of Debian now for my main distro, mounting my old hard drive as scrap space.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
sanity checking in your input values
basic rule of thumb, don't let people past your nic see anything but html; don't accept anything but stuff that you can *prove* is safe.
I live in a giant bucket.
Yeah. It certainly is. If you've ever done embedded work before and found oneself subject to the cosmic horror that is slaying $500 worth of flash hardware because the kernel configs made a booboo one will realise just how fantastic ESR's theorem checking autoconfigurator would of been. What a shame it's been beaten off by the anti-python mob.Stupid stupid stupid.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
GGI tried to do too much and it abstracted too far.
Userspace PCMCIA drivers? That's a new one. I can only imagine that you were refering to the external set of drivers that used to be the standard and where characterised as being so hard to install that Linus himself had trouble with it. I completly understand his reasons for wanting that mess replaced.
ESR's configureator was massive overkill and it made life harder for developers. On top of that what killed it in the end wsa not Linus but ESR's refusal to update the patches to handle changes Linus made to the core code.
Not everything gets to be black and white.
After finally being able to get the page, I think that it is a great start and a tremendous improvement over Xconfig.
That said, I think he still needs to go further. Most users don't have a clue what all the options are or mean. Even with the descriptions and recommendations they will quickly become overwelmed.
I feel that users should be presented with a very basic and lean initial configuration screen. One that lists generic features for them to enable and disable. For example a single check box for IDE and SCSI HD support or a single checkbox to enable HAM radio support with generic or "standard" options preselected for those devices. Then there should be an advanced button that brings them to the complete configuration options, such as Roman's example.
This, combined with some form of modprobe hardware detection, would make kernel configuration a breeze, even for MCSEs. Also, the fact that this configurator reads the existing config, rather than starting with a blank slate everytime, is great!!
Further, people are working on the configuartion language but there are bigger problems to be solved, everyone knows it and still the efforts don't fully address them. Like how do you know the configuation options used on the kernel you are running? There is no reason to change just for the sake of change and compilation speed isn't a huge issue, my dual amd compiles kernels so fast I don't care if I cut the speed in half. Plus, when you're hacking you usually work on a module or two and don't rebuild the whole thing.
The process is good, they don't take crap. The VM system and the IDE system are other prime examples. Al Viro is kind of mean to people but everyone else makes it pretty clear what needs to be done, why things aren't accpeted, even Al has expectations that he makes clear. There are expectations for robustness, it's more important than performance. Hans Reiser has had issues with that, he can't explain the robustness or answers concerns but he can point to benchmarks; clue: they don't give a shit if it's not robust.
There have been a handful of people who just don't cut it. Believe me, they can be replaced. It sucks, it'll be a dark day when Alan Cox or Dave Miller quit, if they ever do but they also know the rules, they play by them and they have their own forks if they don't agree. If Linus or someone else don't like your code, it doesn't get in, fork and show that they are wrong or make it better. This isn't bullying or anything like that, it's not that they are elitests, they have real expectations that aren't meet some times. Are some people and some parts of the kernel more equal than others? Of course, we're all human.
I take exception to the suggestion that the kernel team is throwing out great stuff for non technical reasons. They aren't they throw it out because it doesn't do what it is supposed to, people are trying to get it in for non-technical reasons with non-technical means or because it's not robust. It's not easy to write a VM or IDE system, there are a ton of expectations, it's a hard job, there are working solutions already that you have to do better than.
Kernel changes that modularize everything that can be (pretty much that way now) and everything loaded on need (it's done that way now too mostly). So why compile your kernel (besides the because you can thing). One thing I would like is to see a standard way for non GPL'd drivers to be added to the kernel without a recompile, or having to half way compile (proprietary core) with a kernel interface needing compiled. It's kind of that way with some, but only if your binary is developed against the same kernel (the LTMODEM drivers used to be and may be still this way). Microsoft does not write all of their drivers. We should not have to either. Seems to me this would sure make alot more hardware work under Linux! I know the GNU bigots won't like it much, but I just want to be able to have more stuff supported out of the box then I do now.
Gorkman
"Shit... don't inflate my stock more than it's worth." - Jeff Garzik
Now if only more [people] were at least this humble...
are the marketing and PR departments to cover up or put spin on anything that could be even remotely considered a mistake.
To parent poster: Do you honestly believe that worse things don't happens behind corporate walls!? Have you been living in a bubble!? The great thing about open source is, whatever happens, you will always have enough information to form your own opinion. As a corporate drone, I can safely assure you that you will NEVER get that level of detail from a corporation (even though the Internet has helped expose a lot). Personally, I think your shock is due to a lack of exposure to a REAL community (people argue all the time . . . that's how things get worked out), rather than anything having to due witht the Kernel developers. Goes to show how corporate our society has become . . .
Sdelat' Ameriku velikoy Snova!
My question is why custom kernels are needed anyways? Except for embedded applications, such as Tivo, why should the common user have to build a custom kernel to get certain hardware support? Is the Linux device driver model really flawed as many claim?
Certainly its nice for development, or experimental patches such as low-latency patches. However it often seems necessary to build a kernel to get certain modules or hardware functionality.
Any comments on the Linux device driver model?
We shouldn't have to decide for hundreds of packages whether we want them or what options they should be pre-configured with in the first place. Almost everything should always be dynamically loadable and should always be dynamically loaded. Modules should be independent between minor kernel versions. There should be very few options, and those that are there should be configurable at runtime. The few remaining compile-time options shouldn't require some complicated interface. If we want single-file kernel distribution, we should be able to create a single file archive of the kernel and the required modules in a way that the bootstrap loader understands.
While parts of the Linux kernel are great--the variety of kernels and file systems, for example--I think overall kernel architecture and configuration is by far the weakest part of the Linux operating system. It's not the GUI that inhibits Linux adoption by the masses--Linux GUIs are up to par with other platforms--it's the fact that a large number of people end up having to recompile the kernel to get things like audio, FireWire, power management, cameras, and USB working, even with the modularized kernels in some distributions.
I know what hardware I have in my computer. But Linux often either labels it strangely, or labels it completely wrongly because of its bizarre way of operating. For example, I have not a single piece of SCSI hardware in my system. Yet for my IDE CD burner to work, I have to load the ide-scsi module, because apparently CD burning in Linux has only been implemented for SCSI burners, so the only way to get IDE burners to work is to emulate them as SCSI burners. Not intuitive.
Not to mention the millions of chipset names. In Windows, you choose the name of your card, and it figures out the chipset (that's in the worst case; usually it just auto-detects it in the first place). In Linux, you have to figure out who made the chipset on your card, which often isn't labeled on the box or in the manual, so requires some guessing or googling. An easy-to-find example is the emu10k1 for Soundblaster Live cards (this is actually documented by Creative); a harder-to-find example is the tulip driver for LinkSys network cards (most of the $10 LinkSys cards don't come with a manual, and the box doesn't mention what chipset they use). And so on for ever.
The Debian way of solving this is by default to build almost everything in the kernel as a module. That way if you discover you need some functionality, you don't have to recompile the kernel; just load the required module. It makes kernel compiling take a bit longer (~20 mins on my Athlon 1.33 GHz), but it's worth it IMHO for never having to recompile it again (until the next kernel upgrade anyway).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
KDE 3 does this via it's configurator with the current kernel/module system.
Here's a screenshot.
Really, I see no problem with the current system. It works well, and is totally modular. You never really even have to recompile your standard, vanilla kernel.
But hey. This new system should be given a chance, I suppose, though I see no use for it personally. I would prefer that it wasn't forced upon me in 2.5.
The primary problem I have with "graphical" anything, is that this is a Windows era issue of "every program written has to use a mouse and a window or it isn't user friendly."
Simply not true. When all I had was a VT100 command set, I wrote terminal interfaces that a 4 year old could use for fairly complicated pieces of software, no mouse required.
Although it did use windows....of a sort.
As for configuring and building a kernel, beyond:
1) Interfaces to remove and pull out components on demand....
2) The interface should provide optional documentation and guidelines as well as best practices for most kernel configs given the applications the machine is going to be running.
(i.e. Will it be a router, firewall, an app server or database server?)
3) The configuration system should be easily scriptable with a minimal set of gcc utils.
(sh, make, config..etc.) This is so that it requires less software to build the kernel.
This implies inherent reduced security risks, smaller kernel distribution and less dependancies for linux systems integrators.
Eric S Raymonds vision fails on all three accounts as far as I can tell, on how a kernel should be built and what the logical assumptions are for building a kernel in the first place.
Primarily, users, shouldn't be building kernels anyway. Which is what I think the root problem is here. No, I don't think either, that there is something wrong with Linux if a user can't do EVERYTHING with a mouse and windows.
Lets be realistic here: Users do not have the background to properly build a kernel, and building a nice graphical front end too build a kernel for a sophisticated developer gets in the way. It also, doesn't detract from Linux one iota simply because this fact exists.
That is what the argument here is, and that is why many people who write kernel programs don't use graphical tools ANYWAY. Which I think breaks another assumption made by Mr. Raymond about a new config system.
Dependancy graphics are nice, rules seperation parsers built to create such graphics with a language are nice.
But this is really OLD SCHOOL stuff. Any computer science/computer professional can buy a book on such theory and compeently learn everything there is to know about REINVENTING the wheel.
(ISBN: 0-13-1555045-4 Start reading at 7.3.2)
And you too can write a configuration system similair to Eric's...
But WHY WASTE YOUR TIME?
The existing kernel configuration system is very scriptable, has supporting documentation available with each modules or options, and works with a very minimal set of build tools on the command line.
Very nice, simple and it works very well very nicely without Python, X, windows, Mice a supported video driver and a whole new set of tools that basically give us the same thing we have now, just a whole lot more complicated.
I would like to see Eric address points 1-3 and tell use exactly why we need all this stuff as kernel developers. He hasn't done so.
His website just shows pretty pictures of a kernel configuration system.
Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Check out the second screenshot. 2 scrollbars of 2 different applications. One has a normal, ugly X scrollbar, the other has a nice look, probably inheriting the selected theme.
That, my friend, is a result of the true error in the whole picture: there is no consistency. People are doing what they think is right, but there is no big, guideline which will bring the whole system to a certain level because it's all worked out.
That is true for the gui, it's also true for kernel configuration. You are right about the fact that people shouldn't be hassling over which package should be installed and which option should be compiled into the kernel. On windows I just run setup and the system configs itself. I never have to recompile any kernel, because 1) I don't have the sourcecode (;)) but 2) I don't have to: WinXP will config itself and will work no matter what hw card I jam into the pci slots: install the driver (or better: xp has the driver already) and off you go. There is no need for compilation of a certain subsystem into the 'kernel'.
Never underestimate the relief of true separation of Religion and State.
Custom kernels are necessary because Linux is a monolithic kernel. That means that in order to use certain hardware or other features, the drivers have to reside in the kernel itself.
Now, lets suppose that you just got the latest gee wiz device and you want to use it on your Linux box. You hook your "flux capacitor" up to the firewire port and nothing happens. Why, because either a firewire or a flux capacitor driver (or both) is required and the kernel doesn't have it installed. This means that you must rebuild the kernel with the appropriate driver in order for your new flux capacitor to work.
Now, some may argue that the kernels should be pre-built with all the drivers and everything. Indeed, many distros do something like this for their stock kernels. But that still doesn't account for hardware that is yet to be invented. It also causes the kernel to grow into a giant that gives the term monolithic a whole new meaning. This large size means slow boot times and slower overall performance, in some cases. Surely, you don't want that?
Indeed, many people want to trim the size of their kernel to an absolute minimum to improve the performance of their system, not to mention the security enhancement of removing unneccessary services. Do you really need HAM radio support? Most people don't, so why would most people want the HAM drivers loaded in their kernel? Do you need NTFS file system support, as I do? Probably not, especially with write access, so why include it? But at the same time, why prevent me from using it, as I need to?
Even without the above reasons requiring the custom kernel, there is one more reason in favor of it. Part of the whole idea behind Linux is the ability to modify and customize it to your heart's content. That means if you want to modify your kernel you can. And this project will make such modifications easier than in the past. If you don't want to bother with customizing your kernel, then use the latest stock kernel from a major distribution, which will have mostly everything included. But, if it is slow or your flux capacitor isn't supported, you'll just have to wait and hope that the distro includes the support in its next release.
And some folks questioned his motivation for getting this grandiose project into the kernel - was it just to help out, or was it primarily to establish additional hacker reputation for Eric? I'd be willing to give him the benefit of the doubt on this - he did the work.
... was it just to help out, ...
What's wrong with being motivated by hacker reputaion points? Isn't that what was supposed to replace money in the open source motivational system?
So an open source developer is evil unless he's motivated solely by altruism?
(That humming sound you hear is the beat between the spin rates of Ayn Rand and Friedrich Hayek.)
C'mon, Bruce. You know better than that.
Regardless of how much we want to help out humanity and all that, SOME of us aren't the leisure class - with old money, idle time, and an indoctrination in the obligations of nobility to give us internal satisfaction when we do something "just to help out" the benighted masses of the common man. Some of us ARE those commoners, with a family, a mortgage, and (if we haven't been laid off in the latest recession) a paycheck that is all that stands between using a shopping cart for groceries and using it for a mobile home.
If we're to contribute time and effort to the open-source codebase we need a way to keep that paycheck coming. Like "reputation points" to put on a resume, to find work the next time the current project is over or the current company goes belly-up.
Maybe Eric doesn't need any more points. But let's not have a big name flaming him for maybe wanting some - and thus convince thousands of onlookers that working open source is a good way to get a BAD rep, so they'd be better off getting that MCSE instead.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
In addition, requiring the Qt or GTK libraries is ridiculous. I don't want to link to anything that large. If you can't get it done with Xaw (or something similarly small) I'm not interested in your stupid config tool. I'd rather use something fast and ncurses-based.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Eric was playing games and his solution was technically superior. Done deal.
...Eric's Solitaire? (bu dum-pssssh)
Lemme guess...
Thank you, I'll be here all week. Remember to tip your waittress.
It looks surprisingly similar to the KDE Kernel Configurator.
Control Center->System->Linux Kernel Configurator
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Exactly!
How is it that Knoppix can get it so right and the major distros are a hash?
Of my 7 personal computers:
Knoppix boots them all, with all their devises functioning.
Mandrake 8.2 fails to initialize USB on 3 of them.
Redhat 7.3 fails to initialize the video on 2 of them (and therefore fails to start X)
Debian 3.0r0 fails to intialize a standard PS/2 mouse on one and ethernet cards on 4.
SUSE 8.0 does not recognize the second CPU in a dual processor machine!?
I just don't understand.
If voting were effective, it would be illegal by now.
Just remember that ESR was the one who wrote about the reputation and the like to begin with, in addition to the rules of social interaction in the OSS world. He didn't write them, he wrote about them. Whether he's correct on all these points is another matter. It may be that hackers write for reputation but it seems that the appearance of writing for reputation is bad.
I Browse at +4 Flamebait
Open Source Sysadmin
If it ain't broke, there is no reason not to try to improve it, IMHO.
However, the changes usually should be incrimental rather than all-at-once. This forces better code, and better systems, and all-round better products.
LedgerSMB: Open source Accounting/ERP
The screenshots look more complicated to me - just a horrible GUI interface with a single giant tree list. How horrible.
The sad thing is that you should need to recompile the kernel to add support for various bits of hardware. What is wrong with using drivers that are not compiled into the kernel, and being able to add them at runtime?
I can understand recompiling the kernel for certain reasons:
1) Want to compile for your architecture to get the best performance
2) Want to make use of a kernel patch, or non-standard kernel feature
The monolithism of the Linux kernel is primitive. It should be fully modular - a small kernel core with additional services for various aspects of the kernel, and with full runtime driver addition and removal, etc. This will become even more necessary with systems that need 99.99% uptime using hot-swap PCI and the like.
The kernel configuration should basically be an automated process - check how many processors you have, optimise for that processor type, etc. Compile all hardware support as drivers/modules. Install.
I think I may have found the answer in the following excerpt from his World Domination guest editorial on Linux Journal:
I can't help wondering whether, in this case, Linus and Jeff are "the bosses"; indeed, stuff like pretty pictures and theorem provers and various other kitchen sinks associated with CML2 qualify (amply) as those "snazzy special effects" of which he is so fond.
Now, love him or hate him, Eric is not going anywhere, even after getting booed off a very important stage. And in light of his, um, staying power and in consideration of the CML2 affair, it should be of some comfort to his detractors that at least Eric the Rich Guy hasn't lost his hackitude and keeps producing worthwhile stuff. When Eric first threatened to quit politics, I looked forward to the return of Eric the Hacker and the retirement of Eric the Politician ; alas, half an Eric must, ipso facto, half not be, and I'll take a whole Eric over half an Eric any day, thank you very much.
At least with Debian, the precompiled kernel doesn't automatically have CD burning properly set up. You have to load the required modules and pass them the proper arguments, as I described in my previous post (and yes, I got the requisite steps from the CD-Writing-HOWTO). In Windows, it detects the hardware and sets it up for you.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I don't agree with your interpretation for why the GGI failed.
The way I saw it, the GGI developers had very grand ideas but insufficient time/resources. In the end, the GGI lost out because FB and the DRI offered something tangible with a reduced complexity. Maybe you could argue that GGI offered more but that's just confirmation of the classic 80/20 rule.
Ive never had as much trouble with a kernel build as i have had since 2.5.31.
the IRDA stuff just wont compile, the orinoco driver wont compiler either. ive never seen the kernel not compile like this. Im having to take out module after module to get something that builds.
Don
Actually all you might have to do is boot up the default kernel which in most systems is full of just about every single modules and run a script that takes an lsmod and generates a config file out of it. I really can't see why this is so damn difficult, you'd think someone would of done this by now. I'm sure this isn't the right way to go about it but... hey... what do you want from a slashdot comment ;).
can't sleep slashdot will eat me
Whether I have the ide-scsi module installed or just the ide-cd module, my CDs are accessible at /dev/cdroms/cdrom0 /dev/cdroms/cdrom1
and
Which drive is which does indeed switch depending on the order in which I choose to load the modules, but anyone who's installed a removable disk driver on windows will tell you that all the disks there jump around too. (e.g.: my wife installed the driver for a compactflash reader on her windows 98 machine, and the CD rom was moved from D: to E: to make room for the compactflash device. Later, we had to re-install it and D: and E: swapped places again)
Anyone saying that linux requires you to use the scsi names hasn't tried devfs lately.
> GGI tried to do too much and it abstracted too far.
KGI (the code to go into the kernel) was just a bit more sophisticated than DRI. Under KGI, the mode switching would be provided by the kernel so that you never lost all use of your console because of X crashing, text blitting routines would be included in the kernel to support Linux's in kernel terminal, for hardware with an accel engine an interface is provided for the driver to tell userspace what accel methods are available. It is as simple as that. KGI was never "acceleration in the kernel" as was shouted about a lot, it was "operations that can render your console or system bus unusable are allowed with care taken to ensure that nothing bad can happen while maintaining DRI level performance".
For matrox (a good, stable accel interface), userspace could query what interface is available and the driver might respond "matrox mmap interface" since it is safe to mmap the accel registers from userspace. If there were any code to operate the accel registers they would be in a badly designed driver (or a driver for badly designed hardware), and nothing to do with KGI *at* *all*.
KGI is the minimum necessary to safely support high performance graphics from userspace and that's not a lot.
ESR's refusal to update the patches to handle changes Linus made to the core code.
Sorry, you don't have permission to rewrite history. Eric updated his patches, and updated and updated, all the while waiting for Linus to suck in CML2 *like Linus promised*. Finally, he got burned out, and started to publicly wonder WTF was going on. All this time he was being roundly, soundly, and viciously abused by various people on the LKML.
All of which goes to show that Linus's promises are worth nothing. But we all knew that, didn't we?
Don't piss off The Angry Economist
Whether you compile code as a module or into the kernel, what difference does it make? You still have to compile the code, so it still takes the same amount of time t ocompile.
What's this Submit thingy do?
Like how do you know the configuation options used on the kernel you are running?
/proc/config, and it spits out all the CONFIG_* options that were defined when the kernel was compiled. I sent that patch to Linus years ago.
You just cat
-russ
Don't piss off The Angry Economist
He instisted in keeping in synch with both the stable and unstable versions and the killer was here followed by Linus making the changes and ESR never updating to match.
I hope you read this as the topic is a few days old. You managed to pick up on something that I am very interested in, language & how it got the way it is. If only I had more time (and intellgence).
.sig :-)
"Philosophy is stored in these terms."
I couldn't agree more, there seem to be "clues" or code regarding something scatered about in language, especially root words and they seem to link in to old myths & legends.
I am not nearly bright enough to express this very eloquently nor to figure it out but language seems to hold a lot more value than just basic communication and something we take for granted.
If only the birds could talk.
Also, time for a new
A journey of a thousand miles starts with a brutal anal raping at airport security