:: 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 11:43, KatolaZ wrote:
> On Fri, Nov 16, 2018 at 10:19:30AM +0000, Rowland Penny wrote:
>
> [cut]
>
>> So, after reading Steve's enlightening description, I am with him, the
>> merge is only needed by systemd and seems to be a way of forcing it on
>> everybody, so I am against it.
>>
> It would be actually more productive to base this discussion on solid
> technical arguments.



  I am one of those who can't do without initramfs because I mostly run
GNU/Linux on laptops and for obvious security reasons they all run on
fully encrypted filesystems, / included.

  However I do loath the / and /usr merge.  I find it irritating that I
am asked to provide with sound technical reasons to keep the two
filesystems separated as I needed to justify 4 decades of sound
sysadminiship practice when it's the proponents of the merge who in fact
have been doing a poor job to justify the purported need of the merge. 
Their reasons all boil down to: "it's the way we want to do stuff". 
Fine, I too like and enjoy doing things my way on my systems, and when
there are good reasons to keep things the way they've worked for decades
and there are no compelling reasons to introduce such deep changes I
just say no.

The "good reasons to keep things the way they" are have been enumerated
several times, but I'm happy to list them again:


1) complexity and bloat are the key enemies of resiliency;

2) the smaller the most critical OS components are, the more solid the
whole system is;

3) the smaller / is the easier it is to repair, to secure and audit, to
provide with alternative boot paths/rescue procedures;

4) merging / with /usr takes away significant degrees of freedom in
customization and hacking into one's own system and GNU/Linux owes much
of it's fortune in being a hacker-friendly system that is easy to
customize, even to the extremes.


An example of the last point is the possibility of having two similar
yet different systems boot out of the same / but with separate /usr,
like having a minuscule partition with only the basic stuff in / that's
able to either mount a local partition on /usr or maybe one that is
mounted over an NFS server.

I expect Free(lol)desktop to object something like: "Why on earth would
one want to do that?".

Even before I listed the possible good reasons to do such a thing, I'd
answer: "Why on earth would you take me the freedom to do that away?
What compelling reasons do you have to diminish the flexibility and
customizability of *my* OS?"

Then, the main good reason to do that is: I want to have a laptop that
did not have on it's disk utilities that could land me in trouble with
the local authorities because in some country where I could travel they
are not allowed (P2P software, cryptographic tools, VPN and Tor/I2P
software, penetration testing, packet sniffing and IP spoofing utilities
etc), while at home I have them available on a local NFS server or on an
external disk.

Having to give up on a separate /usr does expose some technically savvy
people to much more serious consequences than having to remember if
mkfs.ntfs is in /sbin or /usr/sbin (Free(lol)desktop people calling this
an issue is ludicrous).

In short: the / -> /usr merge lacks sound good reasons to be adopted as
the only possible filesystem layout scheme in all of GNU/Linux's
installs (Free(lol)desktop people's personal tastes are not), while it
takes away freedom to hack and customize one's own system for uses that
are important to some specific cases or even have not been thought of
yet.  That these uses are fringe cases or not yet here does not matter,
it's the merge proponent's duty to justify the purported need to to take
away the possibility to do these customizations in the least painfully
possible way.  Taking away the flexibility of the OS for no reason
reduces it's Darwinistic Resiliency Index (DRI): the most easily
adaptable systems are those most likely to adapt to the most diverse set
of external circumstances.

Of course, bloated systems that are monolithic, dependent on a single
critical, unreplaceable component, that take away the possibility of
doing thing differently tend to score lowest in the DRI scoreboard.

I was already pissed in the past when they decided that there was no
reason to have X11 applications live in their own filesystem, /usr/X11,
so that I found myself dealing with a disgustingly overcrowded /usr/bin
that made looking for TUI commands and utilities so obnoxiously
time-consuming.  I am determined to fight this crazy / -> /usr merge
tooth and nail.



Alessandro



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