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.
I can see it now from the vendors "Compiling your own kernel voids any software support." Can you imagine trying to keep up with all the changes as a software vendor? So maybe as a test system, yes. Supported? No
"If you are on fire you can just stop, drop, and roll. If you fall into Lava you are just dead." - my 5yr old daughter
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.
...that this would just make things easier for a Linux newbie to break the OS. Then they can't fix it and are screwed. Then you lose a new Linux user because they don't want to feel stupid using their computer.
You are standing in an open field west of a white house, with a boarded front door. There is a small mailbox here.
If people expect to make linux a desktop OS, then this will probably not fly. The sheer number of total borkages compared to the gain is not worth it.
If people expect to make linux a server/embedded OS then it *would* be nice if powerful things could be done without scaring off PHB's and NT admins.
Though of course it could be argued that PHB's and NT administrators are just as likely to screw themselves as Joe User...
- Get the source
- Probe for devices
- Configure, make, make install
more people might consider using Linux because one of the major hassles is removed.Overrated / Underrated : Moderation
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.
Those that oppose this idea mainly think that only those educated few should custom build their own Kernels.
This I just do not understand. Should that attitude prevailed when it came to PCS or ISA cards pre Plug and Play days when you had to be an expert and getting interrupts set correctly or your system hung (and yes I realize problems still happen with PnP, but its still a billion times better than the old days). What an elitest attitude.
*Make it easier*
Should we get rid of the './configure && make' cycle because its too easy for those of us who don't know the ins and outs of the compile cycle?
(Man, am I in a snippy mood today or what!)
I really can't emphasize strongly enough that I believe that if Aunt Tille has to build her own kernel, we have much bigger problems that Eric's autoconfigurator will solve.
Most of the kernel configuration is simply a matter of which drivers to include in the kernel instead of as modules. Distributions put most of the stuff out as modules, so all that a kernel autoconfigurer would do is notice which modules are loaded and build them as part of the native kernel. The advantages of this are minor--slightly better memory utilization, no need for initrd.
On the other hand, there are some areas where an autoconfigurator would be handy. That's when determining which chipset features/bugs to compile for. Hopefully this project will focus on the areas of configuring that are more complicated than (y/M/n).
i remeber setting up my first Linux installation on a laptop and the hell that ensued when trying to figure out how to put together a custom kernel that would support PCMCIA. Yes, i did learn a lot about the kernel, the Linux boot process, compilers and all sorts of other stuff. Problem being, the average computer user has no desire to do any of these things. This is why the average user won't use Linux. If the goal is really to get Linux on more desktops, we're going to have to see WAY more wizards and configuration tools.
I think the beauty of linux is that I can manually edit config files to my hearts content, or I can fire up Linuxconf and do the same thing.
No one forces me to do either.
Choices are good.
"Compiling a kernel" means collecting seeds for aunt Tillie.
This seems like a bad idea if it's a desktop icon or an easy to access program. Let aunt Tillie mess with the kernel and watch how fast the computer will grind to a halt, heck, we're lucky if aunt Tillie knows that a computer mouse is not a rodent !
- sigs are for wimps.
How much easier can it be?
tar -xzf linux-2.4.17.tar.gz
cd linux
make xconfig
make dep
make clean
make modules
make modules install
...and make it boot...
I mean, If you think that is hard you probably wont be able to give any useful instructions to a kernel configuration program at all... Maybe not even know you need a new kernel...
What is nice with linux (compared to Windows) is that very few things happen "behind your back". The system does not change itself. I find this very comforting.
And modern distributions tend to make it quite easy anyway... I installed Redhat 7.2 from isos today for the first time in over a year. All hardware was autodetected and worked without any tweaking at all (then I felt like compiling an own kernel to play DVDs well, but that another history)
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?
Although I use FreeBSD, building a custom kernel is good for Linux or any of the *nix's. You can get rid of device drivers that slow down the boot process, and you can tailor optimization for your specific uP. That will be especially true if we ever get a gcc that has decent Athlon optimization. I'm also told that taking out the plain Jane i386 support speeds up things considerably.
Before she goes round rebuilding her kernel, first she needs to understand that this has nothing to do with maize.
Jumpstart the tartan drive.
If you want zero-effort working systems, the distributions are the way to go at the moment. If there is anything that can be done to help that unfortunate situation, I am all for it.
:-)
... I actually *like* learning this sort of thing, I just prefer to choose the time of my enlightenment :-)
I know lots about unix in general and linux in particular. I've written kernel drivers. I've designed embedded CPU's and PCI plugin cards. I am generally regarded as being very technically minded
The flipside: I have also been mystified as to why one of my (admittedly more esoteric) kernels just gives up the ghost at inopportune moments. It's almost always my fault, and I almost always learn more from the mistake, but it's sometimes a non-timely learning experience
In short, why would you want to make it difficult ? Use the time you save to solve other problems instead - ones that someone else hasn't kindly provided a solution for...
Simon.
Physicists get Hadrons!
What's the problem if Joe Rube decides to build a new one? I mean, if he smegs up because he didn't ask Jane the Ubergeek to help him, all he has to know is to boot the prior kernel and no damage done for the most part. If he's using Mandrake, he doesn't even need to worry about how the LILO prompt works as he'll be able to select the old Kernal from a list at bootup. Force a timeout for LILO and keep the old Kernel and you're ALMOST Idiotproof, IMHO.
Devo Andare,
Jeffrey.
Time Lord, Dark Horse: The Techno Mage of Gallifrey
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?
Configuring a kernel from source simply ain't that hard. That's why so many pimply-faced youngsters do it. For Eric Raymond to characterize the prospective users of his "make config with training wheels" as something that is needed to get kernel updates to females (his examples are Aunt Tillie and Penelope Power User) is just sexist bullshit.
*****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"
The sad thing is that you have to *recompile* the kernel in the first place in order to get the desired result: *reconfiguring* a system for maximal performance. In Windows 2000, I can go to the management console and change the settings for various services from "automatic" to "disabled", and the code that implements them doesn't get loaded into the system on the next boot. Why aren't we talking about making Linux work similarly?
Go ahead, mod me down for giving MS some credit. I didn't earn 48 karma points so that I could be politically correct.
...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..
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.
Careful there. "via a friendly, Windows-esque GUI." I'll assume you mean "Windows" as in a Microsoft Windows. Don't assume that just because Microsoft's Windows is installed on most computers that it means its the easiest to use. Nevermind the arguments about stability, privacy, etc. I think people overlook the fact that Windows is NOT easy to use. Most people have just grown acustomed to it and they think "this is how a comptuer works." If it was truely easy to use, then a new user could sit down and use it. Right now it takes an experienced user to sit down and say "well, it should work like this for no other reason than it always has." I honestly believe (and have seen some signs of this) if you used UNIX all your life, Windows would be a nightmare to learn.
I do agree with you (and I think you mean) that this should be done with a friendly GUI.
-- Erich
Slashdot reader since 1997
Sure, we all want to build our massively customized kernels for server use, etc. etc.
Take 2 boxes, one running 2.2, one running 2.4. Throw KDE on there, and I am willing to bet that the average Aunt Tillie can't tell the difference which one is faster/better.
The kernel as packaged by distros does a good enough job of running the typical desktop system that Aunt Tillie uses to browse the web. Leave the custom build stuff for the experts.
Actually, having done both, I see the levels of complexity involved as roughly equivalent. Note the original poster said "rebuilding a carb", not "building a carb" -- these are not the same process.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Disabling services and recompiling kernels are two very different things. I can turn off my services in Linux too.
Now if you could go into the control panel and unclick the "Run GUI on startup" then your point would be valid.
They'll still get the standard binaries, right?
That means they'll have to go out of their way to tweak with the kernel. It should be easy to throw up a disclaimer. Think of this: even Micorosoft includes tools for editing registries, with the standard boilerplate.
When in doubt, have a man come through a door with a gun in his hand.
I suppose I'd have no trouble believing this. I'd still like to know what the requests are and why they are ridiculous.
Aunt Tillie shouldn't have to
But.. she does. We don't have runtime autoconfiguration that works in every case. If an autoconfigurator is easy to build, and won't impact the people working on runtime configuration, then why stop them from doing it? My computer should read my mind (or at the least, the pointer should move to the thing my eyes are looking at) but I'm not going to tell people to stop working on improving mouse support.
The autoconfigurator is bound to be an imperfect job
True enough, but this is true for runtime autoconfig as well.
The kernel people are already drowning in bogus bug reports
Kernel bugs are reported via email on the mailing list. This is described in marginal detail in /usr/src/linux/REPORTING-BUGS. Furthermore, it begins with the following dubious paragraph:
What this document highlights more than anything is that kernel developers are drowning in bug reports because linux kernel bugs are reported in an informal format on the mailing list. Get a proper bug tracking system and it will be much easier to keep track of real bugs. This should be done regardless of whether or not we make "kernels for the masses". 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.It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
My emotional reaction is Noooooooo! Not because I'm elitist and arrogant, I can always find another thing to be arrogant about, ("You use the newbie tool to rebuild, loser" ) but I don't want to field a hundred questions each from a hundred people. I don't want my mother calling me and asking me if she needs iRDA modules, or constantly answering questions at the bar from people who probably have no need to get into that stuff. It's bad enough now fielding questions about windows... I gotta get this shirt from thinkgeek.
I'm the big fish in the big pond bitch.
It would be great if anyone could build a custom kernel.
Imagine this... Let's say it's 5 years down the road, and the hot new computer is the 72 ghz Apple Pentium G7 with 64 gigs of on-chip ram. Hard drives have been totally eliminated because new, memory based permanent storage technology has been invented and proven over the past 2 years. An entire meg can be recorded in under 1 microsecond. The only remaining mechanical component of a computer is the standard Glass-RW drive (the 2 terabyte recordable successor to DVD), so the whole computer is now a small single board, and most of the electronic hardware is inside the main processor, an inch square in size. In fact, the plugs on this board take more room and cost more than the computation hardware.
Now imagine that a build world takes 4 minutes to complete. Here's how installation of FreeBSD 9.8-RELEASE takes place. (Yeah, I know this was a Linux thread.) You pop the Glassdisk in the drive, choose a few options, and all your software is configured, optimized, checked for security vulnerabilities, compiled and installed within 2 or 3 minutes.
In order for that to happen in 5 years, Granny needs the ability to custom configure her own kernel right now.
Disabling services and recompiling kernels are very different things indeed. The latter is something no end-user should ever have to do. And if the latter is seen as the appropriate way to accomplish a particular result desired by the end user, then you haven't designed the system well enough.
If you can turn of services in Linux too, then what is Aunt Tillie tryint to accomplish that she needs to do my recompiling her kernel?
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.
Under capitalism man exploits man. Under communism it's the other way around.
Aunt Tilley bought her PC and it came with Windows XP preinstalled, has a web browser preassigned and an email program automatically assigned to her preassigned ISP built in already - so guess what..
she doesn't give a crap and wouldn't know what the hell all of you geeks in here are talking about.
A kernel to Aunt Tilley is a piece of corn... Jeez...
Talk about being out of touch....
guns kill people like spoons make Rosie O'Donnell fat.
Pro Coder: "So Aunt Tillie, how would you like to compile your own custom Linux Kernel?"
Aunt Tillie: "What the hell are you talking about?"
Pro Coder: "You know, compile a custom Linux Kernel, so you can have a very customized OS."
Aunt Tillie: "Why would I want to do that?"
The conclusion we draw from this interview is: your average user doesn't have any idea what a Linux Kernel is and that they don't need a custom kernel, at least not yet
...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
I don't think it is smart to have Aunt Tillie care about kernel recompilation, even if almost everything is done by an autoconfigurator.
But what about auto recompiling the kernel while aunt tillie's screensaver is running ? The kernel could collect usage and performance data while it runs and automatically make kernel configuration changes that suits the usage of aunt tillies kernel.
Modules are a nice thing, but there is a small performance lose when you use modules. Why not ship linux distribution kernels with almost everything compiled as a module and then let an autoconfigurator compile an custom new kernel every few weeks until the kernel gives aunt tillie near optimal performance ?
ISA Cards are a problem, but there aren't almost anymore ISA cards in the aunt tillie systems out there anymore and normal distribution kernel have the same problems, they also need to try find all the isa cards in your system and normally it doesn't work that bad.
Jan
"Compiling a kernel is hard and should only be done by the select few."
Thats sounds like what programmers used to say when they wrote things in machine language.
The goal is to make it easy enough for anyone with a brain to do it. Hell they don't even need to know that they're recompiling a kernel.
"Oh you want to do that? Ok give me a sec and then I'll reboot and you'll be all done." *compiling*
Thats the goal. The user doesn't HAVE to know just 'what' they're doing.
Do you really know exactly what that for statement you just wrote compiles to in machine? Do you care? If you want Open GL do you have to know ANYTHING about the kernel?
Sure it HELPS to know these thigns but for the end user it's not a must and should never be a must.
In Soviet Russia, the television watches YOU!
Well, think of it this way. The registry editor (two of them actually) live in Windows, but you don't have the masses actively going into it to tweak settings. Yeah, you hear some horror stories about people going into the device manager and mucking stuff up, but in general, most people turn on their computers, log into AOL, and surf. I don't see any reason why having a nice easy kernel editing program is any more an issue than having regedit or DELETE on a Windows system.
But I doubt it's going to make any difference to Aunt Tillie that she can compile her own kernel in choosing Linux over Windows. Either it runs AOL or it doesn't. Either it runs Master Cook or it doesn't. Either it runs Family Tree Maker or it doesn't. You can say until you're blue in the face that there are compatible programs, but all her friends use Master Cook and she "just can't swap recipies without it". Linux on a desktop? First you gotta get past Aunt Tillie and her recipies.
-- If god wanted me to have a sig, he'd have given me a sense of humor.
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
If you were to implement such a system, along with some sort of QoS monitor (a la Mozilla), you might be able to analyze the data from all the different builds and more easily figure out which kernel modules were interfering with each other and causing the instabilities in 2.4.x (the Kernel of Pain).
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
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?
The problem with the whole idea of computer elitism and the idead that only certain people should be able to try something on a computer is what always gets companies in trouble.
In the early days of computers, only elite people with technical knowledge bought, or indeed could afford a computer. Apple brought it to the average Joe and 'lo and behold computers took off.
Then Apple got elitist with it's GUI, providing only to apple users (I'm not bashing apple here, I am a mac fan). That was a mistake, soon realized when M$ released their GUI to the masses, and took the market by storm.
Now, here's a chance for the concept of creating custom kernels to come to the masses. I say give it to em, let's see what Uncle Fester can come up with.
T Money
World Domination with a plastic spoon since 1984
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?
It can be talked to death but everyone knows the bottom line - I know what to expect with MS Windows or an Apple OS out of the box. I don't know what to expect with Linux and I have no idea whether I'll be able to resolve any problems I have, and if I can't suddenly I have a very expensive paperweight on my desk.
(Please don't flame me about how Linux is just as good or better or tell me all I need is to get this or that. I don't dispute this. I say only: I've been using Apples and Windows PCs for 16 years, I know what to expect, I know will be able to make the computer do what I want it to. I don't know this about Linux. I don't know what a kernel is, really. The last thing I compiled was som crap Pascal code I wrote in college about 9 years ago. And I would guess about 90% of the computer buying public knows less than me)
So the question is framed wrong. The real question is, do sophisticated users, already capable of operating in a Linux environment, want this? To me the basic concept sounds great - streamline my computer's OS to maximize efficiency for my particular needs? Wonderful. But don't sell to me that I'm "building my own kernel..." I don't know what that means so I don't want anything to do with it. Offer me a supported service to "customize my computer..." if I can get it in a box, if it loads and runs out of that box, if there is a number I can call that will help me when I have problems, I'll not only use it... I'll pay for it.
It Is the Nature of Information to Transgress Artificial Boundaries
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!
This is a step in the right direction, but true kernel compilation for the masses is still a ways off. I think for custom kernel compilation to hit the mainstream there needs to be an automated tool that will inspect your machine configuration and hardware and then automatically configure most options (eg... don't compile in X.25 drivers if you don't have an X.25 device). Just my 2 cents.
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
Too much configurability is already a problem for some.
My parents, for instance. I didn't believe it at first when the inevitable tech support came:
"There's something wrong with my word."
"Your Microsoft Word?"
"Yeah, that one."
"What's wrong?"
"There's nothing on the screen and I can't control it."
"Ok, well click on the file open icon... looks like a file folder with a curved arrow on top."
"There isn't any."
"Hm.. ok well click on where it says 'File'."
"It doesn't say that..."
It was true. They'd managed to get rid of every icon and command on the screen, and it was completely blank.
How did they do it? I don't know, but you can do it pretty easily by right clicking and then checking or unchecking things.
So as we add configurability to Linux and its applications, we should hide it and protect it behind selections which say "are you sure you want to..." -- similar warnings can be placed as comments in the top of all the important config files.
I know this will rub many the wrong way, but this sort of protection can be turned off or on as an installation option (just make it on by default).
Linux can work for the mainstream the way cars work for the mainstream: in both cases, the ugly guts (or beautiful guts, depending on your attitude) can be hidden, locked away under the trunk.
After all, God knows how many times my mom asks me, "Should I up my ODDDEFNAME to 256?"
That this question is even being asked shows that Linux is not ready for the desktop. Or, more to the point, Linux zealots aren't ready to even develop a desktop OS.
Potato chips are a by-yourself food.
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;
The point of this whole thing is to make rebuilding a kernel doable by Aunt Tillie.
Software is built to make hard things easy. I couldn't write this slashdot-message in telnet, a browser makes it easy.
I couldn't configure all the software packages that I compiled and installed on my computer, but the various ./configure scripts make it damn easy.
Why should the kernel be any different? Just because you feel superior because you can compile a kernel?
What we need is a simple ./configure; make; make install - routine for the kernel.
And if the autogenerated kernel doesn't work, it's no problem because no distribution in their right mind would not keep a factory kernel around if things go wrong.
Compare that to normal software, where usually things are overwritten. - So in fact the kernel is even less dangerous to mess with.
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?
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 use KDE/Linux (yeah, I say KDE/Linux, not GNU/Linux - in your face RMS) for 3 years almost exclusively and Windows becomes harder and harder for me to use. The most annoying thing is that when I select some text and press the middle mouse button to paste it somewhere, nothing happens.
And of course I also miss my 16 desktops, knotes (small, primitive, but really great) and Konqui in Windows.
..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.
We're proud of our mad programming skillz and our ability to wrestle with arcana.
Which is on the bottom of the Aunt Tilly link. If you want people to stop confusing the two groups ESR you could at least try to make them appear somewhat seperated by, say, not talking like them. Maybe ESR can hook me up with some "leet private sploits" too.
Personally I think autoconfig is a great idea, especially if it can detect my video card (which only happens to be the most popular video card on earth btw, an nVidia GeForce II).
How we know is more important than what we know.
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.
If i remember right, this "flamewar" started when ESR wanted to change the output of each of the drivers to contain their CONFIG_ symbols. This got a lot of people irritated, and then the reasoning he used was "Aunt Tillie."
I think if Aunt Tillie can create a swap partition during installation, pick a window manager, download compile + install the latest mozilla browser update (or maybe she prefers Opera), configure her firewall, and set up lpr for her printer, she can recompile her kernel. I just don't want to be around when she starts looking for "Freecell."
_______
2B1ASK1
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.
Compiling the kernel is easy. Make menuconfig has everything laid out and easy to find with a little exploration. Compile a kernel a couple of times and it becomes second nature. Really, if you've never tried it, read one of the 200,000 pages out there on how to do it and jump right in. Don't forget to run lilo.
The real issue is that the kernel deals with concepts that "good ol' aunt tilly" doesn't comprehend. Does she know what chipset she has for her IDE controllers? What about old CDRom drivers? "That's a 12x... it's pretty old... Bluetooth? What's that? Better put it in just in case... MTRR support? Oh, I'd better put in math emulation so I can use my calculator..."
There's only two ways to solve this; One, put better help in the kernel configuration. This is being done, actually, and I'm all for it, but some things will still be very vague to the non-techie no matter how much help you put in. The other way is to "user-friendlyize" it, which is usually done by taking away options and hiding the real technical details from the user. Do that and a lot of people are going to be pissed off (like me).
A new configuration program I'm not opposed to; just don't take away our options - keep in mind who the majority of people out there who compile their own kernels are (i.e. people who know what they're doing). And for the gods' sake don't give aunt tilly the root password.
Those who can't do, teach. Those who can't teach either, do tech support.
(2) Like most of us, Aunt Tilly has a brain. She is able to spot the difference between a real issue and a quasi-troll dreamt up by ESR. She knows, for example, that no-one wants only "the educated few" to be "able" to compile their own kernels. All the tools to do it are already there. But who should have to unless they want to? And why on earth should anyone forbid them if they so wish?
(3) Like some of us (though not me), Aunt Tilly has an iMac and thus already has a powerful Unix-based OS with a beautifully designed GUI and proper software management. She knows she can tweak it if she likes (see [2] above), but it works so well she doesn't need to think about it, which suits her fine (see [1] above).
Take a giant step backwards with ESR if you like. I hope for the day when Open-Source software is as well-designed and functional as it is well-motivated and worthwhile.
"...Under the hood, the machine is downloading the tip of the stable branch from a kernel.org mirror site..."
First we got stuff going on under the hood, then we got stuff going on behind our backs, and soon we got stuff calling home to the mothership every time we start up a particular app...
Wait!?
Doesn't this sound familiar?
Should...
It's what Window$ has been doing, more and more, for years.
As Mr Horse used to say: "Hmm.. Nope. I don't like it. I don't like it one bit."
t_t_b
I'm on PJ's "enemies" list! Are you?
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
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.
I've been programming for 23 years. I've used Linux off and on for about 5 or 6 years, but not daily.
I used to be able to do kernel builds. My last several attempts have been disasterous. The main thing is that the config just has too many damn options and the language is too technical, even for a programmer. That's insane.
I'd like a simpler utility, but Aunt Tillie doesn't need to be rebuilding her kernel. That's insane. This is the dumbest question I've seen on Slashdot in a long time.
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.
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.
Programming is no more automatable than mathematics. The two fields
are highly akin. Please refer to Gödel's Incompleteness Theorem.
If you mean to say that SOME of the programming that is done today --
the lower level, already explored and understood coding which
is so much reinvention of the wheel -- can be automated
I'm with you all the way. But that just moves the act
of programming towards the higher level, towards building
on that which is already written. It doesn't automate
programmint itself.
-josh
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........
What is it with ESR and coming up with the dumbest fucking arguments about practically everything? Does he enjoy running up hill with ankle weights pulling a Eurovan by a rope between his teeth?
"Hey I know...I'll pitch my kernel autoconf to people by saying it is so easy their aunt can use it, I'm a fucking genius!"
An automagically config for kernel compiling would be a really nice thing to have but not becsause my extended family is going to fucking use it. It also isn't going to do anything to make Linux more popular. Joe Sixpack doesn't know what the hell a kernel is let alone what compiling one would do. Linux users naysay stuff like Wizards because they feel it takes away from their freedom somehow which is an entertaining thought because anything done with a wizard can be done by hand if you want. However having something that knew what it was doing but let you pick some parameters would be a good thing for something complex...like compiling a kernel. ESR's shit about Aunt Tillie doing kernel compilations is entirely moot and too damn stupid to even discuss. The point of discussion is ought an autoconf be included in the stardard kernel package. I think so but if not distros can always add it anyhow as they fucking should. Most distros pack a system configuration utility to pick what software packages you want installed by the same token they ought to have their own (or a standardized) kernel config utility that does most of the picking and choosing for the users.
I'm a loner Dottie, a Rebel.
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 mean should Aunt Millie be allowed to chop and channel her Chevy? Sure if she's up to it. That's what Linux is all about - a computer replacement for making hotrods. Not many Millies did this - but hey a few did I'm sure. More now-a-days than ever before.
Get out those torches and chop away!
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"
This has nothing to do with granny compiling a kernel, it's about making the build process *better*.
That makes more sense now. Thanks for the clarification.
The best way to accelerate a windows box is at 9.8 meters per second square.
Shouldn't that be "squared"?
e don't care what the vendor thinks we should and should not do
I didn't say "no end-user should ever do". I said "no end-user should ever HAVE TO do". There's a difference.
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.
It depends on how you see the question. Should Aunt Tillie ever be required to build her own kernels to get certain features? I think not. However, if Aunt Tillie wants to optimize her kernel for her particular system and configuration, I don't see why it would be a bad thing to make this easy for her.
given that future versions of Linux are going to replace XP, perhaps it's time to think less about bloat, and require memory, like the other guys I completely disagree. Given that Microsoft's software is shoddy and bloated, one of the biggest selling points for Linux could be that "you don't have to spend $$$ for a new computer to use a word processor".
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
I think people should calm down a little. I presume you're going to need to be root to do this, yeah? So if Aunt Tilly had root and wants to recompile her kernel, then seems to me she's gonna screw it up anyhow.
I've recompiled the odd kernel myself despite being a bit of a Linux newb, and it's not that hard to do. OK, I broke stuff with a few of my tries, and one or two wouldn't boot, but it was always easy to switch back to a working kernel. Now, if I had a utility that made it all smooth, with it able to semi-automatically swithc me back to a working kernel, I'd be doing it every day.
Look at it as a leveraging thing. Here's something that Linux can do that Windows, MacOS, etc. will never be able to - recompile the kernel for optimization. It's a feature. MAke it easier to use.
~~~~~ BigLig2? You mean there's another one of me?
This really has nothing to do with aunt Tille, Grandma, or what ever other prototypical uninitated user you might be talking about. Although it is a good idea to keep them in mind when developing things, there is far more potential than just to make it easier for a novice to configure a Linux Kernel.
/boot or wherever else someone might want to put it, add the proper entry in lilo or grub config files, and get everything ready to run the new kernel on reboot. No this shouldn't be the only way to do it, but it would make things simpler.
Every time a new kernel comes out, I have to go through every option, and check what it is, I usually need to activate and follow every sub-menu, just to make sure that there isn't something bizarre down there that I need. Usually I don't, but I've been bitten more than once.
If you recompile your kernel every week or so, you get to know the menuconf menus pretty well (does anyone use the original make configure anymore?), but when something new is added or changed, everything changes, and you have to go through it all over again.
If you recompile occasionally, though, it becomes a very time consuming task to check and recheck that everything you have done is correct. Even then it usually takes me a couple of tries because I overlook something stupid.
This makes a lot of unnecessary work, that isn't difficult, but does take far more time than is really necessary.
Something very like what is being suggested would remedy this. It could detect the hardware, go out get the newest kernel, check for other drivers or patches that might work with the detected hardware (this has the advantage of making it possible to add support for some strange hardware), patches the kernel, then optionally allows the user the opportunity to do some basic or even full configuration tweaks on the config file.
This has the added benefit of making it easy to compile and install a kernel for unknown hardware. Laptops and the like are notorious for strange hardware configs. Without research as well as a lot of trial and error, it is usually not possible to have a fully functional system. You might have a usable one, but some components might not work quite right.
An automatic config generator would resolve this as well. Forget Aunt Tille, this would make my life easier. Sure, give me a way to tweak the configuration later, but something that would generate an intelligent config file for most hardware would make things a lot easier.
How about trying to create some sort of Linux network, say a hetrogenous lab. Something that would allow me to select some configuration options the kernel config that have nothing to do with the hardware, then automatically determine the hardware and compile a custom kernel for each machine. This would save a great deal of time and energy.
For that matter, it should be rather simple to create a utility that would take a newly created kernel image, put int in
If I were updating the kernel on say 30 or more hetrogenous machines, I sure wouldn't want to sit at each machine and configure it independantly. I'd want to be able to specify some config stuff, run a command, let the machines sit, and come back to check them later to pound on any that didn't work with the new kernel.
Some might fail, but a reboot into the old kernel, a little tweaking of the config file, and a retry would still be better than doing each one by hand.
What if I am a sysadmin, and I need to keep someone elses machine running? (Best is to keep a running kernel, but sometimes you need to upgrade.) Unless I know their exact hardware, I'm going to have to spend some time figuring out what they have. Why should I waste that time and effort (that could be used more constructively), if the machine can do most of it for me?
Yes, it would be nice if a novice user were able to get a new kernel automatically, and yes, it would be nice if all novice users were to learn how things work, but neither really cuts it for me as the best motive for going either way.
For me this or something very much like it could make life much much easier.
There is a civil war coming in the United States. Remember which side has most of the guns
Well, I hate both the Windows and classical Unix ways. One important reason why I originally converted to KDE was because I could configure it to click-to-focus (like Windows) but raise-only-on-borderclick (like classical Unix)
Similarly, a lot of people say that Javascript in Konqueror is completely broken, not realising that in KDE2 Javascript is *disabled* by default because it's a potential security risk.
But I agree here, disabling Javascript by default is not good, IMO. They should really enable it by default.
I only posted a brief description of the article. I included a link to the article. If I had posted the entire article that would defeat the purpose of posting a link and providing the due respect the original website deserves
However had you clicked on the link and read the whole story you would also read about "Nephew Melvin" who uses the autoconf tool to quickly and easily modify a setup he had previously created. Or "Geek Girl Penelope" who needs a custom kernel to support a driver but has no time to become a kernel hacker.
The main point is not wether there should be an autoconf tool. There will be...regardless of what anybody thinks. The point is should it be included into the mainstream, available in the standard kernel and in the popular distributions.
http://www.kubuntu.org/
To really do damage to the TV you had to take the back cover and mess with the internals. Of course, if you did not know what you were doing you could get a fatal shock in the process!
A man who wants nothing is invincible
Hi!
;)
/boot/new.kernel
/etc/lilo.conf
/etc/silo.conf, do NOT run silo. If you are running some other arch I dont know...
First, I never said Aunt Tillie would ever compile a kernel the old way
A good thing when configuring a kernel (using xconfig) is to change as few things as possible. Do not add drivers to devices you might buy in 6 months. If you get a new device you can just recompile the kernel then. Most devices can be compiled as modules - that is a good idea for devices that are not needed for getting the system up.
Is you saw, I forgot "make bzImage". That command should be given after "make clean" and before "make modules".
A good start (if you usually fail when compiling your kernel) is to start "make xconfig" and exit and save immediately (that is the same as "make config" give default answer to all questions). Try to compile this standard kernel. It might not run your system, but it will tell you whether the compiler is working well. If this test fails you probably have to upgrade the compiler (be careful with gcc 3 though). I prefer Slackware and Debian, and the compilers in these distros usually work well. Yesterday Redhat 7.2 turned out to have a good compiler too (for the purposes of compiling the kernel).
If this test compilation worked then "make clean" and "make xconfig" again. Now change:
-> CPU-model (do not pick a newer one than the one you have)
-> SMP?
-> SCSI adapter (if you have none, turn off scsi)
-> Network adapter (as module)
-> Sound (you can take a bunch of them, as modules of course)
-> You might want ramdisk and loopback device as well (In block devices section, I think).
-> You might want vfat (but probably not umsdos)
When it comes to ISDN and USB I have no experience - I never use it.
Now exit and save and "make bzImage"
The new kernel is arch/i386/boot/bzImage
now:
#cp bzImage
add to
image=/boot/new.kernel
root=/dev/hda1 (where your root is)
label=new
read-only
now:
#/sbin/lilo (i386 only!)
if lilo gave you no errors the kernel is properly
installed. If you are running sparc just edit
...it is a good thing to not be root when compiling the kernel, untar it in your users home directory and compile it there.
If you still fail:
-> What distribution are you using?
-> i386?
-> What is failing?
Good luck!