3 ms·
I would drop it in a heartbeat if I could. Dealing with servers it's not solving a problem I have, and just introducing the strangest behaviour along the way.
by Twirrim 10y ago
I would drop it in a heartbeat if I could. Dealing with servers it's not solving a problem I have, and just introducing the strangest behaviour along the way.
- SteveNuts 10y agoAgreed, the config files for upstart were so easy to template out and always worked reliably.
- josteink 10y ago> Dealing with servers it's not solving a problem I have, For me it's solving the problem of simply and reliably wiring up persistent and resilient services (not shipped with the OS). I don't know about you, but that's a need I especially have on servers. When systemd works, it works remarkably well.
- tomc1985 10y agoIndeed, I've deployed it in both embedded linux and server environments and it works quite nicely in both roles.
- Twirrim 10y ago>For me it's solving the problem of simply and reliably wiring up persistent and resilient services (not shipped with the OS). That aspect was already largely solved, and has been for a long time. runit, upstart, daemontools etc. Daemontools, like a number of djb's tools, manages to really manage to blend an amazing level of "just works" and "ZOMG, I configure this how?!"
- tomc1985 10y agoI always hated the prevalence of so many tools -- I get sick of having to learn 30 variants of the same stupid thing because none of them seem to excel in every area. One server from recent memory had crap running in sysv, inittab, and with deamontools because not everybody liked the same system and kinda just did what they knew. I'm rather happy that systemd throws all that out.
- Twirrim 10y agoThat's just lousy technical culture. If you can't ensure you've got clean practices on your servers to that degree, you've got bigger problems on your plate.
- tomc1985 10y agoAs if one is always able to influence a lousy technical culture, especially if they just walked through the door...