6 ms·

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's

by krylon 10y ago

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion. But having used a couple of Linux systems running systemd - Raspian Jessie and openSUSE - I have to admit it's not that bad. In practice - on laptops and desktop systems (assuming one counts the Pi as a desktop system; for my use case, I do) - I had no problems with it. Enabling and disabling services is a lot easier. I do not think is as great as its proponents claim, but it's not as bad as some people think, either. Personally, I have come to appreciate journald, even though I still agree that binary logs are a bad idea. At least there is still the option of installing a syslog daemon.

digi_owl 10y ago
Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code. Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.
- noinsight 10y ago
  > a big wadded up ball of code. To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.
  - digi_owl 10y ago
    Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.
    - krylon 10y ago
      OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.
      - d33 10y ago
        It's not only about whether you do it, it's also about HOW you do it. I once saw a slide from FOSDEM which listed lots of CLI tools that systemd replaced. Some of them seemed quite trivial and if they all depend on low-level systemd, I believe it really is bad design.
      - JdeBP 10y ago
        Is there any chance -- any chance at all -- that we cannot do the same dance of ineptly-phrased-objection followed by rebuttal-that-misses-the-point when it comes to this particular facet of the discussion? Both sides of this are wrong. The people complaining about "monolithic" are groping in the dark for ideas such as low coupling. The people saying "but count the binaries!" are not addressing the questions of fully documented interfaces between said binaries, composability, and interoperability. The "uselessd guy" explained this quite well, as have many other people. Can you please advance to not dancing this same old dance every time? * https://news.ycombinator.com/item?id=12879771 https://news.ycombinator.com/item?id=12879771 * https://news.ycombinator.com/item?id=12652071 https://news.ycombinator.com/item?id=12652071 * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
      - wott 10y ago
        But this tends towards Windows model, not a form of UNIX-like model. If I wanted a Windows-like, I'd use a Windows.
    - scrollaway 10y ago
      It's kind of annoying reading people lecturing projects they clearly don't know the internals of on how much better their code would be if they did X. This applies not just to your comment here but to a ton of comments that pop up on HN all the time. Why not in Go? Why not in Rust? Why not in React and node and electron and why don't you use my library that's still in alpha? It's not OOP. You're not using tabs. MIT is too permissive. GPL is too restrictive. And obviously, this should be a set of tiny separate libraries, how dare you work on free software with different ideas than mine. I once found a project called Razor-qt. It was a desktop environment that included a bunch of interdependant binaries all under the same repo. I didn't like that very much. I joined it, worked on it, ended up leading the project and merging it with LXDE into LXQt. When came the time for the reorganization, I did push to create tiny components that "could be downloaded piecemeal and compiled independently". And we did end up going that route. You know what I didn't do? I didn't go on HN and complain about a project I didn't know the internals of at the time. But hey, maybe you know better. ¯\_(ツ)_/¯
pmlnr 10y ago
> I had no problems with it. You're lucky. For me, systemd randomly fails to execute a reboot, then, because of this, fails to do halt, and I have to force power off the machine. And this is just one.
- digi_owl 10y ago
  Freedesktop, recreating Windows one project at a time...
danieldk 10y ago
I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure. I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time. The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems. [1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/ https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-2...
- rkangel 10y ago
  > The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems. This is a reasonable criticism of systemd. The other points seem mostly to be a criticisum of the various distro implementations that use systemd. The sort of thing that gets tidied up over time anyway.
  - throw2016 10y ago
    The bigger question is whether an init should be a continuously developed project with rapidly increasing scope as now various distributions are on differing versions of systemd with widely varying compatibility and feature sets.
- pawadu 10y ago
  I think systemd would benefit from a slower adaptation. The network and boot issues that practically everyone have encountered are mostly due to incorrect default configurations. This shows that the maintainers are not ready to use systemd as they don't yet fully understand it.
tyfon 10y ago
I'm a bit more on the positive side. I actually really like systemd. When it was first introduced I spent 10-15 minutes learning how it operated and after that it has been so much better than the old init systems. And the best part is that it's on all the major distros so I don't have to keep relearning the init system if I try something new. My guess has been that the majority of users enjoy it and a few very vocal opponents have such hate for anything new that they will latch on to every small bug as if it's the worlds end. (Anecdotally, this is the first time I have written a comment about systemd as other discussions have been non-productive flame fests without substance).
- 1_2__3 10y ago
  If your effort to learn how systemd functions took you ten minutes it's unlikely you're involved enough in the internals of it to understand the debate.
bitwize 10y ago
> The way it was pushed on distros was problematic, in my opinion. The technical term for this is "precommitment", and it comes from Tom Schelling. It's actually quite advantageous: once you're precommitted to a particular direction, you're emotionally invested in getting the most out of it. By precommitting you to systemd, the distros hope to get the community to leverage systemd's benefits.
- digi_owl 10y ago
  Sounds like a restatement of Thatcher's TINA (There Is No Alternative)...

by krylon 10y ago

digi_owl 10y ago

Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code. Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.

noinsight 10y ago
> a big wadded up ball of code. To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.
- digi_owl 10y ago
  Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.
  - krylon 10y ago
    OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.
    - d33 10y ago
      It's not only about whether you do it, it's also about HOW you do it. I once saw a slide from FOSDEM which listed lots of CLI tools that systemd replaced. Some of them seemed quite trivial and if they all depend on low-level systemd, I believe it really is bad design.
    - JdeBP 10y ago
      Is there any chance -- any chance at all -- that we cannot do the same dance of ineptly-phrased-objection followed by rebuttal-that-misses-the-point when it comes to this particular facet of the discussion? Both sides of this are wrong. The people complaining about "monolithic" are groping in the dark for ideas such as low coupling. The people saying "but count the binaries!" are not addressing the questions of fully documented interfaces between said binaries, composability, and interoperability. The "uselessd guy" explained this quite well, as have many other people. Can you please advance to not dancing this same old dance every time? * https://news.ycombinator.com/item?id=12879771 https://news.ycombinator.com/item?id=12879771 * https://news.ycombinator.com/item?id=12652071 https://news.ycombinator.com/item?id=12652071 * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
    - wott 10y ago
      But this tends towards Windows model, not a form of UNIX-like model. If I wanted a Windows-like, I'd use a Windows.
  - scrollaway 10y ago
    It's kind of annoying reading people lecturing projects they clearly don't know the internals of on how much better their code would be if they did X. This applies not just to your comment here but to a ton of comments that pop up on HN all the time. Why not in Go? Why not in Rust? Why not in React and node and electron and why don't you use my library that's still in alpha? It's not OOP. You're not using tabs. MIT is too permissive. GPL is too restrictive. And obviously, this should be a set of tiny separate libraries, how dare you work on free software with different ideas than mine. I once found a project called Razor-qt. It was a desktop environment that included a bunch of interdependant binaries all under the same repo. I didn't like that very much. I joined it, worked on it, ended up leading the project and merging it with LXDE into LXQt. When came the time for the reorganization, I did push to create tiny components that "could be downloaded piecemeal and compiled independently". And we did end up going that route. You know what I didn't do? I didn't go on HN and complain about a project I didn't know the internals of at the time. But hey, maybe you know better. ¯\_(ツ)_/¯

pmlnr 10y ago

> I had no problems with it. You're lucky. For me, systemd randomly fails to execute a reboot, then, because of this, fails to do halt, and I have to force power off the machine. And this is just one.

digi_owl 10y ago
Freedesktop, recreating Windows one project at a time...

danieldk 10y ago

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure. I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time. The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems. [1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/ https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-2...

rkangel 10y ago
> The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems. This is a reasonable criticism of systemd. The other points seem mostly to be a criticisum of the various distro implementations that use systemd. The sort of thing that gets tidied up over time anyway.
- throw2016 10y ago
  The bigger question is whether an init should be a continuously developed project with rapidly increasing scope as now various distributions are on differing versions of systemd with widely varying compatibility and feature sets.
pawadu 10y ago
I think systemd would benefit from a slower adaptation. The network and boot issues that practically everyone have encountered are mostly due to incorrect default configurations. This shows that the maintainers are not ready to use systemd as they don't yet fully understand it.

tyfon 10y ago

I'm a bit more on the positive side. I actually really like systemd. When it was first introduced I spent 10-15 minutes learning how it operated and after that it has been so much better than the old init systems. And the best part is that it's on all the major distros so I don't have to keep relearning the init system if I try something new. My guess has been that the majority of users enjoy it and a few very vocal opponents have such hate for anything new that they will latch on to every small bug as if it's the worlds end. (Anecdotally, this is the first time I have written a comment about systemd as other discussions have been non-productive flame fests without substance).

1_2__3 10y ago
If your effort to learn how systemd functions took you ten minutes it's unlikely you're involved enough in the internals of it to understand the debate.

bitwize 10y ago

> The way it was pushed on distros was problematic, in my opinion. The technical term for this is "precommitment", and it comes from Tom Schelling. It's actually quite advantageous: once you're precommitted to a particular direction, you're emotionally invested in getting the most out of it. By precommitting you to systemd, the distros hope to get the community to leverage systemd's benefits.

digi_owl 10y ago
Sounds like a restatement of Thatcher's TINA (There Is No Alternative)...