The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Grant Taylor <gtaylor@tnetconsulting.net>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] /usr separation
Date: Wed, 24 Feb 2021 09:14:11 -0500	[thread overview]
Message-ID: <YDZfM7L5xzx8WELZ@mit.edu> (raw)
In-Reply-To: <3d2d7b46-41e8-92d7-3a7b-d0f3006bc761@spamtrap.tnetconsulting.net>

On Tue, Feb 23, 2021 at 01:29:11PM -0700, Grant Taylor via TUHS wrote:
> On 2/23/21 11:57 AM, Theodore Ts'o wrote:
> > There are two reasons why you might want to have an initramfs.
>
> Rather than getting into a tit for tat debate, I'll agree that we have both
> proposed reasons why you /might/ want to use an initramfs.  The operative
> words are "you" and "might".  Each person probably wants slightly different
> things.  It's far from one size fits all.

Sure, I was trying to enumerate the reasons why initramfs, for some
combinations of hardware / configurations, might be necessary.

> > /boot needs to exist due to limitations to the firmware and/or boot
> > loader being used.
> 
> Not necessarily.  E.g. one single partition containing /boot and / (root).

Sorry, I should have written, "/boot MAY need to exist".

> > Other than that, there is no reason why /boot needs to be its own file
> > system, except that most installers will create one just because it's
> > simpler to use the same approach for all cases, even if it's not needed
> > for a particular use case.
> 
> As Steve Gibson is famous for saying; The tyranny of the default.

I wouldn't say that; I'd rather say that if you have a huge
combination of configurations that you have to test, those
configurations which aren't regularly tested will tend to bitrot, or
have odd failures in various error cases.  The more corners that you
have, the more corner cases.

And this is where it's all about *who* gets to pay, either via money,
or via their labor, to support these various cases.  Weren't people
just complaining, in other TUHS threads, of "bloat" in Linux?

Well, this is how you get bloat.  It's just that if it's a feature
*you* want, then it's not bloat, but an essential feature, and if it's
not provided, you whine mightily.  And when you have a large number of
enterprise customers paying $$$ to enterprise distribution vendors,
each with their own set of essential features, and where *binary*
backwards compatibility is considered an essential feature, then
that's how you get what others will called "bloat".  I would call this
the "Tyrany of Gold", as in the reformulated Golden Rule, "The ones
with the Gold, makes the Rules".

> > P.S.  Oh, and if you are using UEFI, you might need to have yet another
> > file system which is a Microsoft FAT file system, typically mounted as
> > /boot/efi, to keep the UEFI firmware happy....
> 
> Yes, the file system needs to exist.  But that's part of the firmware, not
> the operating system.  I also question if that FAT file system needs to be
> mounted or not.  --  I don't know how GRUB et al. deal with a non-mounted
> UEFI file system.

GRUB doesn't care.  But various system administration utilities that
want to manage to UEFI boot menu (as distinct from the GRUB boot
menu), they need to modify the files that are read by the UEFI
firmware.  So it's convenient if it's mounted *somewhere*.  Also, even
if it's not mounted, it's still a partition that has to be around, and
one reason to keep it mounted is to avoid a system administrator from
saying, "hmmm, what's this unused /dev/sda1 partition?  I guess I can
use it as an extra swap partition!"  And then the system won't boot,
and then they call the enterprise distro's help desk, and unnecessary
calls into the help desk costs $$$, and distro's tend to optimize for
unnecessary cost.  (Plus lots of unhappy customers who are down, even
if it is there own d*mned fault, is not good for business.)

> But even if it does need to be mounted, you can still get away with two
> partitions; / (root) and /boot/efi.  I suspect UEFI does away with the LBA
> issue you mentioned.

Yes, in another 5 or 10 years, we can probably completely deprecate
the MBR-based boot sequence.  At which point there will be another
series of whiners on TUHS ala the complaint that distributions are
dropping support for i386....

But since most TUHS posters aren't paying $$$ to enterprise
distributions, most enterpise distro engineers are going to give
precisely zero f*cks.  But hey, if you want to volunteer to provide
the hard work for supporting these configurations to the community
distribution, like Debian, those distros will be happy to accept the
volunteer help.  :-)

						- Ted

  reply	other threads:[~2021-02-24 14:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20 23:09 [TUHS] Abstractions M Douglas McIlroy
2021-02-21  8:15 ` Otto Moerbeek
2021-02-21 11:08 ` Rich Morin
2021-02-21 22:40 ` Dave Horsfall
2021-02-21 23:01   ` Steve Nickolas
2021-02-23  3:31     ` Andrew Warkentin
2021-02-23 17:29       ` [TUHS] /usr separation (was: Abstractions) Greg A. Woods
2021-02-23 18:28         ` [TUHS] /usr separation Grant Taylor via TUHS
2021-02-23 18:57           ` Theodore Ts'o
2021-02-23 20:29             ` Grant Taylor via TUHS
2021-02-24 14:14               ` Theodore Ts'o [this message]
2021-02-24 17:50                 ` Grant Taylor via TUHS
2021-02-24 18:37                   ` Theodore Ts'o
2021-02-24 18:48                     ` Grant Taylor via TUHS
2021-02-25  3:38                       ` Theodore Ts'o
2021-02-24 20:25                     ` Steve Nickolas
2021-02-24 22:08                       ` Steffen Nurpmeso
2021-02-24  3:12         ` [TUHS] /usr separation (was: Abstractions) Andrew Warkentin
2021-02-22  0:13   ` [TUHS] Abstractions Warren Toomey
2021-02-27  2:47     ` Dave Horsfall
2021-02-23  0:25   ` Wesley Parish
2021-02-23  0:38     ` Steve Nickolas
2021-02-23  2:50       ` Theodore Ts'o
2021-02-23  3:19         ` Warner Losh
2021-02-23  1:47     ` Theodore Ts'o
2021-02-21 22:54 ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YDZfM7L5xzx8WELZ@mit.edu \
    --to=tytso@mit.edu \
    --cc=gtaylor@tnetconsulting.net \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).