:: Re: [DNG] /usr to merge or not to m…
Top Page
Delete this message
Reply to this message
Author: Alessandro Selli
Date:  
To: dng
Subject: Re: [DNG] /usr to merge or not to merge... that is the question??
On 16/11/18 at 12:08, Irrwahn wrote:
> Steve Litt wrote on 16.11.18 11:11:
>> On Fri, 16 Nov 2018 22:11:17 +1300
>> Daniel Reurich <daniel@???> wrote:
> [...]
>>> So... for Devuan, do we want to default to a merged /usr in our coming
>>> release of Beowulf or are we going to resist another pointless
>>> rearranging of the deck chairs...
>>>
>>> Keen to get some feedback on this
>> Back in the what, 1970's, the Unix guys
>> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
>> by separating out statically compiled stuff used in the earliest boot.
>> But then initramfs made these separate directories unnecessary, so why
>> in the world would we continue the split?
> Steve,
>
> with all due respect, in think your reasoning suffers from some kind of
> slight misconception:
>
> The file system hierarchy split between / and /usr happened because the
> disk mounted at / on one particular machine was filling up. Neither was
> it a deliberate design decision, nor was it deemed elegant at the time
> (and still is not). It was nothing but a dirty makeshift botch to quickly
> compensate for some transient hardware constraint almost fifty years ago.



  As Rick Moen already pointed out, this is irrelevant.  Empty bricks
might have been introduced just for the sake of economy (use less
material and save on building costs) they but turned out to be a boon
for other then unexpected reasons: they allow to do away with the
concept of walls that serve as the sustaining elements of the building,
being replaced by much more earthquake-resistant structures that only
rely on thin, light and much more flexible steel and concrete beams to
hold up the whole structure.

  A separate /usr might have been introduced for the silliest an maybe
even wrongest of the reasons, fact is that it turned out to be a very
good filesystem layout concept that introduced flexibility and the
possibility of further separation of binaries into essential and
inessential ones.  Shifting the small complexity of a separate /usr into
another, more complex solution (initramfs) is stupid.  It's like telling
experimental aircraft pilots to do away with they back-packed parachute
because it's old technology that was invented by a guy that was afraid
of riding hot air baloons and telling them that they should instead
adopt a modern, more advanced solution: the jet back-pack.

What's next, merging /var into /usr?  Doing away with /boot?  Going back
having user's home directories in /usr, since that was it's original use?

Shall we please stop the madness?


> It has nothing to do with the practice of using an initramfs (or similar
> construct) for early user space system initialization.



  It's the merge proponents who have been insisting that initramfs are
the technology that makes a separate /usr useless:

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

«Today, a separate /usr partition already must be mounted by the
initramfs during early boot, thus making the justification for a
split-off moot.»


 Which is ludicrous, as it's just their design decision to make the
initramfs indispensable to mount /usr on early boot, as it could in fact
be mounted from / resident scripts and boot procedures without any
initramfs at all.  And the reasons to want a separate /usr filesystem go
well beyond not having an initramfs.


> In fact, if anything, a merged /usr obsoletes the need for an initramfs
> WRT mounting system partitions,



  Again, the reasons to want a separate /usr filesystem go well beyond
not having an initramfs.  In fact the separate /usr filesystem was a
reality well before initrd and initramfs were introduced.


> as it is highly unlikely for /usr to
> reside on a separate volume when it is merged into the root hierarchy,
> where it belongs.



  This is crazy.  Free(lol)desktop people decide out of thin air that /
stuff belongs to /usr, constrain the distributions they control into
this layout, and then say: "See? It is highly unlikely for /usr to
reside on a separate volume! Root stuff belongs to usr!"

  You're putting the cart in front of the horse.  And when people point
this out to you you tell them that's where the cart belongs as it's
unlikely to have a cart behind the horse.


> If you dislike initramfs, you should go for a merged
> /usr tree to err on the safe side when it comes to ensure availability
> of essential system components during system initialization.



  No, what you actually do is: you put essential system components in /
and you let the system initialization procedures take care of mounting
/usr. This can be done without initramfs as it has been done for many
years before initramd was introduced.

That is, the best thing you could do is just leave things as they are,
because they work just great.



--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE