I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses.<p>For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case.<p>For me, systemd has provided a much more consistent way of managing services. There's a tightly defined service definition format that allows one to comfortably modify any 3rd party service as well, (unlike random, variable-quality shell scripts), relatively small amount of commands to learn that work consistently across services, mounts, timers etc. There's also much better handling of modern hardware, hotplugging & the like.<p>I can't say I miss sysvinit. Also, stuff like [1] from the anti-systemd camp doesn't inspire confidence.<p>1 - <a href="https://lwn.net/Articles/786593" rel="nofollow">https://lwn.net/Articles/786593</a>
I read everything I could find on systemd to form my own opinion. I used FreeBSD for a decade and have many years of Ubuntu/upstart experience after that.<p>Based on my experience and all the anti-systemd posts online, I expected to dislike it.<p>But on it's merits I really like the consistency it brings to the "system layer" of the OS.<p>I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system.<p>On the other hand, I <i>do</i> support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.
One of the better videos on this subject:<p><a href="https://www.youtube.com/watch?v=6AeWu1fZ7bY" rel="nofollow">https://www.youtube.com/watch?v=6AeWu1fZ7bY</a><p><i>BSDCan 2018—Benno Rice: The Tragedy of systemd</i><p><i>"systemd is, to put it mildly, controversial. Depending on who you ask it's either a complete violation of the UNIX philosophy, a bloated pile of bugs, a complete violation of the elegant simplicity it replaced or, it most cases, some or all of the above. So why have so many Linux distributions taken to it? Is it as bad as people say?</i>
Guix is missing, which uses GNU Sheperd, which is in Scheme:<p><a href="https://www.gnu.org/software/shepherd/" rel="nofollow">https://www.gnu.org/software/shepherd/</a><p>That said, to me systemd has been a large improvement. Maybe it has its problems, but at least there is consistency in handling services and logs between Linux distributions, which is a big improvement over a bunch of homegrown sysvinit derivatives, Upstart, and homegrown non-sysvinit scripts.
I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate.<p>The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes.<p>Also, it seems to make writing a service a lot easier. Instead of the service needing to daemonize, write out a PID file, or whatever, it can just be a program that does its thing without forking, sends its output to stdout/stderr and systemd takes care of the details. I tried to go through this exercise on a FreeBSD system and ended up just installing 'pm2' to do it for me. I subsequently figured out what I did wrong, but pm2 is working and I see no need to change it.<p>Obviously systemd isn't suited for every use-case, but it doesn't seem nearly as bad as some people make it out to be.
I actually really like systemd's service files, and the functionality it provides. I like the ability to express dependencies clearly, the fine-grained control over server restart behavior, and a ton of other systemd features. I'm also very happy to see it replace cron.<p>What I _do not_ like are:<p><pre><code> - systemd-resolved
- systemd-networkd
- systemd taking over disk mounts
- systemctl
- unit files spread out all over the place
- mandatory journald
- mandatory dbus
- only works on Linux
- pushing the BSDs farther towards being obsolete
</code></pre>
I'm very glad to see sysv-init on the way out, personally. I think systemd unit files are a huge improvement, and greatly improve standardization and init quality. But that doesn't intrinsically mean that the systemd project is doing the right thing.
It's comical how people get so "jazzed" about something like not liking systemd and make a whole movement about it (with their t-shirts and everything). I get people may not love everything about systemd (or maybe they hate it), but I'm not convinced it's so bad. I've been using it since RHEL 7 and I've really gotten used to all of the benefits of systemd. It also doesn't hurt that I went to the session on pid 1 by Lennart Poettering at Red Hat Summit 2014 and he convinced me of the at least not-horribleness of systemd.
I get no end of bemusement from open source advocates that think it makes any kind of rational sense to campaign <i>against</i> an open source project. THIS IS ALL OPEN SOURCE. Freedom and choice is the <i>whole point,</i> isn't it?<p>If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate <i>for</i> the system you prefer. Convince people that the choice you have made is better.<p>Meanwhile the vast majority of distributions have voluntarily chosen systemd. Perhaps if its critics reflect on the reality of that shift, they could look at ways to improve the alternative to address its perceived deficiencies—just as GCC started doing now that LLVM has taken a bite out of their dominance.
Most arguments about systemd will devolve into a Motte and Bailey argument. The problems with systemd are all the stuff tacked on that are mandatory, but if you criticize them you'll get people switching to try to put words into your mouth about how the init replacement is good/bad.<p>The Motte is all the shovelware attached to systemd that is nearly impossible to detatch and the Bailey is the init replacement.
I have way too many cases of systemd startup items hanging with their timeout for no good reason.<p>Worse, my most complicated high-uptime machine usually does not shut down in a reasonable time. Systemd says "waiting for session user cracauer" (something like it) for whatever reason. It also hung on undoing swapspace, when that swapspace was a custom stack of block layers. I don't need swapspace to be "shut down". It went into 20 minutes something always stating another timeout when one expired. I mean, WTF?<p>The problem here is that I had to do an unclean shutdown on that machine (reset button) multiple times, and <i>that</i> I really can't have.<p>This also illustrates a point I have been making about Linux and the BSDs from day one: When the BSDs boot or shut down the keyboard is connected to the rc scripts. You can do Control-C for SIGINT and Control-\ for SIGQUIT, The latter makes everybody in the stack leave a coredump on disk.<p>Now, compare these two:<p>1)
in BSD when there is a startup or shutdown item taking too long or hanging I can abort that single item and I can later debug what was going on with the coredumps.<p>2)
on a Linux system with systemd I cannot "cut through" startup or shutdown items I don't want to wait for, and there is no way to debug any of that if the machine doesn't actually come up completely, or if thing happen at shutdown. The only interaction I can conduct is the reset button.<p>To add insult to injury, systemd also hides a lot of error messages that would traditionally be dumped on the console, and instead of giving me that error message systemd captures it and print on the screen instructions how to get that error message (which usually are longer than the error message was, WTF?). Instructions that I cannot follow because somebody detached my keyboard, and because I will never be in that machine in an up state while that context is available.<p>This also invalidates the point that systemd could be one platform that you learn once and then use on a wide basis. The debugging abilities are nowhere close to adequate, so you have to learn by try-n-error.
SystemD definitely spurred some controversies years ago but is it that bad in 2019?<p>All major distros adopted it and even some that are listed there as "no systemd" in reality just give you choice (e.g. Gentoo).<p>I'd gladly hear the opinion of distro maintainers why did they switch to SystemD if it's as bad as it looks like in people's perception.
My experience with systemd has be extraordinarily positive. I like the unified syntax of unit files. I know that's like 50% of what systemd does, but it does it extraordinarily well.<p>Is systemd-nspawn secure enough now we can forget docker et all? I liked the idea of a "chroot" being supported by the service manager.
Love this!<p>Notice that the text about slackware sounds a bit "pessimistic", as if it was a somewhat legacy distribution. Nothing further from the truth. We run a small farm of virtual machines with different up-to-date distributions, and slackware is typically the one that follows upstream packages more closely. For example it had gcc 9.1, bash 5, etc. a few days after they were released.
I don't like it when my process init and logging system also tries to manage my volume mounts. If I unmount a device, I don't want systemd going behind my back and remounting it for me.<p>It's non standard behavior changes like this that drive systemd hate.
Alpine is great. I have nothing against systemd but Alpine stands on it's own for containers and VMs. I haven't given it a try on baremetal but I imagine it does just as well there. Not really desktop focused but if you want to run it with a GUI on a laptop it's technically possible.
The biggest complaint I regularly see about systemd from those that don't like it is that it violates the UNIX philosophy by combining too many functionalities into one project.<p>Based upon this I found the following quote from the article in regards to Alpine Linux, a distribution based upon BusyBox which implements the functionality of over 100 usually separate executables into one, quite amusing.<p>> It is small and simple, realising the UNIX spirit to the core: doing one thing and doing it well.
I have been running Void Linux since Debian switched to SystemD both at work and at home (including playing Skyrim SSE on Steam using Proton, or StarCraft 2 and Diablo 3 using Lutris) .<p>It is a very nice distro although I would not recommend it to beginners since it is a little rough around the edges if you want to do full disk encryption during installation.<p>Initially I switched to FreeBSD and then OpenBSD but I missed Linux conveniences like native cloud sync clients[1], Steam, Docker, support for the hardware I already had, etc.<p>[1] this was before I discovered Rclone
The most recent reason I found to hate systemd was it replaced my system DNS resolver with its own (thus requiring me to modify /etc/systemd/resolved.conf, and doing the daemon-reload-service-restart-hokey-pokey, to get a host to function on a network+VPN like it did before). The only reason systemd has its own resolver is they wanted extra DNS functionality. Did I ask for these features? Did I want a new resolver? No. But that's the whole idea behind systemd. A few devs shoving complex features down everyone's throats, just because they felt like it. Operating system fascism.<p>But I don't think we should be angry at systemd developers; they can develop whatever they want. I'm mostly angry at the distributions who opted in to their crap. Systemd has not made my life easier, but it has often made it harder, and the only reason that happened was because a distro allowed it.
I've actually done sysvinit style setup before and had to migrate to systemd when it came out later. It's not that bad. It's just another way of running things. It's actually quite simple and consistent. It's a step forward.
Systemd is the worst init system except for all the others that have been developed from time to time.<p>Some of the trade-offs it makes, and its expansionist attitudes, are really grating. But it introduced a higher level of consistency in the Linux world for userland developers, which is almost invariably a good thing from a commercial perspective.
I maintain systems with and without. I thought I understood systemd, but I've given up trying to predict the behavior of systems running systemd.<p>The tragedy for me, is that I don't really like how the Init systems work, either. So there's really no one on my side. I seem to always fall into the trap of the Dreaded Centrist.
One of my biggest concerns about systemd is the ownership. Sure it is open sourced, however RedHat has a lot of pull on its maintainers (Soon to be IBM). What is to stop them from dual licensing it or close sourcing it. They have lots of products like that (jboss/wildfly...spacewalk/satellite). After everything runs on systemd the ball in in their court. Sure people can say they are going to fork it, but in reality how often does that work out (I concede are some examples where it does, X11, nextcloud, etc.).<p>In my paranoid mind I can see Redhat commercializing it and adding features to it for only paying customers after they win through attrition the monopoly on the OS (after systemd incorporates everything, resolvers, cron, ntp, etc...). They are first and foremost a business with investors and a bottom line.<p>Again not an attack on system itself, just my untrusting and paranoid nature (to many years of security scans and cve’s and users, can’t trust users)…
systemd is pervasive in the GNU/Linux world and I think it’s futile to stay on GNU/Linux and try to avoid systemd. Just look at the list of distros in the article: a bunch of obscure forks of prominent systemd distros like Debian and Arch, a distro (Gentoo) whose main claim to fame is compile it yourself, one where they say a leading Google search is whether the distro is dead, and one where they say “oh gee, we haven’t heard of it, let us know if it works.”<p>Seems to me that if you hate systemd, it’s time to try a BSD. GNU/Linux has been going down this path of complexity for years. These same arguments spawned with udev years ago, and Slackware held out then just as it is with systemd. OpenBSD on the other hand embraces simplicity and the old UNIX way. Of course it also lacks niceties like Bluetooth, but that’s the price you pay. Maybe systemd is needed to manage complex systems that support ugly things like Bluetooth.
I wish there were some way to favorite <i>discussions</i> on HN, not merely the article that started them -- if that feature existed, then this would be one of my favorite <i>discussions</i> on HN ever... why? Well, you have a ton of bright minds, who, for whatever reason(s), can't agree, yet each one adds some valuable piece of information to the debate.<p>Basically, where there's controversy (especially with bright minds) then there's always <i>something there</i>.<p>I hope that future system designers and historians will read and re-read these systemd controversies we are having in the present day... maybe we'll have some fundamental key piece of understanding then that we don't now, and based on it, everyone could agree... of course, then again, perhaps that would never happen...<p>Still, a lively, highly informative, interesting and thought-provoking discussion! A+ as far as discussions on HN go!
systemd is good, but I think it came too soon. A lot of the comments here are about memory safe languages are spot on. systemd was written with two major assumptions in mind:<p>1. Linux system complexity has exploded and needs a top-to-bottom rewrite<p>2. It's safe to do such a rewrite in C<p>Since the systemd project, I'd say #1 has been largely affirmed. I like the result of systemd because it provides uniform tooling around complex Linux systems.<p>I'd also say the tide has shifted against #2 in a big way, there's much greater skepticism that anyone on this planet (short of djb or a few others) can write safe C, let alone safe C with concurrency and side effects.<p>This is really unfortunate, because it probably means the solution is to rewrite systemd in a memory safe language, and that's a huge undertaking.
What's the recommended way for someone to <i>learn</i> systemd <i>properly?</i> Is there a readable manual somewhere that documents <i>everything?</i><p>That's the only thing I find scary about such big systems, the lack of comprehensive docs and a "starting point for learning them" from 0 to hero. Like, with Git there's tons of nice tutorials like "learn kit bottom up by reinventing it in way X" etc. plus a good "default book".<p>What's the equivalent of <a href="https://git-scm.com/book" rel="nofollow">https://git-scm.com/book</a> for systemd?
SysV init had the ability to restart, allowing upgrades without rebooting. Can systemd do that?<p>The mechanism was kind of interesting:<p>SysV init would create socketpair, then fork. The parent (with PID 1, required for correct functionality) would then exec the new SysV init binary with an option specified to make it receive state over the socket. The child would supply that state, then exit.
This anti-systemd meme is getting tiring. I generally find it is perpetuated by people who use Linux at a hobby level. Rarely do I speak with guys in Ops who dislike systemd. I am not trying to discredit people here, there are hobby users who are more knowledgeable about Linux related systems than many guys who are professionals. My point is that Linux and systemd are both meant for use on servers, in production, where speed and consistency rule.<p>I manage 3000 Linux servers and 20,000 services running on those servers. When I log into a machine and am welcomed by a RHEL6 motd I groan, because sysvinit is not enjoyable to use, it takes longer to reboot those machines, and tracking down logs is a chore.<p>When I log into a RHEL7 machine I am not elated, but I am glad to know that pid 1 isn't trying to make my life harder.
Don't Google's servers also run a custom systemd-less Debian derivative? <a href="https://www.usenix.org/node/177348" rel="nofollow">https://www.usenix.org/node/177348</a>
This list is missing a linux-ey system which doesn't use Systemd that is growing in popularity!<p>WSL!<p>WSL somewhat annoyingly has a custom/proprietary init system. Partially due to it's "interesting" integration with windows, and partially because it's not even really a full linux system yet.<p>I'm curious if with the switch to WSL2 where they will begin shipping a full linux kernel if systemd will be included or will they stick with their current custom solution?
I went on angry binge where I Ubuntu finally pushed me over the edge with it's latest... och. Between that and systemd, I've starting to dislike Linux, pretty much for the first time since I started using Linux back in the early 90's.<p>The second real, functional, genuinely working docker support shows up in *BSD and is working - I'll be running it on my desktop.
I do find it funny that people crap all over systemd, but don't seem to have a huge problem with launchd, despite the fact that systemd was almost a direct port of it.<p>Personally, while I do think that systemd's scope might have been a bit too ambitious, I do find it easier than something like Upstart
See also the search filter on Distrowatch for non-systemd distros: <a href="https://distrowatch.com/search.php?defaultinit=Not+systemd&status=Active" rel="nofollow">https://distrowatch.com/search.php?defaultinit=Not+systemd&s...</a>
AntiX Linux is my current favorite which happens to be systemd free and runs with lighter weight DEs. It takes up only about 500MB of RAM sitting still, so pretty great for older systems and laptops.
I'm a big fan of systemd.<p>Comprehensive, well organized, reliable, powerful.<p>It makes a consistent service from what was an evolutionary hotchpotch of stuff.<p>Whatever it is that the haters hate, I don't get.
We absolutely love Alpine, but it's been hard to integrate with other systems because of it using musl. For instance, our dns resolvers do not work properly & our monitoring solution is incompatible with musl.
I recommend watching this to give you some perspective on the SystemD hate: <a href="https://www.youtube.com/watch?v=o_AIw9bGogo" rel="nofollow">https://www.youtube.com/watch?v=o_AIw9bGogo</a><p>I too was furious about the existence of systemd, but now I realize that was mostly because I don't want new things and consider many new things to be bad because they are new and there have been a few 'bad apples' in my personal experience
If you are still arguing about systemd, you don't know enough about it, so you should learn about it and you don't understand the big picture. Users crying about Linux desktop all the time, but systemd has a huge part making the situation way better.