6 ms·

that looks so much cleaner than init.d scripts. I have heard some people refer to systemd as not very linux-esque - can someone comment on what that might mean

that looks so much cleaner than init.d scripts. I have heard some people refer to systemd as not very linux-esque - can someone comment on what that might mean?

bitJericho 12y ago
http://boycottsystemd.org/ http://boycottsystemd.org/
- netcraft 12y ago
  >...an abhorrent and violent slap in the face to the Unix philosophy... I can't imagine why this didn't get more traction.
  - jrslack 12y ago
    >Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well. And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true. >In fact, udev merged with systemd a long time ago systemd relies on udev and dbus, but udev doesn't pull in systemd as a hard dependency: another falsehood I've seen parroted by those in support of the eudev fork.
    - vezzy-fnord 12y ago
      Optional, but enabled by default. Most distros seem to ship with defaults and only customize flags related to library paths and FHS details (besides whatever patching they may apply). The fact that it's even there is distressing enough, really. No one is saying udev pulls in systemd as a dependency. Where is that said?
      - jrslack 12y ago
        >Optional, but enabled by default Where is it enabled by default? In what distro does gatewayd get pulled in by default? >No one is saying udev pulls in systemd as a dependency. By the eudev hobbyists, whose justification for their fork was largely "we don't want to force people to use systemd" and "no, we didn't contact upstream with fixes before we forked" in their presentation.
    - jfindley 12y ago
      I'd be very interested to see a qualified crypto expert on the "sealing" that journald uses. This is one of two indicators of a troubling level of arrogance from the developers. The crypto method used by journald to verify messages haven't been tampered with is called Forward Secure Sealing [0]. It's based on an invention of the brother of Lennart - the lead developer, and for a long time after first release even the whitepaper describing it in detail was "coming soon" The code he finally produced is [1] - but rather light on documentation. I'm still unaware of any proper analysis of this, and using your brothers own crypto methods and ignoring all the questions this has raised does not come across well - and appears to seriously violate the "don't roll your own crypto system" rule. The second indicator is the attitude to bugs, of which [2] is a good example - several of the developers appear to be extremely defensive towards any suggestion of defects in their software, and simply close bugs blaming the users, other software, anything else. I'd be hopeful that RedHat manage to reign this behavior in, but that didn't seem to work for Ulrich Drepper when he was employed by RedHat to work on glibc, and I'm not sure if it's going to work here. That said - I'm not in the "systemd is awful" camp - I do think there's a whole bunch of things it does really well, and that a lot of the hate is really quite reactionary - but the thing that frustrates me is that between the haters and the supporters, there are important questions that are getting lost in the noise. [0]: http://lwn.net/Articles/512895/ http://lwn.net/Articles/512895/ [1]: https://github.com/mezcalero/fsprg https://github.com/mezcalero/fsprg [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
      - JetSpiegel 12y ago
        From your [2]: Like for the kernel, there are options to fin-grain control systemd's logging behaviour; just do not use the generic term "debug" which is a convenience shortcut for the kernel AND the Base OS. [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
      - xorcist 12y ago
        Relevant work in the area is Log Hash Chaining as described in RFC 5848, which at least has been through some peer review. I don't know why they chose to ignore that, let alone what their design is really supposed to guard against. Their design allows an attacker a window of 15 minutes where they can rewrite the log at will. So the short of it is: Keep using remote logging. Authenticate that. Don't rely on journald. (I too have had Drepper vibes about the whole situation for quite some time. But a new init standard was long overdue and if distros can finally rally around systemd it might be worth it.)
  - beedogs 12y ago
    Why do people use words like "violent" to describe the decision to change process launchers? Maybe if they'd toned down the rhetoric just a tiny bit that campaign might've worked better.
vezzy-fnord 12y ago
Linux did kind of get the short end of the stick with System V initialization. BSD rc scripts are also written in shell, but much cleaner (particularly when you make use of rcorder(8) dependencies). systemd's declarative unit file syntax is easier to reason with, but comes at the expense of having to memorize a ton of options and being fundamentally dependent on the toolbox provided to you by systemd, since you can't code your way out of unconventional corner cases as easily. The unit file syntax isn't the reason people complain, though.
- jerven 12y ago
  Of course your systemd startup can start a sh script at ease. I think systemd is going to make my life so much easier. Being more on the dev side of devops, but still needing to deploy correctly restarting aps depending on complex systems working. i.e. NFS mounts being available for data etc...
- SEJeff 12y ago
  FWIW, systemd can also call scripts under /etc/init.d if that is really what floats your boat. It is fully backwards compatible, you just lose a lot of the flexibility of systemd when doing that. The redis-server package in RHEL7 (from EPEL) installs an init script and I know that systemctl starts it.
- mprovost 12y ago
  Slackware has always used BSD init scripts and it's one of the oldest distros. You used to be able to choose any init system you wanted but it seems that systemd is becoming entwined with "Linux" in some nasty ways. I wonder how long Slackware (or any other distro) will be able to avoid using it since software like Gnome is starting to require it.
mackal 12y ago
1) Lennart Poettering 2) MAH FREEDOMS! There are technical reasons people don't like systemd that are valid, but usually the die hard anti-systemd people boil down to hating Lennart Poettering and complaining about how the US Constitution must some where say they never have to use systemd. There are some valid concerns (big scope, bloat, feature creep, etc) but they really haven't come to fruition, although are still valid concerns. At the end of the day, without much effort or trouble of switching to systemd from OpenRC, my system boots faster, which is great.
- Torgo 12y ago
  Does "years of fucking with PulseAudio problems" count as its own item, or is that a subset of item 1?
  - mackal 12y ago
    I've never had issues with PulseAudio personally.
    - makomk 12y ago
      It depends what sound hardware and software you use, what the memory layout of the PulseAudio daemon happens to end up like on your system, your tolerance for audio glitches, and how long you go between reboots. The code quality's awful but if you're lucky you can miss out on the worst of the issues.
      - mackal 12y ago
        Haven't had issues across multiple systems, even back when it first came out.
      - e12e 12y ago
        I can at least vouch for 1) drivers (arguably this is an alsa thing, but pulseaudio had a way of exposing problems), and 2) your tolerance not just for glitches, but also latency (in the form of buffers) and overall sound quality. I suspect, based on how few people seem to be upset about pulse audio (as opposed to what one might expect) that some subset of popular sound hw worked rather well. It's just not a subset I ever owned.
keeperofdakeys 12y ago
Systemd isn't just replacing the init process and service manager, it encompasses many other boot and session related features. As an example, Gnome now uses parts of systemd for session management (replacing consoleskit, and others). While there are workarounds, this means no one can really use any other init system besides systemd, or things won't work correctly. This is what many people view un-unix like, a big dependency, that can't be replaced in the chain. The systemd developers also develop udev (which actually builds out of the same source tree as systemd), and there have been a few arguments about whether certain responsibilities are that of the kernel, or udev/userspace http://lwn.net/Articles/518942/ http://lwn.net/Articles/518942/, http://lwn.net/Articles/593676/ http://lwn.net/Articles/593676/. Systemd also touts its cgroup usage, though they view that they should be the only user of cgroups, since they are in a spot to "manage things properly" (which is partially true). (Some services have also started relying on systemd's cgroups to clean up orphan processes, which is bad for other init systems that don't do this). So no one really hates how systemd works, just how its managed, and what it aims to do. If it were a simple init system and service manager, there would probably have been no arguments.
- jrslack 12y ago
  >though they view that they should be the only user of cgroups And they're absolutely correct. There can only be one cgroups manager on the system. cgmanager isn't finished, either. >As an example, Gnome now uses parts of systemd for session management (replacing consoleskit, and others). While there are workarounds, this means no one can really use any other init system besides systemd, or things won't work correctly. Gnome requires logind, which is the successor to consolekit. Gnome has repeatedly stated that they're willing to work with the BSDs et al with workarounds. You can either use the old logind, which doesn't require systemd as PID1 (due to cgroups management changes) or you can develop your own replacement to logind, one that doesn't require systemd as PID1. People criticize these decisions, but they have no suggestions on how to fix it and, for the most part, they have no inkling of why there's a requirement.

that looks so much cleaner than init.d scripts. I have heard some people refer to systemd as not very linux-esque - can someone comment on what that might mean?

bitJericho 12y ago

http://boycottsystemd.org/ http://boycottsystemd.org/

netcraft 12y ago
>...an abhorrent and violent slap in the face to the Unix philosophy... I can't imagine why this didn't get more traction.
- jrslack 12y ago
  >Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well. And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true. >In fact, udev merged with systemd a long time ago systemd relies on udev and dbus, but udev doesn't pull in systemd as a hard dependency: another falsehood I've seen parroted by those in support of the eudev fork.
  - vezzy-fnord 12y ago
    Optional, but enabled by default. Most distros seem to ship with defaults and only customize flags related to library paths and FHS details (besides whatever patching they may apply). The fact that it's even there is distressing enough, really. No one is saying udev pulls in systemd as a dependency. Where is that said?
    - jrslack 12y ago
      >Optional, but enabled by default Where is it enabled by default? In what distro does gatewayd get pulled in by default? >No one is saying udev pulls in systemd as a dependency. By the eudev hobbyists, whose justification for their fork was largely "we don't want to force people to use systemd" and "no, we didn't contact upstream with fixes before we forked" in their presentation.
  - jfindley 12y ago
    I'd be very interested to see a qualified crypto expert on the "sealing" that journald uses. This is one of two indicators of a troubling level of arrogance from the developers. The crypto method used by journald to verify messages haven't been tampered with is called Forward Secure Sealing [0]. It's based on an invention of the brother of Lennart - the lead developer, and for a long time after first release even the whitepaper describing it in detail was "coming soon" The code he finally produced is [1] - but rather light on documentation. I'm still unaware of any proper analysis of this, and using your brothers own crypto methods and ignoring all the questions this has raised does not come across well - and appears to seriously violate the "don't roll your own crypto system" rule. The second indicator is the attitude to bugs, of which [2] is a good example - several of the developers appear to be extremely defensive towards any suggestion of defects in their software, and simply close bugs blaming the users, other software, anything else. I'd be hopeful that RedHat manage to reign this behavior in, but that didn't seem to work for Ulrich Drepper when he was employed by RedHat to work on glibc, and I'm not sure if it's going to work here. That said - I'm not in the "systemd is awful" camp - I do think there's a whole bunch of things it does really well, and that a lot of the hate is really quite reactionary - but the thing that frustrates me is that between the haters and the supporters, there are important questions that are getting lost in the noise. [0]: http://lwn.net/Articles/512895/ http://lwn.net/Articles/512895/ [1]: https://github.com/mezcalero/fsprg https://github.com/mezcalero/fsprg [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
    - JetSpiegel 12y ago
      From your [2]: Like for the kernel, there are options to fin-grain control systemd's logging behaviour; just do not use the generic term "debug" which is a convenience shortcut for the kernel AND the Base OS. [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935
    - xorcist 12y ago
      Relevant work in the area is Log Hash Chaining as described in RFC 5848, which at least has been through some peer review. I don't know why they chose to ignore that, let alone what their design is really supposed to guard against. Their design allows an attacker a window of 15 minutes where they can rewrite the log at will. So the short of it is: Keep using remote logging. Authenticate that. Don't rely on journald. (I too have had Drepper vibes about the whole situation for quite some time. But a new init standard was long overdue and if distros can finally rally around systemd it might be worth it.)
- beedogs 12y ago
  Why do people use words like "violent" to describe the decision to change process launchers? Maybe if they'd toned down the rhetoric just a tiny bit that campaign might've worked better.

vezzy-fnord 12y ago

Linux did kind of get the short end of the stick with System V initialization. BSD rc scripts are also written in shell, but much cleaner (particularly when you make use of rcorder(8) dependencies). systemd's declarative unit file syntax is easier to reason with, but comes at the expense of having to memorize a ton of options and being fundamentally dependent on the toolbox provided to you by systemd, since you can't code your way out of unconventional corner cases as easily. The unit file syntax isn't the reason people complain, though.

jerven 12y ago
Of course your systemd startup can start a sh script at ease. I think systemd is going to make my life so much easier. Being more on the dev side of devops, but still needing to deploy correctly restarting aps depending on complex systems working. i.e. NFS mounts being available for data etc...
SEJeff 12y ago
FWIW, systemd can also call scripts under /etc/init.d if that is really what floats your boat. It is fully backwards compatible, you just lose a lot of the flexibility of systemd when doing that. The redis-server package in RHEL7 (from EPEL) installs an init script and I know that systemctl starts it.
mprovost 12y ago
Slackware has always used BSD init scripts and it's one of the oldest distros. You used to be able to choose any init system you wanted but it seems that systemd is becoming entwined with "Linux" in some nasty ways. I wonder how long Slackware (or any other distro) will be able to avoid using it since software like Gnome is starting to require it.

mackal 12y ago

1) Lennart Poettering 2) MAH FREEDOMS! There are technical reasons people don't like systemd that are valid, but usually the die hard anti-systemd people boil down to hating Lennart Poettering and complaining about how the US Constitution must some where say they never have to use systemd. There are some valid concerns (big scope, bloat, feature creep, etc) but they really haven't come to fruition, although are still valid concerns. At the end of the day, without much effort or trouble of switching to systemd from OpenRC, my system boots faster, which is great.

Torgo 12y ago
Does "years of fucking with PulseAudio problems" count as its own item, or is that a subset of item 1?
- mackal 12y ago
  I've never had issues with PulseAudio personally.
  - makomk 12y ago
    It depends what sound hardware and software you use, what the memory layout of the PulseAudio daemon happens to end up like on your system, your tolerance for audio glitches, and how long you go between reboots. The code quality's awful but if you're lucky you can miss out on the worst of the issues.
    - mackal 12y ago
      Haven't had issues across multiple systems, even back when it first came out.
    - e12e 12y ago
      I can at least vouch for 1) drivers (arguably this is an alsa thing, but pulseaudio had a way of exposing problems), and 2) your tolerance not just for glitches, but also latency (in the form of buffers) and overall sound quality. I suspect, based on how few people seem to be upset about pulse audio (as opposed to what one might expect) that some subset of popular sound hw worked rather well. It's just not a subset I ever owned.

keeperofdakeys 12y ago

Systemd isn't just replacing the init process and service manager, it encompasses many other boot and session related features. As an example, Gnome now uses parts of systemd for session management (replacing consoleskit, and others). While there are workarounds, this means no one can really use any other init system besides systemd, or things won't work correctly. This is what many people view un-unix like, a big dependency, that can't be replaced in the chain. The systemd developers also develop udev (which actually builds out of the same source tree as systemd), and there have been a few arguments about whether certain responsibilities are that of the kernel, or udev/userspace http://lwn.net/Articles/518942/ http://lwn.net/Articles/518942/, http://lwn.net/Articles/593676/ http://lwn.net/Articles/593676/. Systemd also touts its cgroup usage, though they view that they should be the only user of cgroups, since they are in a spot to "manage things properly" (which is partially true). (Some services have also started relying on systemd's cgroups to clean up orphan processes, which is bad for other init systems that don't do this). So no one really hates how systemd works, just how its managed, and what it aims to do. If it were a simple init system and service manager, there would probably have been no arguments.

jrslack 12y ago
>though they view that they should be the only user of cgroups And they're absolutely correct. There can only be one cgroups manager on the system. cgmanager isn't finished, either. >As an example, Gnome now uses parts of systemd for session management (replacing consoleskit, and others). While there are workarounds, this means no one can really use any other init system besides systemd, or things won't work correctly. Gnome requires logind, which is the successor to consolekit. Gnome has repeatedly stated that they're willing to work with the BSDs et al with workarounds. You can either use the old logind, which doesn't require systemd as PID1 (due to cgroups management changes) or you can develop your own replacement to logind, one that doesn't require systemd as PID1. People criticize these decisions, but they have no suggestions on how to fix it and, for the most part, they have no inkling of why there's a requirement.