7 ms·

In this particular case I don't think it'll matter. All the big distros have (thankfully[1]) standardized on systemd. At least we now have something to point th

In this particular case I don't think it'll matter. All the big distros have (thankfully[1]) standardized on systemd. At least we now have something to point the systemd haters towards, I guess. [1] I doesn't even matter too much to me _which_ solution we have as long as it's reasonable (e.g. upstart wasn't) and a reasonably complete daemon supervision solution which can actually capture the output of the daemon's it's running, etc.

Koshkin 10y ago
> standardized on systemd I sort of understand the reason for using systemd on desktop computers, where things may be rather volatile, but in a stable environment such as a server or a mainframe, the value that this complex piece of software brings to the table is not obvious to me; besides, others have mentioned that it is a sysadmin's nightmare, so...
- ZenoArrow 10y ago
  >"others have mentioned that it is a sysadmin's nightmare" Any examples? If anything I'd expect systemd to make things easier for sysadmins, would be interested in finding out what challenges sysadmins face because of systemd.
  - petre 10y ago
    For instance apache not restarting properly on openSuSE 13.2 when ServerName doesn't resolve properly for some reason.
    - lomnakkus 10y ago
      Haven't heard of this particular issue, but my main point is that the reaction should then be: "Ok, so let's fix that in systemd, upstream systemd .service files or whatever, and it gets fixed for everybody all at once.". The reaction should not be "systemd sucks!". That is the real value of standardization. EDIT: As far as I can tell as an outsider systemd is at least engineered well enough that these things can be solved, eventually. That wasn't the case before: Everybody had their own quarter-assed solutions that only worked for their specific case and would fail horribly in other cases, etc. etc.
      - Koshkin 10y ago
        > value of standardization But the Linux community has always prided itself on freedom and diversity. Otherwise we might as well be all using one "standard" Linux distribution.
        lomnakkus 10y ago
        There are things that are worth diversifying on. Basic subsystems that only serve to keep the OS running is not one of them -- the benefits of standardization far outweigh the costs of lack-of-diversity. (Of course this is just my opinion, yours may differ.) As to freedom: I'm not sure what you're driving at here. Can you expound?
        Koshkin 10y ago
        I think freedom and diversity simply do not exist one without the other. Freedom of choice that has been essential in making Linux popular in the first place may be severely limited by imposing more and more "standards"; I would argue that the very spirit of Linux lies exactly in this freedom. This is why we have so many distributions; and the more we standardize, the less need there is for this diversity, which, I think, is bad for Linux and, ultimately, for its users.
        lomnakkus 10y ago
        Ah, yes, the old > freedom and diversity simply do not exist one without the other. "freedom and diversity" defense. Nobody's trying to take that away, FWIW. It may feel threatened, but I assure you that systemd is the least of your worries if you really care about F&D.
        petre 10y ago
        When everybody standardizes on possibly the worst implementation available for that platform, then it is worth diversifying.
        10y ago
- geofft 10y ago
  I'm not super interested in rehashing the flamewar, so this is anecdata: from the perspective of sysadmin of thousands of physical machines, systemd has been a godsend. It gives me a standard way to supervise, gather log output from, and restart long-running-processes with dependencies on other processes. It's replaced a number of "sleep 10"s and "sleep 60"s that our infrastructure has grown over the years in shell scripts at various points in init. Starting services in a consistent environment (not inheriting anything from the sysadmin's own session / environment) has also been useful in an environment with lots of sysadmins. It's certainly not the best solution out there for any single thing it does, but the standardization - i.e., that it is integrated with my distro and also every other distro - is extremely useful. Most existing things I want to run tend to have systemd support, and most homegrown things are very easy to write systemd units for. Also, there are a lot of reasons to want fast reboots for servers, and systemd provides this. (Again, so do other approaches, but the standardization means this actually happens.) It's worth noting that there are sort of two debates: systemd vs. other similar systems (upstart, SMF, launchd, whatever) or systemd/similar systems vs. sysvinit. From experienced, large-scale UNIX admins, I think the wide consensus is that the answer to the second question is "definitely anything other than sysvinit". See, for instance, that the Debian tech committee debate was about systemd vs. upstart vs. insserv or something else, and nobody voted for sysvinit.
  - petre 10y ago
    Most servers boot really slowly anyway (memory tests, raid cards etc), so why would anyone care if it takes one or ten seconds to boot Linux when the server boots in 120 seconds. Other init systems are capable of restarting things with dependencies as well, like BSD's rcng for instance. I am using runit to supervise my services since I can't rely on systemd.
    - geofft 10y ago
      My experience with sysvinit is that it definitely takes well over ten seconds to boot Linux and start all services, especially if you've been putting "sleep 60" into certain scripts to make boot ordering reliable. Again, I'm comparing systemd to pre-systemd Linux distros (including Devuan, which explicitly continues that tradition), not to systems broadly comparable to systemd. If Devuan had a different fancy init system or service manager (which could just be bundling runit configuration for everything the OS ships with) instead of an old-school init system + old-school init scripts, this would be a very different comparison.

Koshkin 10y ago

> standardized on systemd I sort of understand the reason for using systemd on desktop computers, where things may be rather volatile, but in a stable environment such as a server or a mainframe, the value that this complex piece of software brings to the table is not obvious to me; besides, others have mentioned that it is a sysadmin's nightmare, so...

ZenoArrow 10y ago
>"others have mentioned that it is a sysadmin's nightmare" Any examples? If anything I'd expect systemd to make things easier for sysadmins, would be interested in finding out what challenges sysadmins face because of systemd.
- petre 10y ago
  For instance apache not restarting properly on openSuSE 13.2 when ServerName doesn't resolve properly for some reason.
  - lomnakkus 10y ago
    Haven't heard of this particular issue, but my main point is that the reaction should then be: "Ok, so let's fix that in systemd, upstream systemd .service files or whatever, and it gets fixed for everybody all at once.". The reaction should not be "systemd sucks!". That is the real value of standardization. EDIT: As far as I can tell as an outsider systemd is at least engineered well enough that these things can be solved, eventually. That wasn't the case before: Everybody had their own quarter-assed solutions that only worked for their specific case and would fail horribly in other cases, etc. etc.
    - Koshkin 10y ago
      > value of standardization But the Linux community has always prided itself on freedom and diversity. Otherwise we might as well be all using one "standard" Linux distribution.
      - lomnakkus 10y ago
        There are things that are worth diversifying on. Basic subsystems that only serve to keep the OS running is not one of them -- the benefits of standardization far outweigh the costs of lack-of-diversity. (Of course this is just my opinion, yours may differ.) As to freedom: I'm not sure what you're driving at here. Can you expound?
        Koshkin 10y ago
        I think freedom and diversity simply do not exist one without the other. Freedom of choice that has been essential in making Linux popular in the first place may be severely limited by imposing more and more "standards"; I would argue that the very spirit of Linux lies exactly in this freedom. This is why we have so many distributions; and the more we standardize, the less need there is for this diversity, which, I think, is bad for Linux and, ultimately, for its users.
        lomnakkus 10y ago
        Ah, yes, the old > freedom and diversity simply do not exist one without the other. "freedom and diversity" defense. Nobody's trying to take that away, FWIW. It may feel threatened, but I assure you that systemd is the least of your worries if you really care about F&D.
        petre 10y ago
        When everybody standardizes on possibly the worst implementation available for that platform, then it is worth diversifying.
        10y ago
geofft 10y ago
I'm not super interested in rehashing the flamewar, so this is anecdata: from the perspective of sysadmin of thousands of physical machines, systemd has been a godsend. It gives me a standard way to supervise, gather log output from, and restart long-running-processes with dependencies on other processes. It's replaced a number of "sleep 10"s and "sleep 60"s that our infrastructure has grown over the years in shell scripts at various points in init. Starting services in a consistent environment (not inheriting anything from the sysadmin's own session / environment) has also been useful in an environment with lots of sysadmins. It's certainly not the best solution out there for any single thing it does, but the standardization - i.e., that it is integrated with my distro and also every other distro - is extremely useful. Most existing things I want to run tend to have systemd support, and most homegrown things are very easy to write systemd units for. Also, there are a lot of reasons to want fast reboots for servers, and systemd provides this. (Again, so do other approaches, but the standardization means this actually happens.) It's worth noting that there are sort of two debates: systemd vs. other similar systems (upstart, SMF, launchd, whatever) or systemd/similar systems vs. sysvinit. From experienced, large-scale UNIX admins, I think the wide consensus is that the answer to the second question is "definitely anything other than sysvinit". See, for instance, that the Debian tech committee debate was about systemd vs. upstart vs. insserv or something else, and nobody voted for sysvinit.
- petre 10y ago
  Most servers boot really slowly anyway (memory tests, raid cards etc), so why would anyone care if it takes one or ten seconds to boot Linux when the server boots in 120 seconds. Other init systems are capable of restarting things with dependencies as well, like BSD's rcng for instance. I am using runit to supervise my services since I can't rely on systemd.
  - geofft 10y ago
    My experience with sysvinit is that it definitely takes well over ten seconds to boot Linux and start all services, especially if you've been putting "sleep 60" into certain scripts to make boot ordering reliable. Again, I'm comparing systemd to pre-systemd Linux distros (including Devuan, which explicitly continues that tradition), not to systems broadly comparable to systemd. If Devuan had a different fancy init system or service manager (which could just be bundling runit configuration for everything the OS ships with) instead of an old-school init system + old-school init scripts, this would be a very different comparison.