4 ms·

I don't know about deterministic, but there's something to the flakiness. The old stuff was byzantine, but it was decades old, which meant that it had decades

I don't know about deterministic, but there's something to the flakiness. The old stuff was byzantine, but it was decades old, which meant that it had decades of people beating on it, figuring out all the ways that it could flake, and fixing those flakes. And that's not something to sneeze at. That doesn't make the old stuff any less byzantine. And systemd really is a lot more coherent than most of what it replaced. But systemd doesn't have decades of people finding all the ways it can fall over.

leephillips 6y ago
I agree. My comment wasn’t a complaint about systemd per se. The old init system was nothing to fall in love with. I think this is an improvement. The problem is that is hasn’t “replaced” all the older mechanisms, but is one more layer that adds to the confusing mess, with sedimentary layers of conflicting systems, mysterious files all over the filesystem, and obsolete and conflicting documentation. What I’ve enjoyed in particular: systemd timers are an improvement over cron; and I’ve been making great use of systemd-nspawn, which is very convenient and powerful.
- narwally 6y ago
  I agree that it is another layer of complexity, but when it works well it's a really good layer of abstraction for user space programs to interact with the kernel. It's only when issues arise that the extra layer brings in more complexity. And like GP stated, that's mostly an issue of time needed to eliminate the most serious bugs and for edge cases to be well understood and documented. there were plenty of growing pains at first, but the transition period for any project looking to replace the old init system was going to be a headache no matter what. It does take some time to grok, and it feels monolithic at first, but I actually think that's a good thing. It's composed of many separate binaries that individually conform to the unix philosophy, but they're all distributed, maintained, and released together. You still have tons of configurations options, but you can be confident that standard systemd components are always going to play nicely with each other. The only issue I've really had are the binary logs. If the indexes get messed up it's a pain to access the logs even if though the actual files rarely have issues with corruption. But it's fairly easy to forward messages to syslog if you need.
  - leephillips 6y ago
    The problem that I can see is not that systemd and other new systems are complex. They deal with complex problems. The problem is that the old stuff stays around, so a distribution like Ubuntu keeps growing in complexity and obscurity. My Ubuntu laptop and the couple of Debian servers that I take care of have systemd, which is fine, and I’m happily using it. But they also still have an init.d directory, are still running cron, etc., etc. It’s not coherent. When I have to use strace to spy on my system to I can figure out how to configure it, something’s wrong. And it’s not just the init system. My laptop’s sound is much more reliable after I removed PulseAudio, because it seemed to be fighting with alsa, or something else.

leephillips 6y ago

I agree. My comment wasn’t a complaint about systemd per se. The old init system was nothing to fall in love with. I think this is an improvement. The problem is that is hasn’t “replaced” all the older mechanisms, but is one more layer that adds to the confusing mess, with sedimentary layers of conflicting systems, mysterious files all over the filesystem, and obsolete and conflicting documentation. What I’ve enjoyed in particular: systemd timers are an improvement over cron; and I’ve been making great use of systemd-nspawn, which is very convenient and powerful.

narwally 6y ago
I agree that it is another layer of complexity, but when it works well it's a really good layer of abstraction for user space programs to interact with the kernel. It's only when issues arise that the extra layer brings in more complexity. And like GP stated, that's mostly an issue of time needed to eliminate the most serious bugs and for edge cases to be well understood and documented. there were plenty of growing pains at first, but the transition period for any project looking to replace the old init system was going to be a headache no matter what. It does take some time to grok, and it feels monolithic at first, but I actually think that's a good thing. It's composed of many separate binaries that individually conform to the unix philosophy, but they're all distributed, maintained, and released together. You still have tons of configurations options, but you can be confident that standard systemd components are always going to play nicely with each other. The only issue I've really had are the binary logs. If the indexes get messed up it's a pain to access the logs even if though the actual files rarely have issues with corruption. But it's fairly easy to forward messages to syslog if you need.
- leephillips 6y ago
  The problem that I can see is not that systemd and other new systems are complex. They deal with complex problems. The problem is that the old stuff stays around, so a distribution like Ubuntu keeps growing in complexity and obscurity. My Ubuntu laptop and the couple of Debian servers that I take care of have systemd, which is fine, and I’m happily using it. But they also still have an init.d directory, are still running cron, etc., etc. It’s not coherent. When I have to use strace to spy on my system to I can figure out how to configure it, something’s wrong. And it’s not just the init system. My laptop’s sound is much more reliable after I removed PulseAudio, because it seemed to be fighting with alsa, or something else.