No, you just categorically don't understand. libsystemd is not systemd the init system, it doesn't require systemd to be running, it is simply the name of "the shared library that everything developed under the systemd project uses for common code." Now, you can argue until the cows come home that you'd be happier if udev, systemd, and libredhathatesyou (or some other name for libsystemd that doesn't include systemd in it) were all in different Git repos, but since you can run udev without a dependency on systemd running on the system, that seems like a pretty low-stakes dispute.
Of course I understand, as do the rest of the people not employed by red hat upvoting me.
Time and time again, I've seen systemd advocates making slippery, disingenuous, and outright false arguments. When they're called out on it, the goalposts magically move, a rotation of usernames appear to downvote and brigade which can be ascertained through downvote timing correlation. When they can't win an argument through facts, then they make bogus arguments that one doesn't get it, or some such nonsense - or claim they're a red hat conspiracy monger.
Seeing it over and and over again is lame, and played out.
Now, why don't you answer the question - if udev was subsumed by "libsystemd" as is claimed due to "code duplication" - then why did they not just include "libudev" as a dependency for "libsystemd"?
Of course, the question will never be answered, as it'll reveal the truth.
> Of course I understand, as do the rest of the people not employed by red hat upvoting me.
That's a really poor argument you're making. You've only repeated things you've assumed earlier without actually responding or seemingly trying to understand what the other person said.
Libsystemd does not contain init system type logic. You're assuming way too much. There's too much blind hate. The suggestion that people are likely employed by Red Hat as a reason that they don't understand says enough.
Too much emotional responses to the systemd name, too often people use poor arguments and reasoning, while saying it is the other person that is lacking in their reasoning.
The code savings from including udev in systemd turned out to be greater, as there was more re-usable code already written in systemd. Please be the better person and don't revive this flamewar, it's not helpful, let's stick to the technical facts and work together to find the answers we seek -- for example you can look at the git logs to see all the shared functionality and the code that was changed around: https://github.com/systemd/systemd/tree/main/src/udev
This thread got me thinking about all the unix systems I've used, admin'd, and fought with over the years, and I suddenly remembered a system I used the early 90s when you couldn't mv a file across filesystem boundaries because what that actually was was really a copy-and-remove and not just a rename, so it was outside mv's domain.
And that's what 'the Unix Philosophy' means to me, and why I consider it not worth much.
> This thread got me thinking about all the unix systems I've used, admin'd, and fought with over the years, and I suddenly remembered a system I used the early 90s when you couldn't mv a file across filesystem boundaries because what that actually was was really a copy-and-remove and not just a rename, so it was outside mv's domain.
Many similar problems like that is exactly the reason why many systems had GNU tools installed; and "GNU's Not Unix!".
That's basically what has been done. The library was named libsystemd.
You seem to have a problem with the name "libsystemd".