2 ms·

sysvinit brings far less determinism to the table Hm. I was with you until that. The reason I don't have systemd in production is that it's like pulling teeth

sysvinit brings far less determinism to the table Hm. I was with you until that. The reason I don't have systemd in production is that it's like pulling teeth to get a deterministic service initiation order. For all their flaws, the good thing about init.d scripts was that you knew exactly what order things came up and down in, because it was spelled out in a shell script you could view and edit. This was great for administrators, but absolute hell for distribution maintainers; I totally get why the distros went to systemd. But since it solves their problems, rather than mine, it's not particularly useful to me (I use GNU PIES in production, which is kind of a middle ground: it can run inittab and rc.d scripts, but it also has a declarative native format)

scrollaway 10y ago
That's because systemd by default is asynchronous, whereas init by default is linear. It's the main feature of systemd: Execution order is usually not important, it only leads to slower boot. For when it is important, systemd can guarantee execution order by using its dependency system. Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue with this?
- bandrami 10y ago
  I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it. What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditions to work for everyone.
  - scrollaway 10y ago
    Sorry, I read your post the wrong way around. I think you're conflating "transparent" and "deterministic". Init is more transparent in that there are less layers to it. But systemd is more deterministic because it is able to make more guarantees about the state of the system. Similarly, docker is also more opaque but far more deterministic than a provisioning script.
    - bandrami 10y ago
      No, we're just thinking about determinism differently. Systemd makes (or at least tries to make) guarantees about outcomes, which means it doesn't make guarantees about process. SysV (at least the traditional BSD-style a la Slackware) makes guarantees about process, which means it doesn't make guarantees about outcomes. I prefer determinism of process to determinism of outcome.

scrollaway 10y ago

That's because systemd by default is asynchronous, whereas init by default is linear. It's the main feature of systemd: Execution order is usually not important, it only leads to slower boot. For when it is important, systemd can guarantee execution order by using its dependency system. Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue with this?

bandrami 10y ago
I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it. What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditions to work for everyone.
- scrollaway 10y ago
  Sorry, I read your post the wrong way around. I think you're conflating "transparent" and "deterministic". Init is more transparent in that there are less layers to it. But systemd is more deterministic because it is able to make more guarantees about the state of the system. Similarly, docker is also more opaque but far more deterministic than a provisioning script.
  - bandrami 10y ago
    No, we're just thinking about determinism differently. Systemd makes (or at least tries to make) guarantees about outcomes, which means it doesn't make guarantees about process. SysV (at least the traditional BSD-style a la Slackware) makes guarantees about process, which means it doesn't make guarantees about outcomes. I prefer determinism of process to determinism of outcome.