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"
But I don't think "Aunt Tillie" should accidentally come anywhere near a kernel: Users should not care about kernels because they have to, but because they can. That means that most hardware configuration tasks should be accessible without touching the kernel, including installation of new drivers. So include lots of warning signs -- optimally a normal user will never have to log into his box as "root" except for installing new software with a graphical apt-get like tool.
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.
...when elite hackers said that only elite hackers should have Linux, and all of these "Red Hat" guys are polluting the user base. They are, of course, full of shit.
The whole point of Linux is having a stable and friendlier version of UNIX that is GNU and doesn't have any ties to MS. We now have Average Joe User with their own copy of Linux/X and they are using it just fine. Why should we limit ourselves because we need to do it the "old fashioned way"? Let them (and us) have a easy-to-run auto-config script for building kernels. Are we going to delete our "make menuconfig" scripts and tell everybody to replace it with "vi Makefile", just for being elitists?
Personally, I think these are the "10 miles in the snow, both ways" people, who still believe that the best way to configure PPP on Mandrake is rolling your own scripts. (Uhh..."netconf"...duh!)
Zodiac Survey
Easier to use tools are great.
I just hope we don't start designing things such that people say "oh, to do that just reconfigure your kernel with the foobar option". Feature sets should generally not require kernel recompile imho. For a long time, this was a UNIX weakness.
If we can avoid this (which is after all worse than the old "reboot NT to configure something"), I'm for it 100%. I'm not saying that you have to recompile the kernel much nowdays (I had to once to get an unsupported Ethernet driver working), but kernel recompile gets really easy, I'm nervous that people would start to rely on that way of doing things. Which would be bad.
--LP
She doesn't, and the original poster doesn't understand what ESR's system is for. The current build system misses some dependancies and has some other flaws that I can't remember at the moment. Basically, this discussion began a *long* time ago (in linux time at least)...something like a year ago it was coming across lkml. This has nothing to do with granny compiling a kernel, it's about making the build process *better*.
The best way to accelerate a windows box is at 9.8 meters per second square.
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 think an easy to use, Joe User can make his own kernel is a great step as far as making linux more usable for the masses, i.e in a desktop environment. You can make a more compact kernel without knowing ALL the minute system details and random hardware that most people don't have or know what it is. Definitely a step in the right direction.
~.Evanrude
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
Happiness.
...". Needs to describe how to have multiple kernels, in case something wasn't quite 100% safe. Needs to be concise enough so that a total newbie WILL read it.
Aunt Tillie does not need to build a kernel, ever.
Aunt Tillie can easily build a kernel if she feels like it.
Misery.
Aunt Tillie needs to build a kernel.
Aunt Tillie cannot build the kernel she needs.
It's been a long time since I've compiled a kernel except. The last kernel I compiled was to get an NTFS read-only module so I could ftp it to a "rescue". I wish any other configuration was as easy and straightforward. Need to get the "right" starting point and extremely explicit directions, including all the "remember to
Besides, when Aunt Tillie has reconfigured her kernel, she knows the "My" of "My Computer" now really means Aunt Tillie's computer.
I don't think that anyone genuinely interested in linux/open source/what have you, and who doesn't have their head stuck up their own asses in conceit would honestly say that an autoconfiguration tool for the kernel is bad. Let's look at this objectively.
First, such a tool would only make linux easier for people that are not knowledgeable with computer workings, and make it a more viable option for those who don't want to mess with, or aren't knoledgeable of, the inner workings of the computer. I've run into many people (online) who don't have support for xy device with #.#.# kernel, don't want to install another distro, and need to compile a kernel.
Second, (as far as I know) this would be something fairly easy to do, provided that the device that wants to be used is already attached to the system - the kernel seems to have a decent detection system already, just have, say, a 'kernel compilation disk' which would have the kernel you want to compile, with all the possible modules compiled in, which would use your system. it'd have it's own initscript, which would have a step-by-step process, walking you through the configuration (eg., Is the kernel source tree untarred already?, Is the kernel source tree in a location other than the standard location? etc)
Just some ponderings.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
that people understand precisely by messing with things they don't understand. In fact only for very unimportant things does anyone stand a chance of understanding prior to messing with.
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.
I'm with Cox on the matter that I think Aunt Tillie would be better off with the distro's kernel (where she might have lm_sensors, nVidia, TV and Radio drivers), but !
I'l defend Aunt Tillie's *right* to chose !!
That's what freedom is all about, options !
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc