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
How is it someone's else's fault for that systemd has dependencies or that others depend on systemd?
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.
Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.
So if you don't like that, don't you still have the choice not to use software developed by Red Hat?
Embrace extend extinguish tactics, now celebrated in Linux land.
You had choices before, you still have choices, how is that EEE? There never been more distributions available.
They do, they just want to whine about software other people made (that they don't contribute to) doing something they don't like.
Which software has hard dependencies on systemd?
Also, it's not just RedHat that's depending on systemd, as if its a conspiracy on their part.
Gnome, for example. GDB now needs systems's userdb.
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.
With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
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.
The udev developers decided that it made sense to move udev into systemd. If you disagree and want choice, you can fork udev. Actually some people did that, so you can run xterm with eudev instead of udev and thus avoid systemd (though eudev seems hardly maintained now, with the latest release in 2023).
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...
> With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
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.
> 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.
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!
You can turn most parts off. Maybe don't talk about stuff you have not much idea about ?
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
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
> inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.
What about "systemctl --force --force poweroff" ?
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?
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.
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.
One feature of the Journal format which I don't believe to be a great design choice is that entries can contain non-unique fields. Unfortunately this doesn't seem to be something that is handled well by all tools, instead only returning the value for the first field of an entry with the provided name.
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.
> 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".
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
Yep, no "unnecessary entanglements" evidently (their words, not mine).
> Unnecessary entanglements
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.
literally everything the systemD crowd has done leads to lockout and loss of choice. All ramrodded through by IBM/RedHat.
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.
> * "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.
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.
If you build remote attestation into your product, corporate entities will require it. Just look at Android - What phones today give you unlimited root? If you have rooted, what applications have you broken? If you root, what e-fuses have you blown in your CPU meaning it can never be un-rooted? Android, at the start, was open and freely modified - not so much anymore. Companies like Google can and have cut off access to user's data, without recourse. You can't modify your phone, so you don't own your phone. You just pay rent until they don't support it anymore.
I think phones are a completely different beast though (and already a lost cause), PCs seems a lot more resilient to that sort of lock down.
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.
People have been saying this since day dot. It was very controversial for Debian to change to use systemd. The vote was close due to many arguments which are still being played out
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.
Honest question here: why do people hate systemd so much?
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.
> 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.
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.
I mean, 25 years ago I don't think any shop used the distro-supplied init scripts; those were just a skeleton you used to get the system into a state where you could edit them.
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.
Initially i hated systemd for the change it bought and lennarts behavior, but today I'm wiser.
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.
It's that lack of visibility that still makes me low-key hate it, though it's no longer the part of the modern Linux ecosystem that I hate most so I mostly just accept that it's part of watching a platform I used to really like enshittenate itself.
I started using Unix before Linux was a thing, and BSD-style rc scripts were a pain in the arse.
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.
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.
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!
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.
As my friend said:
>If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.
It was very rough the first few years. It's fine now.
Ignoring the more stupid reasons why people dislike systemd; there's really only three reasons.
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.
"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.
The thing is systemd really doesn't: the things people claim "shouldn't be in an init system" aren't - but there are systemd branded versions of a lot of basic facilities because you generally need something like them in a usable system.
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.
It should use some modern alternative, no old bash scripts.
Even the defunct Upstart is better than what's in Devuan.
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.
> hindering the spread and innovation in the Linux space
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.
alternate libc's like musl. the eglibc controversy showed this was necessary but poettering initially refused to support a "non-useful libc". his words.
But musl exists today? And even I use it from time to time, mostly I think in Alpine Linux. How was musl hindered if we can use it?
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.
> As a passionate systemd hater I still will not go back to using older bash-based initsystems and thus devuan.
A number of other distros also use init systems other than sysv init or systemd: Void, Alphine, etc.
The great thing is that there actually ARE options that are far better than init scripts and they don't have to be like systemd.
I remember the time before systemd and there wasn't any innovation happening - everyone was content with hacky bash scripts.
Legible, discoverable, debuggable. They listed the commands the computer needed to run, in the order it needed to run them, to get the system running. It was absolutely beautiful. And then LSB came along and broke it, and as a result of that systemd now manages my home directory and cron tables. Shame, really.
Systems were simpler then and demands were lower. So what if the system boots sequentially and takes two days to boot up. But try to make it parallel and faster, and the whole house of scripts falls down or becomes illegible, undiscoverable and completely unmaintainable mess.
My system is still simple and I still don't have whatever requirements SystemD is needed for.
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.
There were other innovative systems - they just weren't adopted by the major distos - other than I think Ubuntu.
if other systems had actual good idea about how to do pid 1, they'd be used. Systemd despise its issues solved a lot of problems. There were many before but most just aimed to be slightly less shit sysv.
The 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 ?
Other systems are getting used. They're just not getting adopted by the major distributions ...presumably because they've decided that conformity helps.
But I'm happily not using systemd and it's not something that causes me any particular trouble.
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.
Linux (the kernel) has LOTS of functionality anyone barely use or even know. Without that, there's no tooling around this functionality, no adoption. Not even all TCP socket options (setsockopt) are documented!
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.
There are other things just work too.
Always good to have options, but I'd personally never want to use a Linux without systemd.
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.
Yep, the Linux kernel comes to mind. There are niche alternatives but mostly everyone settles on Linux as their kernel because it's easier and allows moving faster forwards.
never used this one but glad to see systemd free stuff. definitely interested to try thanks for sharin!
I like Devuan because it matches the Linux I learned - people who learned with a Systemd distro might not like it as much.
I personally am very much happy that Linux is not like the Linux I learned. Slackware was an excellent learning experience and will always hold a dear place in my heart and memories, but not on any of my computers.
same. i still remember how painful it was to setup services without systemd.
having to manually deal with daemons was so painful, to the point of being exoteric.
The worst was editing an existing service for the distribution. With systemd you just need an override file, without, you have to patch the file and review it each time it is upgraded to check the differences.
Exoteric is the opposite of esoteric, which is the word you mean :)
I liked it coz I did remember the old ways (as in kernel 2.2.x old) and they fucking sucked. Few examples of bugs I had to fix in sysv that just can't happen in very simply written systemd unit:
* 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.
I can use systemd but it's always annoying to configure and sometimes randomly breaks and it's hard to know why. init.d scripts are no better, though. Runit is quite cool.
runit is optional on Devuan.
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.
Why though? Systemd has been a huge success, dragging Linux kicking and screaming into the modern world.
It lacks the UNIX philosophy really. Binary logs are a sort of example of the attitude it has. That's why there has been kicking and screaming that you mention.
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.
Some people try to run Linux on Apple hardware, don't ask me, some people seem to be "technical masochists" :)
Indeed, as mentioned in another comment, all major UNIXes already had something similar in place.
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?
A quick perusal of the site yields this page, which tells you what it uses by default: sysvinit.
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.
who would use this?
Very resource constrained systems, systems where consistent admin between *BSD and Linux is important. Containers where you have reasons to break the single process practice.
Your phone. Haven't looked into Android images for at least a decade but it was just simple bash scripts back then.
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
How is it someone's else's fault for that systemd has dependencies or that others depend on systemd?
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.
Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.
So if you don't like that, don't you still have the choice not to use software developed by Red Hat?
Embrace extend extinguish tactics, now celebrated in Linux land.
You had choices before, you still have choices, how is that EEE? There never been more distributions available.
They do, they just want to whine about software other people made (that they don't contribute to) doing something they don't like.
Which software has hard dependencies on systemd?
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...
Gnome, for example. GDB now needs systems's userdb.
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.
With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
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.
The udev developers decided that it made sense to move udev into systemd. If you disagree and want choice, you can fork udev. Actually some people did that, so you can run xterm with eudev instead of udev and thus avoid systemd (though eudev seems hardly maintained now, with the latest release in 2023).
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...
> With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
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.
> 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.
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!
You can turn most parts off. Maybe don't talk about stuff you have not much idea about ?
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
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
> inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.
What about "systemctl --force --force poweroff" ?
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?
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.
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.
One feature of the Journal format which I don't believe to be a great design choice is that entries can contain non-unique fields. Unfortunately this doesn't seem to be something that is handled well by all tools, instead only returning the value for the first field of an entry with the provided name.
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.
> 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".
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
Yep, no "unnecessary entanglements" evidently (their words, not mine).
> Unnecessary entanglements
The problems with systemd are:
literally everything the systemD crowd has done leads to lockout and loss of choice. All ramrodded through by IBM/RedHat.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.
> * "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.
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.
If you build remote attestation into your product, corporate entities will require it. Just look at Android - What phones today give you unlimited root? If you have rooted, what applications have you broken? If you root, what e-fuses have you blown in your CPU meaning it can never be un-rooted? Android, at the start, was open and freely modified - not so much anymore. Companies like Google can and have cut off access to user's data, without recourse. You can't modify your phone, so you don't own your phone. You just pay rent until they don't support it anymore.
I think phones are a completely different beast though (and already a lost cause), PCs seems a lot more resilient to that sort of lock down.
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.
People have been saying this since day dot. It was very controversial for Debian to change to use systemd. The vote was close due to many arguments which are still being played out
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.
Honest question here: why do people hate systemd so much?
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.
> 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.
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.
I mean, 25 years ago I don't think any shop used the distro-supplied init scripts; those were just a skeleton you used to get the system into a state where you could edit them.
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.
Initially i hated systemd for the change it bought and lennarts behavior, but today I'm wiser.
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.
It's that lack of visibility that still makes me low-key hate it, though it's no longer the part of the modern Linux ecosystem that I hate most so I mostly just accept that it's part of watching a platform I used to really like enshittenate itself.
I started using Unix before Linux was a thing, and BSD-style rc scripts were a pain in the arse.
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.
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.
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!
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.
As my friend said:
>If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.
It was very rough the first few years. It's fine now.
Ignoring the more stupid reasons why people dislike systemd; there's really only three reasons.
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.
"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.
The thing is systemd really doesn't: the things people claim "shouldn't be in an init system" aren't - but there are systemd branded versions of a lot of basic facilities because you generally need something like them in a usable system.
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.
It should use some modern alternative, no old bash scripts.
Even the defunct Upstart is better than what's in Devuan.
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.
> hindering the spread and innovation in the Linux space
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.
alternate libc's like musl. the eglibc controversy showed this was necessary but poettering initially refused to support a "non-useful libc". his words.
But musl exists today? And even I use it from time to time, mostly I think in Alpine Linux. How was musl hindered if we can use it?
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.
> As a passionate systemd hater I still will not go back to using older bash-based initsystems and thus devuan.
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.
The great thing is that there actually ARE options that are far better than init scripts and they don't have to be like systemd.
I remember the time before systemd and there wasn't any innovation happening - everyone was content with hacky bash scripts.
Legible, discoverable, debuggable. They listed the commands the computer needed to run, in the order it needed to run them, to get the system running. It was absolutely beautiful. And then LSB came along and broke it, and as a result of that systemd now manages my home directory and cron tables. Shame, really.
Systems were simpler then and demands were lower. So what if the system boots sequentially and takes two days to boot up. But try to make it parallel and faster, and the whole house of scripts falls down or becomes illegible, undiscoverable and completely unmaintainable mess.
My system is still simple and I still don't have whatever requirements SystemD is needed for.
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.
There were other innovative systems - they just weren't adopted by the major distos - other than I think Ubuntu.
if other systems had actual good idea about how to do pid 1, they'd be used. Systemd despise its issues solved a lot of problems. There were many before but most just aimed to be slightly less shit sysv.
The 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 ?
Other systems are getting used. They're just not getting adopted by the major distributions ...presumably because they've decided that conformity helps.
But I'm happily not using systemd and it's not something that causes me any particular trouble.
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.
Linux (the kernel) has LOTS of functionality anyone barely use or even know. Without that, there's no tooling around this functionality, no adoption. Not even all TCP socket options (setsockopt) are documented!
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.
There are other things just work too.
Always good to have options, but I'd personally never want to use a Linux without systemd.
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.
Yep, the Linux kernel comes to mind. There are niche alternatives but mostly everyone settles on Linux as their kernel because it's easier and allows moving faster forwards.
never used this one but glad to see systemd free stuff. definitely interested to try thanks for sharin!
I like Devuan because it matches the Linux I learned - people who learned with a Systemd distro might not like it as much.
I personally am very much happy that Linux is not like the Linux I learned. Slackware was an excellent learning experience and will always hold a dear place in my heart and memories, but not on any of my computers.
same. i still remember how painful it was to setup services without systemd.
having to manually deal with daemons was so painful, to the point of being exoteric.
The worst was editing an existing service for the distribution. With systemd you just need an override file, without, you have to patch the file and review it each time it is upgraded to check the differences.
Exoteric is the opposite of esoteric, which is the word you mean :)
I liked it coz I did remember the old ways (as in kernel 2.2.x old) and they fucking sucked. Few examples of bugs I had to fix in sysv that just can't happen in very simply written systemd unit:
* 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.
I can use systemd but it's always annoying to configure and sometimes randomly breaks and it's hard to know why. init.d scripts are no better, though. Runit is quite cool.
runit is optional on Devuan.
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.
Why though? Systemd has been a huge success, dragging Linux kicking and screaming into the modern world.
It lacks the UNIX philosophy really. Binary logs are a sort of example of the attitude it has. That's why there has been kicking and screaming that you mention.
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.
Some people try to run Linux on Apple hardware, don't ask me, some people seem to be "technical masochists" :)
Indeed, as mentioned in another comment, all major UNIXes already had something similar in place.
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?
A quick perusal of the site yields this page, which tells you what it uses by default: sysvinit.
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.
who would use this?
Very resource constrained systems, systems where consistent admin between *BSD and Linux is important. Containers where you have reasons to break the single process practice.
Your phone. Haven't looked into Android images for at least a decade but it was just simple bash scripts back then.
[dead]