|
Top-level
 i can’t stress this enough. one of the guiding design principles in alpine is that if you have to read a manpage to perform a basic operation as a user, we have already failed. the competition to systemd in service lifecycle management is largely a minefield of tools with cryptic command line switches and other potholes. the tools do not feel good to use. we want a service management system that feels as good to use as apk. 22 comments
there are of course, valid criticisms of systemd. the fact that so much userspace surface is contained in a single project is unpleasant from a technical and governance POV. however, systemd itself is highly modular. the core service management framework is only a few megabytes on disk, which is comparable to openrc. so the people who complain about bloat are likely just not using a properly packaged form of systemd…  @ariadne modularity of some chunks of code is kind of moot when such fundamental parts of the kernel interface (eg. udev) no longer work standalone. @ariadne you can? hadn't seen anyone do that ever since it got absorbed as systemd-udevd.  @ariadne @spacehobo but systemd doesn’t actually do that. its a monorepo, but it generates tons of binaries. @ariadne Yeah, I was hoping to wave hands a little wider than I did with the word "runtime", really.  @ska @ariadne OK, I did not expect to read that today: that sd_notify() is "over-engineered" and "bloated". It's *literally* a frickin env-var-like text string in a datagram to an AF_UNIX socket whose path is passed in an env var. I mean, I can explain the protocol this in a single (one!) sentence. If that's "bloated", then I think you are smoking some really really really good dope, man. No shame in that, but maybe don't comment on the Internet when you do ;-) @ska i don’t think your sd_notify example holds. a child supervisor could hoist the socket along to its parent to solve this problem using SCM_RIGHTS.  > This assumption means that the only way to implement readiness notification management in systemd is to have a central supervisor for all the services, which is the exact opposite of modularity. Just set NOTIFY_SOCKET to the socket implementing the trivial protocol, which can be named at random? There is no reason this protocol is at all incompatible with multiple decentralized managers? You just run a socket on each? I can't understand the problem here. @ariadne as a long-time systemd hater I tried out Void, which is on runit, and discovered to my displeasure that the Old Ways are actually super annoying and systemctl is actually a very wieldy way to manage services… but there’s also part of me that appreciated having a system where you could quickly figure out how to enable or disable a service by inspecting its peers in the filesystem. I think systemd is equally guilty of needing a manpage check – I’ve had to google how to read logs so much   |
Gregory's Server
@ariadne Not to mention that writing service definitions with systemd is much easier as well <.<