5 ms·

Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, ye

by weland 11y ago

Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services is a good idea. It's this particular implementation that's problematic, not the principle.

madez 11y ago
In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. Where is the evidence?
- weland 11y ago
  All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
  - EmanueleAina 11y ago
    Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.
    - yellowapple 11y ago
      I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".
      - the_why_of_y 11y ago
        http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01537.html http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01537.html
        yellowapple 11y ago
        That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag, which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature, so go whine to the kernel folks about the thing of theirs that we broke and don't feel like fixing", as if the systemd folks have become one with the Microsoft). Whether or not there are other underlying issues stemming from such misbehavior is irrelevant to the fact that the misbehavior exists. It's like sticking your hand in a fire, then blaming your hand instead of your own stupidity for your third-degree burns.
        EmanueleAina 11y ago
        Honestly I find that a single global "debug" option would have been useful, instead of having to know which component (the kernel, the ramdisk, sysvinit, sysv-rc, systemd, upstart, udev, whatever) is at fault. Unfortunately such mechanism introduced a feedback loop in the presence of a bug in the kernel. I understand that it would be difficult for the kernel to guard from such loops, but my sincere impression is that they threw out the the baby with the bathwater.
        yellowapple 11y ago
        I agree that such a flag would be useful, too, in which case the systemd folks could very well have consulted with the kernel folks in advance to work out a deprecation path for the kernel-only behavior and an introduction path for a generic behavior that activates the respective kernel-specific and systemd-specific flags. The problem is that such collaboration didn't happen, and the systemd folks assumed that they were the center of the universe and decided "well fuck the kernel, we're going to use the 'debug' flag for ourselves, everything else be damned", thus causing breakage and flamewars. Had they taken the 10 seconds to write up an email on LKML or somesuch saying "hey, we think the 'debug' flag should apply to everything, not just the kernel; y'all game?", the vast majority of the fallout would have never existed.
    - weland 11y ago
      If this one isn't satisfying, digi_owl has a nice one, too: https://news.ycombinator.com/item?id=9723476 https://news.ycombinator.com/item?id=9723476
      - EmanueleAina 11y ago
        Never heard about it, is there any link with more details?
        weland 11y ago
        https://bugzilla.redhat.com/show_bug.cgi?id=753882 https://bugzilla.redhat.com/show_bug.cgi?id=753882 Enjoy.
        EmanueleAina 11y ago
        Interesting read, thanks! However I would not characterize that as "Poettering completely misunderstanding a perfectly valid use of su". It seems a quite complex issue about a workflow that is only half-working even without systemd. A systemd patch has been committed that fixes the most blatant error, but of course it doesn't solve all problems since most of them existed before systemd.
        weland 11y ago
        I don't know in what corner of the universe was that "only half-working". It was working absolutely fine. It has been working fine since... I don't know, v7, when it was first introduced.
        EmanueleAina 11y ago
        The few times I tried to run GUI programs through su I always got plenty of warning about DBus and stuff. But I don't do that very often, so that's all I know.
  - the_why_of_y 11y ago
    An excellent example of a failure to communicate. Linus said that the fact that systemd parses the "debug" parameter is not a bug: http://lwn.net/Articles/593677/ http://lwn.net/Articles/593677/ But sadly that didn't stop various Linux developers from bullying the systemd developers in that bug report instead of trying to find some common ground. The actual bugs (assertion failure creating debug output in systemd, and inadequate buffering in Linux's /dev/kmsg) could have been fixed much faster without the pointless flame fest.
    - crznp 11y ago
      Your link supports the assertion that systemd doesn't play well with the community -- Linus goes on to say: It does become a problem when you have a system service developer [Kay] who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
cwyers 11y ago
But I think you could find a vocal minority (or several) to oppose ANY particular implementation. One of the reason the anti-systemd crowd has such a hard time gaining traction is because the only thing that unites all of them is opposition to systemd. They don't agree on what should be in its place instead -- some want to hold onto sysvinit, some want Upstart (although that's a dead end now), some want OpenRC, some want dmd, some want runit, some want something else or something that doesn't even exist yet.
- weland 11y ago
  It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle, even among people who otherwise have very different preferences on what kind of engine they like on their vehicle. Unfortunately, yeah, the whole debate there is unproductive. Instead of focusing on real problems, it gets stuck into an endless debate on Unix philosophy, carried among a bunch of people who aren't really sure why it's a problem if something doesn't follow it and another bunch of people who insist that they're following because saying otherwise would be bad PR.
  - yellowapple 11y ago
    > It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle Speak for yourself. Who cares if my rocket is blanketing Earth in nuclear fallout if I get to ride it to Jupiter? :)
- digi_owl 11y ago
  Here is the thing. The problem is not systemd as init, it is systemd as, well, systemd. The constant addition of daemons and functionality to the overall systemd codebase by either subsuming or replacing existing, INDEPENDENT, projects. As such, who cares what init is used. The thing is that until systemd the other daemons/services started by init didn't particularly care what init it was. Previously you could piecemeal your changes. Didn't like syslog? Grab something else that talk the lingo and slot it into place. Sorry, but journald demands that the init is systemd. Want something to handle seats/sessions? Sorry, but logind only works with systemd as init. Etc etc etc! Going on and on and on about inits is a smokescreen.
digi_owl 11y ago
One lovely example i have seen is Poettering completely misunderstanding a perfectly valid use of su, and instead recommending that people ssh back to their own box if they wanted a shell under a different user. This came up in relation to a systemd set environment variable that would break software by overwriting one user's config files with that of another's. The variable was apparently set that way because of pulseaudio. The really worrying part was any lack of "mea culpa" from Poettering once someone outside the bug report told him that pulseaudio could be changed so that the variable was no longer needed and Poettering implemented that change. Instead he just left the bug report hanging, and others had to report on the changes and declare the issue sorted.

by weland 11y ago

madez 11y ago

In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. Where is the evidence?

weland 11y ago
All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
- EmanueleAina 11y ago
  Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.
  - yellowapple 11y ago
    I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".
    - the_why_of_y 11y ago
      http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01537.html http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01537.html
      - yellowapple 11y ago
        That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag, which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature, so go whine to the kernel folks about the thing of theirs that we broke and don't feel like fixing", as if the systemd folks have become one with the Microsoft). Whether or not there are other underlying issues stemming from such misbehavior is irrelevant to the fact that the misbehavior exists. It's like sticking your hand in a fire, then blaming your hand instead of your own stupidity for your third-degree burns.
        EmanueleAina 11y ago
        Honestly I find that a single global "debug" option would have been useful, instead of having to know which component (the kernel, the ramdisk, sysvinit, sysv-rc, systemd, upstart, udev, whatever) is at fault. Unfortunately such mechanism introduced a feedback loop in the presence of a bug in the kernel. I understand that it would be difficult for the kernel to guard from such loops, but my sincere impression is that they threw out the the baby with the bathwater.
        yellowapple 11y ago
        I agree that such a flag would be useful, too, in which case the systemd folks could very well have consulted with the kernel folks in advance to work out a deprecation path for the kernel-only behavior and an introduction path for a generic behavior that activates the respective kernel-specific and systemd-specific flags. The problem is that such collaboration didn't happen, and the systemd folks assumed that they were the center of the universe and decided "well fuck the kernel, we're going to use the 'debug' flag for ourselves, everything else be damned", thus causing breakage and flamewars. Had they taken the 10 seconds to write up an email on LKML or somesuch saying "hey, we think the 'debug' flag should apply to everything, not just the kernel; y'all game?", the vast majority of the fallout would have never existed.
  - weland 11y ago
    If this one isn't satisfying, digi_owl has a nice one, too: https://news.ycombinator.com/item?id=9723476 https://news.ycombinator.com/item?id=9723476
    - EmanueleAina 11y ago
      Never heard about it, is there any link with more details?
      - weland 11y ago
        https://bugzilla.redhat.com/show_bug.cgi?id=753882 https://bugzilla.redhat.com/show_bug.cgi?id=753882 Enjoy.
        EmanueleAina 11y ago
        Interesting read, thanks! However I would not characterize that as "Poettering completely misunderstanding a perfectly valid use of su". It seems a quite complex issue about a workflow that is only half-working even without systemd. A systemd patch has been committed that fixes the most blatant error, but of course it doesn't solve all problems since most of them existed before systemd.
        weland 11y ago
        I don't know in what corner of the universe was that "only half-working". It was working absolutely fine. It has been working fine since... I don't know, v7, when it was first introduced.
        EmanueleAina 11y ago
        The few times I tried to run GUI programs through su I always got plenty of warning about DBus and stuff. But I don't do that very often, so that's all I know.
- the_why_of_y 11y ago
  An excellent example of a failure to communicate. Linus said that the fact that systemd parses the "debug" parameter is not a bug: http://lwn.net/Articles/593677/ http://lwn.net/Articles/593677/ But sadly that didn't stop various Linux developers from bullying the systemd developers in that bug report instead of trying to find some common ground. The actual bugs (assertion failure creating debug output in systemd, and inadequate buffering in Linux's /dev/kmsg) could have been fixed much faster without the pointless flame fest.
  - crznp 11y ago
    Your link supports the assertion that systemd doesn't play well with the community -- Linus goes on to say: It does become a problem when you have a system service developer [Kay] who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.

cwyers 11y ago

But I think you could find a vocal minority (or several) to oppose ANY particular implementation. One of the reason the anti-systemd crowd has such a hard time gaining traction is because the only thing that unites all of them is opposition to systemd. They don't agree on what should be in its place instead -- some want to hold onto sysvinit, some want Upstart (although that's a dead end now), some want OpenRC, some want dmd, some want runit, some want something else or something that doesn't even exist yet.

weland 11y ago
It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle, even among people who otherwise have very different preferences on what kind of engine they like on their vehicle. Unfortunately, yeah, the whole debate there is unproductive. Instead of focusing on real problems, it gets stuck into an endless debate on Unix philosophy, carried among a bunch of people who aren't really sure why it's a problem if something doesn't follow it and another bunch of people who insist that they're following because saying otherwise would be bad PR.
- yellowapple 11y ago
  > It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle Speak for yourself. Who cares if my rocket is blanketing Earth in nuclear fallout if I get to ride it to Jupiter? :)
digi_owl 11y ago
Here is the thing. The problem is not systemd as init, it is systemd as, well, systemd. The constant addition of daemons and functionality to the overall systemd codebase by either subsuming or replacing existing, INDEPENDENT, projects. As such, who cares what init is used. The thing is that until systemd the other daemons/services started by init didn't particularly care what init it was. Previously you could piecemeal your changes. Didn't like syslog? Grab something else that talk the lingo and slot it into place. Sorry, but journald demands that the init is systemd. Want something to handle seats/sessions? Sorry, but logind only works with systemd as init. Etc etc etc! Going on and on and on about inits is a smokescreen.

digi_owl 11y ago

One lovely example i have seen is Poettering completely misunderstanding a perfectly valid use of su, and instead recommending that people ssh back to their own box if they wanted a shell under a different user. This came up in relation to a systemd set environment variable that would break software by overwriting one user's config files with that of another's. The variable was apparently set that way because of pulseaudio. The really worrying part was any lack of "mea culpa" from Poettering once someone outside the bug report told him that pulseaudio could be changed so that the variable was no longer needed and Poettering implemented that change. Instead he just left the bug report hanging, and others had to report on the changes and declare the issue sorted.