4 ms·

Why not just include libudev, in systemd instead?

zxzax 5y ago
Because that would not reduce code duplication. I don't know if you have ever worked on any of the low-level Linux libraries written in C, but the amount of unnecessary code duplication across them is awful. The standard library features provided by glibc are extremely inadequate for modern applications, every non-trivial C project I've seen starts to include their own private implementations of various C++ things like hashmaps, binary trees, dynamically sized strings, unicode support, async event loops, etc. For utilities that have to interact with low level kernel APIs it's even worse, every library seems to have to reimplement their own parsing of various other random things like netlink, or in the various pseudo filesystems like sysfs, procfs, cgroupfs, etc etc, the situation is really way out of hand. I don't know how to solve this in a reasonable manner beyond what systemd is already doing. Yes people will complain that they have a systemd dependency now but what else can you do? This is the exact reason the BSDs update the kernel, libc, init and core utils in tandem and consider a lot of the kernel API to be private, Linux was just slow to catch on in that regard.
- cyberdelica 5y ago
  > Because that would not reduce code duplication. I don't want to call you out for making a disingenuous argument, but it was either subsumed by systemd for code duplication reasons, or it wasn't?! Duplicate code, could be refactored out to a shared library, that could then be incorporated in both udev, and systemd. That would mean, anyone looking to incorporate udev into a system, could do so without depending on libsystemd. Instead, it would seem udev code, has been subsumed by libsystemd (in your own words) - which would appear to the sceptical eye, as a power play on the part of red hat - to force other distributions into using libsystemd, which would logically end with them also using systemd itself. > I don't know if you have ever worked on any of the low-level Linux libraries written in C [...] Yes, I have.
  - jhasse 5y ago
    > Duplicate code, could be refactored out to a shared library, that could then be incorporated in both udev, and systemd. That's basically what has been done. The library was named libsystemd. You seem to have a problem with the name "libsystemd".
    - cyberdelica 5y ago
      How do you compile udev, without "libsystemd", or without glibc? > You seem to have a problem with the name "libsystemd". Ah, the ad hominem. Do you have a problem with the Unix Philosophy?
      - cwyers 5y ago
        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.
        cyberdelica 5y ago
        > No, you just categorically don't understand. 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.

Because that would not reduce code duplication. I don't know if you have ever worked on any of the low-level Linux libraries written in C, but the amount of unnecessary code duplication across them is awful. The standard library features provided by glibc are extremely inadequate for modern applications, every non-trivial C project I've seen starts to include their own private implementations of various C++ things like hashmaps, binary trees, dynamically sized strings, unicode support, async event loops, etc. For utilities that have to interact with low level kernel APIs it's even worse, every library seems to have to reimplement their own parsing of various other random things like netlink, or in the various pseudo filesystems like sysfs, procfs, cgroupfs, etc etc, the situation is really way out of hand. I don't know how to solve this in a reasonable manner beyond what systemd is already doing. Yes people will complain that they have a systemd dependency now but what else can you do? This is the exact reason the BSDs update the kernel, libc, init and core utils in tandem and consider a lot of the kernel API to be private, Linux was just slow to catch on in that regard.

cyberdelica 5y ago
> Because that would not reduce code duplication. I don't want to call you out for making a disingenuous argument, but it was either subsumed by systemd for code duplication reasons, or it wasn't?! Duplicate code, could be refactored out to a shared library, that could then be incorporated in both udev, and systemd. That would mean, anyone looking to incorporate udev into a system, could do so without depending on libsystemd. Instead, it would seem udev code, has been subsumed by libsystemd (in your own words) - which would appear to the sceptical eye, as a power play on the part of red hat - to force other distributions into using libsystemd, which would logically end with them also using systemd itself. > I don't know if you have ever worked on any of the low-level Linux libraries written in C [...] Yes, I have.
- jhasse 5y ago
  > Duplicate code, could be refactored out to a shared library, that could then be incorporated in both udev, and systemd. That's basically what has been done. The library was named libsystemd. You seem to have a problem with the name "libsystemd".
  - cyberdelica 5y ago
    How do you compile udev, without "libsystemd", or without glibc? > You seem to have a problem with the name "libsystemd". Ah, the ad hominem. Do you have a problem with the Unix Philosophy?
    - cwyers 5y ago
      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.
      - cyberdelica 5y ago
        > No, you just categorically don't understand. 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.