>Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". It's a bit of a monolith. Peo

>Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". It's a bit of a monolith. People will say it's not, because it's made out of a bunch of smaller components, but when those components are that closely interlinked it stops mattering if they live in different code bases. It also has a pretty wide scope. PID 1 is responsible for things like dealing with zombie/orphan processes and it's generally a good idea to keep it as minimal as possible, and keep the attack surface as small as possible. Systemd handles things like socket activation, logging, scheduling, etc. It handles all this in more or less one process, which means that when/if that process crashes or has security concerns it's a much bigger deal. It even has it's own docker-equivalent! Really you want to keep PID 1 as minimal and secure as possible. >Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. They've made it hard to work with generic linux tools. For example they have their own custom log format that isn't text based. This means that linux tools like find or grep won't work on systemd logs. Generally systemd has replacements for those tools, like you can still grep but you've got to learn the specific systemd ways of actually getting the output and all that (note that a lot of distros seem to ignore systemd's logging provisions and just log to files like normal, for a bunch of stuff). It's pretty complicated to reason about, one "unit" can be a bunch of different files spread out all over the filesystem, and it can be hard to get a good view of all the aspects that effect a unit without resorting to systemd-specific tools to figure out the relationships between things. For example if you want to edit a unit file the suggested way to edit a unit file is with something like `sudo systemctl edit ssh` or possible `sudo systemctl edit ssh --full` depending on the situation. Spreading files all over the place like that sort of betrays their enterprise roots, it makes some sense when you're working with very large teams but just having all the until files in one location (/etc/init.d) would be a lot more readable and manageable. Also having one file per unit, instead of having to have separate file for units and their dependencies (things like sockets) would be nice. Another problem is that they broke chroot, which makes dealing with embedded systems that use systemd a pain if you're not using a systemd based host to develop on. They sort of force you to use systemd's docker equivalent instead of the more common chroot if you're dealing with systemd-based embedded systems. That means you'd better be running a systemd based host system as well. --- Also I think some of us feel like it's being forced on us. Redhat/IBM funds or has control over a lot of the unix ecosystem, so when we see things like Gnome not working on BSD any more because it has a hard dependency on systemd, well it starts to look like an intentional. Things like the systemd decision to randomly kill off screen/tmux sessions on user logout leave a really bad taste in some people's mouth. Honestly a fair bit of the dislike is just repeated instances like that, and repeatedly ignoring feedback as to why that's actually a pretty big problem, and generally being unwilling to compromise with the broader community. https://www.reddit.com/r/programming/comments/4ldewx/systemd_kills_screen_and_tmux_by_default_on_logout/ https://www.reddit.com/r/programming/comments/4ldewx/systemd...