4 ms·

I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. One of the things this post criticizes, and Poett

I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. One of the things this post criticizes, and Poettering criticizes, is the BSD-inherited daemon() function. Being curious, I looked at the function's implementation, both in FreeBSD's implementation, and glibc's implementation. FreeBSD's implementation handles pretty much everything the daemon writer themself would want to -- it sets the signal handlers and masks appropriately, double forks, creates a session, sets PIDs unless you tell it not to, and changes to the root directory unless you tell it not to. Glibc's misses important steps, like the signal manipulations, tries too hard to create a typical null device, and otherwise completely misses the point. The biggest problem I see with system is that the developers don't play well with others. Instead of working with various parties, like the glibc maintainers, to fix deficiencies elsewhere, they expect developers everywhere to drop what they're doing to redesign how their projects work, when they work just fine for the many, many other unix architectures out there. Too much of systemd is based on magical pixie dust, compatibility be damned, and not enough on actually making things better.

m45t3r 12y ago
Well, the problem is, you only changed the problem. Now instead of depending of a specific init system, you're depending of a specific implementation of daemon() function (which I imagine is not really standard, since if it was glibc would implement it correctly). Maybe you could create daemon_correctly() function that was guarantee to implement daemon as it should, but you would incur the risk of having the case of strlcpy() again (glibc didn't added this function since the maintainer said it was messy and bloated, so almost no software used it). And anyway, correctly daemonizing is only part of what systemd got right. I think the fact that you don't need to track services with random programs anymore (since systemd knows each and every process parent thanks to cgroups) is something much more interesting than just getting daemon() right.
cbsmith 12y ago
> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism. Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.
- makomk 12y ago
  The systemd developers are planning on replacing dbus with their own NIH reimplementation, kdbus, soon - complete with its own serialisation format, its own in-kernel IPC framework, and a hard dependency on systemd. (Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.[1] That library currently supports old-style dbus but they're planning to drop support for that, at which point every dbus-using application will require systemd to function. They're also planning to make udev dependent on kdbus[2] in a way that can't be worked around by forking or using old versions, since apps will use the kdbus API to call it directly[3] ) [1] http://lists.freedesktop.org/pipermail/dbus/2013-July/015726.html http://lists.freedesktop.org/pipermail/dbus/2013-July/015726... [2] http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... [3] http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html http://lists.freedesktop.org/archives/systemd-devel/2014-May...
  - andor 12y ago
    Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too. Have you actually read the mail you're giving as "evidence"? The last paragraph begins with: "The current idea is that systemd will provide a bridge service, that offers the current D-Bus socket, and an unmodified libdbus (or an alternative implementation) can talk to that socket like it talks today to the dbus-daemon." Edit: kdbus is also not a NIH-implementation, in any meaning of the word. It was "invented there", and it also fixes things: it will have much lower latency and overhead than the current userspace D-Bus. http://kroah.com/log/blog/2014/01/15/kdbus-details/ http://kroah.com/log/blog/2014/01/15/kdbus-details/
    - makomk 12y ago
      Okay, correction/clarification: it requires everyone to rewrite their code if they want to use kdbus rather than doing old-style dbus calls to the compatibility daemon, which may not be installed by default and is a fairly ugly hack that's probably going away in the future. It needs a bunch of special support code in systemd that's not used for anything else, and the generall expectation seems to be it's a stopgap and most or all dbus consumers will move to kdbus. Also, technically developers don't have to use systemd's dbus library; apparently Gnome's doing direct calls to the kdbus kernel API instead. That makes it even harder to support systems that don't have kdbus+systemd, of course, but this is Gnome we're talking about.

m45t3r 12y ago

Well, the problem is, you only changed the problem. Now instead of depending of a specific init system, you're depending of a specific implementation of daemon() function (which I imagine is not really standard, since if it was glibc would implement it correctly). Maybe you could create daemon_correctly() function that was guarantee to implement daemon as it should, but you would incur the risk of having the case of strlcpy() again (glibc didn't added this function since the maintainer said it was messy and bloated, so almost no software used it). And anyway, correctly daemonizing is only part of what systemd got right. I think the fact that you don't need to track services with random programs anymore (since systemd knows each and every process parent thanks to cgroups) is something much more interesting than just getting daemon() right.

cbsmith 12y ago

> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism. Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.

makomk 12y ago
The systemd developers are planning on replacing dbus with their own NIH reimplementation, kdbus, soon - complete with its own serialisation format, its own in-kernel IPC framework, and a hard dependency on systemd. (Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.[1] That library currently supports old-style dbus but they're planning to drop support for that, at which point every dbus-using application will require systemd to function. They're also planning to make udev dependent on kdbus[2] in a way that can't be worked around by forking or using old versions, since apps will use the kdbus API to call it directly[3] ) [1] http://lists.freedesktop.org/pipermail/dbus/2013-July/015726.html http://lists.freedesktop.org/pipermail/dbus/2013-July/015726... [2] http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... [3] http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html http://lists.freedesktop.org/archives/systemd-devel/2014-May...
- andor 12y ago
  Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too. Have you actually read the mail you're giving as "evidence"? The last paragraph begins with: "The current idea is that systemd will provide a bridge service, that offers the current D-Bus socket, and an unmodified libdbus (or an alternative implementation) can talk to that socket like it talks today to the dbus-daemon." Edit: kdbus is also not a NIH-implementation, in any meaning of the word. It was "invented there", and it also fixes things: it will have much lower latency and overhead than the current userspace D-Bus. http://kroah.com/log/blog/2014/01/15/kdbus-details/ http://kroah.com/log/blog/2014/01/15/kdbus-details/
  - makomk 12y ago
    Okay, correction/clarification: it requires everyone to rewrite their code if they want to use kdbus rather than doing old-style dbus calls to the compatibility daemon, which may not be installed by default and is a fairly ugly hack that's probably going away in the future. It needs a bunch of special support code in systemd that's not used for anything else, and the generall expectation seems to be it's a stopgap and most or all dbus consumers will move to kdbus. Also, technically developers don't have to use systemd's dbus library; apparently Gnome's doing direct calls to the kdbus kernel API instead. That makes it even harder to support systems that don't have kdbus+systemd, of course, but this is Gnome we're talking about.