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

Ian Molton spyro at
Mon Oct 14 01:21:41 PDT 2002

On Mon, 14 Oct 2002 08:00:25 +0000 (UTC)
matthias at (Matthias Benkmann) wrote:

> On Mon, 14 Oct 2002 02:02:47 +0100 Ian Molton <spyro at> wrote:
> > 
> > Hasnt anyone in favour of grub realised that making ever-more smart
> > bootloaders is the WRONG thing to do?
> > 
> > The ARM community got it right ages ago 
> Does the ARM community have a dozen different OSes from a dozen
> different vendors to choose from?

More than a couple, yes.

> Do you have a dozen different filesystems on ARM you can have on the
> disk at the same time?

Why wouldnt you? CPU type doesnt dictate disc structure...

> >- the booloader is the thinnest
> > shim possible, and sits in ROM, handling
> The same is true on the PC. LILO is NOT the boot loader. Neither is
> GRUB. They call themselves boot loaders but they aren't! The real boot
> loader is BIOS+executable code in the partition table.

I know.

> If you want to boot 10 different OSes on an ARM
> from as many different filesystems, with nice graphical splash screen,
> does your BIOS boot loader help you?

Why on earth do people want pretty spashscreens on their bootloader?!

besides - whats to stop you having the bootloader start the default OS,
and for the OS to chain another kernel after its running? That way, the
bootloader doesnt have to be constantly updated every time something
like USB brings out a new keyboard standard...

> People on PCs want to do this, but obviously this is beyond what a
> boot loader should do (a boot loader should be KISS as you say) so
> they need a program (mistakenly called boot loader) to do it for them.

why? a kernel+init can do it for them, and do it just as fast (linux
boots so fast from ROM that monitors fail to warm up before its booted),
and you get all the drivers you need to get running already on the
Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list