Slashdot Mirror
Helping Linux Newbies Move to the Next Level
NoWhere Man writes "PCWorld has a "here's how" article on how to get the most out of your Linux box. It's basically a very extensive and userfriendly step-by-step instruction on how to recompile your kernel to make it smaller and more compact." Kernel recompilation and optimization is old hat for experienced Linux people, but articles like this, especially in "non-Linux" publications, are necessary to help new Linux users become more adept. Kudos to PCWorld for running it!
Recently a fairly young Windows user that I know wanted to install Linux on his 486 that he had laying around. I am quite happy to help new users if they need anything, but this kid could not understand that if you just read the documentation that comes with the distrobution, 9 times out of 10 you will be able to find what you need to accomplish your specific goal. I was bombarded with questions about how to configure this or that and even before that questions about the install procedure (even after telling him several times what it is like and to just go ahead with it). My point is some people, no matter how clearly spelled out something might be, cannot handle not having the computer do the work for you. I see it sort of like cars, the OS is the engine and the car is the PC. If the engine is already installed and the user learns to drive the car, everything is fine. Having a novice install a new engine however is a different case. Same thing with Linux or windows: a user who learns to use a computer which already has linux installed would do fine eventually. Perhaps what should happen is there should be a distiction between a box with power in it, where knowledge is required to run it and basically an idiot box which does not require knowledge and things like OS or command lines etc are not a concern.
If this makes any sense, I am glad... its 4 AM and I can't sleep so take that in mind.
_joshua_
Well, the article describes the process fairly well, that is a way to recompile the linux kernel. But it isn't enough to go through the steps with no understanding of what you're doing.
Maybe if you know what your hardware is, you can take out a few options, and end up with less total modules compiled and installed, and you'll end up with a leaner system. As in, Ooo, I just saved 10MB of valuable disk space. Big deal. You could have done that using 'rm' on some useless modules.
Maybe if you knew what you were doing, you could compile in something you always plan to be using as part of the kernel instead of as a module, and get some speed out of it instead. And maybe if you really knew something about egcs, you could change those silly default compiler options to something useful (-fno-strength-reduce often isn't necessary anymore, I hope!) and get some more performance gains. But this article wasn't about that.
Nope, to get any real speed-up in the kernel, you'd have to already know something, and this article assumes you don't. Why make newbies go through this process when it won't help them any? Either document the whole thing for those who *really* want to learn, or don't bother. But don't confuse the people you're trying to convert. They don't know -ffast-math from xcalc.
---
pb Reply rather than vaguely moderate me.
pb Reply or e-mail; don't vaguely moderate.
On a related note, has anybody seen that new magazine Maximum Linux? In my opinion it was nothing as good as it's parent Maximum PC. Some articles were Okay, but the interview was godawful dull, and a lot of the writing was pure palaver. One would expect more from them.
When I'm singing a ballad and a pair of underwear lands on my head, I hate that. It really kills the mood.
-Tom Jones
This might the appropriate topic to create a thread of comments/suggestions/ideas regarding a Linux help site that I want to start up. If this is the wrong place to do so, then I apologise.
:P) which would recommend certain HOWTO's/FAQ's based on their problem, before allowing them to submit a help request.
The design of this site would be centered around "users helping users". Those who feel adept in helping newbies could sign up as "helpers", where their particular skills and areas of expertise would be kept track of. Newbies in need of help could then fill in a form requesting for help, from which the system would match their particular problem with a suitable "helper" - who would be emailed their information.
Of course, to remove common questions, users would be taken through maybe some kind of Wizard (ick I hate that word
In effect, what would be created would be a large scale "help desk" system - however free for people to use.
The incentive for people to become "helpers" would be simple - the best helpers each month (derived from positive feedback from users) would revieve free hardware/software from sponsors of the site. I'm thinking people like VA, PenguinComputing, and Redhat could be suitable "sponsors".
Help requests and solutions would be recorded and put in some kind of Linux help knowledge base, which would be free to search.
I have confidence that (once above the ground) such a help system would really benefit the Linux community.
A) People could get personal help with their problems
B) Those who help would be rewarded from sponsors
C) Sponsors get exposure
D) People might feel easier about learning Linux is they knew a free help system existed.
Well, I hope that gives you guys enough of an idea as to what I would like to see. I am eager for constructive critisism/ideas/comments/questions for this idea.
cheers,
semis.
I come across this problem a *lot* with Macintosh users. Most seem to assume that you can use the system forever without ever removing extensions, or running a disk utility, or rebuilding the desktop file.
:)
But the plain truth is that OSes require maintainence. Some more than others, of course. (As I recall, there still are no disk utilities for BeOS, simply because the problem hasn't come up yet.) Anyway, nothing is worse than a computer-lab Mac with 400 extensions in it and a disk fragmented to hell, and the user asks, "Why does it crash?" It would be like a motorist asking, "Why won't it go?" after failing to change the oil for 8000 miles.
Anyway. Eventually we'll get to the stage where no OSes ever require maintainence, or we'll get to the point where computer users are smart enough to realize that they do, and stop expecting miracles.
Now moderate me down for being off-topic, and off-OS.
- James Schend
Comment of the year
I remember being quite lost when I started using Linux. Recompiling the kernel for the first time scared the hell outta me. (It would've been better had I known about 'make menuconfig' or even 'make xconfig', which this article covers.) I definitely agree this sort of article is needed, even though the requisite information is doubtless available from already existing sources (like the linux/Documentation directory).
There are a few points which could've definitely used improvement. For one thing, the article's quite biased toward Red Hat. Understandable, as it's a choice for many who are new to Linux, but still there could be mention of other ways of doing things--to satisfy curious gurus-to-be, at the very least.
Along the lines of edification, perhaps some more detail could have been given for the hows and wherefores of using certain commands. Since this article seemed to use RH as a basis, perhaps some explanation on what exactly that ugly rpm command was doing would be in order. To their credit, though, they did have links to related articles.
Finally, I think some newbies could benefit from information on gathering more information for themselves about the Linux kernel--further reading, to be specific. Every kernel hacker starts somewhere, and a mention of the linux/Documentation directory (at the very least) would be helpful to those wishing to learn the art.
Thanks to PCWorld for this article--though it might not explain everything, at the very least it can help with the intimidating process of customizing one's kernel.
-W-
Is it all journey, or is there landfall?
--Ellison & van Vogt, 'The Human Operators'
Interesting article (I find it useful actually because I'm just showing a Linux newbie around and I really don't feel like explaining every single thing to him. Often one doesn't know where to start though :).
I found it a little sad that it was rather Red Hat-biased at some points (like talking about installing the new kernel using RPM). I wonder though, how easy it for authors of articles such as this one to make their articles fully independent from any distribution specifics. It's rather sad to see how many articles talk about "Linux" in the header but when you look at the article itself are really about "Distribution XYZ". :/. Ah well, I guess that's the cost one pays for having all these distros flying around.
Okay, this may very well be a nice set of
instructions for recompiling your kernel,
but the stated reasons for doing so strike
me as completely insane. The idea that you're
going to get some kind of noticeable performance
boost by tuning up your kernel is pretty
ridiculous. You've really got to have some
pretty specific needs to want to do this.
Me, I recompile my kernels to include support
for an old SCSI card, and I'm actually
beginning think that even this is nutty:
I should just replace the damn card with
something supported by default.
This article is just like the typical "How to optimise Windows" articles.
It assumes that all you can do to an OS is optimise bits of it and that the "power" of Linux is simply it's speed. The benefits of doing what this article suggests are negligible. The only real reason for users to do this is to fix bugs.
At *best* this article is dangerous; It tells users to change the default linux entry in lilo.conf rather than add an additional entry.
They'd be much better focusing on how to use things like cron and shell scripting.
Deleted
As a Linux newbie, I first saw this article on linux.com on Saturday. It has proved VERY helpful. I had tried to recompile/compile kernels before, but I had always gotten errors, or something went wrong. But, I had finally recompiled my kernel on Saturday night (he, 16 and compiling a kernel on a Saturday night, scary :-) and with that success, I tried to compile the latest kernel. Unfortunatly, I still haven't gotten that to work because at bootup, it says VFS is unable to mount the root fs. I'm not sure what's wrong, but it's fun to try to figure it out. Anyway, I really liked this article, and found it extremely helpful.
The best way to get newbies to the next level is to keep them using it after college. All the evidence points to very transient usage. They pick it up in college and give it up when they start working so we have a user base which is primarily interested in starting the basic operating system and trying out different distributions but rarely getting to the point of actually doing anything with it.
At the suggestion of this article, I took a look at my config, and I found that almost everything that's optional was dynamically linked anyway.
I have a PII processor. Do I want to change my processor type? I don't know. What does it buy me to change from 386 to PPro? Is it worth the trouble? I assume that 99% of people are running the default 386. Might there be some subtle kink in the PPro kernel that isn't as well tested? Hmmm.
There's all these little features that I can turn off. How much memory am I saving with each one? It would be nice to know. Is it worth it to turn off a dozen features to save 64k on my 64Mb box? Nope. What kind of gains can a typical user expect from a reconfig?
Last lick. Of course, It's useful to have a kitchen sink kernel so that people can boot it on random hardware, but once you've booted, Linux knows what's there, and writes a /var/log/dmesg file with all that useful and mysterious info about your very own system. How about a prog that takes this custom data and builds a lean Linux kernel config from it?
So don't recompile and live with what you've got -- I'm sure there are still boxes running 1.2.13 and earlier, and they're still going.
You don't *have* to touch a compiler, in the same way that you shouldn't have to mangle the Win9X registries just to get anything done. You might have to in the latter case, but...
Only the dead have seen the end of war.
He didn't say "difficult => real"; he said "!difficult => !real", which implies "real => difficult" but not the other way around.
The reason is that you absolutely need a way to both get more details and change them. Why?
I've seen a freshly unpacked PC with remarkably vanilla hardware die during a similarly vanilla NT4 install, deterministically, before any user decisions, while a machine with an almost identical configuration (perhaps a different IDE drive and keyboard) sailed through.
Hitting random keys during a check for a non-existent SCSI card let it survive -- but there was no way of determining what *actually* was going on, nor no meaningful, reasonable solution. That's illogical.
I've also seen point-and-click systems decide, repeatedly on boot, that it knows what network card you have instead of the actual one, undoing the user's (correct) settings, and switching drivers followed by requiring a reboot. The interface *really* needed a way to bypass it. On a Linux box, OTOH, if your driver is, say, detecting the wrong card, you can simply force the choice...
Computers are inherently complicated -- especially when hardware comes from a variety of vendors. Ergo, either the interface allows complexity, or you lose necessary flexibility.
Only the dead have seen the end of war.