GRUB vs LILO and how STUPID the X86 architecture really is...

David Lautenschlager david.lautenschlager at mcdata.com
Tue Oct 22 07:39:00 PDT 2002


Good software does not crash, lock up, or fail to boot just because of a user error. 90% of the work on any software project is in making it error tolerant. Accidents happen, good software recovers gracefully. People use software improperly, either because of ignorance, laziness or plain old mistakes, but good software recovers gracefully.

LILO works great, and is leaner.

Grub works great, and is more error tolerant.

The question is, for a project that focuses on teaching new people to build a linux system which is more valuable, error tolerance or leanness?

Of course, when building a system for a particular job, the choice may be different. Even LILO is to big for some purposes.

Later,

Dave

> -----Original Message-----
> From: Dagmar d'Surreal [mailto:dagmar at speakeasy.net]
> Sent: Saturday, October 19, 2002 3:05 PM
> To: lfs-dev at linuxfromscratch.org
> Subject: Re: GRUB vs LILO and how STUPID the X86 architecture really
> is...
> 
> 
> On Thu, 17 Oct 2002, Zack Winkles wrote:
> 
> > Multiple times I've installed a new kernel, forgotten to 
> run lilo, then
> > had the old kernel start, or worse yet, had no kernel start booting
> > because part of the new kernel overwrote part of the old kernel, but
> > NOT the whole thing. kernel corruption = bad. I'm aware that this is
> > user error on my part, but the fact remains that grub wouldn't care
> > about such things.
> 
> Shame on you--don't blame user error on the software.  It 
> could be also be
> said that the main reason you're having the problem was that 
> you weren't
> building the kernel "properly" using the `mzke bzlilo` target, which
> _runs lilo for you_.
> 
> 
> -- 
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe lfs-dev' in the subject header of the message
> 
> 
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list