On 17/11/18 at 13:14, Olaf Meeuwissen wrote:
> Hi Katolaz,
>
> KatolaZ writes:
>
>> On Sat, Nov 17, 2018 at 11:45:03AM +0100, KatolaZ wrote:
>>
>> [cut]
>>
>>> OK, before we continue with a flame about what is wrong and what is
>>> right: it seems that the transition to the merged usr is *not*
>>> mandatory so far, but it is actually performed at install time. I am
>>> currently trying to understand at which point during installation this
>>> happens, so that we could just make it optional (i.e, with an opt-in
>>> semantics).
>> I should have waited a couple of minutes before writing: it looks like
>> it is just an option in debootstrap. It should be fairly easy to make
>> it optional by tweaking base-installer. Working on that. We will have
>> it in the new beowulf installer.
> This reminded me of something I did to build my Devuan Docker images:
> passing --no-merged-usr to debootstrap. See
>
> https://gitlab.com/paddy-hack/devuan/blob/master/bootstrap.sh#L21
>
> Just like */bin and */sbin are useful to distinguish between programs
> intended for general use and system administration use, the distinction
> between / and /usr is useful to tell critical and non-critical programs
> apart.


  How long before Free(lol)desktop decides that the separation between
bin and sbin is so old-fashioned and useless to modern systems?

[...]


> Removing the distinction takes the option away from the user. Whether a
> distribution wants to "pay the cost" of keeping this as an option for
> their user base is the distribution's decision. The user base can vote
> with its feet.


  Right, I subscribe to this point of view.  And I also fully agree to
everything stated below.


> # The cost is in terms of having to think about what should go where for
> # one's user base. As far as I can see the /usr merge is mostly just an
> # attempt to get rid of the need to think. Pointing out that others did
> # this already is lemming mentality. Saying that you need stuff in /usr
> # anyway is blindly assuming it is needed in all cases or refusal to fix
> # what your users consider to be a bug.
>
> I have / and /usr on the same file system on all of my machines but
> still appreciate the fact that I have a choice. I like to keep it that
> way. As for */bin and */sbin, the latter category is not in my PATH. I
> also like to keep exercising that as an option.
>
> The idea of grouping certain classes of files in different directories
> makes it just so much easier for homo sapiens to keep a grip on things.
> Just imagine what / would look like if hardware progress would have
> outpaced software developments in 1971. There would not have been any
> need for /usr and we might have ended up with /games and /include and
> /local and /share as well as /src. Actually, that doesn't look all bad
> but I'm glad that the lack of disk space in 1971 helped us identify the
> notion that there are critical and non-critical files on our computers.
>
> About that not looking all bad, perhaps the merge should be in the other
> direction, from /usr to / rather than from / to /usr. Or can we expect
> suggestions to move /var, /tmp, /dev, /run, /media etc. to /usr "because
> all the stuff in /usr needs it anyway"?
>
> # Those are a non-serious suggestion and a rethorical question, in case
> # that didn't come across.
>
> So, I'm against a *forced* /usr merge. I hope Debian does the right
> thing but if necessary, I would like to see Devuan correct the wrong.
> However, let's focus on init freedom (and beowulf) first!
>

> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>  Support Free Software                        https://my.fsf.org/donate
>  Join the Free Software Foundation              https://my.fsf.org/join
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

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