7 ms·

Wasn't it because Kay Sievers was a major developer on both udev and systemd? I can image someone thinking then "I'm implementing everything twice, both for ud

Wasn't it because Kay Sievers was a major developer on both udev and systemd? I can image someone thinking then "I'm implementing everything twice, both for udev and systemd. I'll just merge them"

zxzax 5y ago
According to Lennart that's correct, the reason it was done was to reduce the amount of duplicate code: https://lwn.net/Articles/490441/ https://lwn.net/Articles/490441/
- cyberdelica 5y ago
  That's what code libraries were intended for.
  - zxzax 5y ago
    Not sure why you're saying that -- moving it to a library is basically what happened. The libudev code got moved to libsystemd, and now libudev is a wrapper around that.
    - cyberdelica 5y ago
      > Not sure why you're saying that -- moving it to a library is basically what happened. The libudev code got moved to libsystemd, and now libudev is a wrapper around that. Oh, so now one has to include "libsystemd" if one wants to use "udev" - is that what you're writing? Hence the original comment: > By devouring the udev project, the systemd maintainers have guaranteed that dealing with USB devices on non-systemd systems was going to be a giant pain.
      - zxzax 5y ago
        I don't understand, is this not what you were asking for initially? libsystemd.so is just a shared library, it's not any more of a giant pain than any other library.
        cyberdelica 5y ago
        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.
      - kaba0 5y ago
        Feel free to rename it libNotSystemdButAGeneralSharedLib and link that.. it is named systemd, not systemd-the-init-system itself.
    - mixmastamyk 5y ago
      I'd expect the opposite, if someone said they moved something to a library.
- ohazi 5y ago
  I realize that I don't really have any right to complain about this. I don't contribute to either project, and I think that maintainers should feel free to do whatever they think is best for their projects, including things that help reduce burdensome things that they find annoying. However, as a heavy user of both projects, I see what those decisions have led to in practice, and have opinions about what this might mean for the community in the medium/long term. The reality on the ground today is that you either run systemd+udev, or you run OpenRC/something else + eudev. And having observed other projects that went down the "we forked, but merge regularly to try and keep the forks in sync" rabbit hole (e.g. ffmpeg and libav), this almost always ends badly. The goal may be to keep the two separate projects compatible, but inevitably environment differences, bugs, refactors, etc. cause the two projects to diverge. This sucks for everybody, but it sucks a lot more for people using the less popular fork, and this can eventually kill the fork. I worry about eudev long-term.
  - zxzax 5y ago
    So that really seems to be the core of the problem to me: nobody really wants to seriously maintain udev as an individual project. It's not a fun or glamorous project to work on, it's boring, nobody will notice it unless it breaks, and nobody really seems to care that it depends on libsystemd. For most people this is just an implementation detail. For an embedded distro I can't see why you would use udevd or eudev, you probably want a much simpler device manager without the giant hwdb.
  - throw0101a 5y ago
    > I realize that I don't really have any right to complain about this. I don't contribute to either project This is a strange mindset. Do Star Wars fans not have a right to complain about bad movies just because they weren't part of the cast or crew?

Wasn't it because Kay Sievers was a major developer on both udev and systemd? I can image someone thinking then "I'm implementing everything twice, both for udev and systemd. I'll just merge them"

zxzax 5y ago

According to Lennart that's correct, the reason it was done was to reduce the amount of duplicate code: https://lwn.net/Articles/490441/ https://lwn.net/Articles/490441/

cyberdelica 5y ago
That's what code libraries were intended for.
- zxzax 5y ago
  Not sure why you're saying that -- moving it to a library is basically what happened. The libudev code got moved to libsystemd, and now libudev is a wrapper around that.
  - cyberdelica 5y ago
    > Not sure why you're saying that -- moving it to a library is basically what happened. The libudev code got moved to libsystemd, and now libudev is a wrapper around that. Oh, so now one has to include "libsystemd" if one wants to use "udev" - is that what you're writing? Hence the original comment: > By devouring the udev project, the systemd maintainers have guaranteed that dealing with USB devices on non-systemd systems was going to be a giant pain.
    - zxzax 5y ago
      I don't understand, is this not what you were asking for initially? libsystemd.so is just a shared library, it's not any more of a giant pain than any other library.
      - cyberdelica 5y ago
        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.
    - kaba0 5y ago
      Feel free to rename it libNotSystemdButAGeneralSharedLib and link that.. it is named systemd, not systemd-the-init-system itself.
  - mixmastamyk 5y ago
    I'd expect the opposite, if someone said they moved something to a library.
ohazi 5y ago
I realize that I don't really have any right to complain about this. I don't contribute to either project, and I think that maintainers should feel free to do whatever they think is best for their projects, including things that help reduce burdensome things that they find annoying. However, as a heavy user of both projects, I see what those decisions have led to in practice, and have opinions about what this might mean for the community in the medium/long term. The reality on the ground today is that you either run systemd+udev, or you run OpenRC/something else + eudev. And having observed other projects that went down the "we forked, but merge regularly to try and keep the forks in sync" rabbit hole (e.g. ffmpeg and libav), this almost always ends badly. The goal may be to keep the two separate projects compatible, but inevitably environment differences, bugs, refactors, etc. cause the two projects to diverge. This sucks for everybody, but it sucks a lot more for people using the less popular fork, and this can eventually kill the fork. I worry about eudev long-term.
- zxzax 5y ago
  So that really seems to be the core of the problem to me: nobody really wants to seriously maintain udev as an individual project. It's not a fun or glamorous project to work on, it's boring, nobody will notice it unless it breaks, and nobody really seems to care that it depends on libsystemd. For most people this is just an implementation detail. For an embedded distro I can't see why you would use udevd or eudev, you probably want a much simpler device manager without the giant hwdb.
- throw0101a 5y ago
  > I realize that I don't really have any right to complain about this. I don't contribute to either project This is a strange mindset. Do Star Wars fans not have a right to complain about bad movies just because they weren't part of the cast or crew?