Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

1–10 of 332 posts

Re: Systemd, 10 years later (2020)

#2
It's not as bad as at first feared. Views here are along the usual lines; for many when there's an issue either it's something that's fixable inhouse (init scripts) or needs a support contract.

Having said that, personally (old school) I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason.

Re: Systemd, 10 years later (2020)

#3
Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

Re: Systemd, 10 years later (2020)

#6
post #2

It's not as bad as at first feared. Views here are along the usual lines; for many when there's an issue either it's something that's fixable inhouse (init scripts) or needs a support contract. Having said that, personally (old school) I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason.

It's not so bad now.

You might be forgetting how bad it was at first. In fact I'd argue it was worse than initially feared, and the developer's supreme arrogance did little to help.

Re: Systemd, 10 years later (2020)

#8

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

I’m young enough to have missed the transition and really like systemd, I rely on it for as much as I can

Re: Systemd, 10 years later (2020)

#10
How does it work in a Kubernetes world? I found today that "systemctl stop k3s" actually did not stop all k3s dependent processes. A separate script was supplied to do that. So on a Kubernetes box there are processes running in namespaces that systemd does not manage?
Post reply on HN