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.
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
You can? The system where I'm writing this uses systemd, yet networking is handled by NetworkManager and not systemd-networkd. Time keeping is handled by chrony and not systemd-timesyncd (or whatever the systemd NTP client was called). Etc. Systemd in fact has many components that are optional. Of course, there are also parts of it that are non-optional, just like many other collections of related software.
> Isn't linux about choice?
Linux is "about choice" to the extent that the source code is freely available, and if you don't like what upstream is doing, you have the choice to fork it and do whatever you want. "Linux is about choice" does not extend to upstream maintainers being obligated to cater to every whim of every end user.
Case in point, Devuan: Not being satisfied with the path Debian was taking, they exercised their choice and are now doing their own thing. Good for them! And to the extent this has reduced the frequency of systemd haters starting yet another anti-systemd flame war on the Debian mailing lists, it seems to me Debian has won too. Hooray!
If I use and like Firefox, and others depend on Firefox, or Firefox depend on others, then it's Firefox fault for you choosing Firefox?
I really don't understand the argument you're trying to make. You had choices before systemd, and you still have choices even though systemd is widespread, what's the problem? It isn't modular enough? Use something else then that is modular.
I believe most people moved on, but the way it was all done somehow didn't feel right.
With this new knowledge about the history, I still feel the same as the original question. AFAIK, no one is forcing people/distributions to adopt systemd. It might be easier, and most takes the easiest route, but that's OK, right? That doesn't mean that you cannot make another choice, maybe involving more work, but you can still make that choice, unless again I miss something obvious here.
This has happened with gnome's display manager, and now gnome-shell is threatening to cease functioning without systemd, as well as on systems that systemd doesn't run on such as the BSDs. KDE's new login manager is now doing the same, so in many respects, people's fears have been validated.
Here's my favorite (quickly searched for, this links to other threads): https://www.reddit.com/r/programming/comments/4ldewx/systemd...
As far as I know systemd never changed the default, people only stopped complaining because distros now override it.
> It is now indeed the case that any background processes that were still running are killed automatically when the user logs out of a session, whether it was a desktop session, a VT session, or when you SSHed into a machine.
And the reddit comments include a link to a tmux issue where the suggested solution is for tmux to add systemd as a dependency (https://github.com/tmux/tmux/issues/428). Includes some back-and-forth about how all sorts of software would have to change in similar ways to accommodate systemd, instead of systemd just playing nicely with decades of established practice.
I admin a whole bunch of headless servers and so am often SSHing to them and running long running jobs. Some of them run VNC sessions, and I certainly wouldn't want a VNC session to kill of other SSH sessions by the same user. At least with VNC, I almost never "logout" - they're often autostarted (by systemd) and just get killed when the machine gets rebooted.
But that doesn't mean it's good.
Is the claim here that Red Hat is unnecessary coupling their critical parts of the distribution in ways that other distributions would not do? A few examples here would be nice.
That doesn't seem so different from what Microsoft used to do, as even back then there was always choice if people decided to get together and exercise it, but practically in both cases it's an uphill battle.
Also, it's not just RedHat that's depending on systemd, as if its a conspiracy on their part.
https://www.theregister.com/2026/01/26/plasma_6_6_systemd_lo...
It is indeed becoming harder and harder to avoid and I understand that this isn't great, but systemd tackles some genuinely hard problems that others don't. Which is to say I don't begrudge Gnome devs for this and personally prefer systemd over current alternatives.
Personally, I am a strong believer that declaring the desired state is a lot easier to get right than actually writing the code to get there. Beyond that, I'm not saying any of these are bad at being what they are, systemd just has more features, some of which I really like. Two examples I'm actively using currently are automount units and socket activation (S6 also has socket activation). I have some remote folders mounted via SSHFS automatically when I access them and this is incredibly useful for my workflow.
Could I find tools to slot into other init systems that do this for me? Probably. But systemd has this neatly packaged up, easy to configure and easy to introspect state.
It uses a folder with a subfolder for every service. Each subfolder contains a script called run. The system runs the run script. If it exits, it waits two seconds and runs it again. Repeatedly. It's very worse–is–better.
There are commands to control the services and check their status. For example, if a file called down exists next to the run script, it won't run it. This is how you disable a service.
It checks for service folders being created and deleted. New folders are started, and deleted ones are stopped cleanly. They can also be symlinks, so you don't need to worry about deleting a running service folder and you can remove a service from init without erasing the scripts you wrote.
The whole system is useful in many situations and not only as pid 1.
Maybe one day I'll invent a runit–based distribution.
More and more software will assimilate systemd features. Free distros will patch, shim, emulate, flounder. Or in GPT parlance "Dependencies are no longer intrinsic properties of software; they are emergent properties of a distribution's systemd orchestration layer"
Meanwhile, gripes, fears etc,
'Linux' becomes interpreted vs inspectable.
Requires superfluous new literacy
Convolutes logs, tools Obscures causality
Centralized control above Unix process model
Fair well ps aux, hello systemctl, cgtop, gls
KILL (less lethalized) superceded, replaced by service stop and mask
Surrender chains for events, ie buggy debugging or complexity accretion
General obfuscation beneath the hood
Centralized ... indexed, logs vs text streams
And....
Upstream assumes systemd
Some resist
Costs rise
Optional becomes expected
Accidental incompatibility
And... systemd ingurgitates one by one, policy, supervision, logging, identity, dependency management and the rest of the world... digests it, and from the aether emerges a sweet smiley face, disgorging forth a monolithic mutant avatar, with Linux features.
I'll be quiet happy to be wrong about everything. Feel free to slaughter everything I've written. I don't even oppose systemd - I simply perceive it as a singularity that's drawing everything around me towards it. Wrong would definitely be good, so please don't hold back. I won't seek pardon for the rant though, because true or false, it's honest.
Edit: I was reading through my threads and thought the parent was asking me, though wasn't. I've unintentionally barged in here, but I'll leave the comment anyway, as it references a very big concern of mine.
Want to run xterm? Requires Xorg. rootless Xorg requires udev, udev turned into a systemd component. want to run xterm without systemd? good luck, you are now the maintainer of your own LFS.
I think it's true that it's an exhausting battle to keep all those parts independent when 95% of the devs/money agree it's better to integrate them. But it wouldn't be fair either for the 5% to put on the others the burden of keeping things independent because of their own preferences...
It just so happens that until recently xorg was the only game in town as far as Linux x11 servers are concerned.
Yes, but this is hardly a unique systemd/Linux problem. I despise TypeScript for various reasons, always preferred vanilla JavaScript over TypeScript. So if I'm met with "Huh, this library is using TypeScript, am I ready to deal with that", I make the choice to not depend on that, even though half of the ecosystem uses TypeScript.
Going against the grain comes with more work probably, but this is also a choice we make, because we have strong feelings and opinions about something.
There is point to complain about distros turning it on by default but you could have systemd where systemd just does unit management and not much more.
The hardest part to get rid of would probably be journald as this parasite's log format is just... not good in any metric but it isn't easy to replace either if you want to keep systemd functionality
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
What about "systemctl --force --force poweroff" ?
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.
Doing this is really, really error prone and fragile. Why the hell should I have to learn about double forking and PIDfe validation (and process groups and pty-or-not and all those other esoterica that daemontools still requires you to engage with if you want to do something outlandish like “run a program with a graphical component at boot”) just to make something run in the background?
I am not familiar with daemontools but I think it includes something similar to runit, which likes your processes to run in the foreground.
However, the happy path is very, very narrow. It breaks down as soon as you have to deal with:
- Set(e)uid daemons or any background service that needs to run as a different user than the one launching the service.
- Programs that report readiness somehow (the equivalent of the "notify" systemd type). Plenty of services won't crash when they should, so a standard for "it's all the way up" is useful.
- Start timeouts and failures. If daemontools is your only authority of the "status" result, recognizing a started-but-hung service is hard. Even if your service has some other "yes, the binary exists, but is it working?" check, getting daemontools+init to probe that and appropriately react to start timeouts can be fussy.
- Services that themselves spawn subprocesses (either forking or running separate child programs). Parent-process crashes are a recipe for orphaned things running and consuming resources/doing who knows what. You can solve this with a cgroup/namespacing/prctls to control orphan reparenting, but that's super hard to get right. Systemd has a one-liner for "on stop, kill this service and any program that was ever spawned in its tree". Having implemented the equivalent code to KillMode=control-group a in a few different "this has to be really reliable and bug-free" contexts now, having to manually manage this when managing services is a recipe for disaster. You'd think you know when your services will/won't have child processes, but you'd be wrong a lot (e.g. oddball JVM tracing sidecars, Pythons that always run a multiprocessing helper even if they don't use multiprocessing, Redis sometimes forking and doing bgsave, Erlang with its DNS-management child procs, literally anything ever written in Perl, Postgres, and so on. You would think that most managed child processes in big, mature software projects will know to kill themselves if their parent crashes for whatever reason. You would be wrong).
- Inter-service dependencies. Yes, many init systems take that on, but now you have the daemonization system and the init system--separate tools to configure, with overlap and expectations about each other.
- Race conditions around setting up pidfiles/locks when first deploying a service. Sure, once it's installed flock(2) will work fine, but what if you're installing a new distribution of the service and the installer picks a different lock directory from the one in use by the running service?
There are a lot more things I could list, but I'd rather not go back there. Having to manage this stuff by hand was a pretty low point for our field--as fully clued-in as sysadmins felt, we made a lot of mistakes, and made an environment that was deeply hostile to non-expert operators who just wanted to run a service and forget about it.
Systemd's far from perfect, but the challenges of doing this stuff with daemontools and friends weren't just "this is a worse implementation than systemd"; they were "this is existentially harder than using systemd precisely because it follows the 'unix philosophy' and maximizes control of (and thus responsibility for) an area where simple cases are often ... not".
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.
It's very much not the same situation for systemd.
Say you disabled LSM, rebuilt, now all stuff that requires Selinux does not work. Now what?
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.
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.
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*
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.
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.
The point of devuan is "we really do not like systemd". That's entire feature list
The problems with systemd are:
* that once it was adopted, every single package started requiring it
* which meant that packages that previously could run everywhere, now could only run on systemd-based systems
* binary logs - a solution that solved nothing but created problems
* which locked out any system that wasn't linux
* which locked out any linux system that didn't want to use it
* which led to abominations like systemd-resolved
* "bUt yOu DoNt hAVe tO uSE it" - tell that to the remote attestation crowd, of which Poettering is a founding member of. see https://news.ycombinator.com/item?id=46784572 - soon you'll have to use systemD because nothing else *can* be used.
The systemD developers don't care about any of this, of course. They've got a long history of breaking user space and poor dev practices because they're systemD. I mean, their attitude was so bad they got one of their principal devs kicked from the kernel because they overloaded the use of the kernel boot parameter "debug", which flooded the console, and refused to modify the debug option to something compatible like "systemd.debug", broke literally every other system, and then told everybody else "hey we're not wrong, the rest of the world is wrong." And this has been their attitude since then.
Look, if people want to use systemD, that's just fine. But it is a fact that the entire development process for systemD is predicated on making Linux incompatible with anything else, which is an entire inversion of how Linux and Free Software works.
I actually like unit files. But if systemD was just an init system, it would stop there.
You're saying that because the person who made systemd now work on hardware attestation, all Linux distributions will eventually require remote hardware attestation, where users don't actually have the keys?
Maybe I'm naive, maybe I trust my distribution too much (Arch btw), but I don't see that happening. Probably Ubuntu and some other more commercial OSes might, but we'll still have choices in what OS/distribution to use, so just "vote with your partitions" or whatever.
But on the other hand, you might be right, you never know how the future looks. But personally I'll wait until there is at least some signal that it's moving in that direction, before I start prepping for it to actually happening.
* Literally every game console
* Literally every smartphone
* Microsoft, with their Win11 requirements, is moving there
* John Deere (read on their own hardware attestation efforts to block DIY)
* Car companies (require specialized tooling and software subscriptions to make certain repairs)
* Anything that requires a signed bootloader and signed software updates
* Snapdragon CPUs and e-fuses that burn when you use unsigned software, and brick
* Apple hardware, literally crypto-signed so you can't use aftermarket parts
* Google Chromecast
* Amazon Kindle, locked hardware
* IBM has locked hardware to their laptops for *years*. Ever try upgrading a wifi card in an IBM laptop? They're already invested in this
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.
Today i hate systemd for its bad debugability (edit unit & daemon-reload loops), the lockups that happen whenever there is a fifo in the wrong place, and the processes that systemd spawns with no apparent related unit and without means to mask them. And the difficult to disable suspends on machines that never had any business suspending.
Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source
I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise.
There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know.
> I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.
Then along came Linux with its sysvinit-style init scripts, which were a pain in the arse.
Now here's systemd with yet another form of init scripts, which are a pain in the arse.
Each time there's been an evolutionary shift in how we do things, and systemd works pretty well for the way we use desktop systems now. They're also not terrible for servers once you get used to them. I still find them pretty annoying.
Anyway the TL;DR is that computers suck and operating systems suck and init scripts suck and the whole thing sucks, and everything else we've tried is somehow worse than what we have.
It makes me want to just go back to fixing tractors. People are really grateful when you show up in the middle of a muddy field at 10pm and fix their tractor.
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.
we had tens of thousands of init scripts where we fixed that exact problem with init scripts that were delivered with distro. It's not systemd problem and if anything systemd made it better.
> And nondeterministic service initialization is absolutely Broken and Wrong.
if your dependencies are wrong but init system works you were just lucky.
If you gonna complain, complain about no option to tell machine to shut down in a given time interval which means "my UPS got 5 minutes left pls turn off" is unsolvable under systemd unless you go thru every single unit file in distro and override their timeouts.
The big difference that created deterministic servers in the past is that you could install the server once and then leave it for 10+ years without doing any updates. People were proud of servers and services with massive uptimes with no patches and no reboots. I only see those now if they either have no internet connection or are locked down containers with very restricted network access.
Here's a dinit service file for starting my bluetooth daemon:
type = process
command = /usr/lib/dinit/dbus-wait-for -s -f 4 -n org.bluez /usr/lib/bluetooth/bluetoothd
smooth-recovery = true
logfile = /var/log/dinit/bluetoothd.log
depends-on = dbus
depends-on = local.target
before = login.target
ready-notification = pipefd:4
There's no dodgy bash script behind all of this - it's C++ that just works - I can stop start, list and reload services with reliability.
I love it.
Debian did have a fairly good init builder that attempted to do some form of dependency ordering and trickery to get things done in the right order and in the right time, where you wrote a service-like configuration file and than rebuilt the initscript. The builder then compiled the configuration files into an generated shell script. Redhat did something similar if I recall right.
Manually editing the generated shell script was seen as both dodgy, brittle and dangerous given that it could be arbitrary changed by any installed package. Some packages also sed and awk directly at the generated init script.
Stashing the PID somewhere and writing code to use the PID to work out if the process is still running and hasn't crashed so you can report a status on it. It's just a waste of one's own time doing this repeatedly and there are ways to do it badly. Every initscript repeated the work.
You could probably do something quite good with bash if you provided a library of functions and demanded that scripts be written to use them.
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...
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!
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.
Linux distros have become extremely complicated IMO. Systemd is not the worst example of this - the packaging systems are hard, things like SeLinux are very annoying. The stability is because companies have spent to make it so. There are enterprise features all over the place etc. This just isn't what all of us necessarily want. I think there's room for distros which can be understood at a technical level - which are composed of units that can be easily replaced that have defined functions.
* 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.
Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB.
> It took me about 30 minutes of googling
Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.
> Too many things just happen in the background that never used to.
The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service; run “systemctl stop srv-foo.mount” instead of just yanking out a file system from underneath the feet of any and all services which depended on that mount point.
> I never did figure out how to set the MTU in the configuration either.
“man systemd.directives”, search for “MTU”. Took maybe two seconds.
> Log files aren't where I expect them.
> I had to learn the new systemd way of doing it.
This, I strongly suspect, is your real problem.
I mean this probably depends on your distro. On Debian, it very much is saved to disk by default. And plenty of my 5GB VMs have in the past filled to 100% such that everything fails with write errors because the log files have consumed about 3GB.
> Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.
Again, fine if you know of the existence of that man page (I didn't) and know what option you're even looking for. Systemd always calls it journal as far as I knew, and doesn't use the syslog, so I didn't even think to google for syslog to change what I wanted.
> The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service
Thing is, it's all very well to say that, but it's downright dangerous to change the expectations that have held true for 30+ years without even a warning somewhere - e.g. running unmount popping warning "hey, we know you just asked for this to be unmounted, but we might just randomly remount it whenever because whatever you are doing is unimportant".
And this points to the root of the issue - UNIX has been following the UNIX way for over 3 decades. Suddenly, everything is changing, without any indication of things being different until stuff just doesn't work. This is exactly why people don't like systemd.
> > I had to learn the new systemd way of doing it. > This, I strongly suspect, is your real problem.
Absolutely.
I've got a zillion other things to do, without spending hours every time I upgrade to discover all the new ways systemd has come up with to ruin my life.
When I am forced to interact with systemd, it always slows me down unnecessarily, because the only reason I'm looking at it at all is because it's because something has changed and it's causing me pain.
Only relatively modern Debian versions. And even then, blame Debian, not systemd.
> It's downright dangerous to change the expectations that have held true for 30+ years without even a warning somewhere - e.g. running unmount popping warning
Firstly, umount “popping a warning” would break so many things, and then you really would have something to complain about. And if we really are talking about 30+ years ago, things have changed a lot since then, too. You used to stop and uninstall a service by finding its PID by running ”ps”, killing its process, and ”rm”-ing its files (and editing /etc/rc.local to remove the service’s startup line) But even before systemd, you would not dream of doing that anymore; you would run “invoke-rc.d thing stop”, or at least ”/etc/init.d/thing stop”, and use your package system to uninstall it. Those are new things since 30+ years ago.
> something has changed and it's causing me pain.
Consider quitting the technology business.
Actually, I've been using SunOS and Solaris even longer than Debian. Putting scripts in /etc/init.d / /etc/rc.d isn't "new". It's been standard for at least 30 years. Actually, maybe making /etc/rc.d symlink to the /etc/init.d is early 2000s, I can't remember, but it's certainly not new.
But also, I've written many startup scripts in my time. And no, I absolutely wouldn't find its PID using ps and killing it. In my startup script, I'd save $! in a file, standardised in /var/lock for at least 20 years, and kill that.
And no, I wouldn't manually edit /etc/rc.local - because for decades it's run everything in /etc/rc*.d specifically to prevent the need to manually edit /etc/rc.local. None of this is new.
> umount “popping a warning” would break so many things
I mean, would it really? They've modified mount to pop up a warning to tell you that you manually changed /etc/fstab and what extra steps you need to do to placate systemd just to be able to mount your filesystem. Why can't unmount also do the same, e.g. gated on being run from an interactive tty? Having filesystems randomly mount themselves after you have deliberately unmounted them is actually dangerous.
> Consider quitting the technology business.
How about you consider having some manners?
Somebody responding to a question about why people don't like X with an explanation of how exactly X has changed their workflow for the worse doesn't mean that they should leave the technology business.
I'm sorry for you that your self-worth is so tied up in systemd that you can't bear to hear any criticism of it.
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?
I see no advantages over alternative modern init systems and a ton of disadvantages. I think it's bloated, even if you can disable much of it, I don't care for the binary log format, and I don't want to support something that is encouraging so much dependency and unnecessary inter-connectedness.
Not to mention it doesn't have the best security history.
In another sense, it seems like Windows at some of its worse. The very same people who used to bitch about the registry now advocate for systemd, which I think is kind of weird.
The first is just the simple fact that most people don't want to administer their distro as a hobby. Similarly, distro maintainers primarily care about shipping a complete package that they don't need to mess around with too much. Before systemd, every distro had its own bespoke choices in tools and utilities that were wired to work together. Systemd however effectively homogenized all those choices, since almost every major distro settled on systemd. The main difference between distros now is as a result not necessarily the choices the maintainers made, but things like the package manager and the release schedule, so there's less of an incentive to use other distro's. (This isn't some sort of conspiracy, which the dumber arguments against systemd tend to assume; it's just a case where systemd winds up as the easiest choice - systemd has Red Hat backing, wires complicated things together in a way where it works on most novel PC environments that usually require config fiddling when not using systemd and it's just one upstream maintainers have to submit bugs to rather than a ton of different ones. The reasons to pick systemd as opposed to "one million tools" mostly just comes down to systemd being less of a headache for maintainers.)
The second is that systemd violates some assumptions on how Linux software is "traditionally" designed. systemd is a PID 1 process, meaning it's job is to start every other process on the system. In regular Linux software design, this would be the only thing systemd does. Systemd does this, but it also provides a massive suite of services and tools for things that, historically, have been relegated to separate tools. It's a big bulky program, that while it is modular, is essentially competing with a bunch of other Linux utilities in ways that aren't really standardized. This combines with point 1, where distro maintainers near universally settled on systemd, and what happens is that a lot of non-systemd tools that do what systemd used to do aren't really being used anymore even though the systemd implementation isn't necessarily better.
Finally there is a legitimate, albeit niche, case to avoid systemd. Because it's massive and distro maintainers tend to enable a lot of things in systemd, using it means you're getting a lot of random background processes that use up CPU/memory. If you're constrained by that sort of thing, systemd becomes a pretty inefficient hulk of a program you need to tear out.
I do think a lot of the headaches involving systemd would be simplified if the Linux space had any sort of standardization on how to wire it's tooling together, but outside of the POSIX standard (which doesn't really cover this side of things; POSIX is mainly about userspace utilities and APIs, not "how should an OS's system services behave"), there isn't any. People have rose-tinted glasses about wiring together different tiny tools, when the reality is that it was usually a pain in the ass and reliant on config flags, outdated manpages and so on. Just look at the seemingly simple question of "how do I configure DNS on Linux" and the literal 5 different ways in which it can be set since the "standard" proved to be inefficient the moment things get even a little bit more complex than a single network device handling a single connection. (Which sounds like it'd be the case, but may I introduce the concept of wifi?) Systemd being a big program avoids a lot of these issues.
>If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.
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.
And a lot of those utilities are just straight better then the alternatives, or at least make a decent practicality vs correctness trade off for desktop Linux.
systemd-cryptenroll for example is just straight up much easier to use for most applications of FDE, unless you're really doing network unlocking with something like Clevis.
Also, systemd did not create varlink, nor did they create D-Bus. They simply adopted them as the most suitable and established methods for IPC at the time.
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.
What "innovations" have been prevented or hindered by systemd? I guess you could argue "well, we can't know" but then what is the argument here really? I'm guessing there is something concrete your thinking about here, that systemd made impossible, but I'm not understanding what you're referencing, I can't recall anything like that.
Maybe it isn't as popular as you would have wanted, but I don't think that's the same as claiming it's been hindered by systemd.
Yes and the systemd crowd wants to embrace and extinguish it as well [1]
Being an old fart and sysvinit pundit I am course wrong.
Devuan lets you choose an init system so you do not have to use sys V init: https://www.devuan.org/os/init-freedom
A number of other distros also use init systems other than sysv init or systemd: Void, Alphine, etc.
When I first tried linux on the late 2000s, this was a major selling point. Something not working right? Oh neat I can actually investigate and fix or replace it instead of just having to live with it. Nowadays I'm not sure I'd see the advantage as a new user and may not bother even trying it out.
I could actually see systemd killing the whole year-of-linux-on-the-desktop thing not even because it's worse in any way, but because as time goes on the major distinguishing factors from other OSes are disappearing, so there's no longer reason for people to try it out.
Fine for 80s mainframes... not so great for modern laptops.
Although that breaks systemd as well due to renaming all of your network interfaces because one Lennart Pottering continues to insist that desktop motherboards all work a certain way despite the evidence directly in front of his eyes.
OpenRC does support parallel startup but for a desktop it's already fast enough without it - my whole Linux bootup sequence is faster than BIOS POST.
Regardless of my opinion, this choice has been done by much more knowledgeable people and results are clear. Personally, I would pick a systemd distro any time over script init based.
- daemontools
- openrc
- runit
- upstart
- insserv
- start-stop-daemonThe problem of systemd was the fact Lennart Poettering is smartest person in the universe and why the smartest person in the universe would bother to listen to feedback of any lesser beings ?
That's not how the world works. Oftentimes (most times) political decisions take place with zero or little merit.
> The problem of systemd was the fact Lennart Poettering
As I see it, his incredible arrogancy is the main source of the destructive vibe with systemd. He is actually the smartest person in this space, but paradoxically that doesn't make him right.
But I'm happily not using systemd and it's not something that causes me any particular trouble.
having to manually deal with daemons was so painful, to the point of being exoteric.
* multiple java based apps wrote pid in java which meant few secs after JVM started, so calling start -> status made status return app is not running, which tripped some tools
* mysql wrote pid in /var/run which was (at that time, most moved it to tmpfs finally, and that is also easier with systemd) not removed on stop. and on start it only checked whether PID existed in system, not what the PID was. So sometimes if some other app happened to get same PID as mysql on previous boot, mysql would not start on boot
* there was no checks on whether stuff app needs is mounted so some volume failing to mount could make app start with empty dir and lead to a mess.
It has problems. But it's also a massive improvement.
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.
> ChromeOS (sometimes styled as chromeOS and formerly styled as Chrome OS) is a proprietary operating system designed and developed by Google. It is derived from the open-source ChromiumOS operating system (which itself is derived from Gentoo Linux)
Systemd pushed forward proper usage of capabilities, better watchdogs (in a broader sense, as systemd supports all kinds of them), isolation, policies, and so on and so forth. You need it all to efficiently control the daemons, and it's great when it's all available in a single suite.
Just through some random mess of unintegrated incomplete long abandoned half baked subsystems?
I really want to know, what do you use instead?
https://www.devuan.org/os/init-freedom
It lists other options. It also lists other operating systems that don't use systemd.
I think what I hate most about systemd is that it has seemingly indoctrinated so many into believing that there are no viable alternatives, only some random mess of unintegrated incomplete long abandoned half-baked subsystems.
I have lots of 30-year old books on "Modern XXX" which makes you realise that the label is a bit meaningless. To put it another way, there are 30 year old operating systems with a much more "modern" design than Linux has...and we're not using them. It's not "modernity" per se that obviously tops the list of criteria or we'd be using something like BeOS or even Windows.
The UNIX philosophy is not a golden rule or inherently good. Nor is it even really well defined (what is a "thing"?). SystemD does one thing and does it well - managing Linux systems.
> It's not "modernity" per se that obviously tops the list of criteria or we'd be using something like BeOS or even Windows.
Just because modernity isn't the only criteria for success doesn't mean it is irrelevant.
Oh and "modern" is becoming more and more a pejorative for tech as far as I'm concerned.
It is like the cult of "The UNIX Philosophy" hardly found in any commercial UNIX that spun out of AT&T UNIX System V.
Even the defunct Upstart is better than what's in Devuan.