Didier Kryn - 03.12.23, 15:45:23 CET:
> > That actually the original reason from /usr split from 1971.
> >
> > #v+
> > When the operating system grew too big to fit on the first RK05 disk
> > pack (their root filesystem) they let it leak into the second one,
> > which is where all the user home directories lived (which is why the
> > mount was called /usr). They replicated all the OS directories under
[…]

>      That's exactly why the current /usr merge is insane. It should be
> the opposite: remove /usr and put all its subdirs back into /

>

>      It make no sense to put the biggest part of the OS into /user, but
> not all of it. /etc, /var and /boot for example have not been "merged"
> (yet?).

Well an argument here is that by moving all the static OS parts into /usr
one can easily split the part of a setup that is unchanging from the part
of the setup that is changeable configuration. Everything in /usr could
basically be read-only, instead of for a package manager. Or it could be
handled as one blob that is updated as a whole, probably by having two
copies and then switching between them. That is why more and more
configuration files as shipped by packages are moved into /usr and /etc will
contain contain a file on changes to the configuration.

There is an example about virtual machines on their justification page:

Example: Multiple Guest Operating Systems on the Same Host

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

Another example would be to have a static OS part in /usr and install
applications in some form of application containers. But if you really go
that route, I probably would go all in and do something like what Nitrux
has done with their Aesthetic Filesystem Hierarchy Standard.

https://nxos.org/changelog/release-announcement-nitrux-3-2-0/

My dream would be something like what Runit inventor has thought of. I do
not find it anymore, but it was something along the lines of:

/package/bash-4.01
/package/bash-5.2.21-2
/command/bash => /package/bash-5.2.21-2/bin/bash

And another directory I think for documentation.

I think this is explained somewhere on smarden.org, but I do not find it
anymore. If anyone has the link, please share. Then I finally archive it
locally in order to find it more easily again.

This could combine the best of both worlds, having an easy way to install
multiple versions of something in parallel while still not using
application containers that probably add quite some duplication of the
very same files and probably other bloat.

I do like to install some application as Flatpak and that I can restrict
the permissions those applications have. Like for example Zoom. I avoid
using it, but something it is either the choice to not attend a meeting
that otherwise would be a good meeting to attend or tolerate the service
provider. In case for the few times I tolerate the service provider then
I'd rather not have the Zoom application be able to access all of my home
directory. It is sufficient in case it only can access a few curated
directories. But even with free software like FS-UAE Launcher, it is
broken in Debian since more than a year. It works nicely as a Flatpak.

However I do not see the containerized way to install applications as the
future for just about any application. I do recognize increased startup
time for example for Flatpak applications and its no wonder.

Anyway regarding the question where to store things there is likely no
easy right/wrong. There are different choices with different benefits. I
still like some of the approach of AmigaOS where you could basically place
your apps anywhere. However… there no real package manager to begin with
and while it is possible to install a library into the directory of the
application there are quite some libraries used by several applications
and no provision to have more than one version of one AmigaOS style
library installed. However… there is the somewhat adhered to restriction
for AmigaOS style libraries not to break existing user space. Which means
in case you like to improve a library call in an incompatible way, you
have a new library call and need to keep the old one around. So basically
a library in AmigaOS is a bit like the Linux kernel.

Anyway it is becoming off topic here, however… I would be very interested
to see what comes out of it if you throw in all the existing experience in
how to handle things into one pot and then consider: If I would do a
completely new operating system, how would it look like?

But that is clearly out of scope for Devuan, so I stop here.

Best,
--
Martin