* Tue, 03 Jun 2003, zentara@zentara.net:
On Tue, 3 Jun 2003 22:13:56 +0200 "Theo v. Werkhoven"
wrote: * Sun, 01 Jun 2003, zentara@zentara.net:
I see, so a salesman or doctor "out in the field" with a linux laptop dosn't need to know what to do if there is a boot failure?
Well no, I don't expect an end-user to do these things. Both professions have way more important things to do than screw around with /etc/inittab or bootfloppie while they're doing their business. And luckely for them Linux isn't a system that 'just' fails for no apparent reason. So they won't have to worry about such a thing because that's one of the reasons they use Linux right?
Well linux isn't quite foolproof yet........... How many times have you seen people ask how to boot their system, because the hard drive won't boot because some init script, or module load is hanging? It has happened at least once
After they've been screwing around in /etc ? Plenty of times. Have I seen a boot fail out of the blue ? Not for the last 3-4 years, and then only because of hardware failure (disk errors) or my own stupidity. Do I see a doctor or salesperson hacking in /etc ? Not really. Do I see a doctor or salesperson solve hardware problems somewhere on the road? Not really.
to almost everyone. So you need to know how to adjust bios settings for a floppy or cdrom boot, and start a rescue session.
Nice to know how, but a HP or IBM laptop with Linux installed is as failsafe as it gets, and I can't imagine an appliance user to ever need these tools.
Of course, I've seen windows users in the same situation call their OEM's tech support, and some part-time student doing tech support tells them to reinstall from the OEM cdrom. :-)
Which is al you can do if that's all you get with the PC. Not 'bad' advice, just very unsatisfying.
I don't think it will go over well, if you train people to use linux, then tell them, if you have a problem, leave it with the sysadmin for a few days and he'll fix it.
Desktop systems which are also used as servers probably have a different audience then appliance PCs like laptops. It's not unreasonable to expect more knowledge from these users and for them to solve most of their own problems.
Also, one of the most frequent questions I hear new converts from Windows ask is: "Where is autoexec.bat"?
You're joking right? autoexec.bat isn't in use anymore since NT, if these users want to compare Win9x with Linux than they should first join us in the 21st century before they try to learn a new game.
No, I'm not joking. The last versions of windows I have bought are w95 and wME. They both have autoexec.bat. The people contemplating switching to linux , often come from these older versions. Alot of them jump ship because of the nasty new windows EULA. I'll never buy a newer version of windows.
boot.local is part of the 21st century. Many times I've seen advice, "just put that line in boot.local". I have a few in their myself.
So do I, but the question about autoexec.bat comes from a misunderstanding of Linux and the boot-process in general. boot.local can't be very well compared with au*.bat imho, because boot.local is executed after the kernel is already running while au*.bat is executed before one of these DOS shells and its kernel runs.
I don't agree. One of the most frequently seen questions is "I saw this great new app, but the rpm won't work, how do I compile it?"
And when you tell them to read the INSTALL file they...?
Well that was my point. When someone first encounters a compiler, they need someone to show them a couple of times, just so they over being intimidated by it. Most programmers already know what a Makefile is, what a.out is, and what strip is. But someone new to linux, needs about a half hour of explaning how the whole shebang works, not to make them an expert, but so they are not intimidated to try it on their own; and that it won't break their machine.
Don't say that too loud, making your own glibc and installing it can break a system pretty hard, and there have also been some backdoors in sources of programs, which only hits people that always make their own. Still, following the INSTALL and READMEs usually produces good result, so I'm still puzzled why so many people seem to have problems with tarballs. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 27N , 4 29 45E. SuSE 8.2 x86 Kernel k_Athlon 2.4.20-4GB See headers for PGP/GPG info.