4 ms·

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

by 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.
  - ohazi 5y ago
    Interesting. I didn't realize this was a supported option, but the Gentoo wiki also seems to agree with you [1], so I may need to walk back some of my frustration around this. I still have concerns that having a shared codebase makes it easier for interdependencies to materialize later, but if they've managed to keep it as decoupled as is claimed here, then I'm pleasantly surprised, and also annoyed that the communication around this issue has been confusing enough to lead me to an apparently incorrect conclusion. [1] https://wiki.gentoo.org/wiki/Gentoo_Without_systemd#The_udev_situation https://wiki.gentoo.org/wiki/Gentoo_Without_systemd#The_udev...
    - Conan_Kudo 5y ago
      Most of the systemd components actually work without systemd as the init. I've used udev and nspawn without systemd-init. As long as you don't have a problem with libsystemd existing, most things work fine without systemd-init. Mainly systemd-journal and systemd-oomd both require systemd-init.
dralley 5y ago
>and it has a build dependency on libsystemd That does seem kind of unfortunate for anyone that wants to bootstrap a systemd-less distibution.
- zxzax 5y ago
  Libsystemd is just a shared library with some common code used by various systemd daemons (an epoll-based event loop, the dbus protocol implementation, uuid generation, parsers for the binary logs, etc). I can understand why people don't want to run systemd as pid1, but having some other external daemon depend on this library doesn't make it any harder to bootstrap that type of distribution.
  - salawat 5y ago
    Why take the risk of a maintainer saying fuckit and pulling in the rest of systemd since you're already using their utils? It's just one of those things where it's better to stay away.
    - zxzax 5y ago
      That doesn't really make any sense, libsystemd is just a library with some fairly generic functionality.
devenblake 5y ago
I have a feeling if this was as simple as you say, distro maintainers would be doing it.
- JoshTriplett 5y ago
  They do. The few distributions that still support non-systemd init systems do split out udev: https://packages.debian.org/sid/udev https://packages.debian.org/sid/udev
cbmuser 5y ago
Which is not that uncommon, FWIW. binutils and gdb were also moved into a common repository and gcc merged some repositories as well.
makomk 5y ago
In practice I think systemd-udevd probably still runs without systemd, but as I understand it that's not an officially supported solution and the systemd developers have said they reserve the right to make changes that break it at any time. (The main reason why they haven't yet is most likely that their attempts to integrate dbus into the kernel and systemd more tightly were rejected by the kernel devs; if I remember rightly that was expected to be the point at which you could not use it without systemd.) Using the kernel interfaces that udev relies on without using udev itself is also unsupported and the developers consider it within their rights to break those as well.
- zxzax 5y ago
  It has been supported for at least the last 9 years now, I don't see why they would have any reason to break it. >The main reason why they haven't yet is most likely that their attempts to integrate dbus into the kernel and systemd more tightly were rejected by the kernel devs; if I remember rightly that was expected to be the point at which you could not use it without systemd. That seems quite dubious, udev has never depended on dbus, and there really would be no reason for it to ever do that. >Using the kernel interfaces that udev relies on without using udev itself is also unsupported and the developers consider it within their rights to break those as well. This I know is true, the netlink stuff varies really wildly from driver to driver. The alternative would be to put udevd and the other userspace bits into the kernel, which I really doubt anyone wants to do.
Blikkentrekker 5y ago
IT's not my area of expertise, but the eudev page does speak of restoring some functionality that it lacks without systemd running alongside it, as well as removing glibc and GCC specific dependencies. There is probably a reason why even many binary systems adopted eudev instead. — the maintainers often justify this with “problems” with udev but never go into much detail about what that is but the language does keep suggesting that it restored some functionality that is missing if it run sans systemd.
- bkor 5y ago
  > but the language does keep suggesting that it restored some functionality that is missing if it run sans systemd. People often misunderstand what libsystemd does. See the many reactions here, but also e.g. the response by Devuan around libsystemd. Too often people assume things around systemd, or too heavily rely on incorrect information found via Google. That things are being done this way by a few projects to me isn't enough. Nowadays people did not thoroughly investigate things before they take a decision. See e.g. the various responses in this thread.

by zxzax 5y ago

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.
- ohazi 5y ago
  Interesting. I didn't realize this was a supported option, but the Gentoo wiki also seems to agree with you [1], so I may need to walk back some of my frustration around this. I still have concerns that having a shared codebase makes it easier for interdependencies to materialize later, but if they've managed to keep it as decoupled as is claimed here, then I'm pleasantly surprised, and also annoyed that the communication around this issue has been confusing enough to lead me to an apparently incorrect conclusion. [1] https://wiki.gentoo.org/wiki/Gentoo_Without_systemd#The_udev_situation https://wiki.gentoo.org/wiki/Gentoo_Without_systemd#The_udev...
  - Conan_Kudo 5y ago
    Most of the systemd components actually work without systemd as the init. I've used udev and nspawn without systemd-init. As long as you don't have a problem with libsystemd existing, most things work fine without systemd-init. Mainly systemd-journal and systemd-oomd both require systemd-init.

dralley 5y ago

>and it has a build dependency on libsystemd That does seem kind of unfortunate for anyone that wants to bootstrap a systemd-less distibution.

zxzax 5y ago
Libsystemd is just a shared library with some common code used by various systemd daemons (an epoll-based event loop, the dbus protocol implementation, uuid generation, parsers for the binary logs, etc). I can understand why people don't want to run systemd as pid1, but having some other external daemon depend on this library doesn't make it any harder to bootstrap that type of distribution.
- salawat 5y ago
  Why take the risk of a maintainer saying fuckit and pulling in the rest of systemd since you're already using their utils? It's just one of those things where it's better to stay away.
  - zxzax 5y ago
    That doesn't really make any sense, libsystemd is just a library with some fairly generic functionality.

devenblake 5y ago

I have a feeling if this was as simple as you say, distro maintainers would be doing it.

JoshTriplett 5y ago
They do. The few distributions that still support non-systemd init systems do split out udev: https://packages.debian.org/sid/udev https://packages.debian.org/sid/udev

cbmuser 5y ago

Which is not that uncommon, FWIW. binutils and gdb were also moved into a common repository and gcc merged some repositories as well.

makomk 5y ago

In practice I think systemd-udevd probably still runs without systemd, but as I understand it that's not an officially supported solution and the systemd developers have said they reserve the right to make changes that break it at any time. (The main reason why they haven't yet is most likely that their attempts to integrate dbus into the kernel and systemd more tightly were rejected by the kernel devs; if I remember rightly that was expected to be the point at which you could not use it without systemd.) Using the kernel interfaces that udev relies on without using udev itself is also unsupported and the developers consider it within their rights to break those as well.

zxzax 5y ago
It has been supported for at least the last 9 years now, I don't see why they would have any reason to break it. >The main reason why they haven't yet is most likely that their attempts to integrate dbus into the kernel and systemd more tightly were rejected by the kernel devs; if I remember rightly that was expected to be the point at which you could not use it without systemd. That seems quite dubious, udev has never depended on dbus, and there really would be no reason for it to ever do that. >Using the kernel interfaces that udev relies on without using udev itself is also unsupported and the developers consider it within their rights to break those as well. This I know is true, the netlink stuff varies really wildly from driver to driver. The alternative would be to put udevd and the other userspace bits into the kernel, which I really doubt anyone wants to do.

Blikkentrekker 5y ago

IT's not my area of expertise, but the eudev page does speak of restoring some functionality that it lacks without systemd running alongside it, as well as removing glibc and GCC specific dependencies. There is probably a reason why even many binary systems adopted eudev instead. — the maintainers often justify this with “problems” with udev but never go into much detail about what that is but the language does keep suggesting that it restored some functionality that is missing if it run sans systemd.

bkor 5y ago
> but the language does keep suggesting that it restored some functionality that is missing if it run sans systemd. People often misunderstand what libsystemd does. See the many reactions here, but also e.g. the response by Devuan around libsystemd. Too often people assume things around systemd, or too heavily rely on incorrect information found via Google. That things are being done this way by a few projects to me isn't enough. Nowadays people did not thoroughly investigate things before they take a decision. See e.g. the various responses in this thread.