Hi, On 1/8/21 11:29 AM, Ludwig Nussel wrote:
Vojtěch Zeisek wrote:
Dne úterý 5. ledna 2021 17:03:33 CET, Ludwig Nussel napsal(a):
Hi, While working on MicroOS, UsrMerge, UsrEtc, playing with systemd features I was wondering where that could lead us to. I'm sure we didn't utilize the full potential of what we can do with our OS yet. So I've tried to dump my thoughts into an article: https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/ 2020-12-16-fslayout.md tl;dr rpms to only operate below /usr and nowhere else.
It's very interesting. Looks reasonable. I just wonder about two points: 1) What are consequences (if any) for fully encrypted systems, i.e. now encrypted LVM containing / and swap, with only unencrypted /boot/efi?
Only good consequences I hope :-) Like not having grub prompt for a passphrase to decrypt the kernel and then the initrd prompting again to actually access the fs.
2) What happens if I'd try to install some 3rd party RPM (build outside OBS)? They often go into /opt, or follow "traditional" /etc /usr /var, ...
IMO we need a new approach to that. Creative ideas welcome :-) The host's rpm database is in charge of the OS, the OS is in /usr. So by definition can't deal with 3rd party stuff in /opt.
But 3rd party stuff is not only in /opt! There are plenty of 3rd party applications that put stuff into /usr (if we consider the non containerized "traditional" 3rd party ISV universe). If we strive for a strict separation of "user installed and modified content" vs. "part of the system" then using /usr is not the answer. We are not going to get everyone to behave (keep their stuff in /opt) nor are we going to get the existing apps that do this intermingling to change (move their stuff to /opt). Meaning if one of the goals is strict separation then something new has to be created "/system", for example, and everything that is shipped as part of the system lives there. But then the question becomes how does one protect this new place from getting "polluted" by 3rd party code? The answer may be that "traditional" apps will probably not change and new apps will probably be container based and as such the risk that $UNMANAGED_3rd_PARTY_APP scribbles to "/system" is reasonably low. But hoping to achieve separation, which is what I read into the post as a part of the idea, and keeping things in /usr is a pipe dream.
There are people who prefer to not install 3rd party software as rpms at all and prefer snaps and flatpacks for example. Those app formats might be built from rpms too but rules for the contained tree could be different.
Another approach could be to invent a layered database approach that can track 3rd party packages separately. That may even include 3rd party packages that try to install to /usr...
Forget packages, how many commercial apps that follow the "traditional" install onto the base system approach deliver their stuff as packages? 5%? I've been out of that world for a long time but would be surprised if it has changed much. So what's missing for me is a concise goal statement as to which problem is intended to be solved. Is it over all complexity or is the primary goal better separation of system and user (admin) stuff? Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo