4 ms·

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. et

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?
- vezzy-fnord 11y ago
  You claimed there was no other, not which one was most popular. '/etc/init.d/foo start' was an LSB-standardized initscript convention, yes. Why do you even call that an "activator" in this context? No, that is not the definition of generic support. Generic support would be having some way to intercept system bus events so that external programs can implement on-demand bus activation. 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. Correct. Now, the way that hardware-support services are spawned is through systemd. Incorrect. udisks2 and upower are the official successors to HALd. Otherwise, udev usurped many of the hotplugging capabilities. udev has existed way before systemd merged it into systemd-udevd. If they're unrelated, why did hald disappear? Because of DeviceKit (udisks/upower) and udev evolving and HALd becoming an unmaintainable mess, by David Zeuthen's own words: http://lists.freedesktop.org/archives/hal/2008-May/011560.html http://lists.freedesktop.org/archives/hal/2008-May/011560.ht... I'm calling your statements nonsense because they clearly are.
  - geofft 11y ago
    > You claimed there was no other, not which one was most popular. I said there was no better one. That's very different. Absolutely they could have written daemontools or anything else activation; there was just no major or even semi-major distro that used daemontools, so there was no point. > by David Zeuthen's own words Which contain this: "Apart from all that, I still believe the _idea_ of having privileged mechanisms exporting useful API is the right one if one wants to make progress on the Linux desktop. And certainly, just the last year with the introduction of ConsoleKit, PolicyKit and D-Bus system bus activation shows there's a real trend going in this direction." That's exactly why I said they're related. They're not the same thing, obviously. But the growth of things like D-Bus system bus activation enabled the various kits, enabled UDisks (which is bus-activated), etc.
    - vezzy-fnord 11y ago
      There were better ones. All of the examples I listed were improvements over sysvinit. Again, it's not explicitly supporting one scheme over another. It's more like provide a generic event queue over some channel (stream, Netlink, etc.) for processes to consume and be able to exec(3) processes in response to received events. Much like how udev consumes kernel uevents. Yes, D-Bus system bus activation assisted in lots of desktop subsystems. Your statement that "D-Bus and hald was our systemd" doesn't make any modicum of sense, nevertheless, and is simply conceptually confused. You're really painting broad strokes and taking liberties with the way you categorize things. I don't like poisoning semantics, it's a very dirty game. (As a side note, an "activator" is any program that conditionally exec(3)s a binary in response to an IPC event. Something as simple as "mkfifo /path/to/pipe && sh -c 'while true; do cat /path/to/pipe >/dev/null; /path/to/program; done' &" is an activator. It's not rocket science.)

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?

vezzy-fnord 11y ago
You claimed there was no other, not which one was most popular. '/etc/init.d/foo start' was an LSB-standardized initscript convention, yes. Why do you even call that an "activator" in this context? No, that is not the definition of generic support. Generic support would be having some way to intercept system bus events so that external programs can implement on-demand bus activation. 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. Correct. Now, the way that hardware-support services are spawned is through systemd. Incorrect. udisks2 and upower are the official successors to HALd. Otherwise, udev usurped many of the hotplugging capabilities. udev has existed way before systemd merged it into systemd-udevd. If they're unrelated, why did hald disappear? Because of DeviceKit (udisks/upower) and udev evolving and HALd becoming an unmaintainable mess, by David Zeuthen's own words: http://lists.freedesktop.org/archives/hal/2008-May/011560.html http://lists.freedesktop.org/archives/hal/2008-May/011560.ht... I'm calling your statements nonsense because they clearly are.
- geofft 11y ago
  > You claimed there was no other, not which one was most popular. I said there was no better one. That's very different. Absolutely they could have written daemontools or anything else activation; there was just no major or even semi-major distro that used daemontools, so there was no point. > by David Zeuthen's own words Which contain this: "Apart from all that, I still believe the _idea_ of having privileged mechanisms exporting useful API is the right one if one wants to make progress on the Linux desktop. And certainly, just the last year with the introduction of ConsoleKit, PolicyKit and D-Bus system bus activation shows there's a real trend going in this direction." That's exactly why I said they're related. They're not the same thing, obviously. But the growth of things like D-Bus system bus activation enabled the various kits, enabled UDisks (which is bus-activated), etc.
  - vezzy-fnord 11y ago
    There were better ones. All of the examples I listed were improvements over sysvinit. Again, it's not explicitly supporting one scheme over another. It's more like provide a generic event queue over some channel (stream, Netlink, etc.) for processes to consume and be able to exec(3) processes in response to received events. Much like how udev consumes kernel uevents. Yes, D-Bus system bus activation assisted in lots of desktop subsystems. Your statement that "D-Bus and hald was our systemd" doesn't make any modicum of sense, nevertheless, and is simply conceptually confused. You're really painting broad strokes and taking liberties with the way you categorize things. I don't like poisoning semantics, it's a very dirty game. (As a side note, an "activator" is any program that conditionally exec(3)s a binary in response to an IPC event. Something as simple as "mkfifo /path/to/pipe && sh -c 'while true; do cat /path/to/pipe >/dev/null; /path/to/program; done' &" is an activator. It's not rocket science.)