back
218 comments
I don't care: I can administer with relatively high confidence any Redhat- or Debian-derivate. Thanks to systems.

Most issues regarding systemd I encountered were due to a halfway adoption (Debian). Some things like timers are a bit more cumbersome than "the old way", but I wouldn't want to miss the added robustness. Most things systemd implements lead to _less_ issues. And writing a systemd unit is pretty easy, contrary to the old bash script mess.

So, no. Keep your Poettering-Bashing to yourself. I'd rather invest the time in geokking the systemd choices deeper.

That's good for you!

Isn't that a selfish view, though? "Works for me,so I don't care that systemd is creating dependencies everywhere for everyone else".

I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives.

Isn't linux about choice? It feels we're going on a downwards spiral where choice is being taken away from us in every domain

One system to rule them all, blame any issue encountered on lake of full adoption, and label them as defamation. What could go wrong?
you can use and like and still complain about things that should be better or were better under old.

systemd solved a ton of headaches but also added few more, like inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.

> And writing a systemd unit is pretty easy, contrary to the old bash script mess.

We had thousands of lines of "simple" sysv init scripts fixes because apparently even seasoned maintainers or developers of the app can't figure it out. It's huge improvement.

One example: A java app that writes its own pid. The status subcommand relies on the pid existing.

so calling start then status will return that the service haven't started yet. And that is what stuff like for example Pacemaker does so it could just randomly fail under sysv. Under systemd it's all so much simpler

You could do the same in a less invasive manner with daemontools like forever. Not only on Linux, but on BSD as well.

But people need a corporate and worse knockoff shoved down their throats, because DJ Bernstein is independent and we cannot have independent people in software.

Are you worried that you're going to become subject to attestation via systemd?
Only if you have no issue with the bloat of additional binary parsing of essentially text logs.
Well said!
In my job, I often release Linux services integrated with systemd and I like it more than the old init system.

My problems with systemd is the bloatware, not init related, that comes with it in modern Linux distributions.

In my perception systemd people doesn't respect the freedom of choice of the users, the right to simply switch off features they find useless, annoying or simply they don't want in their workflow for any reason. I have a personal wiki related to the preparation of the development server or PC I personally use and the large majority of the chapters are related to the systemd features I need or want to remove and often that is a pain. I would like to see the users' right to NOT use given secondary feature respected, giving them the capability to easily remove or disable them without side effects, for example, in the OS installer, to have the power to deselect features, having alternative options like "manual operation" (i.e. DNS, I should be able to disable the option opting for manual configuration using resolv.conf, just as example). Even better, the possibility to have an input configuration file with all your options so that them will be applied automatically during the installation.

IMHO, if all the distributions enforce the systemd way to do anything , we have a monopoly and monopolies are never good.

But why is there no such pushback agains linux kernel? What makes that monolith you cannot customize different enough from systemd? What if I don't want to use in-kernel usb stack, or audit, or key management, or LSM modules, or ELF binfmt support, or filesystems — you are forced by the distro to use all those features. Yet with systemd it's somehow different. I'm genuinely curious
I haven't used Devuan for a while but I use another systemd-free distro and I think all such distros have benefited from work that Devuan has done to keep the option on the table.

I think you can even get my favorite init system on Devuan now - dinit. It has a simple and useful service file format that's trivial to use and it can monitor and restart processes and users can use it for starting up their daemons etc - BUT it doesn't take over the world and the log file formats are all text.

Love/hate systemd as I might, it's been rock solid everywhere I've used it, and I've used it heavily. It has it's quirks, as does the init-scripts that came before, and launchd on OSX (not sure what the modern equivalent is for MacOS).

However, the systemd journal raw format is binary data and would much rather a plain text log. All things being equal I'd rather deal with human readable files.

> However, the systemd journal raw format is binary data and would much rather a plain text log. All things being equal I'd rather deal with human readable files.

It happens to be worse than text logs, worse than just spewing JSON to files, and entirely worse than most binary log formats. Every log line takes several times it would under text, duplicates a ton of info (like writing boot id in every entry) and somehow is not crash-proof (at least every non-clean shutdown gets me journald complaining about corrupt log files).

It's also dog slow in commands that matter (well documented in systemd bugs on github).

It should be just sqlite with some strategic indexes and tables. It's so bad.

Personally I would much rather they had simply used an existing database file format. For example, sqlite3 which is robust and already present in the default installation of most Linux distributions. Querying system logs with SQL would be cool and make things a bit easier unlike the sd_journal API with it's strange/bizarre quirks.
I'm probably in the minority for preferring journald's binary logging, especially alleviating the need for things like log-rotate, which I have always fought issues with. I like how RedHat distros have it setup, where journald collects the logs, but rsyslog is there parsing them into the traditional /var/log/messages and /var/log/secure, so you get some logs in plain text as well as being able to send them along to an rsyslog server the traditional way.

I haven't run into a situation with corrupt binary logs, and any crashed system I've booted with a rescue disk I can connect to the binary logs from the rescue distro's journalctl. That being said, I imagine one bad experience with a corrupt log or a non-booting system I can't get logs from would change my mind pretty quickly, but that hasn't been the case for almost a decade, so *shrug*

> However, the systemd journal raw format is binary data and would much rather a plain text log

Yeah, I also wish that at least was an option, would make some things easier.

Also wished the remote log sending was easier, not sure if it's just me but was a huge hassle to setup properly, and really hard to properly validate it works as expected in all cases. Finally got it working, but it isn't as easy as the other parts of systemd/journald.

It seems though not having systemd in it would be against "init freedom": https://www.devuan.org/os/init-freedom . Or is there some particular criteria an init system needs to satisfy to be included, that systemd doesn't satisfy but the others do?
Their criterion for an init system to qualify for this so-called "init freedom" seems to be "not being systemd".
> Or is there some particular criteria an init system needs to satisfy to be included, that systemd doesn't satisfy but the others do?

Reading the first sentence on that page was to much?

"Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice."

systemd fails on the portability criteria.

Apart from that, why should they invest there limited time to include systemd? Devuan is Debian without systemd. If you want systemd install Debian.

they could've just cut out other systemd components (ntp, dns management etc) and use systemd

The point of devuan is "we really do not like systemd". That's entire feature list

A systemd distro tends to be locked to systemd, with many pieces of software requiring systemd to be running. An init–freedom distro avoids such dependencies. Presumably, you can still install systemd if you really want to.
Yep, no "unnecessary entanglements" evidently (their words, not mine).
Honest question here: why do people hate systemd so much?
Many of us starting using Linux before systemd was a thing, and you get used to what you use, so when something new appears that are trying (well, in this case "tried and succeeded at") to replace a bunch of stuff, there is a natural push-back against it.

I think systemd also took a relatively non-unixy approach, where it's a big stack to adopt, rather than individual programs that work together well. Typically, we prefer the latter instead of the former, so some pushback is because of that too.

Because "Stop Job Running For User 1001: (22s / 90s)" with no indication of which @$%^ing stop job it is is incredibly annoying. And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. And nondeterministic service initialization is absolutely Broken and Wrong.

It's.... fine, mostly. It solved no problems I had and introduced some minor ones I didn't, and offers significantly less visibility, but it's no longer the worst offender in those regards (hello, Wayland!) so I just write it off as another of the many ways the Linux experience has gotten worse over time.

Those that love it will fight for it. Those that hate it will simply avoid using it. There may be some commercial incentives for IBM/Redhat to push for it. Either way it will always be divisive for a myriad of reasons listed below. Some sysadmins will begrudgingly support it at work and some absolutely love to support it. I have supported it in the enterprise and I use it on gaming machines at home. (CachyOS / Bazzite). My daily drivers, servers both physical and VM will always be without it. (MX Linux / Void Linux / Alpine Linux).

I only use mini-PC's these days and all the games I play work great on CachyOS. All the other daily stuff works great on MX/Void and of course running firewalls, NAS and servers on Alpine is about as simple as it gets for me anyway. Bazzite on my laptop found my Brother laserjet instantly and without adding drivers.

- Some discussion on the matter [1a][1b][1c].

- Operating systems without systemd [2]

[1a] - https://unixdigest.com/articles/the-real-motivation-behind-s...

[1b] - https://nosystemd.org/

[1c] - https://without-systemd.org/wiki/index_php/Arguments_against...

[2] - https://without-systemd.org/wiki/index_php/Main_Page/

P.S. - One Windows machine left and I think it can sense what is coming...

Its a new thing to learn.

A lot of people like the do one thing well philosophy and systemd is intended to be an entire additional OS layer. People like systemd if they want more uniformity between distros.

The systemd developers are not exactly open to suggestions and criticism. Have a look through their issues!

In 2015, systemd was a giant, immature and complex galaxy of tools, that came to replace a hacky-but-mostly-stable bunch of shell scripts. It was pushed fast. It came with good ideas and innovations. It also came with security issues, bugs, and lost productivity.

The fact that the main guy behind the project has a very... abrasive personality, and that the project got to widespread adoption through political moves more than through technical superiority, turned that dislike into hate.

But it's 2025 now, systemd has stabilized now, and I don't really see the point of all this anymore.

The "my way or the highway" approach. Both how it works and how it was pushed.
For me, I guess several reasons:

* Log files aren't where I expect them. I can't just tail the right log file, I have to figure out a load of options to journalctl instead. Its defaults are annoyingly bad and I usually end up having to type long things to limit the range to something useful.

* The journal grows massively and is unbounded by default. Many times I set up a machine, and then it runs out of disk space. It's now instinctive for me to now check whether it's /var/log/journal that's using it all. In fact, I just double checked on the machine I happened to be using now, and the journal was 2.2GB.

* It's terribly documented, or at least not in the way that's familiar to older UNIX folks. It took me about 30 minutes of googling to figure out how to change the name recorded in the journal, which defaults to the command name in ExecStart (and so was really usefully just unshare in multiple of my services). For anyone that's wondering it's SyslogIdentifier - good luck finding that yourself. It makes sense, but it's woefully under documented anywhere.

* Whenever you change files that used to be the end of it, e.g. /etc/fstab, now you have to remember to `sysctl restart systemd-mount` - why can't whatever needs it just watch the file for changes instead?

* Too many things just happen in the background that never used to. Just now for instance, I manually unmounted a drive to resize2fs it because I wanted to move the underlying data. Between running e2fsck and resize2fs, systemd had already re-mounted it read/write. Luckily, resize2fs is smart enough to tell you. If I'd been doing the actual task using dd to copy the data elsewhere, I'd have ended up with a corrupted copy.

* Just yesterday, I discovered that edits under /etc/network/interfaces.d were just silently ignored, and I had to learn the new systemd way of doing it. I never did figure out how to set the MTU in the configuration either.

* The configuration files feels Windows-like and not UNIX-like

That said, I've reluctantly started creating systemd services instead of rolling my own init scripts, and it's quite nice not having to copy all the boilerplate from elsewhere and just having a handful of lines of config. But most of the time, I feel like I'm fighting systemd rather than working with it.

It was very rough the first few years. It's fine now.
If you don't use rust, i hate you, you should use rust, and i'll force rust on you

If you don't use systemd, i hate you, you should use systemd, and i'll force systemd on you

If you don't use wayland, i hate you, you should use wayland, and i'll force wayland on you

If you don't use gnome, i hate you, you should use gnome, and i'll force gnome on you

See the pattern?

"Tricycle – Car Without Engine"

Honestly though, the argument against systemd is that it moves too much stuff into init, but I don't think it does enough of that, it's still extremely conservative, like, SD-DBus should be using binder x-port IMO.

Devuan is my go to if I need a mainline distro without systemd, but honestly I just use Alpine for everything, even my desktop. People have this idea that it's only for containers, but that isn't so - its package library has everything you could need well maintained. I like the tools better than void, and prefer the release model to that of Artix/Arch.
As a passionate systemd hater I still will not go back to using older bash-based initsystems and thus devuan.

I strongly believe that systemd brand is a worst thing that happened to Linux, hindering the spread and innovation in the Linux space, but at the same time I have to admit that systemd-as-pid1 is the best init system out there.

Always good to have options, but I'd personally never want to use a Linux without systemd.
I like Devuan because it matches the Linux I learned - people who learned with a Systemd distro might not like it as much.
Debian without systemd is a good start. Now, do Debian without dpkg, and you may finally be getting somewhere.

The reason Debian fell to the systemd behemoth is because its sysvinit scripts were already a complete disaster. Slackware and Gentoo, on the other hand, were able to stay clear of the mess because they had a decent implementation to begin with.

And Sysvinit was never the only place Debian kept its mess.

I use another distro but totally appreciate the effort to keep different branches of potential futures alive. Humans have a tendency, in tech and most other domains afaict, to put a lot of eggs in one basket because it's easier/allows-faster-moving-forward.. but that basket may have structural weaknesses that only shows once it has A LOT of eggs in it.
I have to admit to still having some philosophical discomfort over SystemD as I feel that it encompasses too much functionality. That said, it does work and that is probably the most important thing.
So how do you configure it?

Just through some random mess of unintegrated incomplete long abandoned half baked subsystems?

I really want to know, what do you use instead?

Why though? Systemd has been a huge success, dragging Linux kicking and screaming into the modern world.
never used this one but glad to see systemd free stuff. definitely interested to try thanks for sharin!
What is the newest laptop which can use S-states under Devuan? My 11-gen can not.
While other UNIX derived OSes have adopted similar systems before systemd was a thing, in Linux continues to be a drama.

It is like the cult of "The UNIX Philosophy" hardly found in any commercial UNIX that spun out of AT&T UNIX System V.

It should use some modern alternative, no old bash scripts.

Even the defunct Upstart is better than what's in Devuan.

who would use this?
My way or the highway. Classic RedHat (and GNOME, GTK, etc etc)