Le 03/12/2023 à 17:30, Martin Steigerwald a écrit :
> 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.
    Config files can be found in both /etc and /usr/share
>
> 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,

    If you compare the part of the OS which is (after the merge)
outside of /usr, well, you only get /etc, /boot and /var.

    /etc: 13MB

    /boot: 21MB

    /var: 5GB on my laptop with Devuan installed years ago and
periodically dist-upgraded.

    /usr: 11GB but I it can be much bigger.

    What is the point in treating differently /etc and /boot from /lib
and /bin?

    For the other directories in /, they do not consume disk space anyway.

    Would you be lost if all the libraries were in /lib instead of
/usr/lib or sparsed between these directories? I do not propose a big
change: just do the opposite of the current "merge": remove the
nonsensical "/usr" from all the paths in which it is now.

    Cheers.

--     Didier