I was averse to systemd initially, and held on to my legacy init for as long as I could until my distro totally switched over and just stopped supporting the legacy stuff.
At that point, I realized I don't actually want to manage an init system. Which further lead me to the realization that I wasn't actually working with the thing very often, and brought into question my qualifications for having strong opinions on the topic.
I see lots of arguments against systemd that, to my untrained eyeball, seem pretty compelling, and lots of groups who are doing the actual, non-hypothetical work who seem to've ignored the arguments and switched over.
Most of the arguments are theoretical or probabilistic.
It's true that more code means more places for bugs to hide. It's also true that systemd and it's fans(myself included) don't really care about init freedom.
Obviously, no self respecting FOSSer is going to sabotage alternatives actively, but we don't use or know the alternatives, so there could be subtle bugs.
But systemd does work. It's not what I would call buggy. It doesn't appear to impede performance.
And very consistently, whenever I think "Oh, how do I do X", there's a clean and purely declarative way to do it, that hooks into all the logging and monitoring perfectly.
Systemd goes a long way to making Linux work like an OS, rather than a build-an-os kit.
The people who are against it tend to be very security conscious. Not "I use 2FA" conscious, but "I will wholesale refuse to visit a popular site that I believe is selling my telemetry data" level.
A lot of the others are enthusiasts. They want to control and understand the machines they own, and don't want any black boxes, and they are almost as grossed out by anything "overkill" as most people are by a drawer of urine. They don't care if it's tucked away, they don't like it being there and don't trust it, no matter how well it performs who who did a 3rd party audit.
Systemd seems highly inappropriate for people who really like the old Linux modular kit approach, or anyone who doesn't like big things.
But the majority of big corporate and average home users seem to love it, and I wouldn't want a distro without it.
The arguments against it are valid, but usually only if you share the same values they tend to be based on.
There is definitely a significant lack of allergy to complexity among today’s software developers. Complexity is very bad, and it is usually not necessary. Lots of things that people write today are FAR more complex than necessary for no reason other than “best practice”.
Need to instantiate an object? Better have an AbstractObjectFactory, an IObjectFactory, an ObjectFactoryImpl, an ObjectFactory, and an ObjectBean or you will not make it through code review!
There is no room for simplicity in today’s software development world, no matter what language you use, unless you are ready to spend lots of time every single day explaining yourself. It’s sad.
Best practices exist for a reason. If you know for a fact that small lightweight software is not what you are building, and your codebase will probably be bazillions of lines, you can often guess that you probably are gonna need it.
If you want to make Chrome or LibreOffice, you're probably going to need some abstractions.
I've very rarely seen any true IObjectFactoryInstanceMethodAdderMixinAbstractInterfaceBean level stuff, most of the complexity people complain about serves a purpose, at least that I see. It facilitates building complex software with a large amount of reuse and with way more dev effort than one wants to make.
Simplicity is usually harder than complexity, and a lot more design decisions to get right. Complexity is often just following a template. Need to encode something? What's the most popular JSON encoder in your language? Need web stuff? Pick the best practice one, you know it will be around a while and you team already knows it.
You can go overboard, and simplicity has virtues, but it's pretty cool how well everything can just come together without much friction if you really, really aggressively avoid doing anything interesting and "Just do what the industry standard is".
The difference I've noticed is that the complex stuff might bolt together quickly, but it's all broken 6 months later as the shifting sands that underpin it are blown by the prevailing winds of fashion. This sort of software requires constant maintenance, often by large teams, or it immediately begins to bitrot.
Well-thought-out simple stuff, on the other hand, can last for decades and often is quickly adapted to novel devices and environments.
The converse can be just as true, some indie dev instead of a feature-packed, stable dependency will reinvent the wheel because that a subset of those should be enough he/she thinks. Now that code can only handle 80% of the cases because it turned out the complexity of the dependency was not meaningless, and it is buggy and much less maintainable.
> you know for a fact that small lightweight software is not what you are building
Maybe this is the point to stop and ask yourself, if you're doing it right? There is no industry standard for complexity.
It's the "dd" vs "balena etcher" argument. There is very small benefit to the average end user from literally 2000x increase in size/complexity, and for experienced user, fancier tool is actually worse (can't do "ssh foo cat blah | gunzip | dd")
dd vs Etcher is actually my canonical examples for why I'm totally fine with complex software.
dd doesn't verify after flashing. It doesn't alert when you're finished. It doesn't predict the time remaining. It
On Reddit, I see about one "I wiped my disk with dd" post every month or two(Although I suppose using by-path might have prevented some of them, it's slightly more obvious).
Even more relevant is the raspberry pi imaging utility that also lets you set some configuration options when flashing.
It doesn't do anything you couldn't do with a shell script, and Etcher certainly doesn't actually need to be that big.... but it already exists, and using etcher instead of a custom script is one less custom thing to maintain.
I can tell anyone on any platform "Oh yeah just use Etcher" and have a near guarantee they will know exactly what to do and not break anything.
40-80MB seems like a lot. I'm pretty sure you could build a clone in PyQt in a weekend. Etcher is also missing some features(I'd really expect it to be a full studio with plugins to configure the images, make backups, and test in QEMU, considering how big it is).
But Etcher exists already. Using it is one less thing to worry about, one less custom script to possibly maintain, and one less possible mistake that could wipe a disk.
Outside of some 1-2 decades old frameworks, can you show me a singular example for any of your ObjectFactories? Because I really think that the field as a whole moved a bit away from such deep object hierarchies and even in OOP circles will try to use as few levels as possible.
Also, don’t forget that complexity can be divided into two categories: essential and accidental complexity. The former can’t be decreased at all. We should strive to minimize the latter of course, but we often forget about the first.
Just to be a bit more relevant - system boot is a very complex task, so the first type of complexity will be plentyful. It is basically a service/hardware dependency-graph. Sure, you can hard-code singular cases (previous init systems basically did that) but hardware and services are sufficiently different to not make it that feasible, and every single hard coded version can be buggy.
A declarative approach is much saner and it is no accident that basically every OS in wide use switched to that.
I'm not familiar with Java or their concept of trust managers, but I don't really see a major problem with it. It doesn't seem like there is anything confusing. I might not know why they did that, but I don't think I'd have trouble understanding code that uses it.
I'm guessing someone probably thought that a lot of the common use cases would be best done with a factory pattern, and they didn't want you to have to implement it all yourself.
It seems like a very strong form of One and Only One Obvious Way to Do It, extending so far as to have an opinion about what pattern to use.
Or, maybe there's just some other API that needs a factory for something, and so they have to directly expose it, and they don't want there to be more than one way to get one.
I would have to actually be familiar with Java to have a real opinion on it, but on the surface it seems kinda nice. It feels like the kind of thing that might help prevent hacky or quick and dirty code from being written in the first place, and possibly save time refactoring.
You don't think it's weird that there is a static factory method that you have to call in order to get a factory that you have to call in order to get the real thing? IMHO, that's exactly the kind of thing that Java gets rightly ridiculed for.
They could have had just a factory method on the TrustManager class itself.
Also, it is an old, deprecated part of the Java standard library, which lives by different design patterns. Since the public API can’t really change without breaking backwards compatibility, some form of abstraction is required so that later on they can modify the private API well.
> Obviously, no self respecting FOSSer is going to sabotage alternatives actively,
is that so? i do not have the same impression. everything is now built depending on systemd. i worry about that sometimes, though i also prefer systemd..
therefore i have hope for initware which/who want to export some of the stuff to other systems.
also i worked with environments (embedded and also router "things"), where systemd is indeed overblown... but that are nisches. i just hope we do not overcomplicate things for the nisches.. 80% or more (but less then 96%) profit from systemd.
back then unix and opensource managed all the cases, today it looks like it only manages the maincases..
It's existence as an alternative for those who want it doesn't bother me so much. It's watching other projects that existed for years without relying on it tacking it on as a dependency that got worrisome. It DOESN'T particularly follow the Unix philosophy, but that's okay -- not everything needs to be Unix.
At the end of the day, things seem to have washed out over the past few years, and folks who want to run systems without it seem relatively unimpeded at this point (heck, my Bluetooth stack on Slackware 15 worked out of the box). As long as the anti-systemd crowd keeps things constructive with parallel structures, the future seems bright.
And if the systemd proliferation brings users and thus big company driver support, so much the better. I just hope it is done in a way that the benefits can be shared in an init-system agnostic sort of way where possible.
I use and develop on devuan. I can't see any reason to add systemD, a so-called init system that uses binaries and extends it's tenticals in to every part of the OS. You aren't running linux anymore, you are running systemD. It is an abomination, and I will never adopt it.
You didn’t mention any single factual reason to not adapt it.
Isn’t the usual unix tools just little binaries? Also, IPC can very easily bloat the problem domain to much harder levels because now you have to deal with (de)serialization as well. So doing the same thing what systemd does with pipes would be an unholy mess.
I mentioned two, the binaries and the long tentacles. To be clear, I was talking about systemd using binaries in place of plain text LOG files. Both those choices are a huge break from linux philosophy. I expected systemd pros would know I was talking about that.
Enjoy your systemd. But don't hate on me for prefering linux.
"Abomination" is not a good enough argument. Systemd is very useful, and in order for someone to convince me not to use it, I need to see a good argument against it. "It's too big, it's an abomination" don't have clear technical implications, therefore don't make good technical arguments.
I didn't tell you not to use. I said I don't see any reason for me to use it. I prefer the simplicity of text based LOG files over binary files requiring that you use the systemd API that was changing regularly the last time I touched it.
> I didn't tell you not to use. I said I don't see any reason for me to use it. I prefer the simplicity of text based LOG files over binary files requiring that you use the systemd API that was changing regularly the last time I touched it.
Modern syslog implementations (e.g. rsyslog) will write journald log events in plaintext, if you're desperate to have plain-text-on-disk.
The reason to "add" systemD is that most of the major distros use it anyway, and so to avoid it I'd have to specifically go out of my way to find one like devuan.
I really sympathize with people who try to avoid systemd but I think it is a futile exercise.
Every piece of software these days assume you are running systemd and make your life miserable when you try not rely on systemd, and sometimes, it is even not possible to run without systemd at all.
Unfortunately, people don't remember how was the systemd adoption and why it was so controversial.
systemd was promoted as a init system, but in reality, it is more than that, it is a suite of software; we have journald, firewalld, udevd, logind, networkd, resolved and many more.
People forgot how systemd was forced to everybody when Gnome made systemd-logind a hard dependency and logind was extracted to elogind so people could initialize their desktop without using systemd.
The same happened with udev, forcing Gentoo to fork it into eudev to avoid systemd dependency.
People complaint about portability and compatibility because you cannot interact with systemd-* without systemd; you are coupled.
The problem is not systemd as a software, is the attempt to hijack the entire ecosystem, replacing existing services with services dependents of systemd, forcing systemd adoption.
And the question I ask to you is: who is behind this?
You forget the tiny bit of detail how the absolute majority of the linux world voted in favor of systemd, often literally. Debian for example had multiple votes (in a system much more democratic than what we are used to in politics) on the issue where systemd won hands down in each case. Arch got to the same conclusion independently.
You know, the actual people that have to maintain packages, so they actually know what does it entail. So you can’t even claim that they don’t know what they voted on.
So if you call the democratic absolute majority’s choice hijacking, I have to believe you are the one doing the pushing.
>systemd was promoted as a init system, but in reality, it is more than that, it is a suite of software; we have journald, firewalld, udevd, logind, networkd, resolved and many more.
Several of the things you mentioned are completely optional. You can use some of the systemd programs but not others. Many distros don't used networkd or resolved for example.
GNU was promoted as an editor. Just because an organization or project expands into multiple different projects doesn't mean that is a bad thing. Does it matter to you that GNU makes 100 different things?
>People forgot how systemd was forced to everybody when Gnome made systemd-logind a hard dependency
This is not an issue with systemd, but Gnome and whoever else. You should complain to them, not the systemd folks. It doesn't make systemd bad or not a useful piece of software.
Gnome only has a limited amount of resources (both developers and money). You can't really expect them to support an alternative. I'm sure if you talked with them they would support an alternative to logind if you were willing to provide enough money. If gnome won't support it then you could pay Gentoo developers and I'm sure they would create additional alternatives like you mentioned with eudev.
Ultimately I think unification of Linux distros is good. It is unfortunate for BSD and whoever else, but when it comes to Linux this is a good thing. I am currently helping a coworker migrate to Linux and trying to explain apt vs yum/dnf vs pacman vs whatver, rpms vs debs vs snaps vs flatpak vs appimage, etc is just tiresome. When they look up how to do something on Linux and it just doesn't work it is a bad experience. Maybe systemd isn't the correct choice, but unifying on one init, network manager, firewall just makes a better experience, especially for new people.
> GNU was promoted as an editor. Just because an organization or project expands into multiple different projects doesn't mean that is a bad thing. Does it matter to you that GNU makes 100 different things?
You're comparing an organization consisting of projects headed by different people with very few strict inter-dependencies and whose primary goal was being compatible with as many Unix systems as possible at the time, to be able to slowly start replacing their utilities, to a single umbrella project headed by the same people and parent company, whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) and are expressly incompatible with the ecosystem they're trying to replace.
>You're comparing an organization consisting of projects headed by different people
Originally gnu wasn't what you are describing. It grew into it. Just like what is happening to systemd now.
>with very few strict inter-dependencies
Systemd has very few interdependencies as well.
>whose primary goal was being compatible with as many Unix systems as possible at the time
As far as I know glibc is strictly for Linux. Maybe Gnu had an intention of creating software that was compatible with multiple systems but not all their stuff is.
>whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) and are expressly incompatible with the ecosystem they're trying to replace.
The same thing happens with Gnu stuff. Large chunks of gnu software requires GCC.
glibc is one of the few exceptions to the rule, and even that supports Hurd and has historically had patchsets to run on the BSDs.
> Large chunks of gnu software requires GCC.
This is simply not true. Autoconf, the build generation utility, is so insanely complex and archaic because it had to support wildly different compilers and Unix environments. These days it's just GCC and Clang, both of which are very well supported beyond just the GNU ecosystem, to the point Gentoo now has a clang-only variant.
> Every piece of software these days assume you are running systemd and make your life miserable when you try not rely on systemd
This is silly. Apart from desktop environments, barely anything cares about what session manager is being used. There's no connection between almost every software these days and the init system.
I'm not sure if anyone is truly behind it. Systemd is open source.
The problem with FOSS is people make stuff they want, then they share it. Others only complain if it affects them.
And if you have no interest in alternate init systems, then compatibility with anything else sometimes just means stretching your team thinner.
From my perspective, and I'm sure some others, the hijacking is a benefit, it standardizes all the systems. If you're a corporate IT person, or a home user who wants to not have to think about their OS, this is great. It means you won't run into incompatible stuff, there's one standard "Linux platform".
Systemd isn't a DRM, it doesn't cost subscription fees, so I don't see why you would push the technology other than really believing that it is best for your dev team and your users.
From the point of view of the companies doing this stuff, Gentoo and Void and Devuan don't exist. They are like forks of the entire Linux platform.
There may be a bit of corporate competition happening, I'm sure Canonical doesn't want too much variety, but it's hard to separate it from the real benefits it has for non-hobbyist users to have less fragmentation.
There may be some dirty political stuff happening to push it with dependencies, but most of the community seems to be behind it.
Perhaps this should be seen as a tyranny of the masses kind of situation, and the better question is what obligations do the rest of us have for the other systems we will likely never use.
It does seem like there is some minimal level of effort that should be made, in the name of inclusiveness, and compatibility with some possible future QuantumHyperSystemD thing, at least to ask yourself and sure that it's all good faith and you aren't actively sabotaging anything.
But beyond that, unless you're being paid, not many are going to support a system that isn't relevant to them.
Systemd is close to universal now, in any system except possibly some lightweight container image type distros, very tiny embedded, and systems for people who specifically hate it.
I would be surprised to see anything else in any office, data center, or casual user's home.
It seems like red hat is the early adopter for new mainstream Linux tech, they seem pretty influential.
Realistically, is there any better alternatives for a modern personal computer? I'm currently running systemd as I don't know better, and haven't hit any issues, but always keep an open mind for all the pieces in my setup, if there is some better alternative that would give me something better.
But looking at the list of alternatives for the `init` (https://without-systemd.org/wiki/index_php/Init/), it seems like everything stopped updating after 2018, and if that's the case, I'll just go with systemd as it is still receiving updates.
Edit: looking at the footer of the wiki, it says "This page was last modified on 17 March 2018" so I guess the jokes on me, the wiki is not being updated very frequently and that's why the release dates are not up to date.
If it ain’t broke…
If you are going to use Linux at work it will be system d. I use Linux both at home and work so I use systemd. I’ve had exactly 0 issues with systemd and if systemd has a solution for something (like ntp time or efi booting) I just use that.
I understand it’s not everyone’s cup of tea and have nothing against peoples personal decisions. It’s just the ship has sailed regarding systemd regarding that most people use it and it’s the industry standard.
Good for you that you never experienced it breaking, because when systemd breaks, half the time the experience very much feels like breakage in a proprietary software stack (like Windows or, god forbid, Apple). Most recently, I've had systemd entirely prevent the mounting of an encrypted external HDD because the previous service it created for the mount (the previous time the disk was connected) refused to allow itself to be deactivated (even though there were no open handles left to either the disk or the mapper), and conversely knock a rental server offline (after an automated package upgrade from Debian security) as it decided that it didn't need to and wouldn't want to start network.target anymore.
In neither case was there any diagnostic information available (in the journal or daemon status) that would provide pointers to why it behaved as it did, and unlike with an external daemon manager it doesn't seem easily possible to forcibly debug what exactly it tries to do when performing an action (without debugging the entirety of systemd, which probably would require a second machine in physical proximity or at least running the problematic system in a VM?). In the end, I still have no solution to the former problem (which occurs occasionally) other than doing a hard reboot; for the latter, I gave up and made a service (using the hoster's virtual console service) under a different target that performed the necessary ifupdown calls to make the server reachable again upon reboot. Neither of these are things that I remember having to do on Linux before this "enterprise-quality" technology was rammed down my throat; it really feels much closer in UX terms to patching out bugs in system DLLs with a hex editor back in the days.
I have personally experienced a ton of breakage from systemd.
The claim was that systemd was compatible with sysV init scripts. This is not true, and the breakage might not even be noticed until you are dealing with data corruption. If you have a startup script that does an su to a different user, systemd will start the application, but it will just kill the application processes that were spawned after the su, rather than doing a proper shutdown. E.g., if you use the startup script (only sysV) Oracle provided, systemd will kill your DB's processes in an apparently random order rather than allowing a proper shutdown. The issue is in the way systemd uses cgroups to keep track of which running processes are associated with a particular startup script. Every version of systemd is affected.
Systemd initially claimed compatibility with fstab. But, it broke things. Systemd does not process the entries in fstab sequentially. This breaks fuse filesystem mounts that depend upon a backing store mount. Systemd later added additional mount options to try to hack around the breakage, but, in my experience with glusterfs, they are necessary, but not sufficient, and I had to add overrides for other systemd service units to get things to start reliably.
I also had a fun time cleaning up the mess after systemd made remote systems using full disk encryption, unbootable. The responses by Poettering in the bug report from the Debian systemd maintainer were what really convinced me this systemd thing was going to be a huge mess. TLDR Poettering basically said, he never used a feature like Debian's keyscripts, and wasn't willing to make the existing system work. Years later Debian has a hack that allows keyscripts to unlock disks in the initrd before systemd gets involved in the boot.
Another fun issue early on, on an embedded system that was using ext4 without a journal. The system experienced a hard power down. When it came back up, it prompted for a root password for the emergency (single user) shell. But, it wouldn't auth. It started echoing back parts of what were typed mixed in with garbage characters in its prompts (including the plain-text root password). Messing around in this state, I realized that it was executing (as root) whatever I typed as the password. So, for password, I typed fsck -f ... and was able to get the system bootable again. System was reverted to sysV, and everything worked properly again. Maybe this was a systemd-logind issue?
I use systemd since it "won", but it has not been a good experience (the above is a small subset of issues I've personally seen, but pretty representative of impact).
I run resolved and it works for me. That is not to say that is fine for everyone so: resolved and networkd can be replaced if they do not work for you, right? Not sure how it is in ubuntu now (as an example), but when ubuntu started using systemd they did not use either resolved or networkd.
They point against systemd would be resolved both being broken and being unable to replace it with another resolver.
They closed this super-critical bug despite not fixing it, claiming they're making the right decision in their implementation when they in fact misread the spec
Yeah, that's right, with resolved you cannot connect to other machines on your local network by specifying their simple names, because it blackholes those requests, and there's nothing you can do about it.
I skimmed the bug report, and wrote up a reply, but then realized that all of this is meaningless to the actual question: If your beef is with resolved, and resolved can be replaced with your resolver of choice, what is your point against systemd as an init?
> with resolved you cannot connect to other machines on your local network by specifying their simple names
Huh? You most certainly can. I mean, somehow "ssh koyomi" works here on my network, no matter if machine I run this on uses system-resolved or unbound or something else. My DHCP server supplies options 119 and 135 and that's all that's necessary to make it work.
What you can't is to have a CNAME with a bare hostname i.e. make "foo.example.org" magically resolve to "foo.local" when you're on that particular LAN with "search local" (and $deity knows what if you're not). To be honest, I'm not even sure what's the point of this setup, unless you do split-horizon (but then why not respond with "foo.local." proper?)
Do you have a proper domain name for your local network (+ search domain)? I'm talking about the case where you don't, or have a '.local' domain; https://askubuntu.com/a/918161
Oh, now I get it. Sorry, it was not obvious from the bug you've linked above - there it talked about a CNAME record referencing a bare hostname from a "proper" (non-mDNS) domain name, a fairly weird use case I don't quite get.
Yes, I do have a "proper" domain name for my LAN and my .local is for mDNS (although I don't think I've ever used it with short names, always foo.local explicit; and I use mDNS very infrequently) - guess which is why I haven't ever seen this behavior. Thank you for clarifying.
The .local name is intended for multicast name resolution. RFC6762 says implementations may coalesce results with unicast DNS lookups, but it's not required. The only thing required is that anything ending in .local must he looked up via mDNS. So including .local in the search list doesn't seem likely to make your query reach DNS on an mDNS capable stub resolver.
Meanwhile, RFC4795 says that LLMNR senders should not send queries for single-label domains to DNS and that no search list should be applied to such. So querying a single-label domain does not seem likely to reach DNS on an LLMNR capable stub resolver.
My advice to one who wants to use DNS to resolve hostnames on the local network: Avoid using a domain reserved for mDNS domain and use another one.
The thing is that a simple name doesn't work either, so 'server1' doesn't work, 'server1.local' doesn't work. 'server1.example.com' works, and I think 'server1.lan' also works, but I'm not sure about that last one.
"For a modern personal computer", systemd is pretty much spot-on what you'd want.
On the other hand, if you're running a bunch of fast-scaling containers/VMs, and just want init to (re)spawn one (or a handful) of processes, then step aside as quickly as possible, sitting there quietly, reaping zombies - TFA has this page:
As long as it keeps working, I'm happy with 'runit'. I'm not sure what needs to be updated. It runs my boot scripts, it starts my service manager. It's been reliable for over 15 years, across hundreds of installs, in a wide variety of contexts. Importantly, it has never created problems for me when trying to rescue a system.
Right now, nothing is practically "better" than systemd, but replacing init and figuring out all the different decoupled services that make a non-systemd system provide anywhere near the same featureset (and need to be installed separately) is a very interesting exercise on its own, that will teach you why the different bits are important and a bit of linux history.
You can replace the init system on just about any linux distro with a bunch of handwritten shell scripts, slackware style, or use any of OpenRC or s6 to provide you with a framework to make it easier, OR, you can use a preconfigured distribution, of which I'd recommend Artix, Alpine, Void or Slackware, and reading into their respective source code.
At the end of the day, an init is an init. You don't need a lot of the features systemd provides as a home user, though they don't actively hurt to have either.
Many of the distros they link to are very much kept up to date. I can vouch for Voidlinux and Alpine Linux. Another one I like that they left off the list of Qubes OS [1] although that needs a fair amount of memory to take full advantage of.
There are alternatives to [very many] individual core competencies of systemd. Obviously a direct alternative to a kitchen sink such as systemd would be just another kitchen sink, so there's no such thing like that, that I'm aware of.
I think the anti-systemd crowd hurts its arguments (which I tend to agree with at least in spirit) when they throw out stuff like accusing the authors of systemd of being "Ignorant of fundamental operating system concepts" (https://without-systemd.org/wiki/index_php/Arguments_against...).
You can dislike the author and the project and the design, but that's just a foolish thing to say that makes it difficult to take any of the other (potentially valid) arguments seriously.
I checked both of those arguments and wasn't convinced.
First link demonstrates an email by Poettering claiming checksums won't fix anything useful. Clearly he's talking about a specific usecase of checksums and not talking about the whole idea of using checksums to recover data. He was asked about a specific feature in systemd, there is no reason to believe he'd want to bring up anything bigger. So implying he doesn't know RAID... is simply absurd and childish. He could have referred that person to RAID; but that'd be completely off-topic.
Second link is about a feauture request where someone wants a complete machine login functionality from machinectl unlike su. Then, Poettering explains why this situation exists (because su doesn't inherit cgroups) and then they go ahead and implement the desired feauture. Original user says "it works perfectly". Now, the criticism seems like Poettering calling "su" broken since cgroups were introduced after su. This doesn't make any sense. Of course this is a problem of su. If there are two tools: ssh and su, and they perform a certain task differently and one of the behaviors causing problem, clearly it's relevant to mention su's method is flawed and a more complete implementation can be written (and then they went ahead an wrote it). Bizarre.
Another day of reading tons of anti-systemd material for me, and another day of realizing systemd is a perfectly ok piece of software yet there is an odd internet obsession against it.
I don't think the idea of systemd is wrong. Long time ago out of curiosity I decide to learn how the boot process works and examined the code. It turned out, the init system was written as a bunch of shell scripts.
Its creators probably tried their best to write it, gave functions good names, left comments sometimes, but still it was bad. Running several subprocesses to split a string into parts. Parsing text output of subprocesses. Creating unnecessary temporary files.
This style of programming leads to extremely fragile systems. If the command slightly changes its output, scripts will break. If the command output depends on locale, scripts will break.
Futhermore, there is no sane options for error handling in shell scripts. There is only a relatively sane option - crash on any error and an insane option - ignore any erros and continue. For example, we failed to backup a file, but ignore this error and delete the original. No way one can write something reliable using such tools.
So if you want to write an init system, I think there are better languages that a shell script. It is difficult to build a graph of services and find an optimal sequence to start them using shell scripts. Or implement lazy startup of non-critical services.
Init system is not only a program to boot the system, but it should provide some runtime services, like management of background processes, logins and other things. Again, a properly written daemon with an API is better than a bunch of shell scripts.
Regarding languages, I am not sure if C is good for this purpose, it's pretty awful too. To illustrate this, consider a C function declaration:
int set_working_directory(char *new_directory, char **error);
You cannot figure out how to call this function properly without documentation or examining the code.
Instead of C I would choose something like Swift, D, Go (but it has pointers), maybe Rust (but writing in Rust for me is mostly struggling against borrow checker). I would choose something that's easy to read, test and verify and has a package manager.
So if you don't like systemd, consider writing your init system using one of the languages above. But please don't use shell scripts anymore.
Most of your modern Linux infra is corporate. The large distros, the maintainers, the main contributors. The "community" is still free to do whatever they want and go use something else. (eg. Alpine is not using systemd)
Here's my experience with removing systemd from Debian - DO NOT ATTEMPT. There's a reason the Devuan people have made significant changes to the system and packages.
If you don't want systemd it's important to choose a distribution that doesn't increasingly expect it. Don't try to rip it out, that just causes pain to the host (you). You need to treat it by avoiding it.
There is indeed a conflict between two different packages being used for acpi type stuff. For me, I had to sort it out, to get suspend to ram to work(S3) with my laptop.
I have Debian still on my old Thinkpad X40 with systemd removed, it's usable but there are niggles like with ACPI so that it's not useful as a laptop per se. Love that machine. It was my first Thinkpad.
I'm an SRE, I've done Linux from scratch, and I've built my own alternatives to system management, including "Service Managers" and "Container runtimes" (a fuzzy distinction if ever there was one)
Systemd badly needs alternatives. Upstart was a good one, and I wish it hadn't been abandoned. It had a lot of things wrong around it, but Upstart was not all-consuming and it did the one job it was supposed to do - Keep a set of processes alive - well.
Systemd is opinionated in every way, and that's fine. But it needs something out there to challenge those opinions. It needs something that will force it to evolve the way users want and not just how it's developers want. Most importantly, it needs the egos involved to be shut down.
The alternatives all exist and work fine. Init still works great too. And if you need auto "healing" daemons and such you can even use daemontools. There are a slew of actively developed well supported alternatives you can use today. And it's not so much the opinionated nature of the systemd pushers that's obnoxious, it's the fact that the software is enormous, buggy, and insecure.
Have you ever read an old init.rc? I suggest you go do so. Daemontools was a reaction to the deficiencies of systemv init, and that it was not getting updated.
Initrc has always supported "Run this, and run it again if it exits". That's not quite enough for a modern init system, but it's also not far off. Upstart and systemd capture the few additional things that are necessary. It should be in init's job to run daemons. Perhaps pid 1's only job - all the one-time setup that is required should be executed by another pid1 process before daemons start at all, and then you exec into a parallel daemon runner process.
I'm definitely a kid compared to the old graybeards, but I ran and developed on Linux for years and years since the late 90s - And didn't actually read init.rc until like 2014 when I was trying to debug behavior that was different on Upstart WRT terminals. Because if it's deficiencies (such as having just the one init.rc file!), init was rarely used and not much thought of.
- Some Linux users really like modularity and composability ("do one thing") to the point of considering it a core tenet of unix-alikes overall.
- Systemd is perceived as being a super-project that is not practically modular and composable (though it may hypothetically be so)
- Some see systemd and related activity in Gnome and elsewhere as Red Hat bullying their way into excessive control over the direction of Linux.
- Mistrust of Poettering and the general attitude and competence of developers on the project—some of this hostility dates back to pulse audio, another Poettering/Red-Hat project that was seen by many as technically deficient, led by people with excessive hubris without the know-how or taste to back it up, and excessively/unjustifiably promoted by Red Hat and Poettering through political maneuvering.
- Concern that due to all of the above it represents: a power-grab by a single actor over Linux; a risk to Linux security and stability; and a risk to the future maintainability of, and practical transparency to the user of, Linux due to the scope, complexity, and architecture of the project, coupled with its heavy dependence on a single benefactor.
> - Some Linux users aren't fans of super-projects.
> - Some Linux users really like like modularity and composability ("do one thing") to the point of considering it a core tenet of unix-alikes overall.
That’s why Linux itself is a micro kernel. Oh wait… ;)
First, systemd came in and replaced a lot of the base OS, happily changing things to be... either "modern and designed with hindsight" or "breaking compatibility because they could", depending on your viewpoint. As an end user it was mostly invisible, but anyone mucking around under the hood got half the engine replaced on them, and it was not appreciated. (A major example would be the journal; for 40 years logs went into nice flat text files that could be watched with tail(1) or searched with grep(1), and then systemd came along and moved logs into a binary format that forced you to go through journalctl to access anything.)
Second, systemd can be viewed as "playing dirty" in the way that it was pushed through the ecosystem. It was viewed as Red Hat pushing their preferred solution by leveraging what should have been unrelated packages - udev went from an init-agnostic database of hardware and rules engine to being part of systemd and everyone else had to factor it back out, GNOME made systemd a dependency, that kind of thing. Further, the developers tend to take a... "our way is right and anyone who disagrees is out of touch" view, while being remarkably blind to other systems; my favorite was https://github.com/tmux/tmux/issues/428 , wherein they wanted tmux (a portable program hailing from the BSD side of the ecosystem) to abandon existing daemonization code and go with a systemd-specific approach. They even came out and said that they were happy to try and make things harder for people who didn't accept their way - why try convincing someone to adopt your approach when you can just modify the ecosystem to progressively make it harder for them to do things their way (https://lists.freedesktop.org/archives/systemd-devel/2010-Se...)?
These are my main reasons to avoid systemd as much as possible. And a bug in systemd-udev on 32-bit Linux systems that periodically halted the performance of the system into unusable state for long times that is probably never going to get fixed.
Broadly, systemd was trying to do two things at once:
- be "opinionated" software
- supersede all other software in its category
Very few other free software projects have tried that combination.
I think it might have been be possible to do without angering large numbers of people if the developers had been significantly above average in both technical judgement and the social aspects of developing free software.
But the systemd developers weren't either of those things.
For those of you who downvote this because you think I'm being disingenuous, I speak from personal experience of working closely with Red Hat in a number of projects where their code were an integral part of the solution.
Red Hat really do reinvent the wheel, for the purpose of making money selling popular kinds of software. And they're shamelessly declaring themselves superior to the product they're mimicking. And the projects are ran like side projects of the lead developers.
Lennart came down from heaven (or, depending on your perspective, up from hell)
and looked at the state of linux distributions.
He said, "This sucks. Boot times are slow. Distros have a mish-mash of init
systems and shell scripts, all subtlety different. Linux features like cgroups,
which are the bee's knees, are left as an exercise to the sysadmin. Why aren't
user processes manageable? etc."
Thus systemd decided it was going to standardize a new layer between the linux
kernel and userspace using a declarative model for configuration for... like
everything. This was a huge change in the linux world. A huge change was going
to be controversial. Systemd is still controversial.
If only they paid equal attention to shutdown as well. It is relatively easy to inadvertently break a systemd install in such a way that reboot/shutdown would go through a number of grotesque "tasks" with very generous time-outs:
- Unmounting filesystem /mnt/nfs (X seconds out of 1:30)
- Waiting for D-Bus to terminate (Y seconds out of 4:00)
...and so forth. It's so bad, there is a special "C+A+D, 7 times in two seconds" key combination to deal with those. Which, I've seen fail as well.
+10 on this. The first thing I noticed years ago from running a systemd-based distro, is that shutdown (thus reboot) got stuck in "...waiting for xxx to terminate" for multiple minutes. This had never happened before, and there were never consequences from it not happening. So it was (and remains, in many hard-to-debug cases) strictly a drawback for systemd-based systems.
It could be a bug in a third party service that didn't shut down properly or wasn't integrated with systemd properly. You should not put a blame on systemd without investagating first.
> declarative model for configuration for... like everything.
Here I find that many people look for the wrong thing. Their idea is 'do $stuff at boot'.
However, systemd does 'do $stuff at $event', where 'boot' is one of the events in the set. They are not wrong though, we are used to cron is not a valid reason why it should not get unified.
… but you can still just run your favorite crond, and keep doing exactly what you were before? I've still never run a cron job under systemd, and I've never hit trouble doing that. I.e., Systemd doesn't force you to use it for cron.
Although, now that I'm looking at ArchWiki's "list of reasons you might want to do this" … it checks off basically every problem with traditional cron. I might need to start using this.
I really like systemd, but from what I understand, the folks who don’t like it have a number of gripes. The one that most resonates with me is that systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose.
I'm not super familiar with systemd or any of the lower level stuff like init systems in general, but I was under the impression that it's just an umbrella for many individual modules/binaries, like journald, etc, and not actually monolithic.
I get the argument against hard dependencies, which the individual modules seem to be dependent on each other, but is that really that abnormal with Linux programs? I more understand the criticism against higher level programs, like GNOME, having hard dependency on systemd specifically.
With all that said, I'm not doubting there's valid criticism as I'm sure that I'm missing for fundamental points of the "monolithic" argument as it relates to systemd. The above is just my sort-of layman impression.
> but I was under the impression that it's just an umbrella for many individual modules/binaries, like journald, etc, and not actually monolithic.
If you can't use journald without systemd, and you can't use systemd without journald, or they really modular in any meaningful sense? I can take a Void Linux system and drop in rsyslog and chronyd and maybe dnsmasq (for DNS caching); I can't take a Void system and add journald and timesyncd and resolved.
What would you use as an example of modularity? The closest that most of it gets is that you can disable features and put back the non-systemd alternatives, but I'm not aware of any systemd components that play nice on non-systemd systems except for maybe systemd-boot nee gummiboot (which benefits from running before systemd and therefore is less inclined to depend on it).
> systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose
Isn't the typical Unix kernel that most users interact with a giant monolithic program with some runtime modules but mostly compile time configurability? I think this goes all the way back to the original Unix kernels.
Most users don't interact with the kernel. They interact with a posix (or posix-like) environment. And that is definitely a kalidescope of independent utilities. Most of which are at least somewhat portable across *nix/bsds.
To the haters credit, previously the init system itself was also authored with posix-compatible tools. And could be hacked upon easily, readily, without compiling. By compare, you'd kind of need to attach gdb or what not to systemd's pid1 to see what's happening, and it'd be much more complex, and you'd need to be compiling your own systemd to make changes. I'm a huge systemd proponent, but to be honest, it's shocking to me that there's not a bunch of guides to running gdb, to watching systemd do it's thing: we largely are all consumers, accepting systemd's activities/behaviors on faith.
Yes, and as kernels grew this is where the arguments for/against micro-kernels began. Modular monoliths seem most common ATM, but micro-kernel architectures haven't entirely lost the game yet.
The kernel being largely monolithic is an annoyance that people do keep trying to fix where possible, but it's easier to sweep that under the rug than to deal with monoliths in userspace.
> Just read the thread rather than trying to conjure meaning from a single comment
My comments are half of the thread, and I don't think I'm missing context; yes, the kernel is often a monolith, but 1. nobody really likes that, it's just hard to fix[0], and 2. the kernel can mostly be ignored because it presents a clean enough ABI and doesn't really affect userspace[1], whereas systemd is a monolith in userspace that very much does affect the rest of the system. I'm not seeing any "cognitive dissonance".
> rather than trying to conjure meaning from a single comment like a rtard
Insulting people is both against the site guidelines[2] and an excellent people to get people to disagree with you even if they might have been otherwise convinced.
[0] Because context switching in and out of ring 0 murders performance.
[1] Seriously, you can swap out the kernel completely like Debian kFreeBSD and it's basically invisible to the user.
[2] "When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to '1 + 1 is 2, not 3.'" (https://news.ycombinator.com/newsguidelines.html)
the systemd suite had replaced tools that didn't need to be replaced, often does a worse job than they did and introduces measurable overhead, all for the sake of "standardization" no one had asked for
besides that, it is a significant part of ongoing corporate embrace/extend/extinguish of OSS
Any change to Linux will set off some very small, very vocal number of very entitled complainers.
The short is that all operating systems face various problems of synchronization and they have all roughly converged to a very similar design to manage it. And I really mean all--Windows, OS X/macOS, Linux, Solaris, AIX, ...
The long is that there was a window where this problem needed to be solved and there were a bunch of half-baked solutions. Pottering sat down, wrote code, came up with a 3/4 baked solution, and RedHat adopted it. After that, RedHat continued funding and improving it and other distributions realized that systemd made things better and slowly adopted it as well.
And throughout it all, a bunch of people continued to bitch like hell. But at no time did anyone else put in enough work--technical, social AND political--to solve the problem.
Yeah, the social and political work seemed to be "It works. We're adopting it. Pound sand and get lost." However, even in the face of that, still lots of people just pissed and moaned but failed to come up with a decent alternative.
> However, even in the face of that, still lots of people just pissed and moaned but failed to come up with a decent alternative.
Which is, alas, typical. Sources of truth in free software are, of course, not very coordinated, but one does learn, eventually, how to work with that.
So I find it very unfortunate that noise from these sorts of unhelpful reactionaries keeps getting amplified on Hacker News, while actual good and constructive stuff (hey, have you seen those lovely progress posts on GNOME Builder's GTK4 update? Did you know there's a KDE version of Fedora Silverblue? How about that interestingly modern OS image for Steam OS? Did you know people are actually making cool new things with this platform instead of clinging to the past?) barely appears at all.
Old cars are finicky and you need to keep maintaining it. But people know how every part of the system works, and they can repair it with a duct tape and a piece of bent wire.
Modern cars are full of electronics and don't break as much.. until the do. And then you need all new tools to repair them, and those tools are much harder to use, especially if you are used to old cars.
(I myself spent plenty of time on pre-systemd systems. I can tell you wonderful stories about apache children cleanup, and debugging failed startup at scale. I use systemd all the time now, and don't miss rc.d a bit)
There are many arguments, but the one that I identify with best is that systemd is unnecessarily complex, and it's components are tied closely together, breaking the "single function" paradigm of original Unix.
But really, it's more about un-learning the "old way" and re-learning an entirely new way. Is the new way better? It depends on what you need. In my case, I have never had an occasion where it was either simpler or "better" to change a configuration with systemd, so it required learning the "new way" with no benefit. I think many people are in this camp.
But the the main reason I dislike systemd is that it has resulted in broken boots on servers, sometimes randomly, and sometimes for un-debuggable reasons (something you get when you mess with init). "Failed to start X", and system hangs kinds of things.
But I have other reasons. For example, in olden times, /etc/resolv.conf is where your resolver addresses went. But if you're running systemd, then you're probably running systemd-resolved, which means /etc/resolv.conf points to localhost -- because systemd-resolved is a resolver itself. So where do you actually configure the IP addresses of an external resolver, which must be set somewhere? Go ahead and look it up, I'll wait.
/etc/systemd/resolved.conf? Maybe, depends on other systemd configuration files. Want to know what it's set to now? Sure just type "resolvedctl status", so obvious! Unless your distro doesn't have that binary, it's fairly new. In systems without systemd, updating /etc/resolv.conf was dynamic; the network stack recognized the change instantly and you were done. I don't actually know what you have to do after changing /etc/systemd/resolved.conf; I end up just rebooting. So time-saving.
Is systemd-resolved better? Well, it caches DNS for all processes (even the ones that already cache them), so that's something. Do I care? I haven't yet, but this nebulous benefit (for me) results in me having to re-learn how DNS works on my machines regardless.
I have a few servers running Devuan, and it's great.
Less sarcastically: because it does too much, in ways that sometimes are impractical (networkd comes to mind). Expect better answers by more knowledgeable people.
Personally, I like it. But I’m a simple person with simple needs.
This is what it boils down to. Systemd has been solving problems that all distros have been facing.
Unlike most Linux development, they haven’t focused on what their devs want to do (which for much of Linux is repackaging Ubuntu with uglier skins, and Ubuntu itself is a repackaging of Debian/Gnome), but rather, are solving problems that distros are actually facing.
The consequence of that is that nearly every distro goes with the systemd solution, and it’s this popularity that leads to people complaining that it’s being forced upon them.
It brings Linux closer to Windows in philosophy. Systemd is building a coherent large codebase (albeit modular) that solves all the problems, as opposed to Linux userspaces old philosophy of having a collection of "expert" tools, where each tool or project did one thing, one thing only, and did it really well. Then the system was a collection of such expert tools.
The collection of expert tools naturally aren't as well-integrated with each other, so on a system level the solution might look a bit spotty. But every function is thought through and works really well. Plus, each tool is useful on its own, which makes the system very configurable, introspectable, and hackable.
The "one big codebase that solves all problems" approach might appear more stable all-in-all, but it's a fundamentally different approach where you no longer have a bunch of expert tools, but rather a large collection of mediocre software components who's only real purpose is to be integrated with each other.
That "do one thing well" ship sailed decades ago, when ls added sorting. I don't recall the date, but I believe ls has had sorting for more years than it hadn't, possibly a lot more.
ls is not Unixy, find is not Unixy, wget/curl are not Unixy, the list is infinite.
Anyways, those breakages aren't nearly as big of a deviation from the modular design as something like systemd. I'm sorry, but that comparison just cannot be made.
I'm denying the actual utility of the "do one thing and do it well" in practice. It's an awesome soundbite and you can't really argue with it (who would want tools that do "it" badly?), but it practice it wasn't ever respected.
i dunno-- i grew up playing around with every distro of linux and unix i could get my hands on, and my first was Slackware/LILO. a lot of the so-called "expert" tools _work_ in some fashion, but could definitely use a UI/UX improvement.
all of the binutils and basic stuff is pretty antiquated and has an old-school and specific perspective and lot of the modern work we do as developers and operators has use-cases which fall behind due to such a rigid way of thinking.
i think systemd is great, and maybe it's overkill for certain applications, but there are also smaller containers and distros one can use for this. i'm all for modernising linux and the tooling around it, it's sorely needed.
I'm not opposed to the idea of a more intelligent init system, but systemd is doing waaaay to much. One example; it messed up hostname resolution on my lan by blackholing DNS traffic for single-name queries. And you cannot turn their dns component off.
Of course you can turn it off. Fedora didn't even use resolved until 2 or 3 releases ago and they were one of the first major (non rolling) distro to adopt systemd.
Maybe nowadays, but when it came to Ubuntu back in the day it was enabled by default and couldn't be turned off because it was being used early in the boot cycle when other resolvers hadn't booted yet. Talk about bad design decisions...
Speaking of which, there are some other things that Ubuntu does that get my blood pressure up, such as not having a reliable way to do truly unattended upgrades.
Frankly because of the extreme arrogance originally displayed by Poettering and his cronies, in the vein of Apple-style "you're holding it wrong" when people would raise valid criticisms of some early systemd warts.
Nowadays systemd is pretty good and not deserving of the hate it gets, but early on the opposite was true.
Because for basically every new thing it replaces, it causes problems that the thing it replaced didn't have, and Lennart Poettering often pushes back against fixing these problems.
My personal relationship is a necessary-evil one. Without it, I'd have more problems with concurrency and service/session management, but I'd lose a lot of "systemd messed up resolv/nsswitch/hosts" scenarios.
Also, for most basic set-ups, even server ones, a classic BSD or SysV init works, as do simpler and more lightweight options, as proven by Alpine, FreeBSD and derivatives (FreeNAS, PFsense) and OpenBSD based solutions. And when stuff goes wrong, those are infinitely easier to decipher.
That doesn't mean, however, that systemd is hard to write config for, often when you need a service or script ran at bootup or login it's easier to make it work right than with a SysV-style init script. The problem is the growing config- and codebase, coupled with the binary logging system, which makes it even harder (AND NO, I REFUSE TO LEARN ANOTHER HIGHLY SPECIFIC TOOL TO READ THE BINARY FILES).
The logging system is one of those things that are just done right by systemd. I usually force everything to log to syslog and let journald handle it.
Just being able to see all potential new issues all over the system with a single command after system update + reboot is extremely time saving. Viewing only logs from the last boot, filtering, interleaving of all log messages from everything on the system, so you can easily see the timeline of things in one place, sane log rotation that doesn't make it harder to query logs, etc.
If I had to not use systemd, this is the first thing I'd rewrite or find some alternative that takes the same approach. :)
Lots of people complain about its complexity and how many lines of code it is, making it very difficult to audit; it "goes against the UNIX philosophy" because it tries to do too much.
No dog in this race, so if someone wants to correct me, feel free to.
My experience is that it broadly falls into two categories.
The first is comprised of people who never actually had to wrangle sysvinit/upstart (openrc is relatively sane), and have never seen the ridiculous amount of engineering time which went into hacky stuff like supervisord and bizarro, bespoke hacks to try to do things which systemd makes trivial: socket activation, optional service dependencies, file-based service activation/restart, "failing fast", timing various parts of the boot chain, etc. This class of people, broadly, probably never actually understood how `init` worked anyway (or how booting worked once dracut came into the picture), but they now feel like it's an opaque, unobservable system. They would have felt like that anyway if they had tried to work with pre-systemd tooling.
The second mostly thinks that systemd is against the "UNIX philosophy". This class of people, broadly, has never touched a "real" UNIX other than MacOS (and they probably never had to deal with netinfo) or BSDs (which are great). There was absolutely no sanity or consistency between, say, AIX, Solaris, IRIX, and Tru64, and all of them had various classes of "god" tools.
This is indicative of the problem. Ninety-nine percent of users don't WANT to configure 40 different baroque things with their own configuration files (rsyslog/syslog-ng, dhcpcd, resolv.conf, ntp.conf, /etc/hosts|/etc/hostname, etc). They want Linux to work. They want systemd-networkd to get them an address in 1/10th of the time, and they have absolutely no need to start a daemon which can set every DHCP option ever when ACKing. They to fuss with nameserver rotation to deal with flaky stuff for split-horizon DNS -- they want systemd-resolved to handle "this server can't be reached right now, so I'll put it in timeout, keep returning cached results, and send new queries to a nameserver which is responding."
If you still WANT to do the other stuff, nobody is stopping you. Yes, you probably need dbus and udev and udisks, and all of those things are light years better than the tools we used to have before, but systemd itself can be trimmed down to almost nothing if you want to. The alternative, building up a stack which can sort of approximate systemd, would take a very competent admin at LEAST a week to build deployment tooling for, and that's assuming they already knew all the stuff they needed to plug in.
because it's a comprehensive suite of software that largely gets the job done while ignoring various 'unix philosophies', which some people in the linux world really do not like. To me it resembles programming language debates a lot where highly popular, pragmatic languages get attacked by people with strong philosophical ideas about how software ought to be built.
It's a Dunning-Krugerish non-solution, sold as an init system trojan that is replacing more and more of the OS with less and less understanding of how it would need to work in order to do so effectively. It's a monolith that is almost pure attack surface, which requires the rest of the OS to change to work with it, thereby making it part of that monolith and extending the attack surface.
Every admin issue I've had over the last decade save two has been due to SystemD. I'm not opposed to change, but I'm also not going to embrace change for its own sake, particularly incompetently designed and implemented change.
Then we get to the project's social problems. But people get very defensive about that, so I'll just point out that if change is such an unalloyed good we certainly can't argue against changing away from using SystemD, can we?
> Every admin issue I've had over the last decade save two has been due to SystemD.
Do you administer systems with SysVinit as well? If not, please consider that of course the system which manages startup and background services is going to be responsible for admin issues. It is exactly the area you are responsible for administering! If yes, I'm curious how those are going in comparison. Are they less trouble?
A lot of the arguments about systemd are annoying because they’re either based on things that are simply inaccurate (like many of the jabs about stuffing things into PID 1, done by people who don’t realize systemd-init is just one component,) are based on a super luddite mindset (I really don’t think shitty Bourne shell sysvinit scripts are better than systemd units, TYVM,) or hyperfocus on relatively small points of contention (Usually Poettering’s attitude, which does suck sometimes. Sometimes more specific things like the UID fail-open bug. Sometimes valid but contentious design choices like binary log storage.)
Granted. There is plenty of valid criticism against systemd, and when it was first pushed on all of us I was among the angsty annoyed people. However, I also don’t care that much about init systems, so if it was gonna work it was gonna be fine for me. Systemd today works quite well. It’s a more complete replacement for many of the components it replaces. It has a handful of annoying behaviors, but it also does a lot of things quite well. I really like socket-activated units. User systemd works OK for me too. systemd-networkd is pretty good for systems that don’t need NetworkManager. I initially had some issues with logind, but today it does roughly what I want it to. (Desktop Linux is the only OS that gives me the actual behavior I want with sleep on lid close: it does it only when the last external display is disconnected. I have written software to try to get similar behavior in Windows.)
My remaining complaints:
- I dislike the way systemd is pushing the world towards dbus even more. Not every UNIX like ships dbus by default and not everyone wants it. It is flawed in some ways and it is terrible that it is being imposed as a boundary for all kinds of system services in a way that will take ages to break free from.
- I dislike that instead of building more generalized interfaces or working into existing frameworks, systemd’s interface is quickly becoming a major part of the desktop Linux ABI. Major projects increasingly depend on it, working poorly or not at all without it.
- Generally just RedHat not caring about the former concerns as a whole makes me not like their control over the ecosystem. I’m glad somebody takes the mantle of trying to push desktop Linux forward, but I really have a strong dislike towards RedHat in general, and things that are perceived as highly influenced by RedHat. GNOME’s CSD initiative is the worst thing that has ever happened to desktop Linux and libdecor is an ongoing failure of a solution years later. No offense to the folks who painstakingly work to make it happen, but I’m not sorry, it’s crap. My opinion hasn’t changed even slightly since day one. (Though almost all Wayland compositors outside of GNOME’s support server side decorations, so you could always give GNOME users decorations that let them know how you feel ;)
Even if systemd was great software it would be a bad idea to use it. It's just an attempt for Red Hat to corner the market with embrace, extend extinguish.
At that point, I realized I don't actually want to manage an init system. Which further lead me to the realization that I wasn't actually working with the thing very often, and brought into question my qualifications for having strong opinions on the topic.
I see lots of arguments against systemd that, to my untrained eyeball, seem pretty compelling, and lots of groups who are doing the actual, non-hypothetical work who seem to've ignored the arguments and switched over.