3 ms·

It quite clearly says that there's only two modes of operation: the incorrect D-Bus activator, and the communication with systemd's internal D-Bus protocol. Not

It quite clearly says that there's only two modes of operation: the incorrect D-Bus activator, and the communication with systemd's internal D-Bus protocol. Nothing else. That's not "exaggerated systemd butthurt", it's your deliberately obtuse misreading.

tdicola 11y ago
Isn't systemd a daemon manager that solves all the pain of managing daemons though? If you want D-Bus activation and good daemon control then just use systemd as it was designed.
- vezzy-fnord 11y ago
  You don't realize the problem with an essential component like D-Bus properly integrating only one service manager out of dozens instead of being generic, or even better - not having explicitly broken functionality to begin with? (And no, systemd does not solve all the pain. Having to debug dependency loops, stuck job states, journal fragmentation, intertwining of system and service states, etc. isn't much fun for the benefits that I can just as easily get from something intensely more modular and sanely architected like nosh or s6.)
- viraptor 11y ago
  systemd is a daemon manager that works on a limited number of linux (and only linux) systems. Sometimes you can't use systemd, sometimes you just don't want to. Most opensource software tries to be compatible with as much ecosystem as possible so that's not a problem. That doesn't seem to be the case for dbus/systemd. Other systems which solve the same pain: upstart, nosh, daemontools, supervisord, ...
- throafmgm 11y ago
  The post's author writes a systemd-alike daemon manager named 'nosh'. Hence the complaints about the non-systemd behavior. Also note that DBus runs on more than just Linux (BDSs and perhaps OS X or Windows), while systemD only runs on Linux.
geofft 11y ago
There's some temporal disconnect here, which I think is making the two of you talk (angrily) past each other. The D-Bus activation system was written in 2006. So was Upstart. There wasn't a better activator to use at the time on Linux; it was certainly many years before anyone even thought of systemd. This was back when we were actively using hald. And the D-Bus developer had reservations about whether Upstart in fact covered that use case: http://lists.freedesktop.org/archives/dbus/2006-October/006161.html http://lists.freedesktop.org/archives/dbus/2006-October/0061... https://lists.ubuntu.com/archives/upstart-devel/2006-October/000126.html https://lists.ubuntu.com/archives/upstart-devel/2006-October... So it is reasonable that the "incorrect" activator was around. Back then, D-Bus (and hald) was our systemd. Ubuntu added Upstart activation support to D-Bus in 2010, just a few months after systemd v1 was even released: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032295.html https://lists.ubuntu.com/archives/ubuntu-devel/2010-December... So the article has some important omissions of chronology when it claims that "the writers of D-Bus didn't make it capable of talking to any [daemon management subsystems]". I don't think jjoonathan's reading is a misreading at all.
- vezzy-fnord 11y ago
  There wasn't a better activator to use at the time on Linux runit, s6, depinit, initng, minit, eINIT, simpleinit-msb, plain old daemontools with UCSPI, etc. etc. There were plenty. In fact, before Ubuntu wrote Upstart, they were considering adopting initng instead. Gentoo was experimenting with it at the time, but ultimately went on to make OpenRC. Back then, D-Bus (and hald) was our systemd. This statement is absolute nonsense. D-Bus, HALd and systemd are three completely orthogonal and unrelated pieces of software.
  - geofft 11y ago
    Yes, but by and large the most popular activator at the time was `/etc/init.d/foo start`, so either way, you would have had to include generic support for D-Bus to actually work on any of the systems the developers cared about (Fedora and OLPC, most notably). What they have is, essentially, generic support. I can see the argument in the blog post for having the launch helper work with the `service` command, though. Although I'm not sure `service` existed. > D-Bus, HALd and systemd are three completely orthogonal and unrelated pieces of software. They're not unrelated, which is what I'm trying to say if you could just listen and make a cogent response instead of calling other people's statements nonsense without understanding. They are related in the sense that the way that hardware-support services were spawned on common Linux desktops of the 2006 era was through hald. Now, the way that hardware-support services are spawned is through systemd. If they're unrelated, why did hald disappear?

tdicola 11y ago

Isn't systemd a daemon manager that solves all the pain of managing daemons though? If you want D-Bus activation and good daemon control then just use systemd as it was designed.

vezzy-fnord 11y ago
You don't realize the problem with an essential component like D-Bus properly integrating only one service manager out of dozens instead of being generic, or even better - not having explicitly broken functionality to begin with? (And no, systemd does not solve all the pain. Having to debug dependency loops, stuck job states, journal fragmentation, intertwining of system and service states, etc. isn't much fun for the benefits that I can just as easily get from something intensely more modular and sanely architected like nosh or s6.)
viraptor 11y ago
systemd is a daemon manager that works on a limited number of linux (and only linux) systems. Sometimes you can't use systemd, sometimes you just don't want to. Most opensource software tries to be compatible with as much ecosystem as possible so that's not a problem. That doesn't seem to be the case for dbus/systemd. Other systems which solve the same pain: upstart, nosh, daemontools, supervisord, ...
throafmgm 11y ago
The post's author writes a systemd-alike daemon manager named 'nosh'. Hence the complaints about the non-systemd behavior. Also note that DBus runs on more than just Linux (BDSs and perhaps OS X or Windows), while systemD only runs on Linux.

geofft 11y ago

There's some temporal disconnect here, which I think is making the two of you talk (angrily) past each other. The D-Bus activation system was written in 2006. So was Upstart. There wasn't a better activator to use at the time on Linux; it was certainly many years before anyone even thought of systemd. This was back when we were actively using hald. And the D-Bus developer had reservations about whether Upstart in fact covered that use case: http://lists.freedesktop.org/archives/dbus/2006-October/006161.html http://lists.freedesktop.org/archives/dbus/2006-October/0061... https://lists.ubuntu.com/archives/upstart-devel/2006-October/000126.html https://lists.ubuntu.com/archives/upstart-devel/2006-October... So it is reasonable that the "incorrect" activator was around. Back then, D-Bus (and hald) was our systemd. Ubuntu added Upstart activation support to D-Bus in 2010, just a few months after systemd v1 was even released: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032295.html https://lists.ubuntu.com/archives/ubuntu-devel/2010-December... So the article has some important omissions of chronology when it claims that "the writers of D-Bus didn't make it capable of talking to any [daemon management subsystems]". I don't think jjoonathan's reading is a misreading at all.

vezzy-fnord 11y ago
There wasn't a better activator to use at the time on Linux runit, s6, depinit, initng, minit, eINIT, simpleinit-msb, plain old daemontools with UCSPI, etc. etc. There were plenty. In fact, before Ubuntu wrote Upstart, they were considering adopting initng instead. Gentoo was experimenting with it at the time, but ultimately went on to make OpenRC. Back then, D-Bus (and hald) was our systemd. This statement is absolute nonsense. D-Bus, HALd and systemd are three completely orthogonal and unrelated pieces of software.
- geofft 11y ago
  Yes, but by and large the most popular activator at the time was `/etc/init.d/foo start`, so either way, you would have had to include generic support for D-Bus to actually work on any of the systems the developers cared about (Fedora and OLPC, most notably). What they have is, essentially, generic support. I can see the argument in the blog post for having the launch helper work with the `service` command, though. Although I'm not sure `service` existed. > D-Bus, HALd and systemd are three completely orthogonal and unrelated pieces of software. They're not unrelated, which is what I'm trying to say if you could just listen and make a cogent response instead of calling other people's statements nonsense without understanding. They are related in the sense that the way that hardware-support services were spawned on common Linux desktops of the 2006 era was through hald. Now, the way that hardware-support services are spawned is through systemd. If they're unrelated, why did hald disappear?