Slashdot Mirror
Should Aunt Tillie Build Her Own Kernels?
DeadBugs writes: "Linux Weekly News is reporting on a new linux controversy. The inclusion of a Kernel Autoconfiguration program that would make it easy for almost anybody to build a custom Kernel on their computer. Eric Raymond supports this idea saying that this will bring Linux to a wider market. Those that oppose this idea mainly think that only those educated few should custom build their own Kernels. I for one hope this gets included if only to make standard installations and upgrades faster."
Why the heck is this a controversy? It seems to me that anything that makes good technology accessible to more people is a good thing.
I'd like to hear good arguments in the other camp, though.
Am I reading correctly? Is this a debate over limiting vs. allowing certain behavior? What part of the Open Source philosophy got suspended while I was at lunch?
Let some distribution try this. It may take off, it may fail-- that's what it's all about...
davejenkins.com |
Expect to see a lot of "This software only supported under the standard Red Hat v7.2 Kernel."
I don't blame the software companies one bit either.
Most Linux users are already familiar with the caveats and reprecussions of customizing your kernel. This kind of tool would just make it easier to get to.
There aren't all that many "casual" Linux users. That market is dominated by Microsoft. And if you've deployed Linux to a work environment, chances are you won't allow a tool like this to be used, because you'll probably want to lock down the configurations (making your life as a sys admin a lot easier).
Assuming Linux continues to proliferate to the consumer market, I still wouldn't be worried about people tinkering with their kernel too much. Most people, especially at the "average Joe" level, don't understand the inner workings of their OS. Heck, most of them fear their OS and assume that they'll break something if they tinker with the OS's inner settings. I wouldn't conclude that simply because the tool is there that most people would be interested in using it.
My sigs always suck.
Ponder:
Should Aunt Tillie Build Her Own Kernels?
Should Aunt Tillie Install Her Own OS?
Should Aunt Tillie Install Her Own Applications?
Should Aunt Tillie Run Her Own Applications?
Should Aunt Tillie Produce Her Own Documents?
Should Aunt Tillie Think Her Own Thoughts?
*****WARNING. USING THIS TOOL CAN SCREW UP YOUR COMPUTER, BIG TIME. IF YOU WANT TO USE IT, DONT BE MAD AT ANYONE BUT YOURSELF IF YOU FUDGE THINGS UP*****
.. I mean, seriously. The only thing you could end up with is some fucked kernels (who should get along just fine with the fucked registries) and some users who will learn and be cautious, and end up having a better understanding their computers.
If MS can include regedit, you cant tell me that we can't inlcude autoconf
"Old man yells at systemd"
I mean honestly, what claim can linux hold over windows if not that the availabillity of the source code allots the user more freedom? This is, as far as I'm concerned, what linux is all about. I am totally unable to understand any argument against making one of the most important benefits of linux more accessible to a wider market.
Aunt Tillie doesn't need this. But, as a computer consultant and VAR, I need the ability to easily make these kinds of changes based on what my customers need.
Sure, I can do this myself the old-fashioned way. But this is the kind of thing I prefer to delegate to someone with a lower billing rate so I can focus on the things that really bring in the bucks. It is easier to train someone to use Eric's AutoConfigurator than it is to explain make files and such...
Jack William Bell, who likes the KISS method in most things.
- -
Are you an SF Fan? Are you a Tru-Fan?
I want a distribution that has a similar GUI installer that RH and Mandrake have, but instead of invoking "rpm -i" for each package, it would build all the install packages from source drops. The "installer script" could be a large XML file that describes how to compile each package, what its dependencies are, and provides a mechanism for tweaking the packages configuration. Most of the packages out there can have their runtime configuration configured via their 'configure' script (wow that's a lot of "configures"), making it a fairly uniform approach. In addition, at the beginning of the install, it would be neat to see controls for your *exact* hardware configuation that get turned into CFLAGS like -march=i[my]86 and -O3, etc.
The only drawback I can see is that it would increase install times by a *lot*. However, in the end you would end up with a *highly* optimized distribution.
The idea came to me while building my own.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
I hadn't heard about the bug report problem until you brought it up, and it's frankly amazing that it hasn't been addressed in this manner already.
Actually, the bug/patch reporting problem was mentioned in a very recent article about Linux VMs. Rik van Riel complained that Linus' (rather human-based) system was prone to missing patches, no doubt because the mailing list is filled with bogus bug reports, if indeed these are the same lists. Even if they aren't the same lists, Linus would probably have to monitor both anyway.
The point is that we have clear evidence a better system is needed for bug reporting and patch submission to give the main developers some way of organising and prioritising things. Clearly a simple mailing list does not suffice when the number of people submitting gets very large. Any takers?
----- rL
I have problems with Eric Raymond's scenarios. Forget about if it's a good idea to make it easy for anyone to build a custom kernel, my question is, why should you need to recompile the kernel just to install a device driver ? That's just stupid. Installable drivers, that's the way to go.