[conspire] upgrade and grub

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Debian wiki tends to be very good to excellent, ... but ... it's a
> wiki.

True enough _but_ the advice of the particular page cited
(https://wiki.debian.org/Seamonkey) strikes me as sound -- despite the odd
name of the SourceForge project ('ubuntuzilla') on which maintainer
'nanotube' maintains a SeaMonkey deb that the wiki page maintainers 
assert is Debian-compatible.

I have _some_ faith that the Debian Project stakeholders would notice
and fix any egregiously bad advice on a Debian Wiki page, especially
about as important a subject as a Web browser.

While I'm on the subject, though, among the questions I didn't address
at the time, partly because Paul Zander didn't ask it, is whether I'd 
install SeaMonkey in 2018 at all.  The answer is 'no, definitely no'.

I wish the volunteers trying to keep alive what used to be the Netscape 
Communicator groupware suite well, _but_ I thought it was a really bad
idea even back when it had a medium-sized corporation behind it, and
now that it's maintained by a somewhat ragged bunch of volunteers 
and has negligible mindshare, it seems an even worse idea.  The design
is infamously monstrous, and the likelihood of poor maintenance seems
high.

There are arguably reasons to be a software dissident by (even) Linux
standards and use/advocate one of the many small-codebase, light, fast
Web browsers with small mindshare, but adopting the SeaMonkey
brontosaur in that spirit strikes me as quixotic.


> $ fgrep -i probe /etc/default/grub
> GRUB_DISABLE_OS_PROBER=true
> $

Oh, _hell_ no.  You're right.   Obvious disaster waiting to happen.

IMO, the role of a bootloader is to do exactly what I told it to do,
not to silently go behind my back and reconfigure itself.

Also, you have just highlighted one of the inherent problems of all
versions of GRUB:  Way too much potential for WTFery on account of 
hidden gears and pulleys doing strange things.  My point specifically
about _this_ example is that one might naively expect all GRUB settings 
to be in its conffile -- and not suspect that something important is
lurking in an obscure /etc/default file.  (Unless perhaps there's an
#include pointer to it?  You tell me.)


[About GRUB in general:]

> Yeah, it's quite big 'n bloated and all that, but it *is* loaded with
> many features and capabilities ... which is both a quite significant
> advantage ... *and* disadvantage.

Quite.  Here's a disturbing pattern:  

Q: You know how a Linux package tends to get adopted as the standard
   distro choice over competitors?  
A: By being a universal solution for all use-cases.

Q: You know how a Linux package becomes monstrous, bloated, and maybe
   even cause non-deterministic behaviour?
A: By being a universal solution for all use-cases.

GRUB has remained the standard distro choice because there's just about
nothing in its overblown set of functionality that it cannot do.  GRUB
has remained IMO objectionable and dreadful because there's just about
nothing in its overblown set of functionality that it cannot do.

I am increasingly of the view that it's in the interest of technical Linux 
users to push back against the distributions' magnetic attraction to 
universal-solution bloatware, by removing it and substituting better, 
smaller, easier to administer Works-for-Me[tm] alternatives.

The syslinux/extlinux suite of bootloaders originated by H. Peter Anvin
solve the use-cases I care about.  Does it solve every possible
use-case?  I don't know or care -- but Linux distributions do.  If I
were to propose the syslinux suite to, say, Devuan or Debian as a
standard-installation bootloader, I'd probably hear back 'But we need a
single bootloader that does everything possible.'

They think they do.  I don't think *I* do.  So, my solution is to be
prepared to override distribution choices of software that do not meet
my needs.  That way, they're happy _and_ I'm happy.

And the feature advantages supposedly distinctive to the bloatware 
default (in this case GRUB) aren't always _that_ distinctive.  E.g.,
Syslinux handles booting from md-type RAID1 with little fuss.  You just
dd the MBR binary to both devices.  Recipe:
http://edoceo.com/howto/mdadm-raid1

A year or so ago, I was talking about such matters on Devuan's DNG 
(main) mailing list, and someone raised the md-type RAID1 objection.
With a small amount of research, I was able to show that even _LILO_ 
had recipes to permit it to transparently handle booting from either
drive of a RAID1 mirror pair.  (I'm not sure that still works, and there
was some dispute on that point.  LILO obviously is ancient now, and 
cannot do GPT/EFI and never will.  A rewrite for GPT/EFI called 'ELILO" 
existed for a while but is orphaned:
https://sourceforge.net/projects/elilo/ )

But, even after I disproved the assertion (on DNG) that 'LILO can't
handle booting from md-type RAID1', there's no way in a million years
that Devuan would _even_ so much as offer LILO or any other non-GRUB
bootloader in its installer image -- because that's the way distros
think.  And there's always _some_ objection in the form of
'$NON_GRUB_BOOTLOADER can't do $THING'.  So, bloat.


My larger point is that:  Knowing the way distros make decisions, 
you should anticipate that they will veer towards the Big Dumb Choice
depressingly frequently, and that drifting along, accepting that because
(your wording) 'it does mostly just work, and quite dang well, and sure,
it has (way too?) many features/capabilities ... but at least
*sometimes* those things come in dang handy' and 'default on Debian,
so, typically the easier path/approach' and 'for Debian, it mostly "just
works", and pretty dang well so' will distract you from the opportunity
to make different decisions that are better for _you_.

Drifting and taking what's prepackaged doesn't lead you to GRUB and
Debian, Michael.  It leads you to Windows 10.  ;->

I'm not pushing LILO.  That's a dead issue.  However, I'll praise its 
pleasing simplicity over GRUB's absurd sprawl, any day, and the classic
argument that 'I once moved/replaced my boot files and forgot to update
LILO's map, resulting in inability of my system to boot, and I wasn't 
smart enough to have a fallback stanza in lilo.conf' doesn't move
me.  My answer was:  http://linuxmafia.com/kb/Kernel/zen-of-lilo.html


> GRUB is even pretty dang good about assisting with that (many
> capabilities to probe stuff, list relevant information
> about what it finds, etc.).

You call that good.  I call that _bad_.  IMO, a bootloader should _boot_.
It should do exactly what the conffile directs it to do, as installed.
Exactly that, no more than that.

Back in the days of LILO, even if you were negligent and moved around
your boot files without re-running the map installer (/sbin/lilo), _and_
were too stupid to have a fallback stanza in lilo.conf to rescue you
when you made this error, it was nonetheless easy to fix with any Linux
boot CD and a tiny amount of Web searching.  

Why?  Because LILO was dirt-simple.  Which, in context, was a major virtue.

It didn't have built-in self-repair, helpful hardware probing, and
extensive built-in documentation.  It didn't have hardly any built-in
anything.  It booted.  It followed very simply what you wrote into
lilo.conf and then applied using the /sbin/lilo map-installer.  If you
were very negligent and broke it, you had to use Web-browsing and a live
distro to fix it -- but that was easy, because it was a simple tool that
did one thing deterministically and reliably.

Which is everything GRUB isn't.


> Let's say, for sake of argument, one has an older Debian installation
> ...maybe something that's been sitting unused in a closet for years, ...
> and then one wants to use it again and get it current ... via
> upgrades.  Is that doable?  What if it's from a point in time /
> version that's no longer supported?

Of possible interest:
http://linuxmafia.com/faq/Debian/gradual-upgrade.html

Documents how to go without problems all the way from Debian 1.3/bo to
then-current (as of 2002) Debian 3.0/woody -- the point of which is not
to provide a copy-and-paste guaranteed recipe for upgrading any/all
obsolete Debian systems but rather to show a _general_ approach:

1.  Move forward one release at a time.
2.  Upgrade crucial packages first, before the rest.

Page also highlighted things that could languish at antique versions if
you weren't attentive.  At the time, this included one's Linux kernel
package (because, at the time, it wasn't yet standard to have a
metapackage installed that always resolved to the latest binary kernel
or the latest of the desired series of kernels).


[Debian 'menu' facility:]

> In more/most current Debian stable, that's changed somewhat ... I
> don't recall the details, but I do recall it being mentioned in ...
> the Release Notes?  Well, I thought I'd read it there - not finding it
> there now ... it may be somewhere else that I read that.

Well, https://www.debian.org/doc/packaging-manuals/menu.html/ still
claims it's current.

p.d.o. page for 'buster':
https://packages.debian.org/buster/menu
Developer page doesn't say anything about it being yesterday's news
(though that may not signify):  https://tracker.debian.org/pkg/menu

If you find out more about that, or confirm/disconfirm what you think
you read, please post again.

Anyway, the point is that there's a base-level expectation that any
graphical application installed onto Debian from Debian package repos
_or_ compatible third-party repos will register itself with the Debian
menu-management facility, automagically creating pop-up menu listings
for the app  on all Debian-installed window managers and DEs.  

Even if that menu-management facility becomes something other than the
'menu' program, my point is that I would still expect Debian to continue
to do that using something else.  Therefore, there's really no point in
something like that Java-based lxmed program that Paul Zander went out
of his way to retrofit.