| My reasons for avoiding it: * build system actively makes it difficult to build one component without the others, seemingly for political rather than technical reasons * build system relies on Python, making bootstrapping more difficult (not quite desirable for "building blocks to build an OS from") * needless overlap with countless other pre-existing projects including binfmt-support, lxc/runc, and libdbus * cgroups2 hierarchy model which is unworkable for rootless containers unless they register with systemd via dbus or are running directly as systemd services * The dependency model has lots of corner cases and gotchas. OpenRC and the LSB headers are much simpler and just as effective. * Events are done in a hacky way: device events are performed by tucking "SYSTEMD_WANTS=..." away in a udev rule somewhere, IPC and timer events have their own unit types. This model is not extensible, and it obscures the policy rules that can be used to start a particular service. * All the positive PR and marketing has left a bad taste in my mouth. Why did RedHat fly Lennart across the world dozens of times just to sell this hunk of C to literally anybody that would listen? It was a waste of petrol and shows that systemd did not win on merits alone. * does not make any attempts at portability, and does not follow any pre-existing standardized interfaces that can be easily emulated on other OSs. * Reliant on dbus as its primary IPC mechanism, when it does not even need a bus in the first place. JSON over a socket could have been a simpler and cleaner choice. |