If you are reading this post you’re very much likely not a fan of systemd already. So we won’t preach on why systemd is bad, but today we’ll focus more on what are the alternatives out there. Our approach is obviously not for settling for less but for changing things for the better. We have started the world after systemd project some time ago and the search isn’t over.
I’ll be honest and say that I completely missed the systemd controversy back when it happened, and while I’ve tried reading up on the criticism of systemd, I clearly lack the technical acumen to say anything meaningful about it either way. But hey, for those of you out there who don’t like systemd – this one’s for you.
Coming from Slackware (over 20 years ago now), and having learned to do things the “one true Unix way”, systemd has thrown me off balance. It broke my firewall knowledge, kept reassigning my Ethernet ids, and when it broke my previous experience with Linux did not help me much (even /var/log/ was not properly populated).
Simple things like running a separate X server on a secondary graphics cards became insanely difficult thanks to new definitions of seats, login sessions, and systemd’s insistence on overwriting X configs. In fact to day I have still yet to master that.
Nevertheless, It took me a while, however I started “not disliking” systemd. I understand where the need for a change came (lots of manually curated init scripts were not easy to automate). It allowed scaling up in the cloud, and easy deployments for containers. It also automated desktop configuration (hence my issue with custom configs).
I am now comfortable with tolerating systemd. Who knows, one day I might start liking it, but that might take a while.