4 ms·

> What gives the init system the right or the duty to reach down into a user's processes and determine[0] that they are stuck (versus running appropriately, as

by deno 8y ago

> What gives the init system the right or the duty to reach down into a user's processes and determine[0] that they are stuck (versus running appropriately, as e.g. the user indicated with nohup(1))? Why is it the init system's job to handle that? If this behavior was mandated by some other piece of software named FluffyUnicorn and had nothing to do with Lennart, but was still widely adopted just as systemd is, would you be ok with it? It’s in systemd because it makes sense to be there. Systemd already groups services into cgroups so it makes sense to also do that for user sessions. > That's just not its job. If I wanted to run some sort of misbehaved-process killer, I could. Or, y'know, not running misbehaving processes. Ideally, that would include not running misbehaving processes like anything from the systemd project. So toggle a configuration switch on your system. What you are actually trying to do is to FORCE this bad and confusing behavior as a DEFAULT on regular users that have no need or want for it.

zeveb 8y ago
> What you are actually trying to do is to FORCE It's a rule: if you're advocating systemd, you don't get to accuse anyone else of forcing anything.
- deno 8y ago
  What do you disagree with in that sentence? There are defaults, distros have defaults, they’re the subject of this discussion. Anyone arguing for any default is likely dictating the de facto behavior for majority of nontechnical users, which is the majority of users period.
zrm 8y ago
> If this behavior was mandated by some other piece of software named FluffyUnicorn and had nothing to do with Lennart, but was still widely adopted just as systemd is, would you be ok with it? If this behavior was mandated by some other piece of software, it wouldn't be as widely adopted as systemd is. That's the true problem with systemd. It tries to do everything and does 80% of it well enough that many people use it, but then is too complex and integrated with itself to easily identify and carve out the problematic bits and replace them with third party alternatives.
- deno 8y ago
  > If this behavior was mandated by some other piece of software, it wouldn't be as widely adopted as systemd is. So your argument is that this is forced on people because of systemd’s political power? There’s a configuration option to reverse this behavior, it’s not hidden away somewhere, it’s been widely publicized. Any distro could have flipped the switch and easily reverted to preserve backwards compatibility, but none did. This is because this change is a net benefit to the majority of users. > That's the true problem with systemd. It tries to do everything and does 80% of it well enough that many people use it, but then is too integrated with itself to easily identify and carve out the problematic bits Again, you don’t need to fork systemd to change this behavior. If that was the case I would understand the criticism. But that is not the case. The alternative workflow is perfectly well supported. All we’re arguing about is the defaults. Systemd developers go out of their way to not break things. You’re arguing for making up some abstraction layers for plug-n-play components that no one is demanding, and would probably never be used. Modularity has a cost, and not only that, but you also have to know where to draw the line between core and addon. And if systemd actually did all of that, I’m pretty sure all those habitual complainers would just argue that it’s over-engineered and should have been kept simple. You can’t win with the peanut gallery.
  - zrm 8y ago
    > Any distro could have flipped the switch and easily reverted to preserve backwards compatibility, but none did. No, many of them did. The problem is that this is not the only such issue, and distribution maintainers don't have unlimited time and resources to re-evaluate every individual default chosen by upstream, so most of the upstream defaults end up in the distributions. The distributions can fix this once you identify the problem, as e.g. Debian has done, but "you can change it" is no argument for a bad default, because changing it is work in the meantime things are broken. > Again, you don’t need to fork systemd to change this behavior. If that was the case I would understand the criticism. But that is not the case. The alternative workflow is perfectly well supported. All we’re arguing about is the defaults. If the defaults weren't important then why are you arguing about them? > Systemd developers go out of their way to not break things. Yet tmux and screen are broken on the distributions that use upstream's default. > You’re arguing for making up some abstraction layers for plug-n-play components that no one is demanding, and would probably never be used. Modularity has a cost, and not only that, but you also have to know where to draw the line between core and addon. You say that as if it wasn't the way everything works in many other init systems. The init system doesn't typically have a DNS server, you can use dnsmasq or BIND or unbound or djbdns or whatever you like. It doesn't have its own cron, there are many choices and you can choose any of them. And just drawing any hard lines would help. Even if you had to replace two modular components to replace one thing, or one component that does two things when it should be one, that's certainly a lot more feasible than having to understand and touch thirty integrated pieces to replace one component.

by deno 8y ago

zeveb 8y ago

> What you are actually trying to do is to FORCE It's a rule: if you're advocating systemd, you don't get to accuse anyone else of forcing anything.

deno 8y ago
What do you disagree with in that sentence? There are defaults, distros have defaults, they’re the subject of this discussion. Anyone arguing for any default is likely dictating the de facto behavior for majority of nontechnical users, which is the majority of users period.

zrm 8y ago

> If this behavior was mandated by some other piece of software named FluffyUnicorn and had nothing to do with Lennart, but was still widely adopted just as systemd is, would you be ok with it? If this behavior was mandated by some other piece of software, it wouldn't be as widely adopted as systemd is. That's the true problem with systemd. It tries to do everything and does 80% of it well enough that many people use it, but then is too complex and integrated with itself to easily identify and carve out the problematic bits and replace them with third party alternatives.

deno 8y ago
> If this behavior was mandated by some other piece of software, it wouldn't be as widely adopted as systemd is. So your argument is that this is forced on people because of systemd’s political power? There’s a configuration option to reverse this behavior, it’s not hidden away somewhere, it’s been widely publicized. Any distro could have flipped the switch and easily reverted to preserve backwards compatibility, but none did. This is because this change is a net benefit to the majority of users. > That's the true problem with systemd. It tries to do everything and does 80% of it well enough that many people use it, but then is too integrated with itself to easily identify and carve out the problematic bits Again, you don’t need to fork systemd to change this behavior. If that was the case I would understand the criticism. But that is not the case. The alternative workflow is perfectly well supported. All we’re arguing about is the defaults. Systemd developers go out of their way to not break things. You’re arguing for making up some abstraction layers for plug-n-play components that no one is demanding, and would probably never be used. Modularity has a cost, and not only that, but you also have to know where to draw the line between core and addon. And if systemd actually did all of that, I’m pretty sure all those habitual complainers would just argue that it’s over-engineered and should have been kept simple. You can’t win with the peanut gallery.
- zrm 8y ago
  > Any distro could have flipped the switch and easily reverted to preserve backwards compatibility, but none did. No, many of them did. The problem is that this is not the only such issue, and distribution maintainers don't have unlimited time and resources to re-evaluate every individual default chosen by upstream, so most of the upstream defaults end up in the distributions. The distributions can fix this once you identify the problem, as e.g. Debian has done, but "you can change it" is no argument for a bad default, because changing it is work in the meantime things are broken. > Again, you don’t need to fork systemd to change this behavior. If that was the case I would understand the criticism. But that is not the case. The alternative workflow is perfectly well supported. All we’re arguing about is the defaults. If the defaults weren't important then why are you arguing about them? > Systemd developers go out of their way to not break things. Yet tmux and screen are broken on the distributions that use upstream's default. > You’re arguing for making up some abstraction layers for plug-n-play components that no one is demanding, and would probably never be used. Modularity has a cost, and not only that, but you also have to know where to draw the line between core and addon. You say that as if it wasn't the way everything works in many other init systems. The init system doesn't typically have a DNS server, you can use dnsmasq or BIND or unbound or djbdns or whatever you like. It doesn't have its own cron, there are many choices and you can choose any of them. And just drawing any hard lines would help. Even if you had to replace two modular components to replace one thing, or one component that does two things when it should be one, that's certainly a lot more feasible than having to understand and touch thirty integrated pieces to replace one component.