Without Systemd
without-systemd.org
without-systemd.org
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.
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.
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".
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 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.
Well-thought-out simple stuff, on the other hand, can last for decades and often is quickly adapted to novel devices and environments.
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.
For example, in Java, to create a Trust Manager for certificates, you have to first call a factory method to get a TrustManagerFactory, before I can even get a TrustManager: https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/Trus...
That's just really weird and confusing design.
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.
They could have had just a factory method on the TrustManager class itself.
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.
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..
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.
Enjoy your systemd. But don't hate on me for prefering linux.
As for log files, I don’t see how is it different than a pdf or any other standard.
You could make the same argument about KDE, or Gnome. It's not a good one.
Systemd isn't trying to be just "an init system".
You know Linux is just a kernel, right (now's the time for that copypasta I think)?
Modern syslog implementations (e.g. rsyslog) will write journald log events in plaintext, if you're desperate to have plain-text-on-disk.
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?
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.
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.
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.
They have strong influence over the entire Linux stack, and this is why IBM bought them.
Basically, even if you avoid systemd, you will still be over Red Hat influence, no matter what.
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.
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.
The systemd components all depend on libsystemd (a systemd project), and the GNU apps all depend on glibc (a GNU project).
A common dependency doesn't make them all "deeply interwoven" in any meaningful way.
With systemd it's often not just libsystemd that's the dependency, but PID 1 and the rest of the stack.
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.
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.
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.
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.
And then there's systemd-resolved…
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
https://github.com/systemd/systemd/issues/2514
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.
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?)
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.
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.
And yes, I'm a little upset about it being broken by default and having to hunt down the issue, which did take quite a bit of time.
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.
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).
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:
https://without-systemd.org/wiki/index_php/Init/#standalone_...
And there are other alternatives as well, such as:
Unlike systemd:
- it's nice and simple
- it's well documented
- it's easy to troubleshoot
- it doesn't have it's tentacles in everything
That said, I don't run any desktop environments like Gnome or KDE, but just run i3 as my window manager.
OpenRC also worked well for me when I was on Gentoo.
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.
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.
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.
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.
It looks like an example of corporate bullying vs. open-source community and the corporate won.
It’s like claiming that kde-plasma is bloated because it has everything even a video editor under the namespace.
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.
I run sawfish, and trinity, no problems with either...
I'll have a look at my notes shortly...
I dunno, I've been running systemd on Ubuntu across over 100 machines for ~5 years and I can't agree with either of those points.
Without Systemd - https://news.ycombinator.com/item?id=14875452 - July 2017 (49 comments)
Without Systemd - https://news.ycombinator.com/item?id=9515125 - May 2015 (88 comments)
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.
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 run a minimal init process and my desktop rig is inited by a brutal and beyond idiotic sh script.
What's long is the EFI bios init, and displayport programing, namely everything is done in a matter of very few seconds.
Anything more complex would be grotesque.
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.
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.
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)
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.
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.
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.
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.
I just want to be able to have resolv.conf work. Thank goodness it still does on debian.
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)
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.
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.
Upstart would have been a better alternative.
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.
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.
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.
My point is worse than you think.
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.
So why treat it like a sacred icon?
Be practical instead, ergo systemd.
Nowadays systemd is pretty good and not deserving of the hate it gets, but early on the opposite was true.
- 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.
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.
No dog in this race, so if someone wants to correct me, feel free to.
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).
Ysall
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. :)
- 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.
That’s why Linux itself is a micro kernel. Oh wait… ;)
The funny thing is that Redhat management didn't see the point until other distributions (read: Arch) adopted systemd. Until then, it was skunkworks.
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...)?
Update: The bug was related with integrated Bluetooth card on some Dell laptops and is fixed on Ubuntu 22.04: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/17598...
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.
Systemd won though.
- 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.
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.
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.
besides that, it is a significant part of ongoing corporate embrace/extend/extinguish of OSS
besides that, Poettering is a little shit - https://nitter.net/pid_eins/status/1376838491863191556
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?
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?
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.
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.
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.
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.
Lennart is not always right, but he does have a vision of Linux for the 99%. That is, one of the "against systemd" links is this: https://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is...
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.
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 ;)
Notably, Avahi and disabling thereof.
Some problematic things remaining are:
- pull an Ethernet cable and watch weird state enter via systemd-networks
- your long running custom-made daemon that spent many weeks building up cache goes down when Ethernet link state change
It does not enable IP address to stay truly static IP when netlink device goes down.
Nor does it leave the IP route table alone.
Caveat emptor.