Gentoo seems to be chasing nu Linux design (/usr merge)

spork_kitty · Tux's lil' helper Joined: 05 Jul 2019 Posts: 124

Sources:

I hope the developers have the care and foresight to avoid foisting the nu Linux paradigm on their users. Merged /usr is less modular, typically requires an initramfs (adding more steps to kernel upgrades,), and is really only used by systemd and other software mistakenly placed in /usr like LUKS and LVM. (By extension, any mainstream distro like Fedora is already heavily invested in systemd tech due to it coming out of Red Hat) Every other init system and service manager can adapt to split /usr without issue, but systemd needs the entire package tree to change to suit it. That seems sane. /s

Please note metadata.xml information on all current init systems in Gentoo, and their maintainers:

sys-apps/openrc: openrc@gentoo.org (see https://wiki.gentoo.org/wiki/Project:OpenRC)
sys-apps/systemd: systemd@gentoo.org (see https://wiki.gentoo.org/wiki/Project:Systemd)
sys-apps/sysvinit: williamh@gentoo.org
sys-apps/s6: williamh@gentoo.org (member of Systemd team) + proxy maintainers
sys-apps/s6-linux-init: williamh@gentoo.org + proxy maintainers
sys-process/runit: williamh@gentoo.org
sys-apps/cinit: no maintainer
sys-apps/minit: no maintainer

Upstart is not in tree. Please list other init systems (and the result of `equery m <pkg>`) so we can get a better picture of what's going on. I listed the ones I could find.

From my vantage point, I see one person and/or team making policy to suit a single init system over others, mostly due to said init system being incapable of booting on split-usr systems. That sounds like a problem with upstream, who don't support split /usr at all.

This sort of stuff belongs in the systemd profiles, imo. If you don't think it belongs there I'd be interested in reading why.

What solutions do you guys plan on using to maintain your split /usr?

EDIT: qualified statements to appease nitpicks, bolded important part

Naib · Posted: Sun Jul 21, 2019 2:11 pm Post subject:

just to be clear, rather than acting on hearsay

https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

Anon-E-moose · Posted: Sun Jul 21, 2019 2:21 pm Post subject:

Naib · Posted: Sun Jul 21, 2019 2:25 pm Post subject:

hey, im not saying separate /usr isn't fine, i am just getting some info. If key applications (udev WHICH is a systemd application) store info or applications in /usr AND itself does not have the concept of "needed to boot" and "once things are booted" then yes there is an architectural flaw

I have said this time and time again with FOSS software (and software in general) there is no system engineering going on. no use cases, no sequence diagrams. every now and again you see BDD and IBD but none of the rational as to that

Had the system been modeled and a separate /usr been considered as a use-case then the pre-req would have been clear for the likes of udev (a systemd project)
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

mike155 · Posted: Sun Jul 21, 2019 2:59 pm Post subject:

spork_kitty,

please stop posting bullshit!

spork_kitty · Tux's lil' helper Joined: 05 Jul 2019 Posts: 124

Hu · Administrator Joined: 06 Mar 2007 Posts: 22896

This problem is exacerbated by two distinct major changes, both involving /usr. First, there was the "separate usr is broken" fiasco that systemd pushed (while carefully claiming they were just messengers reporting other people's brokenness), which Naib linked above. Various boot-important programs began assuming that they could access /usr during early boot, and rather than fix those assumptions, someone hit on the idea to require /usr be a directory on /, not mounted separately, or else you must use initramfs tricks to let the system pretend that /usr is not a separate mount. That happened years ago. It was disruptive and annoying, but that is mostly settled. Everyone who wants /usr to be a separate mount has adapted, whether by blacklisting the software that cannot handle it, using initramfs tricks to work around it, or giving up and moving /usr to /.

More recently[1], there has been another big disruptive change. This one advocates the equivalent of:

NeddySeagoon · Posted: Sun Jul 21, 2019 5:33 pm Post subject:

spork_kitty,

Naib · Posted: Sun Jul 21, 2019 5:43 pm Post subject:

/usr was a hack to start with but the use cases it enabled have been viable.

It never ceases to amaze me how piss poor software engineer are at architecting a system... Critical to boot and that which can be delayed should have been understood and managed by now. This constant hack upon hack upon hack, initiated by systemd development, and perpetuated by a lack of understanding has gotten us where we are.
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

bunder · Bodhisattva Joined: 10 Apr 2004 Posts: 5939

NeddySeagoon · Posted: Sun Jul 21, 2019 6:01 pm Post subject:

Naib.

The lack of systems design goes back much further in the PC world than systemd. systemd is just an example of a very long trend.
For an early example look at the introduction and growth oy hard drives and all the hacks that went into that.
The partition table was squeezed into 66 (unused) bytes at the end of the boot record as a hack to get around the MSDOS maximum file system size of 32MB.
That worked until HDD got to 128MB, as the partition table could only hold four entries.
Then the extended/logical partition was a hack grafted on to of the previous hack.

There was more to come ...
The BIOS could only read the first 528MB af a HDD. Thus the /boot at the front of the volume hack was introduced
The problem with the BIOS only being able to read part of a HDD has been repeated several times since.
33G and 137G limits come to mind.

Its not all software either ... why did early PCs ship with a dummy load on the 12v?
It was to keep the early switch mode PSUs regulating properly when no HDD was fitted.

There are lots more.

On the other hand, when Intel actually tried to do it properly, from a systems perspective, and drop all the legacy cruft, we had the Itanium, which nobody wanted because it was not legacy code compatible.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Anon-E-moose · Posted: Sun Jul 21, 2019 6:05 pm Post subject:

Naib · Posted: Sun Jul 21, 2019 6:12 pm Post subject:

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

NeddySeagoon · Posted: Sun Jul 21, 2019 7:05 pm Post subject:

Naib,

I'll just smile :)

Its all good stuff.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

saellaven · l33t Joined: 23 Jul 2006 Posts: 655

Tony0945 · Posted: Sun Jul 21, 2019 7:49 pm Post subject:

Anon-E-moose · Posted: Sun Jul 21, 2019 7:54 pm Post subject:

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

axl · Veteran Joined: 11 Oct 2002 Posts: 1146 Location: Romania

I think the whole effort to separate "things that could be usable to bring the system up" in /bin|/sbin and "things that are just extra" in /usr/bin|/usr/sbin is just pointless.

And further more, I really dislike the new 17.1 profile. I liked having 3 entities. lib|lib32|lib64. now in lib there's mixed lib/libexec stuff|lib32 stuff and lib64 stuff. Really dislike the new 17.1 profile.

Anyway, getting back to the new usr split issue. I feel like this has been an issue for a long time. ebuilds confused about what the split means. like USE="-split-usr" emerge systemd and the dude installs init in /usr/lib/systemd/systemd. use USE="split-usr" and init installs in /lib/systemd/systemd. and again, maybe it's the beer, but i feel like each maintainer understood instructions into his own language, and for some split usr goes in usr, for some goes in /. Not ready to name names or packages, but at least systemd is confused about where the init should be. what is that about? is it my beer? I feel like if you use USE="-split-usr" it should go in /lib and with +split-usr it should go un /usr/lib.

And one more thing. why do you need a link? not sure it's still common practice, but the (or some) of the packages that had USE="split-usr" would also do links for the binaries. like if they installed binaries in /bin/ls they would also do a link to ln -s /bin/ls /usr/bin/ls. or if the binary is in /usr/bin, the other way around. ln -s /usr/bin/ls /bin/ls. what is that about? if you have the real binary in /bin, why do you need a link to it in /usr/bin? I really hope they outgrew that stuff, coz it was really silly.

GDH-gentoo · Posted: Sun Jul 21, 2019 9:01 pm Post subject:

Tony0945 · Posted: Mon Jul 22, 2019 2:40 am Post subject:

OK, I synced and see a lot opf packages with "split-usr" flag. Do I turn this on or off to keep the present behavior?

fedeliallalinea · Posted: Mon Jul 22, 2019 5:37 am Post subject:

Tony0945 · Posted: Mon Jul 22, 2019 2:40 pm Post subject:

Naib · Posted: Mon Jul 22, 2019 6:43 pm Post subject:

Personally I think the packages that provide an init/unit file but also depend on files in /usr (ie the problem child packages w.r.t. split usr) should be identified...

This should be a non-issue yet somehow it is. What EXACTLY needs to be started soo early it has to come before network and nfs? What about these applications cannot be postponed OR even better split launched (a stub to get going and then a reload post nfs)

I really am struggling to see how this became an issue OR how this cannot easily be fixed. The Freedesktop/Redhat/Systemd/Pottering excuse of "oh other packages" when one of them is part of systemd source tree is a poor excuse. More to the point why is the FOSS community just accepting this?

since udev is one of hte trouble poackages (from their perspective), why not bolster eudev with a more sane rules management. Define what is critical to boot (is alsa? no so get it the fk out of the critical path) and move on
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;