On Fri, 16 Nov 2018 21:50:11 +0100, Irrwahn wrote in message
<a6134a8a-b3ae-92fa-adb0-eb66bc3484cd@???>:

> g4sra wrote on 16.11.18 21:19:
> > The concept of which is at fault anyway, if root file system network
> > support no longer required the merge should go the other way in any
> > case, it is /usr/{bin,sbin,lib} that is depreciated.
> >
> > /usr/bin > /bin
> > /usr/sbin > /sbin
> > /usr/lib > /lib
> >
> > with the exception of special cases which are frequently abused by
> > distros but are not supposed to be a part of the standard OS and
> > should stay under /usr.
> > e.g.
> >
> > /usr/local
> > /usr/share
>
> I once was on the same page, but have since changed my mind when I
> realized that the other way round, i.e. /{bin,sbin,lib} -> /usr/...
> actually to me makes more sense, as it keeps all the "static" files
> that are part of the distribution neatly in one place.

...which is a neat way to crash and burn when that neat one place fails.


> The only other
> significant things left in / then are site specific configuration in
> /etc and, if not already placed in a dedicated file system,
> persistent variable data in /var.
>
> This allows e.g. for things like rendering the entire "static" part
> of the system effectively immutable simply by mounting /usr
> read-only. (And yes, referring to other sub-threads, in that case one
> would indeed have to mount /usr by means of an initrd, which is
> neither brain science nor rocket surgery.)

..some of us has had to do such stunts to try escape expensive
ramifications.

--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.