16 ms·

I actually like using systemd. I took the time to learn how to use it, and as a desktop Linux user, it's honestly quite nice. But the one thing that still real

by ohazi 5y ago

I actually like using systemd. I took the time to learn how to use it, and as a desktop Linux user, it's honestly quite nice. But the one thing that still really pisses me off about systemd-the-project was the fact that they ate udev-the-project. In my view, that decision was unnecessary and was done for purely anti-competitive reasons. If you're not familiar, udev is basically the user-facing device manager for Linux. It's what allows you to easily configure rules and permissions for all the USB devices that you plug into your computer. These devices still need kernel drivers, but udev is how you tell your system "Please let user ohazi use this device, and also give it a convenient name like /dev/someDevice0" 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. Then came the forks -- Gentoo maintains eudev, which is a systemd-free fork of udev. But really, this shouldn't be a fork. Udev should be independent and available on all systems. If systemd wants to do something special with devices, they should use udev APIs like everybody else. In my view, this is what finally allowed systemd to win the init war, despite all the protest. Ideological arguments about how best to start daemons is one thing, but you simply can't use a modern system without a sane approach to USB. Edit: It seems that some of my concerns were overblown, e.g. you apparently can run udev without systemd as pid 1. Udev has a build-time dependency on systemd, but not a run-time dependency. The eudev fork removes that build-time dependency, and (maybe?) also papers over some other inconsistencies. I'm pleased that this is the case. I'm annoyed that the discourse around systemd/udev has been muddy enough to lead me to incorrect conclusions (and I'm aware that the original version of this comment likely added fuel to this particular fire). Oh well... live and learn.

edoceo 5y ago
I love Gentoo and really like they chose to make eudev and a elogind so I can continue to use OpenRC, which has been working great for me since forever.
- ohazi 5y ago
  Don't get me wrong -- I too am extremely grateful to the Gentoo devs for maintaining eudev. It's also the obvious choice for highly memory constrained embedded Linux systems that can't fit systemd. I just think it's absolutely bonkers that it has to be a fork... eudev should really just be udev.
- medstrom 5y ago
  Credit where it's due, the GNU Guix folks made elogind and Gentoo picked it up.
unilynx 5y ago
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.
zxzax 5y ago
>that decision [...] was done for purely anti-competitive reasons. This is not correct, I don't know where you got this idea. The systemd-udevd daemon still runs without systemd. The code has moved into the systemd repository, and it has a build dependency on libsystemd, but otherwise it has no runtime dependency; your distro should be able to package it separately if it wants.
- ohazi 5y ago
  Can you point to a distro that does this vs. using eudev? I mean, you might be right, but I haven't found any, and I think the reason for this is that there are subtler inter-dependencies that require additional workarounds: > > Also, AFAIR the connection between systemd and udev doesn't really go deeper than the fact that they're sharing the same upstream tarball. It is still possible to build and use udev without systemd > But that's not really the case operationally, and it's why eudev was forked away from it for Gentoo. https://lwn.net/Articles/778547/ https://lwn.net/Articles/778547/
  - asfodelsu 5y ago
    The people that makes distro without systemd have users that scan the filesystem and get crazy if they found the name systemd in the filesystem. I can say the same for the devs also. So we have hardcore-hate distros that "liberates" packages and the dependency of the unused library. Better give that time to make the distro better imho
  - zxzax 5y ago
    The udevd package in gentoo does exactly this, which is supported as an alternative to eudev: https://packages.gentoo.org/packages/sys-fs/udev https://packages.gentoo.org/packages/sys-fs/udev I believe the reason for eudev is to avoid some of those other unwanted changes from upstream udev that broke udev scripts. Which to me is a fine technical justification, but not really related to another udev implementation having a build dependency on libsystemd. The udevd package seems maintained so I really don't understand what operational issues that comment is getting at.
Valmar 5y ago
> But the one thing that still really pisses me off about systemd-the-project was the fact that they ate udev-the-project. In my view, that decision was unnecessary and was done for purely anti-competitive reasons. The developers of udev at the time agreed to merge to the project into systemd, as it made a lot of sense to them. There was no "devouring", no "anti-competitive" bullshit.
- regularfry 5y ago
  Given that at the time of the merge the developers of udev were the systemd developers, "agreed to merge" seems like an odd presentation of that particular piece of history.
  - bkor 5y ago
    Why? You're saying it was pushed. But actually the maintainers agreed. Further, the maintainers overlapped. Instead of acknowledging that it wasn't pushed because the maintainers overlapped you make up "anti-competitive" behaviour. I work for a company where every year there is a mandatory refresher on anti competition laws / behaviour. The suggestion that this is done for malicious purposes is highly offensive, yet so easily stated. This without actually going into a lengthy and thorough explanation. I think you're failing to understand how offensive you're being towards these developers. So easily using very harsh words, so easily dismissing what anyone else says, plus what the developers said. Yet not actually proving any good proof for your statements.
    - regularfry 5y ago
      > Why? Because saying that they were separate groups implies a level of propriety to the decision that doesn't hold when the groups "overlap". > You're saying it was pushed. Am I? Where? > But actually the maintainers agreed. At the risk of repeating myself, this implies a level of propriety to the decision that doesn't hold when the maintainers are the same in each group. > I work for a company where every year there is a mandatory refresher on anti competition laws / behaviour. Didn't take, did it? Just for giggles, see if you can identify the common factor in these classes of anticompetitive behaviour: - Cartel price-fixing - Refusal to deal - Conspiracy to monopolise - Dividing territories - Regulatory capture > I think you're failing to understand how offensive you're being towards these developers. I don't. I also don't think they need you to defend them.
TacticalCoder 5y ago
> By devouring the udev project... That's the main issue (not udev specifically but the overall philosophy of trying to make systemd mandatory for as many things as possible). Any distro adopting systemd is basically forever giving up any hope of moving away from systemd in the future. I'm still on Debian (Debian user since "Buzz") but I already tried Devuan (Debian fork without systemd) once and may switch to it at some point. I simply don't like the overall mindset of those pushing systemd.
- jamal-kumar 5y ago
  I had a hard time trying Devuan because all the package mirrors are really far away from me unfortunately, but I don't have any issues at all just removing it from whenever I am working with debian servers. It all used to work through some shell script called systemd-shim, I'm not entirely sure now though, maybe someone else has an idea off hand https://sysdfree.wordpress.com/2020/07/02/319/ https://sysdfree.wordpress.com/2020/07/02/319/
mjw1007 5y ago
What particularly grated was that they managed to introduce bugs into udev and then say they didn't have the "expertise or understanding" to fix them: https://github.com/systemd/systemd/issues/7157#issuecomment-338482132 https://github.com/systemd/systemd/issues/7157#issuecomment-... (That bug was causing udev to give multiple disks the same name in /dev/disk/by-path, which I think is pretty much core udev functionality, given that udev was intended to supersede devfs.)
- 867-5309 5y ago
  the systemd stars-to-issues ratio is worrying to say the least
  - Iolaum 5y ago
    lolz - i 'll be keeping an eye on that from now on :) (on some of my fav projects)
  - TheDong 5y ago
    What do you imagine that ratio shows? Different projects use issues differently, so that number isn't super comparable... And I've also noticed that low-level systems projects generally attract relatively few stars (i.e. a javascript library or go library will have more stars than a well used c library or systemd). My theory on that is that the people involved in projects like systemd, gnu, etc, see github as mostly just a git repository host, and don't bother with stars etc. I guess from my perspective, I put zero weight into the stars on a project, and issue count only matters in the context of how the project deals with issues. What do you see as "worrying" in there? Do you see more value in those numbers than me?
    - 867-5309 5y ago
      I think it generally shows how active, responsive and sufficiently staffed the maintainers are. should projects be on github if the issues aren't used as intended? the worry comes from the number of systems in production relying on systemd
egberts1 5y ago
systemd still hasn’t properly replaced ISC dhclient so I dumped the entire systemd and went both Gentoo and Denuvan (systemd-free Debian).
- bkor 5y ago
  Are you being sarcastic? The DHCP bits are entirely optional. You can either use it, or not use it. The code is useful in some cases, not useful in others. Saying that some optional code has issues as a reason to not just use something else, but as a reason to not use the project: not logical.
  - egberts1 5y ago
    Try getting Nintendo to do a DHCP with systemd, you can’t. Nor with Juniper DHCP server configured by Comcast and Verizon, you can’t. Hence, ISC dhclient remains.
nine_k 5y ago
I cannot shake off the feeling that the core developers standing behind systemd, pulseaudio, Gnome desktop spend a lot of time using macOS, and like it better than Linux. This would explain why they imitate or copy many of its features (and misfeatures), and seemingly tend to replace the Unix ways with entirely different approaches. Effectively forcing things on users, as it was with pulseaudio and systemd, is also a very macOS thing to do. I'm not opposed to replacing Unix with different approaches, as long as they keep playing on its key strengths, and do not remove modularity and composability. That is, Plan 9 is fine with me. Much of what Red Hat does, sadly, no.
- zxzax 5y ago
  If plan 9 is what you want, I would encourage you to use 9front. I can't see why you would use Linux if you didn't like Red Hat, they have been a key contributor in Linux land for a long time, employing many long-time kernel developers.
  - nine_k 5y ago
    I'm not sure if 9front can be a daily driver yet; say, it does not seem to be able to run Emacs. Would be nice though. Not that I don't like Red Hat. They are the poster child of a successful open-source company, and did and keep doing a ton of great things. I only don't like certain directions of development of certain userspace things which happen to be done under their corporate umbrella. These things, systemd in particular, were quite noticeable on the Linux landscape as of recently, both in the tiny desktop niche, and the huge server sector. Nobody's perfect, you know.
    - zxzax 5y ago
      I have to say, that seems like a strange requirement: I have never really considered Emacs (or Lisp) to be particularly Unix-like at all! I think the plan 9 people would probably tell you to ditch Emacs and use acme (Me personally, I say use whatever you want).
      - 5y ago
Blikkentrekker 5y ago
> But the one thing that still really pisses me off about systemd-the-project was the fact that they ate udev-the-project. In my view, that decision was unnecessary and was done for purely anti-competitive reasons. Such are all the common criticisms on systemd. It was never a technical objection; it was a political objection to the fact that systemd unnecessarily coupled things that could and should be separated, but were coupled not for technical reasons, but for anticompetitive ones, and this goes beyond systemd. Many Red Hat projects have a way of finding themselves to be dependent on one another in ways that are often hard to justify from a technical standpoint, and often even use unstable, undocumented interfaces that they make available for one another.
- kaba0 5y ago
  How about the technical standpoint of having loose coupling everywhere is bug prone and hard to maintain? Will you create a public API that you will break at each update? That’s not too different to what is the state now. Should you carry around 10 years old baggage APIs or what exactly would you propose?
- regularfry 5y ago
  Unnecessary coupling of components is a technical objection. It's poor engineering, and that criticism was framed by systemd supporters as political.
  - Blikkentrekker 5y ago
    By that argument, all criticism of software is technical. The argument is that it's not done due to incompetence, but commercial strategies.
gregkh 5y ago
The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the systemd codebase in order for lots of duplicated code and functionality to be removed. By doing this, we have made the maintenance and support for this core userspace tool much easier for everyone who was involved in working on it. If the developers involved in a project do not do what you want with that project, feel free to fork the project as that's the beauty of open source! And hey, that's exactly what the eudev developers did, go use their fork if you want to, no one is forcing you to use the version from systemd, just like no one is forcing you to use any other open source program. It's your choice to do so or not :)
- totony 5y ago
  Why did you chose udev using libsystemd and not systemd using libudev (or made a different shared library, I'm not familiar with what happened)? Seems like this would have been a more widely accepted change and achieved the same thing.
  - gregkh 5y ago
    I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :) Also, udevd is a program, not a library.
    - totony 5y ago
      As I understand there was some shared code between the two projects and udev was refactored into using systemd's code. Why not make systemd re-use udev code instead? Aka either expand udev's library or make a library out of the shared code that's used by both systemd and udev. That way udev stays a separate project and you don't have to bring in a big library to use it. Systemd needs udev both ways so it changes nothing for it apart perhaps a bit of maintenance for a separate library for the shared code.

by ohazi 5y ago

edoceo 5y ago

I love Gentoo and really like they chose to make eudev and a elogind so I can continue to use OpenRC, which has been working great for me since forever.

ohazi 5y ago
Don't get me wrong -- I too am extremely grateful to the Gentoo devs for maintaining eudev. It's also the obvious choice for highly memory constrained embedded Linux systems that can't fit systemd. I just think it's absolutely bonkers that it has to be a fork... eudev should really just be udev.
medstrom 5y ago
Credit where it's due, the GNU Guix folks made elogind and Gentoo picked it up.

unilynx 5y ago

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.

zxzax 5y ago

>that decision [...] was done for purely anti-competitive reasons. This is not correct, I don't know where you got this idea. The systemd-udevd daemon still runs without systemd. The code has moved into the systemd repository, and it has a build dependency on libsystemd, but otherwise it has no runtime dependency; your distro should be able to package it separately if it wants.

ohazi 5y ago
Can you point to a distro that does this vs. using eudev? I mean, you might be right, but I haven't found any, and I think the reason for this is that there are subtler inter-dependencies that require additional workarounds: > > Also, AFAIR the connection between systemd and udev doesn't really go deeper than the fact that they're sharing the same upstream tarball. It is still possible to build and use udev without systemd > But that's not really the case operationally, and it's why eudev was forked away from it for Gentoo. https://lwn.net/Articles/778547/ https://lwn.net/Articles/778547/
- asfodelsu 5y ago
  The people that makes distro without systemd have users that scan the filesystem and get crazy if they found the name systemd in the filesystem. I can say the same for the devs also. So we have hardcore-hate distros that "liberates" packages and the dependency of the unused library. Better give that time to make the distro better imho
- zxzax 5y ago
  The udevd package in gentoo does exactly this, which is supported as an alternative to eudev: https://packages.gentoo.org/packages/sys-fs/udev https://packages.gentoo.org/packages/sys-fs/udev I believe the reason for eudev is to avoid some of those other unwanted changes from upstream udev that broke udev scripts. Which to me is a fine technical justification, but not really related to another udev implementation having a build dependency on libsystemd. The udevd package seems maintained so I really don't understand what operational issues that comment is getting at.

Valmar 5y ago

> But the one thing that still really pisses me off about systemd-the-project was the fact that they ate udev-the-project. In my view, that decision was unnecessary and was done for purely anti-competitive reasons. The developers of udev at the time agreed to merge to the project into systemd, as it made a lot of sense to them. There was no "devouring", no "anti-competitive" bullshit.

regularfry 5y ago
Given that at the time of the merge the developers of udev were the systemd developers, "agreed to merge" seems like an odd presentation of that particular piece of history.
- bkor 5y ago
  Why? You're saying it was pushed. But actually the maintainers agreed. Further, the maintainers overlapped. Instead of acknowledging that it wasn't pushed because the maintainers overlapped you make up "anti-competitive" behaviour. I work for a company where every year there is a mandatory refresher on anti competition laws / behaviour. The suggestion that this is done for malicious purposes is highly offensive, yet so easily stated. This without actually going into a lengthy and thorough explanation. I think you're failing to understand how offensive you're being towards these developers. So easily using very harsh words, so easily dismissing what anyone else says, plus what the developers said. Yet not actually proving any good proof for your statements.
  - regularfry 5y ago
    > Why? Because saying that they were separate groups implies a level of propriety to the decision that doesn't hold when the groups "overlap". > You're saying it was pushed. Am I? Where? > But actually the maintainers agreed. At the risk of repeating myself, this implies a level of propriety to the decision that doesn't hold when the maintainers are the same in each group. > I work for a company where every year there is a mandatory refresher on anti competition laws / behaviour. Didn't take, did it? Just for giggles, see if you can identify the common factor in these classes of anticompetitive behaviour: - Cartel price-fixing - Refusal to deal - Conspiracy to monopolise - Dividing territories - Regulatory capture > I think you're failing to understand how offensive you're being towards these developers. I don't. I also don't think they need you to defend them.

TacticalCoder 5y ago

> By devouring the udev project... That's the main issue (not udev specifically but the overall philosophy of trying to make systemd mandatory for as many things as possible). Any distro adopting systemd is basically forever giving up any hope of moving away from systemd in the future. I'm still on Debian (Debian user since "Buzz") but I already tried Devuan (Debian fork without systemd) once and may switch to it at some point. I simply don't like the overall mindset of those pushing systemd.

jamal-kumar 5y ago
I had a hard time trying Devuan because all the package mirrors are really far away from me unfortunately, but I don't have any issues at all just removing it from whenever I am working with debian servers. It all used to work through some shell script called systemd-shim, I'm not entirely sure now though, maybe someone else has an idea off hand https://sysdfree.wordpress.com/2020/07/02/319/ https://sysdfree.wordpress.com/2020/07/02/319/

mjw1007 5y ago

What particularly grated was that they managed to introduce bugs into udev and then say they didn't have the "expertise or understanding" to fix them: https://github.com/systemd/systemd/issues/7157#issuecomment-338482132 https://github.com/systemd/systemd/issues/7157#issuecomment-... (That bug was causing udev to give multiple disks the same name in /dev/disk/by-path, which I think is pretty much core udev functionality, given that udev was intended to supersede devfs.)

867-5309 5y ago
the systemd stars-to-issues ratio is worrying to say the least
- Iolaum 5y ago
  lolz - i 'll be keeping an eye on that from now on :) (on some of my fav projects)
- TheDong 5y ago
  What do you imagine that ratio shows? Different projects use issues differently, so that number isn't super comparable... And I've also noticed that low-level systems projects generally attract relatively few stars (i.e. a javascript library or go library will have more stars than a well used c library or systemd). My theory on that is that the people involved in projects like systemd, gnu, etc, see github as mostly just a git repository host, and don't bother with stars etc. I guess from my perspective, I put zero weight into the stars on a project, and issue count only matters in the context of how the project deals with issues. What do you see as "worrying" in there? Do you see more value in those numbers than me?
  - 867-5309 5y ago
    I think it generally shows how active, responsive and sufficiently staffed the maintainers are. should projects be on github if the issues aren't used as intended? the worry comes from the number of systems in production relying on systemd

egberts1 5y ago

systemd still hasn’t properly replaced ISC dhclient so I dumped the entire systemd and went both Gentoo and Denuvan (systemd-free Debian).

bkor 5y ago
Are you being sarcastic? The DHCP bits are entirely optional. You can either use it, or not use it. The code is useful in some cases, not useful in others. Saying that some optional code has issues as a reason to not just use something else, but as a reason to not use the project: not logical.
- egberts1 5y ago
  Try getting Nintendo to do a DHCP with systemd, you can’t. Nor with Juniper DHCP server configured by Comcast and Verizon, you can’t. Hence, ISC dhclient remains.

nine_k 5y ago

I cannot shake off the feeling that the core developers standing behind systemd, pulseaudio, Gnome desktop spend a lot of time using macOS, and like it better than Linux. This would explain why they imitate or copy many of its features (and misfeatures), and seemingly tend to replace the Unix ways with entirely different approaches. Effectively forcing things on users, as it was with pulseaudio and systemd, is also a very macOS thing to do. I'm not opposed to replacing Unix with different approaches, as long as they keep playing on its key strengths, and do not remove modularity and composability. That is, Plan 9 is fine with me. Much of what Red Hat does, sadly, no.

zxzax 5y ago
If plan 9 is what you want, I would encourage you to use 9front. I can't see why you would use Linux if you didn't like Red Hat, they have been a key contributor in Linux land for a long time, employing many long-time kernel developers.
- nine_k 5y ago
  I'm not sure if 9front can be a daily driver yet; say, it does not seem to be able to run Emacs. Would be nice though. Not that I don't like Red Hat. They are the poster child of a successful open-source company, and did and keep doing a ton of great things. I only don't like certain directions of development of certain userspace things which happen to be done under their corporate umbrella. These things, systemd in particular, were quite noticeable on the Linux landscape as of recently, both in the tiny desktop niche, and the huge server sector. Nobody's perfect, you know.
  - zxzax 5y ago
    I have to say, that seems like a strange requirement: I have never really considered Emacs (or Lisp) to be particularly Unix-like at all! I think the plan 9 people would probably tell you to ditch Emacs and use acme (Me personally, I say use whatever you want).
    - 5y ago

Blikkentrekker 5y ago

> But the one thing that still really pisses me off about systemd-the-project was the fact that they ate udev-the-project. In my view, that decision was unnecessary and was done for purely anti-competitive reasons. Such are all the common criticisms on systemd. It was never a technical objection; it was a political objection to the fact that systemd unnecessarily coupled things that could and should be separated, but were coupled not for technical reasons, but for anticompetitive ones, and this goes beyond systemd. Many Red Hat projects have a way of finding themselves to be dependent on one another in ways that are often hard to justify from a technical standpoint, and often even use unstable, undocumented interfaces that they make available for one another.

kaba0 5y ago
How about the technical standpoint of having loose coupling everywhere is bug prone and hard to maintain? Will you create a public API that you will break at each update? That’s not too different to what is the state now. Should you carry around 10 years old baggage APIs or what exactly would you propose?
regularfry 5y ago
Unnecessary coupling of components is a technical objection. It's poor engineering, and that criticism was framed by systemd supporters as political.
- Blikkentrekker 5y ago
  By that argument, all criticism of software is technical. The argument is that it's not done due to incompetence, but commercial strategies.

gregkh 5y ago

The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the systemd codebase in order for lots of duplicated code and functionality to be removed. By doing this, we have made the maintenance and support for this core userspace tool much easier for everyone who was involved in working on it. If the developers involved in a project do not do what you want with that project, feel free to fork the project as that's the beauty of open source! And hey, that's exactly what the eudev developers did, go use their fork if you want to, no one is forcing you to use the version from systemd, just like no one is forcing you to use any other open source program. It's your choice to do so or not :)

totony 5y ago
Why did you chose udev using libsystemd and not systemd using libudev (or made a different shared library, I'm not familiar with what happened)? Seems like this would have been a more widely accepted change and achieved the same thing.
- gregkh 5y ago
  I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :) Also, udevd is a program, not a library.
  - totony 5y ago
    As I understand there was some shared code between the two projects and udev was refactored into using systemd's code. Why not make systemd re-use udev code instead? Aka either expand udev's library or make a library out of the shared code that's used by both systemd and udev. That way udev stays a separate project and you don't have to bring in a big library to use it. Systemd needs udev both ways so it changes nothing for it apart perhaps a bit of maintenance for a separate library for the shared code.