3 ms·
discussions like this are good reminders of how low quality most HN threads are. a huge mass of random whinging about the people involved, non-technical whingi
by bananapub 3y ago
discussions like this are good reminders of how low quality most HN threads are. a huge mass of random whinging about the people involved, non-technical whinging about imagined architecture decisions (like "systemd is a monolith") and then conspiracies about Microsoft like it's a slashdot thread in 1998.
notably missing:
- discussions about how fucking shit PID files and things like start-stop-daemon are or how annoying it was writing a sh script for every daemon, or how in sysvinit things can become un-shut-downable
- discussion about how making containerisation/chroot/resource limits trivial is good actually
- reflections on how hard making a reliable good init system is, cf upstart/launchd/whatever solaris had and how nice it is that someone actually did it for linux
etc etc
- sophacles 3y agoDon't forget the single biggest problem of sysvinit: Making services start in a deterministic order when the appropriate (and necessary) resources are actually available.
- bananapub 3y agodunno what you mean, my "start) sleep 15" works fine most of the time !
- ElectricalUnion 3y agoI would add - making handling of forking to the background and log rotation not a task of the program itself, instead of making every program (or worse, a bespoke wrapper shell script) do it. Because such things are non-trivial and demand reasonably many man-hours of otherwise "trivial" projects. Granted, you don't actually need systemd to do such things (for example, runit can do such things, and runit is available under busybox and therefore almost universal in most GNU/Linux distros), but I think it was systematic distro/systemd that enforced such new paradigm.