Effects of blocking systemd via INSTALL_MASK

[jd2066]

In the topic New profiles 17.1, a reply was done regarding using INSTALL_MASK to block system.
To avoid making that topic go more off-topic, I decided to open a new topic to reply to it.

Here is the message I'm responding to:

Derk, tey adding this to your make.conf:

Code: Select all

INSTALL_MASK="${INSTALL_MASK} /etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d"

That last one fixes a deliberate bug that loads all modules instead of the modules you selected to load in /etc/conf.d/modules because as a user th3e gods of Gentoo have decided that you are too stupid to know what modules need loading when you boot your machine (Correction: Their machine!).
You can safely rm -r all those directories. Unless you want to give up and give in to the systemd plague.

You specified a specific deletion of /etc/systemd, /lib/systemd, /usr/lib/systemd and /usr/lib/modules-load.d via INSTALL_MASK to block systemd.
However, removing those directories is not necessary to avoid using systemd and in fact could cause harm to the system setup, even if they don't use systemd.
For instance, I use udev which would not work if I removed /lib/systemd because even though I use OpenRC, udev installs it's main binary to that location.
As for /etc/systemd and /usr/lib/systemd, they only contain text configurations files for use should systemd be installed.
I don't plan to install systemd but it doesn't hurt anything that some small configuration files are hanging around unused.
As for /usr/lib/modules-load.d, it only contains configuration files to load modules from packages that the user installs, it won't load all installed modules as your post seems to imply.
There has not been a time where I installed virtualbox-modules and didn't also want the modules to be automaticly loaded.
I did not know about this feature before but it would have saved a bit of time by not needing to add the modules to the /etc/conf.d/modules file.
It appears to be one of the few ideas that originated with systemd that is helpful and is easily supported by other init systems.

[proteusx]

This is my INSTALL_MASK in all my machines (4) for some time now.

Code: Select all

INSTALL_MASK="${INSTALL_MASK} /etc/systemd /usr/lib/systemd /usr/lib/modules-load.d /usr/lib/tmpfiles.d"

Everything works fine.

Unfortunately, because of inertia, I still have udev so /lib/systemd stays.
One day I hope to find the time to get rid of that too.

EDIT
As regards to vmware-modules, if they wanted to be helpful, they could write
the modules in /etc/conf.d/modules and use the etc-update mechanism.

[jd2066]

Unfortunately, because of inertia, I still have udev so /lib/systemd stays.
One day I hope to find the time to get rid of that too.

EDIT: It seems I confused proteusx and Tony0945.
Do you realize that you didn't mention this in your initial post so assuming that user has udev (safe assumption as it's the default), then what you told that user to do would have actually broke their system by deleting the udev binary?
An issue like that is likely why asturm was not happy with what you posted, someone suggesting deleting directories that could be important without much rational.
To a certain extent, asturm was correct about random because unless you know that all the directories you listed are used by systemd then some of them make no sense.
Like /usr/lib/modules-load.d for instance as it's not really specific to systemd as OpenRC uses it too.
Unless you knew that systemd did it first, you would not think it had anything to do with systemd at all.

touches on the very soul of Gentoo as a distrubtion independent of RedHat. There is so much FUDD spread by systemd adherents that it must be addressed somewhere. Like the BS "could cause your openrc system harm" and "should you decide to switch to systemd". Maybe I should always keep a sharp knife handy in case I decide to cut my throat in the future?

I quoted this from your recent reply on the other topic as I'm wondering what you mean.
Are you saying in general or were you talking about my post?
Because I'm not really invested in the big systemd debates on the forum.
I prefer OpenRC as there are a few things I don't like about systemd but it seems like systemd has some good things.
I have rarely used systemd though so I can't much about it.
I can understand not liking or using it but I don't understand the use of INSTALL_MASK as just not having systemd merged works just fine to avoid as it can't run if it's not installed.

As regards to vmware-modules, if they wanted to be helpful, they could write
the modules in /etc/conf.d/modules and use the etc-update mechanism.

That would make the ebuild specific to one init system, by using the /usr/lib/modules-load.d directory, the configuration works with openrc and systemd.
I suppose I can see your point in regards to if you decided to remove automatic loading of the virtualbox modules and not being able to do so by editing /etc/conf.d/modules could be an issue.
I wouldn't think that is something many would want anyways though unless someone had a situation where they didn't use virtualbox that often and wanted to only load the modules when they did use it.
Though, in that specific case, according to modules-load.d man page, the configuration could be overwritten by adding a symlink to /dev/null in /etc/modules-load.d/virtualbox.conf as that empty file in /etc/modules-load.d will take precedence over the one in /usr/lib/load-modules.d.
However, it does appear that the OpenRC module-load script doesn't set any priories on directories so that will not work with it (I suppose a bug should be filled about that).

[khayyam]

[...] removing those directories is not necessary to avoid using systemd and in fact could cause harm to the system setup, even if they don't use systemd.

jd2066 ... this is part of the objection, why should we accept that these are "standard" locations, and why should they necessarily exist for proper functioning when the system in question isn't using systemd? Further, we know where these "standards" are going as systemd has stated it has a "very strict policy [...] to gently push the distros to standardize on the same components for the base system", and at any opportunity (ie, sys-apps/usbutils) will lock you into requiring it once the groundwork has been laid. These "same components" do not include openrc (or other init systems), so why should we be accepting of its incursion into our systems?

For instance, I use udev which would not work if I removed /lib/systemd because even though I use OpenRC, udev installs it's main binary to that location.

So, system binaries are now located in /lib? Is that the new standard?

As for /etc/systemd and /usr/lib/systemd, they only contain text configurations files for use should systemd be installed. I don't plan to install systemd but it doesn't hurt anything that some small configuration files are hanging around unused.

You are defeating your own argument, if they are not needed then an INSTALL_MASK is perfectly fine.

As for /usr/lib/modules-load.d, it only contains configuration files to load modules from packages that the user installs, it won't load all installed modules as your post seems to imply.

So, /usr/lib is the new standard for configuration files?

There has not been a time where I installed virtualbox-modules and didn't also want the modules to be automaticly loaded. I did not know about this feature before but it would have saved a bit of time by not needing to add the modules to the /etc/conf.d/modules file. It appears to be one of the few ideas that originated with systemd that is helpful and is easily supported by other init systems.

Well, it could also be argued it violates the principle of least surprise, and the uniformity principle.

best ... khay

[Tony0945]

First, anyone on OpenRC should be on eudev, not udev as has been mentioned several places on the forum. Non-systemd support by udev is officially deprecated and will be withdrawn soon.

Next, even blocking udev will not damage a system. At most, it will stop bootiing and need to be booted by usb or CD, the Install mask restored by editting make.conf and re-emerging udev.

Regarding automagically loading modules, see https://forums.gentoo.org/viewtopic-t-1 ... ed95bd8b9b

Before rehashing all this all over again, see comments by Ant P and Fitzcarraldo here: https://forums.gentoo.org/viewtopic-t-1 ... art-0.html

Likewise this earlier topic thread: https://forums.gentoo.org/viewtopic-p-8 ... dbc2d2c171

Systemd files don't belong on a non-systemd system (OpenRC, runit, S6) period. Nor do Ubuntu files or anything else no needed. What's the harm in leaving non-executing crud, you say?
Well, I had the automagically loading stuff. I had two ethernet cards, one Intel, the other Realtek. I built support for both as modules but only loaded one each boot, controlled by /etc/conf.d/modules. I found both loading, leading to the uncertain allocation of eth0 and eth1. Trying to find out why lead me to that first link.

To a certain extent, asturm was correct about random because unless you know that all the directories you listed are used by systemd then some of them make no sense.
Like /usr/lib/modules-load.d for instance as it's not really specific to systemd as OpenRC uses it too.

As I said, read the first link.

[jd2066]

jd2066 ... this is part of the objection, why should we accept that these are "standard" locations, and why should they necessarily exist for proper functioning when the system in question isn't using systemd? Further, we know where these "standards" are going as systemd has stated it has a "very strict policy [...] to gently push the distros to standardize on the same components for the base system", and at any opportunity (ie, sys-apps/usbutils) will lock you into requiring it once the groundwork has been laid. These "same components" do not include openrc (or other init systems), so why should we be accepting of its incursion into our systems?

I suppose that makes since.
I'll have to do more research on this to see what the deal is as I didn't know anything changed with usbutils to force lock-in to systemd.

So, system binaries are now located in /lib? Is that the new standard?

My post was primary aimed at the user Tony0945 who giving out advice on INSTALL_MASK to a user without knowing for sure how it would affect that user.
The point was that this advice could cause harm to the user if the user used udev as it installed it's binary there.
I was not saying that udev's binary being in /lib/systemd is a good or bad thing, I was just pointing out an issue.

So, /usr/lib is the new standard for configuration files?

Well, the standard for package installed system or default configuration files but even then I'm not sure as it seems like other packages like dbus and kde use /usr/share/pkgname as a place to store system or default configuration.

Well, it could also be argued it violates the principle of least surprise, and the uniformity principle.

Ok, I'm not really sure how to respond to that.

First, anyone on OpenRC should be on eudev, not udev as has been mentioned several places on the forum. Non-systemd support by udev is officially deprecated and will be withdrawn soon.

Huh, well I did not know that.
I don't any news items mentioning that.

Next, even blocking udev will not damage a system. At most, it will stop bootiing and need to be booted by usb or CD, the Install mask restored by editting make.conf and re-emerging udev.

Yes, it won't damage a system but a user just wanting to upgrade their profile won't be happy to have to deal with fixing a problem that only happened because of code someone suggested that wouldn't even fix that problem.

Now I don't have any free time to read up on the module-loading right now so I'll have to check out your link later and reply when I have checked them out.

[proteusx]

Do you realize that you didn't mention this in your initial post so assuming that user has udev (safe assumption as it's the default), then what you told that user to do would have actually broke their system by deleting the udev binary?
An issue like that is likely why asturm was not happy with what you posted, someone suggesting deleting directories that could be important without much rational.

I am not Tony0945, I never said I deleted the udev binary.

As regards to virtualbox-modules, since forever, I have my own script
which loads the modules and brings up certain services
whenever I need to start a VM. I was livid when accidentally I discovered that openrc
was loading the modules unbeknown to me. Even today the virtualbox-modules ebuild
post installation continues to advise:

Code: Select all

* If you are using sys-apps/openrc, please add "vboxdrv", "vboxnetflt",
* "vboxnetadp" and "vboxpci" to:
*   /etc/conf.d/modules

That would make the ebuild specific to one init system, by using the /usr/lib/modules-load.d directory, the configuration works with openrc and systemd.

Why tamper with openrc to accomodate systemd and not the other way round?
Why write an init.d script to load "systemd style" modules and not write a systemd service
to load modules from /etc/conf.d/modules?

[jd2066]

Do you realize that you didn't mention this in your initial post so assuming that user has udev (safe assumption as it's the default), then what you told that user to do would have actually broke their system by deleting the udev binary?
An issue like that is likely why asturm was not happy with what you posted, someone suggesting deleting directories that could be important without much rational.

I am not Tony0945, I never said I deleted the udev binary.

Sorry about that.
My mistake.

As for the modules, I thought about it some more and I think you are right that /usr/lib/modules-load.d is an odd place to store automatic module loading configuration.
The more I think about it, keeping the module loading to just /etc/conf.d/modules is simpler and mores more sense.
As I have the virtualbox modules listed in that file, there is no point to the /etc/init.d/modules-load init script as it's just a waste to run for it to even run.

Why tamper with openrc to accomodate systemd and not the other way round?
Why write an init.d script to load "systemd style" modules and not write a systemd service
to load modules from /etc/conf.d/modules?

That is a good point. I didn't think about that.

[khayyam]

I'll have to do more research on this to see what the deal is as I didn't know anything changed with usbutils to force lock-in to systemd.

jd2066 ... it was a change to usbutils-008 (a change made by a systemd developer) that requires hwdb from libudev. You can find some discussion of the fact on various embedded lists, and I expect this is in part why busybox announced later that year that "systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them". As far as gentoo is concerned, no one noticed.

So, system binaries are now located in /lib? Is that the new standard?

My post was primary aimed at the user Tony0945 who giving out advice on INSTALL_MASK to a user without knowing for sure how it would affect that user. The point was that this advice could cause harm to the user if the user used udev as it installed it's binary there. I was not saying that udev's binary being in /lib/systemd is a good or bad thing, I was just pointing out an issue.

Yes, I understood that, however, the question still stands, why should we be taking the direction, and adopting the "standards" of, a project which clearly operates as though such things are theirs to decide willy-nilly.

So, /usr/lib is the new standard for configuration files?

Well, the standard for package installed system or default configuration files but even then I'm not sure as it seems like other packages like dbus and kde use /usr/share/pkgname as a place to store system or default configuration.

The filesystem hierarchy standard states this is for "[l]ibraries for the binaries in /usr/bin and /usr/sbin", so, no.

Well, it could also be argued it violates the principle of least surprise, and the uniformity principle.

Ok, I'm not really sure how to respond to that.

The "principle of least surprise" is one of the "rules", or "principles" of the unix philosophy, it states "always do the least surprising thing", which in this case could mean don't load modules unless they are explicitly configured to load. In cases where we install a daemon we do not automatically add that daemon to a runlevel, even though the user has explicitly installed it, and I would expect this be the "least surprising" thing for some package. Again, that could be argued either way, as the question involved is one of where the user stands in all this. The "principle of uniformity" is about consistency (ie, naming scheme, namespace, etc) so where configuration is stored, the mechanism used, etc.

best ... khay

[berferd]

I have that install mask set up precisely because I want my system to break as quickly and loudly as possible the moment some package I have installed decides to depend on any kind of systemd cruft. Any package that misbehaves in that way will be removed immediately.

I was removing that crapware by hand until I discovered INSTALL_MASK here. Thanks!

As an aside, I'm curious about the effect of adding /usr/lib/tmpfiles.d to INSTALL_MASK. The stupid "Setting up tmpfiles.d" step takes the longest time in my boot up by far. I don't have tmpfiles.d in my current install mask.

[khayyam]

As an aside, I'm curious about the effect of adding /usr/lib/tmpfiles.d to INSTALL_MASK. The stupid "Setting up tmpfiles.d" step takes the longest time in my boot up by far. I don't have tmpfiles.d in my current install mask.

berferd ... I can't speak for having it in INSTALL_MASK but I've removed it (tmpfiles.dev and tmpfiles.setup) from the runlevel ... after checking what was being done.

best ... khay

[proteusx]

With openrc-0.17 there is no need for the sys-apps/opentmpfiles scripts.

You may need to put it in package.provided because some packages (e.g. eix)
require it as a dependency.

[khayyam]

With openrc-0.17 there is no need for the sys-apps/opentmpfiles scripts.

proteusx ... that is because sys-apps/opentmpfiles was a component of sys-apps/openrc until it was split out.

Code: Select all

% eix '-I*' --format '<installedversions:NAMEVERSION>' sys-apps/openrc
sys-apps/openrc-0.12.4
% equery -NC files sys-apps/openrc | grep tmpfiles
/etc/conf.d/tmpfiles
/etc/init.d/tmpfiles.dev
/etc/init.d/tmpfiles.setup
/lib/rc/sh/tmpfiles.sh
/usr/share/openrc/runlevels/boot/tmpfiles.setup -> /etc/init.d/tmpfiles.setup
/usr/share/openrc/runlevels/sysinit/tmpfiles.dev -> /etc/init.d/tmpfiles.dev

best ... khay

[Hu]

I have that install mask set up precisely because I want my system to break as quickly and loudly as possible the moment some package I have installed decides to depend on any kind of systemd cruft. Any package that misbehaves in that way will be removed immediately.

If you have not already, you should locally package.mask sys-apps/systemd, so that declared package dependencies on systemd provoke a package mask error before you install the package. This is likely cleaner than using INSTALL_MASK to break the package after it installs.

[berferd]

Yes, my package.mask has started this way for a long time now

Code: Select all

# Lennart
sys-apps/systemd
sys-power/upower
sys-apps/gentoo-systemd-integration
# Lennart's minion
>sys-apps/openrc-0.17
>sys-apps/lm_sensors-3.4.0

I also have -systemd in my USE flags. However, packages insist on installing systemd cruft despite these settings. I'm wary of trojan horse dependencies, so I was removing everything in the systemd directories after every emerge just to be sure. INSTALL_MASK is much easier

[jd2066]

I'll have to do more research on this to see what the deal is as I didn't know anything changed with usbutils to force lock-in to systemd.

jd2066 ... it was a change to usbutils-008 (a change made by a systemd developer) that requires hwdb from libudev. You can find some discussion of the fact on various embedded lists, and I expect this is in part why busybox announced later that year that "systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them". As far as gentoo is concerned, no one noticed.

Hmm, I decided to look it up and found what you were talking about.
There are two commits done on Sep 12, 2013 from Tom Gundersen to the usbutils project to make it use hwdb instead of the usb.ids text file.
It appears hwdb is a binary database based on data from the pci.ids and usb.ids text files.
I have to say that it seems like the systemd developers really like binary databases over plain text files as the systemd journal also uses a binary database instead of plain text log files that syslog outputs.
It appears that this developer assumed that any distributions using usbutils would have hwdb available so it would simplify things by not including the usb.ids file with usbutils.
If hwdb is only available via udev/systemd then this assumption would be incorrect for any systems that don't use udev/systemd.

The "principle of least surprise" is one of the "rules", or "principles" of the unix philosophy, it states "always do the least surprising thing", which in this case could mean don't load modules unless they are explicitly configured to load. In cases where we install a daemon we do not automatically add that daemon to a runlevel, even though the user has explicitly installed it, and I would expect this be the "least surprising" thing for some package. Again, that could be argued either way, as the question involved is one of where the user stands in all this. The "principle of uniformity" is about consistency (ie, naming scheme, namespace, etc) so where configuration is stored, the mechanism used, etc.

Ok, that makes sense.
In this case it seems like using modules-load.d fits that principle for those using systemd as one of it's functions is to automatically load modules when possible and using it for users using OpenRC would be against the principal.
In which case, it seems that adding support for modules-load.d to OpenRC was a mistake in regards to expectations.

[krinn]

In case it help you, i've been hit by that, so i have add this to stay quiet.
PKG_INSTALL_MASK="${INSTALL_MASK}"

[Ant P.]

There are two commits done on Sep 12, 2013 from Tom Gundersen to the usbutils project to make it use hwdb instead of the usb.ids text file.
It appears hwdb is a binary database based on data from the pci.ids and usb.ids text files.
I have to say that it seems like the systemd developers really like binary databases over plain text files as the systemd journal also uses a binary database instead of plain text log files that syslog outputs.
It appears that this developer assumed that any distributions using usbutils would have hwdb available so it would simplify things by not including the usb.ids file with usbutils.
If hwdb is only available via udev/systemd then this assumption would be incorrect for any systems that don't use udev/systemd.

???

Code: Select all

 ~ $ qlist hwids | xargs file
/lib/udev/hwdb.d/70-touchpad.hwdb:                 ASCII text
/lib/udev/hwdb.d/70-pointingstick.hwdb:            UTF-8 Unicode text
/lib/udev/hwdb.d/70-mouse.hwdb:                    UTF-8 Unicode text
/lib/udev/hwdb.d/70-joystick.hwdb:                 ASCII text
/lib/udev/hwdb.d/60-sensor.hwdb:                   ASCII text
/lib/udev/hwdb.d/60-keyboard.hwdb:                 ASCII text
/lib/udev/hwdb.d/60-evdev.hwdb:                    ASCII text
/lib/udev/hwdb.d/20-usb-vendor-model.hwdb:         UTF-8 Unicode text
/lib/udev/hwdb.d/20-usb-classes.hwdb:              ASCII text
/lib/udev/hwdb.d/20-sdio-vendor-model.hwdb:        ASCII text
/lib/udev/hwdb.d/20-sdio-classes.hwdb:             ASCII text
/lib/udev/hwdb.d/20-pci-vendor-model.hwdb:         UTF-8 Unicode text
/lib/udev/hwdb.d/20-pci-classes.hwdb:              ASCII text
/lib/udev/hwdb.d/20-net-ifname.hwdb:               ASCII text
/lib/udev/hwdb.d/20-bluetooth-vendor-product.hwdb: UTF-8 Unicode text
/lib/udev/hwdb.d/20-acpi-vendor.hwdb:              UTF-8 Unicode text
/lib/udev/hwdb.d/20-OUI.hwdb:                      UTF-8 Unicode text
/usr/share/misc/usb.ids:                           UTF-8 Unicode text
/usr/share/misc/pci.ids:                           UTF-8 Unicode text
/usr/share/misc/iab.txt:                           UTF-8 Unicode text, with CRLF line terminators
/usr/share/misc/oui.txt:                           UTF-8 Unicode text, with CRLF line terminators
/usr/share/misc/usb.ids.gz:                        gzip compressed data, was "usb.ids", last modified: Tue Oct  3 21:50:40 2017, from Unix
/usr/share/misc/pci.ids.gz:                        gzip compressed data, was "pci.ids", last modified: Tue Oct  3 21:50:40 2017, from Unix
/usr/share/doc/hwids-20171003/README.md.bz2:       bzip2 compressed data, block size = 900k

If that's a binary database then sorry but you need to upgrade from IBM EBCDIC already.
Drop the blind religious outrage and stick to facts, please.

[proteusx]

With openrc-0.17 there is no need for the sys-apps/opentmpfiles scripts.

proteusx ... that is because sys-apps/opentmpfiles was a component of sys-apps/openrc until it was split out.

Code: Select all

% eix '-I*' --format '<installedversions:NAMEVERSION>' sys-apps/openrc
sys-apps/openrc-0.12.4
% equery -NC files sys-apps/openrc | grep tmpfiles
/etc/conf.d/tmpfiles
/etc/init.d/tmpfiles.dev
/etc/init.d/tmpfiles.setup
/lib/rc/sh/tmpfiles.sh
/usr/share/openrc/runlevels/boot/tmpfiles.setup -> /etc/init.d/tmpfiles.setup
/usr/share/openrc/runlevels/sysinit/tmpfiles.dev -> /etc/init.d/tmpfiles.dev

best ... khay

Indeed, but also I do not start the tmpfiles.{setup,dev} scripts at all:

Code: Select all

#  rc-status -u | grep tmp
 tmpfiles.setup                                                    [  stopped  ]
 tmpfiles.dev                                                       [  stopped  ]

I have /tmp and /run mounted on tmpfs.

[jd2066]

If that's a binary database then sorry but you need to upgrade from IBM EBCDIC already.
Drop the blind religious outrage and stick to facts, please.

From the hwdb man page:

The hwdb files are read from the files located in the system hwdb directory /usr/lib/udev/hwdb.d and the local administration directory /etc/udev/hwdb.d.
[...]
The content of all hwdb files is read by systemd-hwdb(8) and compiled to a binary database located at /etc/udev/hwdb.bin, or alternatively /usr/lib/udev/hwdb.bin if you want ship the compiled database in an immutable image. During runtime, only the binary database is used.

So it seems hwdb can refer to the initial key-value pair text files or the binary database those files are compiled into.

I did originally get those two things confused and think both were binary databases but it was just a simple mistake due in part to being tired.
There was no "blind religious outrage" as you put it, it just seemed interesting that another binary database was involved with systemd but it is different then the systemd journal as the binary database is not only part of hwdb.
It does appear though in the context of usbutils that I was talking about, the binary database is likely the only part of hwdb that is accessed by usbutils.

[steveL]

It appears hwdb is a binary database based on data from the pci.ids and usb.ids text files.

Yes, and the problem is that both have been subsumed into udev, and are now marketed as a systemd product, when in fact they are the end-product of the work of thousands of users across the world.
This applies to udev as well; it had a simple spec, from the kernel bods, and given a simple spec, any decent coder can produce the mux, especially given the prior art.
Years of work from users, and ofc all that groundwork from Bob Burtle, got it to the point where it was reliable, and then it was subsumed by systemd, as if only the systemd team were capable of providing dynamic device "discovery".

This may be non-technical in terms of how the attack is carried out, but it is an attack on the spirit of FLOSS, with wide-reaching technical implications.
When all the software we rely on has been taken over by teams of corporate drones, in order to "embrace, extend, extinguish" the competition, the community will be reduced to a voluntary work-force, slaving in our free time to provide the infrastructure used to sell us our own work. (In fact I'd say we're already there; atm we still have a way back -- for now.)

I have to say that it seems like the systemd developers really like binary databases over plain text files as the systemd journal also uses a binary database instead of plain text log files that syslog outputs.

This specific usage is again, nothing new; cf: man tic. Hardly surprising when you remember that this is not a systemd project: it's just been taken over and bundled with systemdbust to make it look better.

It appears that this developer assumed that any distributions using usbutils would have hwdb available so it would simplify things by not including the usb.ids file with usbutils.

It would make much more sense in distribution terms to keep the usbutils project independent.

But then it's not for the benefit of all distros; in fact it's designed to take away any and all USPs from the competition, that RedHatMegaPlex can.
Once you're all effectively RedHat clones, it makes it a lot easier to present the case that "RedHat is Linux"[1] and thus establish the "No one ever got fired for buying RedHat" trope.

Sad to say, but their real competition is Oracle, not the community. For both, we're just the do-gooder marks, who prop up the system with our time and effort.
--

[1] "because we bought off all the coders we could, and bad-mouthed the rest till they got bored of arguing with us. Now no-one argues with us. :) So we can pretend we have consensus."

[jd2066]

So, system binaries are now located in /lib? Is that the new standard?
[...]
So, /usr/lib is the new standard for configuration files?

It appears the systemd file-hiearchy man page explains this:

Operating systems using the systemd(1) system and service manager are organized based on a file system hierarchy inspired by UNIX, more specifically the hierarchy described in the File System Hierarchy specification and hier(7). This manual page describes a more minimal, modernized subset of these specifications that defines more strictly the suggestions and restrictions systemd makes on the file system hierarchy.

In that file system layout /lib is actually a compatibility symlink to /usr/lib and the purpose of /usr/lib is "Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent). Note that this includes internal executables or other binaries that are not regularly invoked from a shell."
Other binaries go in /usr/bin which has compatibility symlinks at /bin, /sbin, /usr/sbin to point to that directory.
The path /usr/lib/arch-id is "Location for placing dynamic libraries into, also called $libdir. The architecture identifier to use is defined on Multiarch Architecture Specifiers (Tuples) list."

I don't know why those behind systemd thought they needed to change the file system layout like that.
I also don't entirely understand it as parts of it seem confusing.

I was thinking some of the anti-systemd people were just blowing things out of proportion and things weren't really that bad but after reading things like this I'm not so sure.

The systemd people shouldn't just come up with new standards, write systemd to use those standards and then just expect everyone to just adopt those standards without any debate but that certainly seems to be what has been happening.

[Tony0945]

I don't know why those behind systemd thought they needed to change the file system layout like that.

Because they could.

The systemd people shouldn't just come up with new standards, write systemd to use those standards and then just expect everyone to just adopt those standards without any debate but that certainly seems to be what has been happening.

Well, that's what Microsoft does and RedHat is a Microsoft wannabee.

[Fitzcarraldo]

I don't know why those behind systemd thought they needed to change the file system layout like that.

Because they could.

The systemd people shouldn't just come up with new standards, write systemd to use those standards and then just expect everyone to just adopt those standards without any debate but that certainly seems to be what has been happening.

Well, that's what Microsoft does and RedHat is a Microsoft wannabee.

Reminds me of the xkcd cartoon Standards. Rearranging the furniture again.

[krinn]

Other binaries go in /usr/bin which has compatibility symlinks at /bin, /sbin, /usr/sbin to point to that directory.

You miss a point there, because it is not obvious as you may not notice the hole hide behind that.

LFSH define /sbin as "tools for admin that are needed to boot", /usr/sbin for tools that are not critical too boot, while still use by admin.
But if you remove /sbin and symlink it to /usr/sbin, it mean "critical to boot" are now in /usr/sbin, which in turn mean: you cannot boot if /usr is not mount.

So by removing /sbin and symlink it to /usr/sbin you void anyone that will use /usr in a separate partition ; which is not a big deal as systemd doesn't like that.
But the funny part, is that you are hinting everyone: if you have something critical to boot, it should goes in /usr/sbin because we may remove /sbin one day ; and the proper way is to use /usr/sbin and not /sbin
And if dhcpcd start to agree the "systemd" way, it will not put its binary in /sbin, but in /usr/sbin ; and all users using systemd that cannot use a separate /usr won't see any change: /usr must be present at boot, or the system will fail to use dhcpcd.
But for non systemd users, that do use separate /usr, it mean: oh nice, now dhcpcd install itself in /usr/sbin and i couldn't use dhcpcd in recovery mode, because i couldn't boot if my /usr is not mount, which i mount normally later.

I don't know why those behind systemd thought they needed to change the file system layout like that.

So for me, best answer to this is: "to fuck all other init that could boot with a separate /usr while trying to making sure they couldn't do that anymore"