The year is 2013 and I am hopping mad.
systemdis replacing my plaintext logs with a binary format and pumping steroids intoinitand it is laughing at me. The unix philosophy cries out: is this the end of Linux (or, as many are calling it, GNU plus Linux)?The year is 2025 and I’m here to repent. Not only is
↫ Tyler Langloissystemda worthy successor to traditionalinit, but I think that it deserves a defense for what it’s done for the landscape – especially given the hostile reception it initially received (and somehow continues to receive? for some reason?). No software is perfect – except for TempleOS – but I think that systemd has largely been a success story and proven many dire forecasts wrong (including my own). I was wrong!
The article goes into detail on a number of awesome features, niceties, and clever things systemd has, and they’re legion. Even as a mere user, I like systemd, as every time I have had to or wanted to interact with it, it’s been a joy to use, with excellent documentation making it remarkably easy even for someone like me to get into it without doing any damage or breaking anything. Every time I read up on system’d more advanced features, I’m surprised by how well thought out and implemented it all seems to be.
I’ve experienced several major leaps forward in the Linux world that made using Linux on my computers easier and more reliable, and the adoption of systemd stands among them as one of the biggest leaps forward desktop Linux has ever made. The idea of going back to a random piles of non-standardized init scripts with nebulous dependencies from varying sources and wildly different levels of quality seems like a complete nightmare to me.
There’s a lot of charm in doing things ‘the old way’, and I’m not saying you’re wrong for wanting an init system that tries to do less, or that’s easier to read and parse for you, or whatever, but that doesn’t mean systemd is bad, evil, or part of a Red Hat conspiracy to kill Linux.
It might not be a Red Hat conspiracy, but it’s a product of our time, where software gets bloated constantly, and developers lose track of the actual benefits, until they give up and build a new project from scratch, which will start being slower than the previous one, of course.
If systemd were plugin-oriented, with different and independent parts that could be plugged in or not, then maybe it could be reasonable. But a monolithic 1.2 million lines of code for an init system? No thanks. Not to mention that so far systemd has more than 82 thousand commits — which can be translated to more than 220 years if we consider 1 commit per day. Are users more satisfied?
Also, we have many examples of distros that don’t use systemd and they’re doing just fine. This includes Slackware, which has a very solid set of init scripts. Well, at least far more solid than systemd, meaning it works without requiring constant maintenance.
Hoo boy, I’m getting my extra large popcorn for this one!
I understood the need for systemd when I was working in webhosting and dealing with MySQL processes that would crash without the init system being aware of it. Reliable service management is something older inits can’t do at all and Upstart didn’t do as well.
Yup. Having had to do instance deployments of linux at massive scales for several projects, made it quite obvious why systemd is a thing.
Phew… Systemd supports anything and everything these days. It grew an NTP client, manages your resolv.conf and fsck knows what else on top of being an init system. I only find out about yet another thing taken over by systemd when I try to change it and it reverts it or it fails. Granted, for an average user it works nicely and keeps things ticking along remarkably well, but when you’re used to UNIXness and you’re up against a d[a]emon that throws all sorts of trickery at you, it’s bound to get frustrating. It became a tradition of sorts to rant about systemd and reminisce on the good old days of sysvinit but systemd undeniably is a success story. Do I like it? No. Do I avoid it on purpose, especially as far as distro choices go? Also no.
owczi,
When systemd’s tools don’t quite do what you need, like with complex networking, it can be easier to script the old school commands directly than to use systemd networking.
I actually despised sysvinit. Maintaining state with scripts and pid files was a hack. The lack of a built in process monitor was really problematic. Almost every modern init system including systemd solved it. I wrote my own in 2005 (IIRC) and it did process monitoring too. I just wanted to say this because the set of people who rant on systemd isn’t the same as those who reminisced about sysvinit. Many sysadmins who welcomed improvements over sysvinit still would have preferred one that promoted unix philosophy and portability better than systemd.
@Alfman,
you are not wrong of course and I see it in a similar way. Also, I always liked OpenRC much more and found it easier to understand.
That said, I reflect on myself and wonder: From Wayland (which is maximum modular and kiss) we expect to be more holistic and complete, covering everything.
On SystemD, we complain that it is too monolithic. Doomed if you do and doomed, when you don’t.
For me SystemD just works and luckily it just stays out of my way and I have no need to do anything with it. Timers are very confusing (compared to cronjobs) but that was my only complaint. Though I still don’t like it.
Andreas Reichel,
I think openrc and runit are good examples of non-invasive monitoring init systems. Obviously Thom’s distro of choice uses systemd. That’s fine, but it’s rather unlikely he’d even notice a difference running a distro with a different init system unless he was working under the hood. For a regular user the main criteria is that “it just works”, and while systemd achieves it the truth is that most other init systems achieve it as well without being as monolithic.
I think the situations are a bit different. I for one don’t oppose wayland simplifying the stack and I am not trying to avoid wayland. It’s just a pragmatic decision to wait for the remaining issues to be sorted out in my distro before switching. The same can’t be said for systemd though. I don’t like the monolithic and non-portable path that systemd keeps plotting for linux. I consider it harmful to alternatives and perhaps even intentionally so. Part of the reason I migrated to linux away from windows was the appeal of the unix philosophy and in such terms systemd has been regressive.
@Andreas
I have often reflected on the difference of opinion between Xorg/Wayland and Systemd/other-init when it comes to modularity.
The Linux world celebrates modularity, interoperability, security by design, and multiple implementations everywhere except Xorg.
Systemd, the init system, is an improvement on what existed before it but I still do not like it. Like the rest of the Red Hat Linux platfom (GNU + systemd + GNOME) it is somewhat over-engineered and built to work with the rest of the platform without regard for anything else.
Most of my thoughts about it are captured fairly well by the Chimera Linux founder:
https://chimera-linux.org/docs/faq#what-is-the-projects-take-on-systemd
LeFantome,
From your link…
This view is entirely omitted from the article, but I think it should be included because many people feel this way.
Systemd proponents almost always compare it against legacy sysvinit scripts, which so many of us hated long before systemd entered the picture. Most of us were never against replacing init scripts. Instead, most of us strongly dislike systemd for failing to embrace the unix KISS principal where you’ve got simple tools that do one job and do it well. Yes systemd has been made to work, but it’s come at a cost of making everything more difficult to decouple from systemd. Frankly systemd’s monolithic approach makes linux less flexible and more windows like – for better and for worse.
Kroc is right, behind the scenes systemd is becoming an OS onto itself especially as it keeps displacing non-systemd tooling.
Kroc is paraphrasing an old (OLD!) meme about GNU/Linux attributed to RMS[1], but ironically he’s not wrong. We do seem to be moving towards a GNU/systemd/Linux paradigm, for better or worse.
I feel there will always be a small group of folks who hate systemd enough to maintain their systemd-less forks of major distros, and then there are those like me who could take or leave systemd but my distro of choice (Void) can’t use it for technical reasons. The init system on Void, runit, is perfectly fine and far less complicated than systemd. With that said, if Void ever embraced systemd I’d be along for the ride as it’s the distro itself, not the init system, that appeals to me. I trust that the Void devs know what they are doing.
[1] https://stallman-copypasta.github.io/
@Morgan
What are the technical reasons that Void cannot use systemd? I assume that it is because systemd does not work with musl and Void offers a musl option. Is there something else?
The fact that distros cannot use systemd due to totally unrelated engineering choices illustrates quite nicely the problem with systemd in my view.
That said, the fact that glibc and musl are incompatible in this way makes the same point about glibc and GNU generally in my view as well.
More and more, I see this all as a symptom of the Red Hat Linux Platform. They contribute more to Linux than anybody. But they basically build all their stuff only to work with their other stuff. If you step off the path, that is your problem.
That’s it, in a nutshell. As I said, I’m along for the ride; it’s Void itself that appeals to me, not the init system (though runit is perfectly fine and does exactly what it needs to and no more).
I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, Systemd/Linux, or as I’ve recently taken to calling it, Systemd plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd daemon, shell utilities and vital system components comprising a full OS as defined by POSIX…
The systemd folks do a decent job of documenting the features of systemd that they want you to use in the default manner.
But they do a lousy job of documenting how to minimize systemd, how to disable portions of systemd, how to bring systemd under the user’s control. It’s kind of like Apple. Apple will tell you how to use your device the approved Apple way, but once you start wanting to change the configuration to suit your needs you will have to find documentation from external Apple-hacking communities.
And unfortunately with systemd, there aren’t really any systemd-hacking communities that have sprung up. For the most part, you either use systemd or you don’t. And so you either use systemd in its rather bloated and sometimes annoying release state, or you go use Devuan or MX or antiX or Guix or Hyperbola or a similar distro that replaces systemd with a different init manager.
No matter how many youtubers from the southern hemisphere will mock this idea, systemd slows down the system. Of course, you won’t notice this on a hardware setup built around the fastest i9 processor. I recently discovered that a certain Debian fork without systemd is available for the Raspberry Pi. This fork is the fastest way to use the Pi 5 as the desktop PC. It’s the Debian 12 experience running as fast as good old Debian 7 did. The Raspberry Foundation should embrace it and base RaspberryPi OS upon it instead of Debian mainline.
Can you share the name of this fork? I’ve looked around and can’t find anything other than a really old fork of Devuan Ascii for the RPi3. I’d be interested to test it alongside the official Raspberry Pi OS on my RPi5. Thanks!
Look there: arm-files.devuan.org/RaspberryPi%20Latest%20Builds/
Last time I mentioned that distro by its name my comment here was deleted.
Thanks, I’ll have to check that out. I had a feeling it was still Devuan, it just didn’t pop up when searching for it.
Heh, wonder what the deal is I’ve never heard of any controversy there.
Meh, systemd just reminds me a lot of svchost on Windows land.
It’s not bad, just not my cup of tea, so I ended up moving all I could to FreeBSD. We can have it both ways.
{q]systemd just reminds me a lot of svchost on Windows land.[\q]
Seems fair and is especially annoying when you are aiming for a slim, single purpose VM guest that runs only a VPN client or something.
This is literally why Alpine Linux exists. It’s designed to run in containers and VMs, is extremely small and light weight, and it also works great on bare metal. It uses OpenRC instead of systemd, and is built on musl instead of glibc.
[q]Seems fair and is especially annoying when you are aiming for a slim, single purpose VM guest that runs only a VPN client or something.[\q]
Well, exactly, and as Morgan mentioned, there are really options for everyone these days. So I do not see the reason for all the drama.
For example, my FreeBSD setup is extremely lightweight (no bluetooth support, since I don’t use it, for example) webcam drivers loaded on demand, touchpad disabled and no driver loaded (I use the trackpoint).
The whole X11/Wayland drama worries me a bit more, but just because waning X11 support may condemn older computers to the landfill. But the situation with systemd is not bad. Yes, you may not be able to use GNOME/KDE so easily anymore, but there are endless desktop environments that are not dependent on systemd and, honestly, I haven’t had issues to run anything I need under FreeBSD and even gaming is in a pretty decent shape (albeit not so straightforward to run).
If you are on Linux land, yes, you get Alpine, Adelie, Slackware, Gentoo and many others that can make do without systemd and are popular and well supported.
(binary logs will annoy me until the end of my days, though)
However, as many of us said in the early days, it must/has to be a requisite layer, despite claims of their leaders that “it’s optional”. It’s not. It can’t be. systemd, to those that could see clearly (why couldn’t the devs at the time see clearly??) has to be “everything” essential to have what most would consider to be a operational platform to build upon. Without it, everything crumbles. And now, finally, as if the “magic lava lamp” was turned on, the devs are seeing systemd as that requisite piece of the system as both Gnome and KDE have made it requisite as it, and it alone, defines “what a session is”.
Anyway, say what you will. Sometimes very “smart people” are complete idiots.
Yes. I used to enjoy KDE but I am ok without it. openbox FTW.
I guess it’s just way more convenient for developers not to have to worry about providing services that systemd can provide and it is probably a relief – they can focus on the the purpose of the product rather than scaffolding. I don’t blame them, and, even though I’d rather have everyone keeping their code fully portable and as self-contained as possible, I’d not go as far as you and call them idiots.
As a very poor programmer, I can appreciate the effort. During my free time, I write a small multithreaded fully portable very simple game engine, and I try to make sure the same code base runs on everything I own – meaning everything between IRIX and FreeBSD, passing through Windows CE, nextstep and Linux. It is a bag of hurt. cthreads vs pthreads vs windows threads, dps vs X vs win32, IO. What I do is extremely simple and I go through the point of creating wrappers for everything exactly because it keeps me in touch with how complicated the modern infrastructure is.
So, yes, I’d love just be able to easily install modern KDE and not have to worry about Wayland or systemd shenanigans. But I also understand their point.
As long as we have alternatives, it is ok.
Shiunbird,
I don’t really agree. I accept that my own personal reasons for disliking systemd are not going to matter in the least to people who don’t really care about the unix philosophy and the KISS principal. I have to concede that for people who don’t care about decoupled software and unix philosophy, the case against using systemd is weak. It does work after all. However I also think the case against using non-systemd init systems is also very weak. When you write your own distro decoupled tools are not more difficult to use and they can be better suited to customization.
If you’re worried about downloading and compiling numerous tools, busybox can be a big time saver.
https://www.busybox.net/
One build gets you practically everything you need to build an OS userspace. It’s very popular in routers. Despite being built into a giant binary ball, the tools are all traditional decoupled applications that do not depend on each other and busy box doesn’t presume to know better than the system admin. If you’re building a distro, I highly recommend it. It even includes a simple runit init system. But because of it’s decoupled design you’re free to use something else.
For me this is the real power of unix. Systemd drags linux in the direction of windows where one size fits all. It works, but I suspect it will always ruffle the features of unix traditionalists.
Yes. This experience is very common to anyone porting software.
Your best bet in the future is probably to use a framework where the portability layers are already abstracted from you. For example I’ve used fltk, a very lightweight toolkit, to good effect.
Other frameworks like QT and GTK exist too, but are more bloated.
Edit: I see my quote was a bit haphazard and could be interpreted as my disagreement with you not calling people idiots, haha. It was the first part where you said systemd is more convenient than other init systems that I disagreed with.
Both KDE and GNOME are available on non-systemd distributions and will remain so.
Exactly. I use KDE Plasma on Void Linux on my main workstation, and I’ve used GNOME on OpenBSD in the past. There is always someone out there willing to do the heavy lifting to make their DE of choice work on their OS of choice.
This is not because KDE or GNOME are doing anything. This is because programmers are making the effort of simulating some systemd services for those desktops. You can easily find in lists how much work it is.
bemcl,
That’s really what it comes to when talking about decoupled versus monolithic design. Morgan’s comment above is right that someone will be there to do the work and FOSS means it will always be possible. But it’s not really ideal that linux is evolving in a direction that forces others to do more work to run the same software.
Somehow, SystemD and Wayland are in the same box in terms of people complaining about changes in the environment of Linux systems. I fully understand that people loving UNIX diversity and BSD users, are concern about these 2 software packages made just for one of the kernels of the UNIX family. However, SystemD is also breaking the KISS concept, even worst for UNIX lovers.
“Evil” is a strong word, but I think it’s OK for people to say they don’t like the direction of things. Developments don’t happen in isolation, and systemd is more than just technical. I personally don’t trust its ethos.
I’m not a fan of systemd, but a lot of the things that I dislike about it aren’t the usual ones (although I’m definitely not a fan of the binary logs with well-known UUIDs; any log functionality beyond what basic text files provide should be done with a separate binary file on the side rather than making the base log binary). Some of my criticisms of it relate to its extensive use of ad-hockery instead of actually having proper extensibility. I definitely am not one of those reactionary minimalists who thinks that traditional SysV or BSD init is all you’ll ever need, and think that a stateful init system with built-in support for dependencies and starting units on demand is a good idea, but systemd goes about doing that kind of thing in the wrong way (my criticisms of Wayland are also very similar to systemd).
The biggest one I have is that despite it trying to unify a lot of things, there is one major thing it doesn’t touch at all, which is event handling. Linux and most other modern OSes have a lot of ad-hoc daemons that each manage a particular type of event, such as udisks, NetworkManager, udev, and the like. All of these could probably be replaced by a single event daemon that handles all types of events and reacts to them by running external commands defined by unit files. I think I remember hearing one of the systemd devs object to generic event handling for some reason. I really can’t think of any reason why somebody would object to something like that other than Linux developers having a habit of being purists on stupid things. The only major problem I can see is that such an “event superserver” on Linux could have issues when it comes to listening for events due to the ad-hoc nature of the kernel APIs and the kernel developers being a separate group from anyone developing an init system. It would be relatively easy to implement such a thing on an OS with something like a unified file-oriented API.
Another one is its use of a built-in parser for unit files with only the somewhat limited support for generators as a way to implement dynamic units, rather than having a generic API for creating a unit in memory and the parser being an external command that acts as a client. A generic API would allow more flexibility when it comes to creating dynamic units.
In a similar vein, I’m not a fan of the way it shoves a whole lot of functionality into process 1. I much prefer the way SMF on Solaris is structured, with a very minimal process 1 that only acts as a failsafe, most of the core unit-handling functionality in a library, and separate delegated restarter daemons for different unit types. SMF certainly isn’t perfect (I’m definitely not a fan of its heavy use of databases and XML), but I do like the way it’s modularized.
I should have dropped this here earlier. It is an attempt to make Systemd more modular and portable so that it can be used by systems like BSD.
https://github.com/InitWare/InitWare
InitWare’s philosophy differs from that of systemd by the Three Shoulds:
InitWare should be highly portable. It runs on all major BSDs (including macOS) as well as GNU/Linux. Ports to other Unix platforms (e.g. Illumos) are a future goal.
InitWare should be modular to a significantly greater degree than systemd. This is in terms both of software architecture and functionality; note for example that InitWare doesn’t have to be run as the init system.
InitWare should have a clearly-defined scope, concerning itself only with system, service, and session management, and matters ancillary to these, such as event log management.
Looks promising.
i don’t exactly like the entire ecosystem that grew around systemd, but it’s mark of the times.
init system has to bring up the system and its services . and systemd does that – it’s just that the scope is broader now. it used to be simpler, but as time went on, it required more and more patching and workarounds on top of the old init – cron, xinetd, user-services, hardware triggered services – not a lot of init systems that can handle it all.
ability to limit resource per service, isolate them in cgroups and separation into namespaces (network,process,logs, etc)
on top of that unified service definition that works on every distribution out there.
also, systemd introduced some very welcome generic improvements to the kernel, and Linux userspace in general. we have now the /run directory, instead of various dubious workarounds, for instance.
the fact that some people were kicking and screaming when systemd was introducing some related improvements to other projects may suggest that they were, in fact, going in the right direction.
But systemd is so darn slow… not only at booting, but also achieving its tasks. runit runs circles for the most part on Void.
Another bonus side effect to systemd yes. Moving from Debian after a solid 10 years to MX Linux was an “OMG yes” moment for me. Went from Windows boot times to Linux boot times again.
I’d say systemd is a conspiracy by RedHat to make Linux require more certifications 🙂
The traditional init systems were too intuitive.
The worst part – and not only RedHat is guilty of it – is that all this modernity assumes a server running in a data center. Do you know how long systemd takes to timeout when it’s started without internet connectivity?
Do you know all those super duper network managers Ubuntu seems to rewrite every 3 LTS releases cannot configure or even integrate with a manually configured pppoe easily? Why would you want to run Ubuntu on your home router when you can run it inside a container in a data center?