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."
While 2.4's module support is excellent, and modularisation is become more and more prolific throughout the Linux architecture, there are still several important features which need to be excised from the kernel core and made available as runtime modules. Trivial features such as APM support, SMP and Unix sockets shouldn't require a full recompile to activate. Why do we insist on prolonging the life of "make config" and its brethren when we could very well do without it altogether?
...doesn't everyone build a custom kernel? I've been using Linux for years, and I always assumed that the prebuilt, "Christmas Tree" kernels were just to make installation easier. People actually run with those things? Heh..
Because your referring to somehting completely diffrent. RedHat Mandrake SuSE etc all provide the same mechanism only they call it "daemons"
Same goes for kernel features you don't use.. they are simply unused.
Kernel recompile is a step further and not one often needed by the averge user anymore.
With the exception of some wierd features/devices the only reason you should need to recompile a kernel is if you either want the bleeding edge or want to upgrade to something less buggy and the later is usually pre packaged by the distro.
Some people (like me)want to squeeze that last 1% out of their load times/ram useage by recompiling and that's not a feature windows 2000 even comes close to offering.
This is not true at all. People /migrating/ from Windows environment lack the knowledge that you might be able to assume in a "hacker." I mean, it's a burgeoning hacker, right?
/know/ exactly how to compile a kernel. After all, it may not be necessary. Someone could deploy linux because they want to run their own webserver, or code assignments from school, or code their own little pet projects.
/always/ a good thing."
Besides, some like to deploy linux without wanting to
I have a friend who just came into the linux world. Couldn't figure out how to change the resolution in X... "The option wasn't anywhere in the menus!" Of course not, but he didn't know that, and how could have? He just moved over! He's still learning.
I agree with one of the first posts: "Why is this an issue at all? Increasing accessibility is
It's worse than that.. he wanted autodetection of non PnP ISA cards.
Auto configure is one thing... auto detection of hardware that was never designed to be auto detected is quite another.
I for one would hope Aunt Tillie would have a reasonably recent system. If she uses 10 year old componants she should expect it to be hard.
There are quite a few posts of the form: make xconfig && make dep && make clean && make bzImage && make modules && modules_install && reboot
Depending on your hardware that's a 5 - 30 minute process. Most of the time spent on kernel configuration is in make menuconfig (xconfig -or- config). This is where you make decisions on what drivers/features you will need/include. Keep in mind that the above won't always boot the machine if one of the decisions is made incorrectly.
When a distro is first installed, it always has a working hardware footprint by definition. Running through the options/features that are working for the install process to create a
www.dedserius.com
VB != VisualBasic
Personally, I don't care one bit if this happens or not. As long as I am not forced to use it, it doesn't matter. It isn't my responsibility to decide how other people should use their computers. Although my suspicion is that this will suck supremely. But whatever, give the newbs the device to shoot themselves in the foot with.
----
All of whose base are belong to the what-now?
I have multiple engineering degrees and several years' experience building and using Linux and BSD, and *I* have trouble configuring, building, and installing the Linux kernel. Forget Aunt Millie -- I want a good kernel autoconfig tool for myself!
Aunt Tiley would likely not need to upgrade her kernel all that often once she's up and running anyhow. We don't need to establish the same kind of upgrade-frenzy that Microsoft and others have pushed. Linux isn't a purely market-driven product, and so frequent updates aren't a requirement just to stay in business. Short of any major technical or security issues, Aunt Tiley would be fine running the default kernel for quite some time. No need to upgrade to the latest and greatest kernel in order to get more eye-candy. Hell, the eye-candy's in a wholely seperate bunch of non-kernel packages anyhow.
So, Aunt Tiley could as easily grab the new kernel upgrades and new kernel modules via red-carpet or Redhat's FTP site. A simple upgrade using RPM since she's never installed anything from a TAR, she should never run into any kinds of conflicts.
I don't see Aunt Tiley or anyone out side of us hairy-chested geeks wanting to recompile their kernel anyhow. When was the last time your Aunt Tiley insisted she needed to use regedt32? They're users, not tweakers. A normal user shouldn't have to recompile the kernel. Ever. Thanks to loadable modules which have been around forever. It's just a matter of a good installation system that sets things up well to begin with.
--- http://foo.ca
Programming is the act of creating automations of complexities that are made up of simpler things.
Does the programmer re-write open() every time they need to open a file?
There is not only nothing wrong with making it easier to build a custom kernel, but in fact there should be a growing interest in doing this sort of simplifying, given the GNU Hurd is about not only modularity but about servers/transltors and creating such, even custom as is needed.
This can be taken even further in that autocoding tools can be and should be built for the GNU users.
In a hundred years from now, how do you suppose programming will be done (given programming today is only about 50 years young)?
As things are being done today, it is not possible to do such a program of complexity as can be imagined of what would be a holodeck program (And we do have such virtual reality cudes today in university labs).
It won't be untill the general programming field realized the need to genuinely and honestly address and do the automation of the field of programming. Certainly everything else can be automated, including human balance and movement (segway).
It's fooling to continue the illusion that programming is not itself automatable. And to begin making it happen, where better than on higher level like autoconfiguration system that allow custom kernels to be done? (Or at least one place for it to begin)
A recent research paper on autocoding presents the current/recent mindset on autocoding. It's worth reading to see how young and admitedly immature the field is. Open system and Open Source Software such as the GNU efforts (Linux, the Hurd, etc..) with their open community has far better ability to do what needs to be done than any private effort which will be biased away from doing the things that need to be done.
Soooo, anything that automates computers and their use is inherently a good thing, for iot will allow us all to reach and achieve much more advanced systems and the benefits of.
Aunt Tillie can do anything she wants, as long as the software she's using to do it will automatically back up the current, working kernel with *no prompting* (because you know she'll just click past it if it takes too long, right?), and if the OS has the 'newbie' flag set, it also won't let her do it without a working boot disk. This isn't so much for her, more for the poor person who has to make the computer boot after Tillie's had her way with it.
Newbie flag, you say? I say Linux should have a newbie flag set in the system somewhere (selectable on installation) which is basically linux with training wheels. It provides detailed prompting, hand-holding, and will try to let the user be able to recover from Really Stupid Mistakes.
Applications which support it will also have additional prompting, plus a training mode, perhaps. This adds usuability for newbies and stays out of the way of those of us who vaguely know what we're doing.
Hey, it's a thought.... at the moment, there are no gradations. It's Win9x or WinMe for newbies, and linux for us. If linux had a training mode, wouldn't it be better for both Aunt Tillie and Slashdotters in training?
-- INTX Grouch. http://www.midnightblue.net
The last thing that the geek who helped me install Linux for the first time said was, "Go home, and recompile your kernel." I don't understand what the controversy is; it's really not that hard. I had no trouble figuring it out - it just took a while on 4mb of RAM. I've done it many times over the years, and never broken anything. I'm not an idiot, but I'm not that geeky, either. So, why shouldn't Joe User be allowed, nay, encouraged, to rebuild his kernel?
Christina! Bring me an axe!
I don't really know if there are any tools that gather it all into one place. However, there certainly can be, so if anything, your claim has nothing to do with the kernel itself, and rather with some simple userspace tools that may/may not be written at this time.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
They want fences. They want their OS to ask 3 times if they really want to send that file to the Recycle Bin. Microsoft could put a big button in the middle of the Windows desktop that says "Click here to _permamently_ destroy your computer" and they would get hundreds of tech support calls a day from users asking how to restore their computers after they clicked the button.
:)
Heh heh...you said:
1.) People want their OS to set up limits for them
2.) People want to completely ignore those limits and fuck stuff up anyways.
Since the beginning of your argument went something like "people don't want something they can fuck up" and then you concocted a situation where people do just that, I'm confused. Either people are monumentally stupid, cow-like creatures, or you misspoke. Which is it?
But what does my opinion matter, I just vote here. It's not like I have any money or anything.
..we'll also probably want a special "boot" filesystem, which automatically re-runs lilo whenever someone copies a new kernel to it. Yeah, it's for Aunt Tillie, not me, yeah, that's the ticket...
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Should the typical user be running a precompiled, distribution supplied kernel or a customized kernel that may offer performance advantages or may be wildly inappropriate and which creates immense tech support headaches?
;)
Heh, I guess it depends on who you ask. Since RedHat's money making owes a large part to support fees, I'm sure they won't mind walking through custom kernel configurations at a few dollars a minute, will they?
I suppose this is where open source and commercial processes differ: commercial joints see support calls as 'headaches', open source joints see them as 'a source of revenue'. Who are you going to get better support from, I wonder?
----- rL
That was way back in the 2.1.x days. Then, I knew all the caveats of the minor revisions, and I knew which particular revisions were more stable than others. Now I'm nearly the opposite. I'm happy to leave my system running for months on end without checking the status of the kernels. I actually have to "cat /proc/version" to see what revision I have fired up.
That attitude is only reinforced with the 2.4.x tree. Pondering a kernel upgrade is like pondering if I want to step into a minefield.
Reading the comments in "2.4, The Kernel of Pain", I know there's still Version Whores out there. They know the obvious stuff like "don't use 2.4.15". And I'm sure there's less obvious stuff, too. Aunt Tillie or whomever isn't going to keep up. If she steps onto the 2.4.15 mine (or its equivalent in the future), she could do damage to her system.
To that end, we could use short, digestible ranking/summary system of the kernel revisions. (Or does one already exist?) Which kernels in the stable branch are really unstable? Which are the most robust? Many, Aunt Tillie and myself included, would find value in such a system, regardless of a Kernel Autoconfiguration program.
This thread's funny.
I put together a kernel rebuild guide a few years ago ( Kernel Rebuild Guide ). I'd guess that for perhaps 95% of Linux users, there's absolutely no need to rebuild a kernel. For those that do, it's usually to enable a feature or to tweak just an iota more performance from the system.
Sure, anything that makes the system easier to use is good. It would be wonderful if guides such as mine were obviated. At the same time, should we really be wasting time on what's essentially a band-aid? By this I don't mean that Aunt Tillie shouldn't re-compile her kernel, only that if Aunt Tillie (a regular user) requires the feature then the distribution should already support it through other tools.
The main problem I see is that no matter the frontend, a kernel recompile will invariably ask a lot of questions that Aunt Tillie may be unprepared to answer. And if she can answer them I strongly believe that she would have absolutely no problem with the current configuration tools such as xconfig/menuconfig.
Even though I can hand-edit kernel source files according to needs, I don't want to. I don't feel a need to prove how long my geek-peter is by burning hours doing something that an automation tool will let me do in a couple minutes.
Right now, my S.O. is trying to install Turbolinux on her system: she's a web-type developer who is looking to grow past IIS/ASP/ecmascript and check out things like php and apache and perl. Now, I don't read a word of Japanese, and I don't use RedHat based distros, so she's kind of on her own - I can only give her general advice, and on Japanese-specific things none at all. I'm curious to see what her experience is going to be. But she fits the profile you mentioned - a non-newbie who doesn't need to be a techie if she can help it.
This is perhaps the dumbest flame war I've yet seen on discussion. This is one of the reasons Windows is leading Linux by FAR in the OS wars - if you even want to call it a war.
The answer is very simple. Of course allow this autoconf. Autoconf's are great, people should be able to run a program that makes life easier.
BUT
If you're building a Distro of Linux for end users like your fictional Aunt, don't include the feature. Just don't include it. There isn't enough of a performance increase that you'll see from a kernel optimization in almost every case. Truly if Linux wants to make it onto the mainstream, they are for all intensive purposes going to have to dumb it down a bit. People who just want a simple environment to write their reports, file their taxes, surf the web, and email friends are not going to give a crap about optimizing their kernel. That is best left to hackers. Why not create a distro that speaks to the masses? So don't put it on your 'enduser' distros. That's why distros exist, isn't it?
Now let's face it, the majority of people who use Linux are using it in server environments. If I'm a sysadmin and I want to setup this new distro of Linux quickly and easily without having to search through lines of what ends up looking like a bunch of code, I'd easily take autoconf. I don't see what the argument is about, really. What it comes down to is, there's a bunch of little Linux brats (no better than 5cr1p7 k1dd13z if you ask me) who are trying to protect their little clique of windows-bashers and Linux advocates (who probably don't use Linux anyway), who would rather dismiss the general public as idiots than work with something innovative and smart that makes life easier. These are Syds of the world who insist that the world was better when people did their programs using punch cards.
With those new Ghz machines, better hardware detection, and some luck, The install process could now make the entire system, or at least the biggest resource users (kernel, X, KDE/Gnome, audio/video crap) completely customized and optimized for the machine. And with a simple autodetection program run at boot, new hardware could be taken into account and stuff re-compiled as needed. It might extend the install time a bit, but if packages are already optimized for 686 and above on consumer distro's (as it should be I think), It might not be that much time at all. Even a simple question at the start of install might do it: Are you a user? (compile for celeron, and budget graphic card). Are you a geek? (compile for ridiculously overclocked Athlon and GeForce 3). This really could work...
Shift happens. Fire it up.
Well, if all the Unter-Geeks start flooding the lists with why doesnt my kernel work then it sucks..
UNLESS that leads them to learning to do it themselves.
Ive often wondered why DISTOS didnt have an autocompile script for their kernels so at install it builds one to suit your system
Sig went tro...aahemmm.....fishing........
According to LWN, Alan Cox said that Linux 2.6 will not have compiled-in modules.
From: Alan Cox
To: babydr@baby-dragons.com (Mr. James W. Laferriere)
Subject: Re: ISA hardware discovery -- the elegant solution
Date: Mon, 14 Jan 2002 18:08:32 +0000 (GMT)
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), esr@thyrsus.com,
cate@debian.org (Giacomo Catenazzi),
linux-kernel@vger.kernel.org (Linux Kernel List)
> Hello All , And what mechanism is going to be used for an -all-
> compiled in kernel ? Everyone and there brother is so enamoured
> of Modules . Not everyone uses nor will use modules .
For 2.5 if things go to plan there will be no such thing as a "compiled in"
driver. They simply are not needed with initramfs holding what were once the
"compiled in" modules.
Alan
cpeterso
Granted, I've never used the CML2 tools, but I followed along on the discussion on LKM for quite some time. It seems as though every post is way off the mark.
First, ask yourself this. Is 'make xconfig' a bad user interface? Nope, it ain't. What sucks about kernel configuration? The dependency resolution crap. Linus has a nifty little program in place that does a pretty good job of figuring them out too -- but it's ugly, and admittedly a kludgey solution. CML is more "elegant and flexible" which is a damn good thing -- but last I knew the bugger took 2x longer to do it's job than the old system. Kernel developers do probably 99% -or more- of kernel builds so why on God's good green earth would they want a system that's going to slow them down right now? They don't and I can't blame them in the least bit.
CML2 is nice, and it seems like it's a really good little system, nobody on LKM is opposed to it really (that I saw) they just don't want something that's going to suck minutes out of their programming day. "Aunt Millie" can't answer kernel configuration question anyway, period. Heck, most Windows users don't know if they have 95/98/NT/2000/Me/XP some of the time, let alone if their processor is Pentium III, Pentium IV, or K7 based.. unless the sticker is still on it. Shoot, they don't know if their mouse is ps/2 or serial, or what USB is. Do they know if their USB host system is UHCI or OHCI? Hell no.
CML2 is about making kernel configuration easier in terms of expandability -- not usability. The current interface is very usable, just not very flexible. Because of it's inflexibility and complexity it leads to un-bootable systems sometimes when depency stuff get borked up in strange configuration situations. CML2 takes care of -that- and nothing else. It doesn't keep you from having to know your hardware inside and out. End of story.
> Your analogy, too, is false. If someone new to computers, someone without the "respect" for the technology you mentioned, tries something dangerous that could delete all his or her files, don't you think that there should be at least one little modal dialog that pops up asking "Do you REALLY want to do that?" What you are suggesting is nothing more than classic Slashdot eliteism: "The user shouldn't touch anything they don't understand." Where's the problem in that statement? Think about how you learned to use a computer ...
.. well, how do you know what you know and what you don't? In windows, I don't think you can! What does msgsrv32.exe do? Can I stop it? Wheres the docs on it? Nothing! But imagine it was named the "Explorer Runtime Checker (Do Not Stop!)" .. then, if you had to stop it, presumably, you'd have checked out if it was safe to do so. So I'm not saying everyone should inherently know what they do and what they don't, but rather that peoples furor over the notion of people knowing this hinges on how well the interface describes it's various componants! If every file is named "sdfg34.dll", who knows what you know, but in Linux, we have the opportunity to actually name and label various things properly .. after all, we havn't made the promise to the world that *nix is foolproof like MS has.
.. guess what, I never heard of the thing. So I'm not going to screw with it until someone has told me what the worst case scnerio is. It truely is not my fault that other people do not operate this way, but I charge that they do - except when it comes to computers, because they've been taught that a good piece of software is unbreakable and can't screw the newbies. Dude, I'm not elitist. I'm advocating the opposite of what you think I'm advocating. I say, dangerous things should be the first thing you see when you march through the 'door' of another interface. Once you know what not to touch, you can mess about with other stuff, and graduate to the big red easy to pull lever with the proper signage and warning labels and confirmation step when you feel you're aware of the consequences of your actions and when you're comfortable with the level of knowledge you have regarding the clearly labeled interface. All these people are saying that making interfaces that are available, but kinda outta the way is how to best keep newbies from screwing themselves, but I say put the dangerous stuff upfront with very clear worst case scenario warnings, and then you can seperate the irresponsible people that deserve crashage (ie, those who pull the level before they are ready) from those who heed warnings, accept accountability for their actions, and actually do some reading and thinking before doing. Same with physical objects. How many times, when friends show you some new toy or something, tell you what not to do first? I think it's the natural, time honoured way, and it's frusterating to see so many people who think thats suicide in the computer interface world.
.. System! Would you want to delete the system? Even if you didn't know anything about MacOS or computers?). Linux does it .. fairly well (the boot dir is a good example). Windows is the worst .. look, don't take my word for it. Usability experts the world over bemoan the windows way (ie, the advanced stuff is there, but just hidden, and no real easy way to tell it from the non-advanced stuff), love the macOS way (an extention, the mac equivilent of a group of dlls, has a full, complete descriptive name (generally including the name of the application that depends on it) all in one file .. god bless the resource fork), and think *nix is definately heading in the right direction! I support all this, and thats why I support the disitrbution of this kernel configuration tool! If people are gunna screw with it, as it is a foregone conclusion in my argument, might as well label it well, provide enough warnings and confirmation steps, and put it right out in the open. Don't hide it, or only the newbies who've fallen off the trodden path and don't deserve the greif are gunna get abused by it. I'd rather see the careless uncautious users befall that kind of fate .. they deserve it the most, and will only make the mistake once or twice before learning that there isn't a single garaunteed safe action on this planet, so best to think before you do. :)
.. the frusterating thing is knowing I'm alot closer to how usability experts feel things should be than the average and/or power user.
You're confused. I support putting this tool out in the open, available to the novice, if, and only if:
a) It's labeled clearly
b) There are descriptive, helpful confirmation dialogs that provide a means of finding additional information
c) describe the worse case scenario of the tool in case of gross misuse (which everyone goes through, I know!)
My point in not touching things you dont understand is touchy with Windows Users (of which I am one), because I feel, in my experience
If some part in my computer is labeled clearly "Event Transmographier"
Windows does this very poorly. Nothing is written with a descriptive name, so people screw around because they can't tell if its important or not. What I'm saying is that the labels and signage should indicate this. MacOS does this well (the most important file, System, is called
I know lots of people don't agree with me
"Old man yells at systemd"
In Netbsd there is a perl script to reconfigure a kernel to just compile in the hardware that you have. It is really handy to be able to just type perl adjustkernel GENERIC > MYKERNEL and have the correct hardware selected. I sat at my desk and `configured' the hardware for a kernel recompile in Netbsd in less than five seconds. Try that with Linux. I can code, I've looked at the Linux source code, but I have better things to do than try and remember whether the 5 year webserver that is sitting at work has a pci bus or not. Netbsd has this, why doesn't Linux?
For the "average" joe user, custom kernels are not really needed anymore.
With the advent of dynamically loadable kernel modules, these days the distribution vendor can ship a fairly flexible kernel.
A custom kernel these days may save 200-300 kilobytes of RAM by removing un-necessary drivers - at the expense of support from your distribution vendor. when you consider that the "average" user these days will have at least 64 MB, its pretty insignificant.
there is of course the issue of specific CPU optimizations, however I believe this can (and should) be handled by the distribution - just give the user a choice of kernels on install (or ideally autodetect CPU type and give the option of "standard 386 kernel" or "xxx cpu optimized kernel").
The only real *need* for custom kernels these days is if you are doing "funky" stuff with your network, and this is really a situation in which you would hopefully have someone who knows what they're doing.
of course, geeks will always want to play with the kernel for fun and amusement, but it shouldn't be necessary for everyone...
just my 2c
smash
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
IMPORTANT: Please read the whole post
I'm sure many of you are aware of this thread already.
If you are interested in helping against the moderators who have been "editing" the thread, please read this.
Please do not moderate this post down. It is good for the long term, but if you still feel like being someone who denies the horrible truth, give me your best shot. You will help hold all of Slashdot users back in the long term.
For more info, read this piece from an apparently superior news site.
What if Aunt Tillie buys new hardware, that isn't already supported in her kernel...
:)
Sure, she could hope that Debian/Mandrake/Red Hat/Slackware/etc bring out a new package that has a patched kernel in it, or....
she just hits the button, waits an hour & reboots.
I don't think this is aimed at computer-illiterates, just people who don't want to (or can't) spend the time learning what all the options in the kernel are for.
The last time I compiled one, I didn't know whether I should choose 'SoundBlaster' support, or 'OSS' - what about my CD? Is it ATAPI? LM-206? I thought it was IDE, but I didn't see that option until after I'd selected the wrong thing...
Anything that makes life easier is good, not everyone WANTS to 'learn how to configure and compile a kernel using the existing tools'.
And if she shouldn't do it, hide the button. When she finds out that recompiling a Kernel is required, she should find out where the button is, and not before
Liked this comment? Why not buy me something nice
I mostly run debian (when it comes to linux) nowadays. Why? Becasue of the dselect convenience. I have thousands of pre-configured free packages to choose from.
.deb-files (maybe there is). In fact, freedom for me is not worrying about how the .deb-files were created in the first place.
Did I compile a lot of stuff when I ran slackware? Yes.
Do I know how to build debian packages? No.
Would I be able to build a debian package if I found out I needed to? Probably.
I dont feel I would have more freedom if there was a very simple program that created
Why would an automatic kernel-compiling-wizard give more freedom to users than the opportunity to choose from a set of precompiled kernels?
But of course, I can not argue that more choice is less freedom. Hopefully the tool gets so good everyone uses it.