Re: my thoughts about grub 2

[Lennart Sorensen]

On Wed, Aug 18, 2010 at 04:42:20PM +0930, Brendan Trotter wrote:
> Hi,
> 
> On Wed, Aug 18, 2010 at 12:35 PM, BVK Chaitanya <address@hidden> wrote:
> > If you could list out specific instances of what you felt is
> > difficult, then it would be a lot helpful.  A general comment like,
> > "its not good or difficult" does not give any chance for improvements.
> 
> If the English language was radically changed, almost everyone that
> became accustomed to the current/old version of English would become
> confused and frustrated when they're confronted with the new English.
> This is relatively easy to understand - radical change means
> confusion, relearning/retraining and lost productivity.
> 
> The syntax used for GRUB's configuration (and the structure and
> location of GRUB's configuration files) isn't really any different -
> it's like a special language people use to tell GRUB what they want.
> Not only was it radically changed, it became a lot more complex too.
> 
> Here's some selected excerpts from the "Configuration" section of the
> (draft?) GRUB2 documentation (from
> http://grub.enbug.org/Manual#head-8bd9ce00a71835c5e4a44b1ae459a8de023e55cd
> ):
> 
> - "Before you edit some file/entry in /boot/grub that mysteriously disappears"
> - "Configuration for GRUB 2 is much different than the original GRUB."
> - "A multistep configuration creation process (i.e. a configuration
> for creating the configuration) might seem convoluted."
> - "Certain items embed configuration information in a non-obvious way"
> - "Users must depend on the configurations fed to the utilities that
> generate these images to infer what they will try to do on reboot."
> 
> Of course this is an intentionally biased and misleading selection of
> excerpts intended to illustrate a point of view; but can you imagine
> what normal users are thinking when they try to understand GRUB2
> configuration for the first time?
> 
> To make thing even worse, (if Ubuntu is a reasonable indication)
> different OS distributions will add their own non-standard extras to
> GRUB2 configuration (and probably add their own non-standard patches
> to GRUB2's code too). This will mean that if someone learn to
> configure GRUB2 on one OS distribution (with one set of extra
> features) then they'll be confused if/when they shift to a different
> OS distribution (with a different set of extra features); and if
> anyone is silly enough to attempt to install 2 different OS
> distributions on the same computer (e.g. dual boot) they'll need to be
> extremely careful that the distributions don't fight over the GRUB
> configuration (and screw each other up).

That was certainly the case with grub1 as well.  Debian had a patch to
add 'save default' to grub1, which upstream did not have.  This
certainly puzzled some people who wondered why it didn't work on other
distributions.

> In my honest opinion, the design of GRUB2 should have began with the
> question "What do normal users expect?". As far as I can tell, most
> users expect a boot manager to be self contained (e.g. doesn't depend
> on any OS for installation or configuration) and includes built-in
> configuration tools that are easy to use (e.g. menu driven).

No, that's not a good design method.  Starting with 'what should it be
able to do' is much better (and appears to be what happened).

grub2 is multi architecture, modular, extendible, and much more robust
than grub1.  The fact it no longer depends on any block maps to work is
a great thing.  The fact it uses modules to build the required features
in and loads any others needed on demand means it can support a lot more
filesystems than grub1 since grub1 would have gotten too big adding all
those features.

Sure grub1's config was simple and the syntax had a lot less in it, but it
was also limiting the ability to add new features.  Now for debian users,
they already had an update-grub command that generated the grub config
file for them, so going to grub2 really doesn't change anything from the
users point of view, unless they happen to want to custize something.
Now those customizations happen in /etc not /boot/grub/menu.lst.  That's
actually a good thing, since all config SHOULD be in /etc, not /boot.
So grub1 was actually the one that was doing the wrong thing before.

Remember it took years for lilo users to finally accept that grub1 was a
much better choice (lilo being entirely blockmap based, even for kernel
images, which made it very fragile and inflexible).  It will take time
for people to get used to grub2 (it certainly has for me), but the fact
it is more robust and flexible, and works on things other than x86 PCs
(I am very happy using it instead of yaboot on an IBM powerpc server now)
means grub2 will soon be the de facto linux boot loader.  It might even
hit version 2.x (unlike grub1 which never got there).  Now the complete
conversion of everything in the code has certainly meant some things
broke over time and got fixed again, but in general it has worked great.
Isn't native mdraid, lvm, dmraid, piles of filesystems and multi
architecture support worth it?  How about multiple partition table types
(disks or raids over 2GB don't work with msdos partition tables after all,
and grub2 supports EFI style GPT partition tables.)

> To confirm my suspicions I spent an hour or 2 doing a survey. I
> started with a Google search for "boot manager", and selected each
> entry in the search results for the first page and a half (before
> deciding I'd spent enough time) and tried to find out about the
> installation and configuration of each different boot manager.
> 
> For the following list of boot managers they all have 2 things in
> common - they don't require any OS for installation, and all
> configuration is done inside the boot manager itself (typically with a
> simple menu driven interface):

So how does installing a new kernel update the boot loader then if it
is only configured by itself?

> - SyMon (http://symon.da.ru/)
> - GAG (http://gag.sourceforge.net/index.html),
> - Plop (http://www.plop.at/en/home.html)
> - Master Booter (http://www.masterbooter.com)
> - Smart Boot Manager (http://btmgr.sourceforge.net/about.htm)
> - System Selector/BootManager
> (http://www.bootmanager.com/uebersicht.html.en.html)
> - BootIt (http://www.terabyteunlimited.com/bootit-next-generation.htm)
> - Multiple Boot Manager (http://elm-chan.org/fsw/mbm/mbm_e.html)
> - MATTsoft Boot Manager (http://martin.hinner.info/mbtmgr/)

Most boot loaders are simple partition selectors, which is really all
windows/dos users ever wanted.  Linux users expect more.

> I only found 3 exceptions. The first is Acronis OS Selector
> (http://www.acronis.com/homecomputing/products/diskdirector/os-selector.html)
> which is part of a much larger toolkit (backup/recovery, partition
> management, etc). It requires a version of Windows for Installation
> and configuration. OSL2000 (http://www.osloader.com/) and boot-us
> (http://www.boot-us.com/) also require an OS (windows) for
> installation and configuration.
> 
> The other thing I noticed is that when you it comes to
> "user-friendliness" all of the boot managers (even the ones that
> require an OS for installation/configuration) make GRUB2 look like an
> extremely overcomplicated mess.

Well people seem to claim the same about linux versus windows.  Apparently
windows is much easier to configure and install (I personally don't
think so, but then again I have used both a lot).

-- 
Len Sorensen