3 ms·

> 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 co

> 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.
      - cwyers 5y ago
        Because they didn't want to maintain two different libraries? (I don't work for Red Hat. My employer runs mostly Windows boxes. I mostly use Ubuntu when I use Linux.)
      - zxzax 5y ago
        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 https://github.com/systemd/systemd/tree/main/src/udev
      - bkor 5y ago
        > 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.
  - bigbillheck 5y ago
    > Do you have a problem with the Unix Philosophy? 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.
    - vetinari 5y ago
      > 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!".
zxzax 5y ago
The issue is not with the actual udev device event logic itself, but with all the other bits I talked about. Those are the things that would need to be duplicated. >to force other distributions into using libsystemd, which would logically end with them also using systemd itself. As I said elsewhere, libsystemd is just a library with some generic functions provided for convenience. This is like saying that installing python libraries on your system logically means that the PSF is trying to take over your system and forcibly rewrite everything in python, it doesn't make any sense.
- ticviking 5y ago
  Why can't there be a libredhat that provide these things to the community with a stable interface? Lots of communities manage to have widely used data-structure and algorithm libraries that aren't closely in the same repo as other unrelated projects, is there some special problem with this kind of systems programming that prevents that?
  - zxzax 5y ago
    Does it really make a difference whether it's called libsystemd or something else? If you're talking about the other functionality that's private and unstable, it's not included in a separate library for exactly that reason: it's considered private and unstable (Also I'm not sure if you're joking with that name but I really doubt there would ever be something like this literally called "libredhat," that makes about as much sense as putting a random b-tree implementation in a library called libubuntu or a libgentoo).
    - ticviking 5y ago
      >Does it really make a difference whether it's called libsystemd or something else? Probably not. But when I think of something named "libsystemd" I think of a library to interact with systemd, not a collection of random hashmap and B-tree implementations. > If you're talking about the other functionality that's private and unstable Why would I talk about factoring out private and unstable code into a shared library. But if udev is depending on that private and unstable code I do have a lot more sympathy for the packagers who are wary of the merger. It's kind of disengenuois to claim that they're totally separate projects, and can reliably be deployed separately when they both depend on some private special sauce. Even if the sauce is open sourced. > Also I'm not sure if you're joking with that name Half a joke and half trying to avoid the "I hate the name" problem. You have clarified a little bit of what that library is actually doing. And why it seems to make sense to have udev pick up the dependency. Thank you.

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.
    - cwyers 5y ago
      Because they didn't want to maintain two different libraries? (I don't work for Red Hat. My employer runs mostly Windows boxes. I mostly use Ubuntu when I use Linux.)
    - zxzax 5y ago
      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 https://github.com/systemd/systemd/tree/main/src/udev
    - bkor 5y ago
      > 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.
- bigbillheck 5y ago
  > Do you have a problem with the Unix Philosophy? 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.
  - vetinari 5y ago
    > 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!".

zxzax 5y ago

The issue is not with the actual udev device event logic itself, but with all the other bits I talked about. Those are the things that would need to be duplicated. >to force other distributions into using libsystemd, which would logically end with them also using systemd itself. As I said elsewhere, libsystemd is just a library with some generic functions provided for convenience. This is like saying that installing python libraries on your system logically means that the PSF is trying to take over your system and forcibly rewrite everything in python, it doesn't make any sense.

ticviking 5y ago
Why can't there be a libredhat that provide these things to the community with a stable interface? Lots of communities manage to have widely used data-structure and algorithm libraries that aren't closely in the same repo as other unrelated projects, is there some special problem with this kind of systems programming that prevents that?
- zxzax 5y ago
  Does it really make a difference whether it's called libsystemd or something else? If you're talking about the other functionality that's private and unstable, it's not included in a separate library for exactly that reason: it's considered private and unstable (Also I'm not sure if you're joking with that name but I really doubt there would ever be something like this literally called "libredhat," that makes about as much sense as putting a random b-tree implementation in a library called libubuntu or a libgentoo).
  - ticviking 5y ago
    >Does it really make a difference whether it's called libsystemd or something else? Probably not. But when I think of something named "libsystemd" I think of a library to interact with systemd, not a collection of random hashmap and B-tree implementations. > If you're talking about the other functionality that's private and unstable Why would I talk about factoring out private and unstable code into a shared library. But if udev is depending on that private and unstable code I do have a lot more sympathy for the packagers who are wary of the merger. It's kind of disengenuois to claim that they're totally separate projects, and can reliably be deployed separately when they both depend on some private special sauce. Even if the sauce is open sourced. > Also I'm not sure if you're joking with that name Half a joke and half trying to avoid the "I hate the name" problem. You have clarified a little bit of what that library is actually doing. And why it seems to make sense to have udev pick up the dependency. Thank you.