> On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm.
Can anybody explain to me again why systemd is so bad ? Genuinely I'm not sure anymore: It is chock full of features and it gets the job done. Since it is used in a lot of big distributions it gets a lot of fixes, updates, testing and feature improvements regularly.
Yes, it is maybe monolithic (but so is the Linux kernel). Its philosophy may differ from unix's "get one thing done well" too but integration of various functionalities comes with its benefits.
Some people say it is bloated. The substitutes to systemd are lightweight but less featureful. Maybe some of them will get bloated as they achieve feature parity.
People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy. However I can't understand why systemd is the point of so much disagreement.
The article compares the Unix/C philosophy with the Lisp philosophy and concludes that Lisp is "better" (it is The Right Thing), but that Unix/C will probably end up dominating. Obviously, he was right.
The article is pretty famous around the suckless, minimalist, crowd. But I think everyone who reads it takes a slightly wrong lesson from that article. The point isn't that Unix/C won because it was simple. The point is that Unix/C was simple enough to use, simple enough to implement on most available hardware and that it did everything you needed it to do.
The minimalist people have turned software simplicity into the modern version of The Right Thing, and are surprised when they found out that the "worse" (more complex) thing wins. But The Right Thing will never win. The Good Enough always wins.
Is Linux better than *BSD? Well *BSDs are more simple, easier to understand and reason about etc. But, at least OpenBSD, doesn't have mount --bind, so I can't use it. Case closed. And I think that's the case for most people. Linux has thing X which I need so I will use Linux, even if ideologically *BSD is imo better.
Is D-Bus The Right Thing? No; but it is The Good Enough. polkit, selinux, ACLs, and so on.
The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
SystemV init was not good enough for complex service management. systemd is. systemd simply does everything you need it to do well enough. So systemd wins. Simple as. It will only be replaced when it is no longer Good Enough.
Exactly, for some values of "good enough". (Unfortunately IMNSHO) Systemd cannot be toppled by all-out assault. It must be subverted. Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
Something like Wine, where in the analogy systemd is the Microsoft Win32 API and we want to be able to run systemd "enabled" software on something else. Or at least re-compile it.
Wine also started with an incredible amount of stubs which did nothing, but that was often enough for many programs to work anyway.
Yeah. Exactly. It's also how Wayland and Pipewire managed to win: by being backwards compatible with X and Pulseaudio, while also overcoming their shortcomings.
The problem is that if the only complaint with systemd is that it's too complex, any backwards compatible alternative will necessarily be as complex as systemd + the new thing (at least in terms of complexity of interface).
If there are actual technical deficiencies of systemd, then sure, maybe such a backwards compatible alternative might be in order.
Also, everything expands in time. Wine may have started out with many stubs, but now we're at the point of implementing Windows-y APIs in the kernel with the sole goal of improving wine performance (NTSYNC).
D-Bus is good enough for all sorts of things. But you absolutely don't need a behemoth like systemd to use D-Bus. A D-Bus communication option can be added to existing programs and utilities, or new ones could be fashioned for which it is a central mode of operation; and still there would have been no an ever-growing pile of centrally-maintained and inter-dependent artifacts.
As for SystemV... as I mentioned in another comment - in hindsight, that was not the issue. There were and are SystemV alternatives [1]. One can even write one that uses D-Bus in an opt-in fashion, to foster other facilities' use of it.
The init system excuse is very much like the stone in the fable of the stone soup: https://en.wikipedia.org/wiki/Stone_Soup - it's what gets the vagabond's foot in the door, and is the first ingredient for the soup. But actually, the stone carried no significance, and the resulting soup is pretty much the same thing as without the stone part.
> The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
I'd wager the vast majority of (non-embedded / single-purpose) Wayland deployments are gnome and KDE.
River is very good but a niche in a niche. Telling that ive been using hyprland though.
Part of the problem with all of them is less the wm and more knowing what parts you need. Not so much bars as portals. I'm vaguely surprised hyprland doesn't have a "good enough" batteries included config and documentation.
I think a lot of the arguments I’ve seen stem from “Unix philosophy” style arguments. Also, historically the systemd project has been quite hostile to user requests in some cases, which broke existing workflows for people.
I personally think the basic “service manager” functionality works pretty well and I like systemd overall.
However, the same is not true for a bunch of the more peripheral services (e.g. resolved, networkd, timesyncd). What’s particularly annoying is that there exist mature open source projects that can provide better functionality in a lot of cases which could be used, rather than bundling a half-assed attempt with systemd (eg. unbound, chrony).
None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.
Yes, but not using those seems to defeat the point of using systemd.
The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
> Yes, but not using those seems to defeat the point of using systemd.
I don't see how it defeats the point - it still nice init / services manager, it still provide features say sysvinit couldn't do at all for my _services_ and management/lifecycle of services.
How often I tackle with resolved or networkd or timesyncd - not even sure, may be once a 2-3 months, while systemd-as-service-manager I do almost every day.
If you don't use them, you still have a standardized way of managing system services, including scheduled batch jobs. The other services are a convenient and integrated way of getting a basic version of that functionality, but they are by no means the entire point of systemd.
Apart from the comparison to NTDLL making no sense, you'd be wrong about the tools too. It aims to provide a basic standardized way to do most system-level management (set up networking, do DNS resolution, get a decently synchronized system clock) but it absolutely does not aim to replace more specialized tools like chrony or NetworkManager. For example, timesyncd doesn't do NTP or PTP, only SNTP.
systemd (the PID 1), journald and udev are different, though, because they're mandatory; and there's no alternative to logind while technically optional.
How so? The functionality of the kernel and of systemd are basically orthogonal: neither really provides features that the others do. There are some interfaces in the kernel which are basically intended to be delegated to one userspace process, like cgroups and the hotplug management done by udev, so talking to them directly as an application or library is probably not a good idea and those processes provide a means of co-ordinating that, but that's a kernel decision and the udev one predates systemd.
I remember that on one of the $dayjobs around 2014 we have used runit, but I honestly don't remember why and what it gave us. Very likely just as auxiliary tool, not main init system.
Your remark may suggest that everything MS does is “wrong”. This is of course an extreme overstatement and all of their approaches should be evaluated on their own.
It's a declerative boot system, where units can declare their dependence on another unit/service, and they will be brought up in accord, with a potential for parallelization, proper error handling, proper logging, all while the user complexity is a trivial .ini-like file.
It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
systemd is just much better for managing cross-cutting concerns. E.g. having the machine wake up from sleep for a timer and do a task (e.g. backup or updates) which delay sleep is trivial, portable and reliable with systemd and probably technically possible without it.
Sorry, I'm not deep enough into it to determine why systemd would be better. Perhaps it's not. I know it's less unix-y, but we shouldn't treat that as holy imho, it's a good guideline though, I try to follow the unix philosophy.
I personally think that most of the OS decisions done by Microsoft are wrong and should be killed with fire but also I'm far from thinking bad about the people who made these decisions. Perhaps these decisions make sense from their standpoint given the information they had a time.
On the other hand on Linux I'd really wish for a centralized settings repository like Registry. But not from the systemd crowd, of course.
resolved and timesyncd are intended to be removed by the end user of the operating system. Sort of like a transparent peel is intended to be removed by the buyer of a new shiny device.
I haven't seen anything worse than those two from systemd crowd.
Resolved is useful if you frequently change networks (e.g. a laptop), particularly if you’re also using an overlay such as Tailscale. Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it.
I started using Linux because I liked stability. Systemd makes a Linux system as dynamic as a Windows one (which is nice) at the price of making it as stable as a Windows one (which is not).
I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
> Resolved is useful if you frequently change networks (e.g. a laptop)
I can see the case. I use it myself on a laptop. And by "use" I mean that I just gave up looking into Linux desktop networking like a decade ago. It works, fine.
> I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
... this is ... incredibly wrong. Hardest disagree on all points here.
It's worth pointing out that Lennart Poettering simply rubbed some people the wrong way in his communication, and that ended up reflecting on systemd, irrespective of the software itself. (I am not making a case that this is good or bad, right or wrong. Just pointing it out.)
> It's philosophy may differ from unix's "get one thing done well"
> it is bloated.
Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
If you want to use an alternative to systemd on those distributions, you are usually on your own, constantly trying to fix it whenever there are breaking changes.
It's good to have options which are simple to replace.
> It is chock full of features and it gets the job done.
>Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
I don't think the phrasing is correct. Your choice of word (spread/ingrain itself) seems to imply there is malicious intent. Software do not sneak itself into distribution by themselves. It is the other way around. Distribution creators have total freedom on what components/software they find useful to build their distributions on. If a majority of distros decided to use systemd, that mean a majority of people maintaining distributions found the positive outcomes of using systemd were worth dealing with any disadvantage it may had over using another solution.
> If a majority of distros decided to use systemd, that mean a majority of people maintaining distributions found the positive outcomes of using systemd were worth dealing with any disadvantage it may had over using another solution.
This is overall fairly weak evidence that users actually find the software to be of quality. Surely there's got to be a stronger signal that this is a positive way forward, like users enthusiastically saying "wow this is an improvement".
I find it hard to imagine objective evidence more robust than the real-world actions of subject matter experts who make real-world decisions. This would have been hotly debated within teams of Linux experts at Debian, Ubuntu, Fedora/RHEL, SuSE, and Arch. These aren't armchair experts who debate on the internet, they're the ones who actually make decisions and, more than most, wear the consequences of those decisions.
For example, we had cron working just fine for decades . We had sshd listen on its port for decades. We had fstab for decades. No one wanted systemd-timesyncd.
In my opinion, all these aux systemd projects came to life purely out of psychological reasons. Can we label them malicious?
How it managed to spread is no surprise. Linux desktop was a complete mess with consolekit and unmaintained stuff. Then they supported cgroups which distros wanted to use and since all the unmaintained stuff didn't there wasn't a lot of options.
Booting up a system is a complex domain. If you randomly cut a complex domain into pieces, you will have the exact same complexity PLUS a huge amount of additional complexity for all the communication/error handling between the different parts - what other complex domain uses million tiny tools? Does chrome use curl and then pipe it into a html renderer and whatnot? Sure, there are libraries (that's a different architectural layer though with less complexity to break, and functions don't decompose arbitrarily either). The unix's philosophy is more of a sounds good on paper, and there are certain cases where it applies - it's definitely not universal.
Also, the core of systemd is not even particularly big. People often mix into completely optional modules that run under the wider systemd project, but that's a false conclusion that "systemd eats the world".
> How it managed to spread
You mean that individual distributions voted/decided separately, multiple times to choose the better tool? Debian has the most democratic voting system and unanimously voted for systemd.
And yeah, if I want to use my own display manager protocol instead of X or Wayland I would also be similarly stranded. Options are good, but standards and compatibility are just as important - a million incompatible options only give rise to chaos.
I am, for example, very happy that Linux applications are finally not as distribution-dependent and there is a good chance to run that .deb file on anything else running systemd without much trouble. I remember the times when it was not so.
> You mean that individual distributions voted/decided separately, multiple times to choose the better tool? Debian has the most democratic voting system and unanimously voted for systemd.
They are influenced by other distros decisions. Debian's justification of adopting systemd starts "Systemd is becoming the de facto standard init system for Linux." https://wiki.debian.org/Debate/initsystem/systemd
> You mean that individual distributions voted/decided separately, multiple times to choose the better tool?
This is a mystery to me. Given the LP attitude is known to be hostile to people with expertise and given the cancerous nature of systemd projects, I really wonder how did people choose to be treated that way.
Maybe they have voted for systemd-as-PID1, which is incomparably better than sysvinit, but this is the way systemd crowd got its foot in the door and before you know nothing works without systemd metastasis present.
Until it doesn't. Fortunately I didn't have to debug it often, but when it was a lot of pain.
I prefer the fs under /tmp to be tmpfs. On the BBB is wasn't. I changed that and on next reboot the system didn't come up again -- no way to log in. Why? And what to do? Turns out I failed to state the fs_freq and fs_passno fields -- those aren't optional, but while the old mount tool tolerated their absence, systemd chose to interpret the fstab strictly, failed to mount that fs, consequently didn't reach the local-fs.target and hence didn't offer any way to log-in. Unlike Raspberry Pis, the BBB doesn't offer the possibility to remove (and mount and debug elsewhere) the boot medium. Fortunately, I found help on-line on how to connect a serial terminal to the BBB and interrupt the boot process, forcing the use of /bin/sh as init process...
> Can anybody explain to me again why systemd is so bad ?
It's huge, messy, has a poor bug and security history, obfuscates things that don't need obfuscating, and is just generally IMO not a clean or efficient implementation. It's a very Windows style solution, very different from the lean and minimal stuff I like to run generally.
The advantages it provides are questionable, and are dwarfed by the issues it has had in the past IMO.
OpenRC perfectly meets my needs at present and my system boots incredibly quickly. When s6 is finished that situation will only be improved.
It would be good to know if it's as ergonomic as systemd. I know it's not perfect, and sometimes the docs are confusing, but it is pretty simple to create a service that starts on boot etc. No scripts required, really.
> People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy.
It's a blessing and a curse. Look at package managers, they more or less all do the same thing, with one primary job of "go download some binary so I can run it", yet there's so many to choose from. Every time you read some Linux guide they have to list 7 different ways of installing the same package. It's stupid, probably even more so for the maintainers of those packages because they have to distribute their package 7 different ways. At least I'm glad systemd has mostly become the standard, so you don't have to also see 7 different ways of creating a service.
Usually, it's the distributions problem to package software. You as a software developer publish documentation on how to build your application and then simply wait for other people to do the packaging for you. The creation of services is the same, you can maybe create a recommendation, but the service definition is part of the package file and thus not your problem.
In practice, though, the packagers quite liked systemd, because it a) makes service definition easier than any other system, and b) it significantly increases the likelihood that the developer has already written a suitable service file (and developers will like that that is used, because it reduces the chance that a packager makes a mistake and increases their support burden).
And as an end user of multiple distros, I really appreciate it because I also have to make services on occasion and it's nice that there's one way to do it and it's pretty easy to do correctly.
Usually, this is not good enough. I as a software developer often make use of the package manager built into the language of choice and use that to distribute my software. I also commonly make use of package managers of languages that I don't use to install software.
We are overdue to package manager interop and common interfaces.
I think you are beating a somewhat dead cow here. systemd wars are over. It's in most mainstream systems nowadays, but there are also lots of cool projects out there doing different things. Everything's fine, nobody wants to go into those old pro and con flame wars any more.
With every new Ubuntu version I have to carve out new metastasis no one asked for. For example, 24.04 (or maybe even 23.10) changed the way sshd is started up - by systemd listener instead of sshd on its own like it was for decades. This way they saved a few megabytes of RAM (solely on computers that are not exposed to the internet, of course).
While fighting against systemd-as-PID1 is futile for many years, fighting against the spread is definitely worth it.
Fair, point taken: Some people are working on systemd replacements because they want to build some cool things in that area. Just like there are multiple programming languages and no one says "Why don't you just use Java/C++" it should be OK to work on Linux systems without systemd and not think too much of it.
Everything is fine, unless/until many developers begin to assume systemd is present and make software ports to non-systemd Linux (or *BSD) systems prohibitively expensive.
> Nothing wrong with this if a system service is going to be present on 99.999% of installs
Is there a sign linux installs will hit this metric in our lifetime? I don't think there's any strong indication of this. There are multiple distros devoted to not moving to systemd.
> GNOME swapped its service manager for subprocesses (e.g. bluetooth) to systemd user units because it does a far better job.
Not on computers without systemd it doesn't! Besides, Gnome still runs just fine on systems with init scripts like *BSDs with no visible loss of quality or stability so this was a purely political choice to spite their own linux user base.
Except exactly the opposite is true: it is sysvinit (and derivatives) who had the job done. In a very basic way, slow and perhaps not even compatible with modern requirements and expectations, but the job was done.
Systemd on the other hand does the job it thinks should be done, not you. Your opinion does not matter.
You can spend however much time you want editing /etc/ssh/sshd_config and then restarting sshd and then pulling your hair out on why tf sshd ignores certain options while still definitely parsing sshd_config. Only to later find out that systemd/ubuntu crowd decided to listen on port 22 via systemd, sort of like inetd did back in the days. It's like sshd directly listening on port was not good enough for the last 30 years, definitely had to be changed. Oh yeah, and to make your life miserable, they mask the name of the listening process with "sshd" in it, so you get confused even more.
And people can come up with countless of similar examples.
Incredible attitude and arrogance is what makes people hate systemd.
I'm sure you have other examples (and I'm not really asking for them) but your sshd example would make me dislike the choices Ubuntu made, not systemd. Like I don't blame systemd for snaps being so awful.
My view is that there is an attitude/approach spillover from systemd crowd into other teams. Switching port 22 from sshd to systemd was not something that any sane person could come up with. It's a stream of incredibly hostile decisions from systemd upstream that allowed that kind of thinking.
Big monolith that imposes requirements on your system and robs one of the feeling of knowing how the whole thing works?
At least that’s me. I use systemd in most of my installs for reasons similar to yours, but nothing feels more sublime to me than installing a simple init system and a few other daemons for system features I actually use.
Numerous kernel features, reliance generally on it by itself and by third party programs (running ceph w/ openrc is hard bc it assumes systemd is present). I’m buying the full car when I use it, when what I really want is a kit that I can optimize for purpose. Honestly though, this close integration is worth it. My main OS build at the moment is pretty much just systemd and podman on top of linux.
> Also, feel free to "rob that feeling back" by learning how systemd works
I really want to! I just don’t know any good resources that can help get me familiar with all it’s doing for me in the background. All I know about it is what I have gleaned from tutorials, I don’t yet feel I know what’s possible with it yet.
Ok, try to go off the well trodden path of a default systemd setup.
Eg. make your system "login interactive" before networking and other unneeded services (database, web server, whatever) are even attempted to be set up/started.
Use just drop-in configuration fragments (*.service.d/override.conf) without making an unmaintainable mess (ie. without making your own copies of whole, OS installed unit files).
That should get you the feel. :) And it's not something crazy, it's just basic re-ordering of dependencies.
That's a really negative comment with little to no contribution to the discussion. Care to elaborate more on that, so that we can discuss detailed points instead of blanket statements?
In the last two years I have spun up new-ish, actively supported versions of ubuntu for pre-production rollout that were shipped with a systemd-resolvd that would occasionally just stop responding for no reason. Logs said nothing was wrong, process was UP and saying it is ready to do work. strace shows a hung process.
Stuff like this is possibly where the complaints from some people begin.
Fortunately, I can find a tracked bug that is active. New updates get pushed, as the honestly phenomenal community of people intended this process to go. But How may years have some of those people been patching bugs like this in systemd on a regular basis? Did that time have to be spent if systemd's architecture was better from the get go?
The Trail of Bugs to get to the point we are at today has truly taken a monumental effort from MANY people. Why wasn't systemd's community doing things well "enough" from the beginning before being folded into so many OSes?
Let's be real. From then till now they have put in hard work, in the face of huge community pushback, because someone had to do it.
Diehards feel it felt "foisted" upon us before it was fully baked, everyone knew sysvinit was way past its prime. Put up or shut up. Plug in a different init for your OS and move on.
But, you know, people like talking and complaining to each other. It's a very important part of solving technical problems!
I think the previous poster made it clear they were just explaining where the complaining comes from. Why are you trying to debate their description of other people's motivations for complaining?
> Diehards feel it felt "foisted" upon us before it was fully baked
That was the minor problem. The major meta-problems are that:
1. The baked form itself is broken. It has numerous fundamentally flawed aspects to its design (and to its existence as a project). More baking would not have helped this.
2. It is not intended as an option, nor even just the default option - but to make more and more utilities and libraries for managing various system facilities and services become unusable and incompatible, to be taken over by systemd. It's not like foisting, say, Thunderbird instead of Evolution as the default mail client; if you don't like it, you run the other thing. Or even version X of the kernel instead of version Y of the kernel and so on.
> everyone knew sysvinit was way past its prime
At this point we can say with clarity that systemd has almost nothing to do with the choice of init system. You could replace the init system with any number of things - some already existing 15 years ago, some which could be developed in the mean time. In hindsight, this is an excuse and not a reason.
Nothing makes my life easier than pulling my hair on why tf sshd listens to port 22 after editing /etc/ssh/sshd_config and restarting multiple times. Oh, of course, it's now systemd that listens to port 22, not sshd.
Nothing makes my life easier than cleaning out crontabs of things that wake my box in the night and find out that something still gets launched. Oh yes, systemd now has timers no one asked for.
Nothing makes my life easier than disabling a service then masking a service then masking it's sockets, then blanking files then chattr +x those files and end up having broken ubuntu instance because there are so many ways to launch a service it's not even funny at this point.
Nothing makes my life easier than finding out multi gigabytes /var/log/journald folder that has exactly zero reasons to exist because text-based logs are still collected and properly rotated in a place where any sane person would expect them to be.
Some defaults are not good for servers. For example, systemd gives up after a few tries to restart a service. This is really annoying for server administrators when they don’t know about the bad defaults.
If a service fails to startup after n times, I most certainly want to take a look at it as it might as well just end up corrupting its state even more - I don't think it's a fair assumption that most errors will just go away on their own. Nonetheless, it can be configured declaratively as a single line, and as you mention, the default can be changed.
For the GP: This is not a talk which explains why systemd is bad, it's a talk which argues which systemd is good and misunderstood. Which I don't agree with, plus isn't what you asked.
Indeed, as the LWN reported stated: "His attempt to cast that story for the pleasure of his audience resulted in a sympathetic and nuanced look at a turbulent chapter in the history of the Linux system."
But overall, I agree on this point. Having been a Gentoo purist during Uni time, I'm now full on NixOS. NixOS has fully abstracted away any interaction I have with SystemD, so I don't think it's useful to replace it.
SystemdD does too much and it's like a monopoly, because it's so much work to replace, it can piss you off a lot, it needs to be very shitty for you to replace it.
Sorry, but there many people who do not like bloat, bad practicies and daily security bugs, partially because of the aformentioned bloat. If we settle this "gets the job done" mindset we are never going to improve.
For me, it's primarily its scope. I had a system for 10 years that changed, but fundamentally worked the same. With systemd, the changes exceeded my threshold and continue to expand into something that to me, seems ugly.
I'm not a typical example. My view is inarticulate, subjective and maybe even irrational, but I remember the system I came to love and that was Linux. My overwhelming impression with systemd is that it's not Linux and it should not be referred to as Linux or even in the context thereof. It's not evil or bad or anything but itself, but it's not Linux. In my abstract, medieval view, Linux has a soul, albeit, at times, a tormented one. Systemd exorcises this soul for me.
Now despite me disclaiming the subjectivity and abstraction of these perceptions, I'm pretty certain there will be some hostile replies, possibly with valid points. If you're really trying to understand the creature, I suspect it's very improbable that it will happen here. There are existing strong, well written arguments both for, against, and even neutral. Definitely worth one's time if understanding is the true objective.
For me, it's scratching a chalkboard and smells bad. It frightens me and makes me sad. It's worse than brussel sprouts and freaks me out.
It's incomprehensible. I make some changes to config files and they don't apply so I have to find whatever poorly-documented systemd thing is controlling it instead. It is taking over every important area of the operating system. Init, login, boot, it just keeps spreading. I think on other Linux systems I am better able to reason through and modify aspects of the system or fix a problem I am having.
I have been trying out atomic Fedora and enjoying it. I like ostree, read only root, podman, building the distro from containers. I think I have had enough of systemd, though, and might move on because of it.
Just see `systemctl $command $unit` to discover that systemd it's not designed by sysadmins, while it's built for them. That's it's problem, like stratis/btrfs vs zfs.
These are software designed by people who have no experience in user-centric design, they design in theory, reasoning in theory, ignoring practice.
> Can anybody explain to me again why systemd is so bad ?
it isn't, it's great. it is different, though.
and then come in two phenomenon:
1. people resist to change, often out of ignorance.
2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
> Yes, it is maybe monolithic (but so is the Linux kernel).
it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other. systemd appears to be monolithic from outside, but it really isn't.
> Maybe some of them will get bloated as they achieve feature parity.
they will, most likely. it's easy (as a piece of software) to be lean and clean when you're doing very little (with little error checking and recovery).
> However I can't understand why systemd is the point of so much disagreement.
systemd was essentially pushed down everybody's throat by Red Hat when they realized it was high time to level up the boot process for the whole ecosystem. systemd made a bunch of things not only feasible (concurrency, on-demand service activation, multiple-instances of the same service running, proper log management) but so easy they're trivial.
so 10+ years, it's definitely a net positive.
some people are still complaining but meh, some people will complain anyway, so let them talk, whatever.
> systemd appears to be monolithic from outside, but it really isn't.
If it looks like a duck, walks like a duck... systemd is modular solely in theory. In practice, I am grateful that I can still remove journald and resolved from current Ubuntu installs and I'm pretty sure that's not going to be possible quite soon.
Systemd itself may be modular, but practically distros are not going to bother.
> 2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
And from that the systemd crowd tend to draw the following conclusion: if something was done a certain way for decades then it is bad and should be replaced.
>> Yes, it is maybe monolithic (but so is the Linux kernel).
> it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other.
So where are all small the projects trying to replace the small parts of systemd? AFAIK there are no stable or convenient APIs in all those parts, so even though technically systemd consists if many binaries, it is monolithic.
This is exactly what people call "forces distributions to use it", i. e., you must choose all or nothing.
I don't believe Linux userspace maintainers are lining up en masse, plus if your alternative implementation doesn't significantly improve the status quo, why even bother?
Here in the comments you can find a lot of complaints about non-main parts of systemd, which could be improved easily if it was actually non-monolithic.
The usual arguments against systemd border on religious drivel. I've seen the talk and while I very much value the work that the speaker has done I did not appreciate that the reasons for doing this are the usual vitriolic cat-v talking points.
systemd is very good because it makes many things that the Linux kernel can do very easy. I would like to know how the people who swear against it implement features that I regularly use in systemd like socket/mount/dbus activation, services that dynamically create a user and group on activation and keep their service and temp directories private from other services, syscall filtering, user session services that start when I log into a graphical session (very useful when you have issues with your system tray's config, for example), network mounts that get mounted asynchronously only when you're using them, actual service management and restarting a service when it fails and service dependencies (which some init systems still don't do!), and so on and so forth...
Yes you could do all of these things by composing other programs, but there is lots of value in having them all bundled together and only having to consult one resource for documentation on them, and the fact that these are all designed to work together reduces the friction that you would get by composing other "general-purpose" tools.
On the other hand, systemd is bad because the implementation is messy, when it does fail it tends to do so in odd and obscure ways, it comes bundled with tons of components that most people won't need, and yes the fact that it's essentially the only option you're given and that it's not portable to BSDs is not very nice.
I would encourage people to read dinit's comparison page and Chimera Linux's FAQ section on systemd for good arguments that are not fueled by religious belief as to both why systemd is valuable and in which ways it is bad.
> I believe in the "Let a hundred flowers bloom" philosopy. However I can't understand why systemd is the point of so much disagreement.
Your first sentence explains, to a great extent, your second. You see, systemd is designed to _prevent_ a hundred flowers from blooming. Unlike most Unix-like system components, the idea is for systemd not be an alternative replacable component, but the whole installation above the kernel. You don't choose things; you get those services and facilities which live within systemd; and those which don't - mostly won't work. That is, unless you tear out everything related to systemd. Which is difficult, since GNOME and some other packages over time have introduced dependencies on systemd, rather than on services or facilities it provides via a common protocol or interface.
This was also how the big Debian debate exploded, causing the fork of Devuan: The "opposition" did not demand "No systemd in Debian!", but rather, that the user would be able to choose not to have systemd at all, if they so please. I am paraphrasing from memory of course, but I believe that was the gist of it.
And the speaker in this video faced this situation.
I am not well-versed in NixOS and certainly not in this new project, but I imagine that if the author could easily just configure NixOS not have systemd, they might not have bothered starting this project and would more likely have published some kind of recipe/how-to page on
>However I can't understand why systemd is the point of so much disagreement.
I think the simplest way to describe it is that it's a religious conflict.
A not insignificant segment of people who develop and/or use Linux are fervent followers of POSIX philosophy, the Unix heritage, Free Open Source Software development, and the Anti-Microsoft Church (note: Poettering is a Microsoft employee).
These people have a religious duty to hate systemd, it's essentially heresy. It's not a disagreement based on technical or even practical merits, so the conflict can't be addressed with technical debates and will continue for the foreseeable future.
> disagreement based on technical or even practical merits
Philosophy can't be reasoned based on merits. Of course there are technical merits as to why systemd-as-PID1 was (not today!) an extremely good piece of software compared to sysvinit, there's no question about that. Likewise there are valid technical reasons why systemd-timesyncd should be abolished and never mentioned again.
But how do you decide LP's attitude on merits? How do I argue with Red Hat who shoved systemd down everyone's throat?
So yes, it's a religious question of sorts. The religion that made Unix unix.
You think you get to just declare the opinion that differs from yours invalid by calling it religious?
Don't the holders of that opinion get to call your position equally religious?
"not a disagreement based on technical or even practical merits" indeed, right there in the mirror.
The first few minutes of this video absolutely articulated some perfectly technical and practical merits. So have some comments here on this hn post. I don't see how it's valid to say no one has ever produced any.
I think the debate on systemd as regards to its merits was decided already years ago when all the major Linux distros adopted it. You need to go way out of your way to run Linux without systemd now, people who want that setup have clearly become a (very small) minority while the rest of the Linux world moved on.
The conflict as parent commenter witnesses it continues because that small minority continue to (very loudly) disagree not on the merits. It is their prerogative to disagree if they desire, but their basis is much more about beliefs than superiority.
It's like Polandball memes where UK crazily chants "Britannia rule the waves...!" while US goes off to freedom some oil with its boats.
Here's my hot take: systemd is the best thing that happened to Linux.
I genuinely believe it's the reason Linux has dominated the other operating systems in the server space in the past decade. As someone who manages servers I wouldn't even consider the other options in space right now, and the features systemd provides is a substantial part of that decision.
As a person who manages thousands of servers I genuinely fail to see systemd as anything but a problem. I can certainly see systemd on Desktop, where the environment (network, screen resolutions, peripherals) are always changing on the go, but on server where everything is more or less fixed... systemd? The worst. Unlimited source of problems.
> I especially like the better encrypted boot support [...]
For some reason I can't directly reply to transpute's comment, but it's relevant to this thread so here goes:
> Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground [...].
Desolder the EEPROM and read the secrets - the loophole is open wide without a TPM/SEP.
The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors, while desoldering and reading the flash is trivial for a hobbyist with cheap tools and some patience.
However this is still an enormous step forward. All of the recent attacks on secure boot chains on Windows[1] and Linux[2] are due to usage of partially-unencrypted core system components in a complex boot chain. Sixos takes the correct approach - minimise the attack surface. All it takes is to stop rejecting the "voodoo" and take what the hardware already offers.
amjoseph focused a lot on the s6-init stuff, but I really think that infusions and the way they lead to more composable system configuration is the key thing here.
NixOS' module system works, but I don't think there's anybody who thinks it's particularly pretty or generalisable. As soon as you want to run one service twice with slightly varying config you're SOL ...
systemd already has encrypted boot support. I suppose when you rip something out you have to reinvent all its functions. At that point, any rational person would question the reasons for doing so.
Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
So removing a transmission and installing/testing/improving a new design or way to solve the problem that hasn't been popularized isn't a worthy cause? How do you think we developed the first transmission? Or the various improvements we all take for granted these days? Yes, systemd can do this, but that isn't a reason to imply developing an alternative that can do the same, albeit in a different way, is irrational.
It has all of those words next to a bullet point, but the implementation is quite different, and I (like the presenter and probably many many others who are clearly not you) have more confidence in a simple fuse than with systemd[1].
> At that point, any rational person would question the reasons for doing so.
That is excellent advice. The presenter has done something you clearly cannot. You should be rational, follow your own advice, and try to figure out what those reasons are (hint: some of them are actually in the video). That might take a few hours to a few weeks of reading depending on your own experiences, and that's just how life is sometimes.
> Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
When I have a new gadget I want to produce, I'm responsible for all of the code in it, so productivity, reliability, performance, and size are important to me whether I have written the code or I have merely used it in my product. I do not understand the way these things are important to the systemd people (or even if they are important at all), so for me, systemd is off-the-table to begin with.
Or to put it another way: I never needed a car in the first place, because I'm making boats, and I'm not starting with a car just because I like the people who made the engine. Ignoring "solved problems" can just make everything more expensive, and maybe I only know that because I've seen enough people make that mistake, but sometimes this is true.
Keeping an open mind means allowing yourself to be convinced too.
I hope this lesson has become clear more clear with the recent deepseek upset. That proved that simply throwing more money and hard to wear at a problem doesn't guarantee a better outcome, innovation seems to favor the opposite. As as Germans say the German saying goes: "
NixOS checks/enforces its own reproducibility via systemd in various ways. It seems unlikely to me that replacing something battle-tested with a bunch of self-rolled brittle scripts will make it more reliable.
This is somewhat ironic, given that it was systemd that replaced the battle-tested systems that came before it, and variants of your comment were used to argue against it.
And then later finding out that a transmission in an electric car will help you both with top speed and mileage, so you have to put it back.
This is just the same old "systemd sucks, let's rip it out" and then later reinvent everything it provides, because it was needed. Also commonly known as reinventing the wheel, the curse of any IT project.
> Also commonly known as reinventing the wheel, the curse of any IT project.
Continuing with the vehicle metaphors, the wheel has been reinvented many times for different purposes. The wheel on a tractor is different from that of a Formula One car.
The good thing about this that it is a Nix OS without systemd, not NixOS without systemd. systemd is so well integrated in NixOS that any attempt to introduce an abstraction to make it pluggable would come with serious disadvantages.
I am all for an alternative Nix OS trying new approaches though, and sixos seems quite innovative.
Guix also does not use systemd, but its own service manager Shepherd.
Edit: the author of sixos mentions it, boils down to personal preference of not liking Scheme.
As a simple linux user that recently tried nixos to power a very small server, I would say that systemd wasn't part of the issues I encountered at all. It was the confusion tooling, the documentation all over the place, and the lack of ressources on specific topics.
I struggled through that phase and now nixos is pretty comfortable to me. Some of the improvements in sixos are attractive, but I'm afraid to try it because it's going to be the same thing but way worse. There's no sixos community, there's just this video, a forum post or two, and the codeberg repo. That's it.
It's a shame there isn't a distribution (at least that I'm aware of) which is dynamic and modular enough to allow choosing your own "process manager" at install or even on boot.
Artix Linux does this. Arch sans systemd, and you have a choice between openrc, runit, s6, dinit, or even some combination of the 4. Any daemon type package will have a -runit/s6/dinit/openrc variant that includes the relevant scripts/configs.
YMMV, I spend a couple of days last summer trying to get a Gentoo install with KDE running and after I changed something which caused a libc recompile, which took over an hour, I was so fed up I went back to Arch.
...granted, my potato only has an i7-6700 Skylake with 4 cores+hyperthreads for 8 threads at 3.40GHz, it's not one of those AMD Ryzen things, but still: I'm not running GNU/Linux because I want to buy a new PC every year.
this is correct, there's even a precompiled kernel (dist-kernel), it works great! and when packages doesn't match your system settings, portage will pull the source and compile them. it's great!
The normal, systemd NixOS does actually make it "stupid easy". It will fetch the latest kernel that is compatible with ZFS and has single-line config options for auto-snapshots, and the like.
I don't have personal experience with zfsboot - I have used UEFI/systemd-boot previously with ZFS root, and now use an initrd which loads the encryption key to ZFS root.
But NixOS itself does something similar, it has generations and if you change some setting and rebuild your system, the previous' link will be available in the boot menu, so you can easily try out stuff and just revert if it doesn't work - it is file system independent, but it only handles nix-specific stuff.
I had tried chimera-linux with dinit (on a VM with GNOME desktop) it was a good experience while it lasted and loved the TL; DR that chimera writes and it was DIY distro which was quite good like arch in it's initial days.
But now I'm back on fedora for want of packages and not being on a mainstream distro is all rainbows and unicorns until we hit the corner case or a missing package which is available only as flatpak and won't integrate with the look and feel of the desktop environment.
Why do people insist on living in the 1980s? systemd has enabled so much missing and previously convoluted functionality. There is a small but vocal coalition of admins that refuse to learn new skills. As if we didn't have enough "systemd free" novelty distros.
If you want to live in the past, go run SunOS. You might need a dusty old tape drive, though.
the dismissal of systemd criticisms by saying they’re unimportant (for you) or that admins are living in the past has got to be one of the most annoying things about the topic. It devolves into a flamewar because of it, since nobody can actually engage constructively once that happens.
I’ve laid my actual criticisms bare multiple times on this site.
1) The tight coupling of the userland with systemd means that while systemd replaced a pleathora of inits (not just sysv): the target is now too large to be replaced even if there are better ones. Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
2) The non-optional/default features have been buggy and difficult to replace. Journald has no replacement; systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
There are more, but these are my main ones. Throwing away the corpus of admin muscle memory is not an an issue anymore.
To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken. Part of what gives me pause is that I know how utterly undebugabble it is when it fails: it just hits those causes less frequently as the world is forced into using it. It becomes battle hardened.
Oh, and the obvious criticism agains the maintainers who have been very unapologetic to bugs and undesired behaviour, in a much worse way than the Apple “you’re holding it wrong”.
Did you ever consider that it’s also free software nerds who are the most likely to hate being told what to do?
> 3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
have you considered the reality that the "unix philosophy" results in incredibly brittle systems? byte streams ("""plain text""") are untyped and prone to mishaps.
Some of the most reliable systems in the world were unix ones.
SunOS was famous for being incredibly reliable, and its a more pure unix than the current linux environment.
And even if we ignore that, the majority of the web was functioning and functionally reliable atop linux with these text stream systems.
bytestreams are less debuggable, which feels silly to say openly since we are all aware that higher level interpreted languages are easier to write/debug/test and iterate on, but we seem not to be bothered by this not being true for the underlying systems.
Systemd clearly is working though, I’m just levying a criticism of opacity.
Text streams are considered "better", because the standard UNIX userland (unlike e.g. DOS) provided excellent tools for dealing with text streams: grep, sed, awk, find, tr, etc and of course the shell itself.
But once you get your hands on excellent tools (like jq) for dealing with other kinds of data (like JSON), it turns out everything is even more powerful - you can now work with JSON as easily as with text, it just plugs into the existing ecosystem. But even though JSON has a human-readable text representation, it is no longer just text - it is dynamically-structured, but strongly-typed data. A JSON array is a JSON array, you can't just awk it.
There are byte stream formats (e.g. msgpack) that have feature parity with JSON. jq can't accept msgpack-encoded byte streams, but suppose a hypothetical tool, msgpack2json, is widely available - just plug it into jq. You're still working on the same level of abstraction (shell pipes), but easily dealing with complex byte streams.
And of course, what we understand as "text" in the modern era, are UTF8-encoded byte streams. If your "text" kit deals with ASCII rather than Unicode runes, it's that much less powerful, and likely full of painful edge cases that you now have to debug. (Note that UTF is a 1992 thing, it's been invented when UNIX was 20-something yro, and it's been around for 30+ years.)
Debuggability of anything is entirely up to your toolkit, the quality and comprehensiveness of that toolkit is what decides the battle.
I don't think the most reliable systems in the world were Unix ones. At least, if you compare systems at that time, you should compare with what the telephone operators were using. They had legal requirements you would not find in the computing world.
Yeah, such a tool will be definitely stable and portable! Until you change the locale and the whole thing breaks apart, with no error message whatsoever..
Also, not even Linux believed in "everything is a file". Everything is either a file or a stream. The two is not the same.
The parent asked a specific question so I gave an answer.
If you disagree that text streams are a good universal medium then thats totally valid, but then perhaps don’t use a unix-like and go for something like VMS, VAX or Windows.
> systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
While I have nothing to say about your general points -
I am pretty neutral to systemd, but I really dislike how it makes porting software to BSDs harder - I have one question:
Why are you not using networkmanager on a desktop computer? I have only used networkd on a server where I needed things like MAC matching and device renaming.
Genuinely curious. On my desktop I used a wired connection, so NM is probably overkill, but I like how I can have a tray icon to manage my VPN and wireguard connections.
I typically use what's provided by my distro, because in my experience from Fedora (heh), fighting the distro is a surefire path for pain.
Even arch has opinions, even if they're much happier to mute them in the name of choice, but it's clear that your life is better if you stick to the happy path.
Without replying to specific parts, I'd like to point out that you and others bring up parallels between Systemd and closed source proprietary software shops like Apple and Windows. I view this as bad faith because Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.
There's nothing apple-esque about any of this. 'If you're unhappy fork it', is a common adage that is definitely applicable here.
> Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.
You cannot fork systemd in practice; it's enormous, and its components are tightly coupled with complex, non-stable interfaces between them. So while you have access to the source code, you do not have the practical ability to exercise the FSF's four freedoms.
GNU/Linux was created as a rewrite of Unix not because Unix was the best operating system around, but because it was a design that could be replaced, changed, and improved piecemeal. GNU were able to write improved open-source versions of the components of a Unix system - such as init - piece by piece, and test them out and use them on existing Unix systems, rather than having to rewrite everything before they could do anything. If those older Unix systems had been designed like Systemd, that would not have been possible, and Linux would never have got off the ground.
This doesn't track with me at all: Nothing about the four freedoms is restricted by systemd's architecture, it's all open source. You're comparing with an effort to replace a proprietary system. And secondly, the variations between different UNIX systems in terms of compatibility were much greater in practice than the variety in systemd interfaces between different components (which aren't that tightly integrated, anyway. Systemd-networkd, for example, is basically just another systemd service, and has multiple replacements. Same with basically everything else. And even the things that aren't 'officially replaceable' are still just as amenable to piecemeal replacement as the UNIX utilities: there are various projects that do, if they object to systemd's core for whatever reason).
I think the main reason that there isn't a systemd fork is that it's just not particularly worth it: it works well enough for enough people that no-one is motivated enough to try to improve on it outside what the project is doing anyway. And those that do strongly object to it tend to reject the whole approach and so they start from scratch, and then lack traction because they don't interoperate at all.
> The attempt at the "GNU OS" failed because the Hurd was never really usable.
Pre-systemd you could get Debian with Hurd and it was fine. There was never much reason to use it - hardware support was worse than Linux and there was no real killer feature in practice - but it worked.
It's more like Chromium; you could fork it, but it's big enough that that's difficult, and doesn't really do anything about its influence on the ecosystem.
A browser is quite literally the most complex project out there - systemd is absolutely tiny compared to it, so I don't think that would make a fair comparison, at all.
> The Linux kernel is de facto pretty tightly coupled with GNU stuff
No it isn't. They go to great lengths to e.g. make sure they can be built with clang and not just gcc. And in the other direction, prior to systemd you could even swap out Linux on Debian for a different kernel.
it was more about how my muscle memory has evolved, that I know how it works and the benfits of it- not that I think systemd is the same as it was back then; clearly not as I mentioned things that are <5 years old.
When comparing systemd to things, I find it more fruitful to compare it to something like SMF, which actually does the things people wanted systemd to do:
* socket activation
* dependency management of startup
* log control
* service supervision.
Except, it did so by interfacing with the operating system in its native language, for example: log files were text.
It is not useful to complain about bash scripts, the original design of init was indeed dated and you’d be hard pressed to find people who don’t think so; so its an invalid point to make in this discussion.
> Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
Why would you write portable software that has a dependency on an init system?
> systemd-networkd is one of the most common causes of failure for my desktop
What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
It is easier to settle on one method (like literally every other OS) and fix the bugs than continually come up with newer, equally buggy and broken, ways of doing it.
> Why would you write portable software that has a dependency on an init system?
Ask the GNOME project.
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
"Linux has 26 different incompatible ways to configure networking. Systemd solves this problem by introducing a 27th way that's buggier than most of the others"???
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
False.
One of those 26 incompatible ways works just fine in the situation where systemd is clearly not working.
It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
> It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
I never said this.
Fix the bugs. Don't fill the well with yet another equally shite solution.
Nothing in there looks particularly big or important, though. There was a lot of noise about GNOME and mutter requiring it, but that has been changed as noted on that page. Dbus is a big one, but a) the socket activation feature of it requires integration with or reimplementation of a service system, and b) There is an implementation that works with openRC instead (just not the one mentioned on that page).
Why everything is inflated and bloated? It is foundational to our computer systems.* There is alternative way, functional programming, that is much harder to learn than Object-Oriented, but makes cleaner code without side effects. So Six/NixOS is very promising and going to install it when I have learned Haskell first to understand it's foundations more deeply.
> when I have learned Haskell first to understand it's foundations more deeply
Nix is nothing like Haskell.
Also, the functional and lazy nature if Nix is not an ideological decision, it's a necessity when you have a giant monorepo config for 200000 packages. (Without laziness you'd have to wait for an hour just to evaluate the config options.)
Slides: https://cfp.cccv.de/media/38c3-community-stages/submissions/...
> On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm.
(via https://news.ycombinator.com/item?id=42881772)
Can anybody explain to me again why systemd is so bad ? Genuinely I'm not sure anymore: It is chock full of features and it gets the job done. Since it is used in a lot of big distributions it gets a lot of fixes, updates, testing and feature improvements regularly.
Yes, it is maybe monolithic (but so is the Linux kernel). Its philosophy may differ from unix's "get one thing done well" too but integration of various functionalities comes with its benefits.
Some people say it is bloated. The substitutes to systemd are lightweight but less featureful. Maybe some of them will get bloated as they achieve feature parity.
People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy. However I can't understand why systemd is the point of so much disagreement.
I think this is as good a time as any to reread "The Rise of Worse is Better".
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
The article compares the Unix/C philosophy with the Lisp philosophy and concludes that Lisp is "better" (it is The Right Thing), but that Unix/C will probably end up dominating. Obviously, he was right.
The article is pretty famous around the suckless, minimalist, crowd. But I think everyone who reads it takes a slightly wrong lesson from that article. The point isn't that Unix/C won because it was simple. The point is that Unix/C was simple enough to use, simple enough to implement on most available hardware and that it did everything you needed it to do.
The minimalist people have turned software simplicity into the modern version of The Right Thing, and are surprised when they found out that the "worse" (more complex) thing wins. But The Right Thing will never win. The Good Enough always wins.
Is Linux better than *BSD? Well *BSDs are more simple, easier to understand and reason about etc. But, at least OpenBSD, doesn't have mount --bind, so I can't use it. Case closed. And I think that's the case for most people. Linux has thing X which I need so I will use Linux, even if ideologically *BSD is imo better.
Is D-Bus The Right Thing? No; but it is The Good Enough. polkit, selinux, ACLs, and so on.
The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
SystemV init was not good enough for complex service management. systemd is. systemd simply does everything you need it to do well enough. So systemd wins. Simple as. It will only be replaced when it is no longer Good Enough.
Exactly, for some values of "good enough". (Unfortunately IMNSHO) Systemd cannot be toppled by all-out assault. It must be subverted. Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
Something like Wine, where in the analogy systemd is the Microsoft Win32 API and we want to be able to run systemd "enabled" software on something else. Or at least re-compile it.
Wine also started with an incredible amount of stubs which did nothing, but that was often enough for many programs to work anyway.
Yeah. Exactly. It's also how Wayland and Pipewire managed to win: by being backwards compatible with X and Pulseaudio, while also overcoming their shortcomings.
The problem is that if the only complaint with systemd is that it's too complex, any backwards compatible alternative will necessarily be as complex as systemd + the new thing (at least in terms of complexity of interface).
If there are actual technical deficiencies of systemd, then sure, maybe such a backwards compatible alternative might be in order.
Also, everything expands in time. Wine may have started out with many stubs, but now we're at the point of implementing Windows-y APIs in the kernel with the sole goal of improving wine performance (NTSYNC).
D-Bus is good enough for all sorts of things. But you absolutely don't need a behemoth like systemd to use D-Bus. A D-Bus communication option can be added to existing programs and utilities, or new ones could be fashioned for which it is a central mode of operation; and still there would have been no an ever-growing pile of centrally-maintained and inter-dependent artifacts.
As for SystemV... as I mentioned in another comment - in hindsight, that was not the issue. There were and are SystemV alternatives [1]. One can even write one that uses D-Bus in an opt-in fashion, to foster other facilities' use of it.
The init system excuse is very much like the stone in the fable of the stone soup: https://en.wikipedia.org/wiki/Stone_Soup - it's what gets the vagabond's foot in the door, and is the first ingredient for the soup. But actually, the stone carried no significance, and the resulting soup is pretty much the same thing as without the stone part.
[1] : ruint, OpenRC, launchd, s6, nosh, finit, procd, upstart etc. See brief description and links at https://alternativeto.net/software/sysvinit/ for example.
> The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
I'd wager the vast majority of (non-embedded / single-purpose) Wayland deployments are gnome and KDE.
Obviously, but I'm talking about bare window managers, not DEs. Alternatives to i3, awesomewm etc. Different niche.
River is very good but a niche in a niche. Telling that ive been using hyprland though.
Part of the problem with all of them is less the wm and more knowing what parts you need. Not so much bars as portals. I'm vaguely surprised hyprland doesn't have a "good enough" batteries included config and documentation.
I think a lot of the arguments I’ve seen stem from “Unix philosophy” style arguments. Also, historically the systemd project has been quite hostile to user requests in some cases, which broke existing workflows for people.
I personally think the basic “service manager” functionality works pretty well and I like systemd overall.
However, the same is not true for a bunch of the more peripheral services (e.g. resolved, networkd, timesyncd). What’s particularly annoying is that there exist mature open source projects that can provide better functionality in a lot of cases which could be used, rather than bundling a half-assed attempt with systemd (eg. unbound, chrony).
> resolved, networkd, timesyncd
None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.
Yes, but not using those seems to defeat the point of using systemd.
The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
> Yes, but not using those seems to defeat the point of using systemd.
I don't see how it defeats the point - it still nice init / services manager, it still provide features say sysvinit couldn't do at all for my _services_ and management/lifecycle of services.
How often I tackle with resolved or networkd or timesyncd - not even sure, may be once a 2-3 months, while systemd-as-service-manager I do almost every day.
Mind providing some example on your setup/cases?
If you don't use them, you still have a standardized way of managing system services, including scheduled batch jobs. The other services are a convenient and integrated way of getting a basic version of that functionality, but they are by no means the entire point of systemd.
At this point, I am willing to believe the point of systemd is to be the new way to do anything. "If you want to talk to the kernel, go through me".
It's a new (ill specified, non standard) runtime to target. It's like what Win32 is to the raw NTDLL, or the dotnet or Java API. It hides the OS.
Apart from the comparison to NTDLL making no sense, you'd be wrong about the tools too. It aims to provide a basic standardized way to do most system-level management (set up networking, do DNS resolution, get a decently synchronized system clock) but it absolutely does not aim to replace more specialized tools like chrony or NetworkManager. For example, timesyncd doesn't do NTP or PTP, only SNTP.
systemd (the PID 1), journald and udev are different, though, because they're mandatory; and there's no alternative to logind while technically optional.
How so? The functionality of the kernel and of systemd are basically orthogonal: neither really provides features that the others do. There are some interfaces in the kernel which are basically intended to be delegated to one userspace process, like cgroups and the hotplug management done by udev, so talking to them directly as an application or library is probably not a good idea and those processes provide a means of co-ordinating that, but that's a kernel decision and the udev one predates systemd.
Uh, yes? Win32 is also largely orthogonal to NTDLL. Doesn't mean one has to love all choices made by Win32.
Of course. That standardized way is runsvdir, yes?
I remember that on one of the $dayjobs around 2014 we have used runit, but I honestly don't remember why and what it gave us. Very likely just as auxiliary tool, not main init system.
Really curious now what it was so.
So, systemd is like "doing Linux services the Microsoft way"
Your remark may suggest that everything MS does is “wrong”. This is of course an extreme overstatement and all of their approaches should be evaluated on their own.
So far the argument for systemd seems to be "well it works so why are you complaining"
It's a declerative boot system, where units can declare their dependence on another unit/service, and they will be brought up in accord, with a potential for parallelization, proper error handling, proper logging, all while the user complexity is a trivial .ini-like file.
It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
systemd is just much better for managing cross-cutting concerns. E.g. having the machine wake up from sleep for a timer and do a task (e.g. backup or updates) which delay sleep is trivial, portable and reliable with systemd and probably technically possible without it.
Sorry, I'm not deep enough into it to determine why systemd would be better. Perhaps it's not. I know it's less unix-y, but we shouldn't treat that as holy imho, it's a good guideline though, I try to follow the unix philosophy.
it's a good argument
It comes down to a philosophy you choose.
I personally think that most of the OS decisions done by Microsoft are wrong and should be killed with fire but also I'm far from thinking bad about the people who made these decisions. Perhaps these decisions make sense from their standpoint given the information they had a time.
On the other hand on Linux I'd really wish for a centralized settings repository like Registry. But not from the systemd crowd, of course.
resolved and timesyncd are intended to be removed by the end user of the operating system. Sort of like a transparent peel is intended to be removed by the buyer of a new shiny device.
I haven't seen anything worse than those two from systemd crowd.
Resolved is useful if you frequently change networks (e.g. a laptop), particularly if you’re also using an overlay such as Tailscale. Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it.
I started using Linux because I liked stability. Systemd makes a Linux system as dynamic as a Windows one (which is nice) at the price of making it as stable as a Windows one (which is not).
I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
Also, bringing INI to Linux is unforgivable.
> Resolved is useful if you frequently change networks (e.g. a laptop)
I can see the case. I use it myself on a laptop. And by "use" I mean that I just gave up looking into Linux desktop networking like a decade ago. It works, fine.
> I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
... this is ... incredibly wrong. Hardest disagree on all points here.
It's worth pointing out that Lennart Poettering simply rubbed some people the wrong way in his communication, and that ended up reflecting on systemd, irrespective of the software itself. (I am not making a case that this is good or bad, right or wrong. Just pointing it out.)
And there is the track record:
https://security-tracker.debian.org/tracker/source-package/s...
That looks not too bad considering what it does and the time range of CVEs
Maybe you can do a comparison to another well known open source project and see how well systemd fares: https://security-tracker.debian.org/tracker/source-package/l...
some?
Let's rephrase the question the other way: is there anyone who thinks that LP's attitude is fine?
I think you answered your own question:
> monolithic
> It's philosophy may differ from unix's "get one thing done well"
> it is bloated.
Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
If you want to use an alternative to systemd on those distributions, you are usually on your own, constantly trying to fix it whenever there are breaking changes.
It's good to have options which are simple to replace.
> It is chock full of features and it gets the job done.
So is Windows :)
>Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
I don't think the phrasing is correct. Your choice of word (spread/ingrain itself) seems to imply there is malicious intent. Software do not sneak itself into distribution by themselves. It is the other way around. Distribution creators have total freedom on what components/software they find useful to build their distributions on. If a majority of distros decided to use systemd, that mean a majority of people maintaining distributions found the positive outcomes of using systemd were worth dealing with any disadvantage it may had over using another solution.
> If a majority of distros decided to use systemd, that mean a majority of people maintaining distributions found the positive outcomes of using systemd were worth dealing with any disadvantage it may had over using another solution.
This is overall fairly weak evidence that users actually find the software to be of quality. Surely there's got to be a stronger signal that this is a positive way forward, like users enthusiastically saying "wow this is an improvement".
> like users enthusiastically saying "wow this is an improvement".
Who are the users in this case?
Weak?
I find it hard to imagine objective evidence more robust than the real-world actions of subject matter experts who make real-world decisions. This would have been hotly debated within teams of Linux experts at Debian, Ubuntu, Fedora/RHEL, SuSE, and Arch. These aren't armchair experts who debate on the internet, they're the ones who actually make decisions and, more than most, wear the consequences of those decisions.
Yes, systemd is wow, it's a major improvement.
> seems to imply there is malicious intent
There is. Well, sort of.
For example, we had cron working just fine for decades . We had sshd listen on its port for decades. We had fstab for decades. No one wanted systemd-timesyncd.
In my opinion, all these aux systemd projects came to life purely out of psychological reasons. Can we label them malicious?
This isn't true. A lot of higher level stuff (e.g. GNOME) assumes systemd.
How it managed to spread is no surprise. Linux desktop was a complete mess with consolekit and unmaintained stuff. Then they supported cgroups which distros wanted to use and since all the unmaintained stuff didn't there wasn't a lot of options.
Booting up a system is a complex domain. If you randomly cut a complex domain into pieces, you will have the exact same complexity PLUS a huge amount of additional complexity for all the communication/error handling between the different parts - what other complex domain uses million tiny tools? Does chrome use curl and then pipe it into a html renderer and whatnot? Sure, there are libraries (that's a different architectural layer though with less complexity to break, and functions don't decompose arbitrarily either). The unix's philosophy is more of a sounds good on paper, and there are certain cases where it applies - it's definitely not universal.
Also, the core of systemd is not even particularly big. People often mix into completely optional modules that run under the wider systemd project, but that's a false conclusion that "systemd eats the world".
> How it managed to spread
You mean that individual distributions voted/decided separately, multiple times to choose the better tool? Debian has the most democratic voting system and unanimously voted for systemd.
And yeah, if I want to use my own display manager protocol instead of X or Wayland I would also be similarly stranded. Options are good, but standards and compatibility are just as important - a million incompatible options only give rise to chaos.
I am, for example, very happy that Linux applications are finally not as distribution-dependent and there is a good chance to run that .deb file on anything else running systemd without much trouble. I remember the times when it was not so.
> You mean that individual distributions voted/decided separately, multiple times to choose the better tool? Debian has the most democratic voting system and unanimously voted for systemd.
They are influenced by other distros decisions. Debian's justification of adopting systemd starts "Systemd is becoming the de facto standard init system for Linux." https://wiki.debian.org/Debate/initsystem/systemd
I do not think this looks like a unanimous vote: https://www.debian.org/vote/2019/vote_002#outcome
> Booting up a system is a complex domain.
systemd goes far beyond this domain.
> You mean that individual distributions voted/decided separately, multiple times to choose the better tool?
This is a mystery to me. Given the LP attitude is known to be hostile to people with expertise and given the cancerous nature of systemd projects, I really wonder how did people choose to be treated that way.
Maybe they have voted for systemd-as-PID1, which is incomparably better than sysvinit, but this is the way systemd crowd got its foot in the door and before you know nothing works without systemd metastasis present.
You can’t pull the facehugger out, OTOH I wonder what form it will take when the egg hatches.
"and it gets the job done."
Until it doesn't. Fortunately I didn't have to debug it often, but when it was a lot of pain.
I prefer the fs under /tmp to be tmpfs. On the BBB is wasn't. I changed that and on next reboot the system didn't come up again -- no way to log in. Why? And what to do? Turns out I failed to state the fs_freq and fs_passno fields -- those aren't optional, but while the old mount tool tolerated their absence, systemd chose to interpret the fstab strictly, failed to mount that fs, consequently didn't reach the local-fs.target and hence didn't offer any way to log-in. Unlike Raspberry Pis, the BBB doesn't offer the possibility to remove (and mount and debug elsewhere) the boot medium. Fortunately, I found help on-line on how to connect a serial terminal to the BBB and interrupt the boot process, forcing the use of /bin/sh as init process...
> Can anybody explain to me again why systemd is so bad ?
It's huge, messy, has a poor bug and security history, obfuscates things that don't need obfuscating, and is just generally IMO not a clean or efficient implementation. It's a very Windows style solution, very different from the lean and minimal stuff I like to run generally.
The advantages it provides are questionable, and are dwarfed by the issues it has had in the past IMO.
OpenRC perfectly meets my needs at present and my system boots incredibly quickly. When s6 is finished that situation will only be improved.
It would be good to know if it's as ergonomic as systemd. I know it's not perfect, and sometimes the docs are confusing, but it is pretty simple to create a service that starts on boot etc. No scripts required, really.
> OpenRC perfectly meets my needs
What distro are you running?
> People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy.
It's a blessing and a curse. Look at package managers, they more or less all do the same thing, with one primary job of "go download some binary so I can run it", yet there's so many to choose from. Every time you read some Linux guide they have to list 7 different ways of installing the same package. It's stupid, probably even more so for the maintainers of those packages because they have to distribute their package 7 different ways. At least I'm glad systemd has mostly become the standard, so you don't have to also see 7 different ways of creating a service.
Usually, it's the distributions problem to package software. You as a software developer publish documentation on how to build your application and then simply wait for other people to do the packaging for you. The creation of services is the same, you can maybe create a recommendation, but the service definition is part of the package file and thus not your problem.
In practice, though, the packagers quite liked systemd, because it a) makes service definition easier than any other system, and b) it significantly increases the likelihood that the developer has already written a suitable service file (and developers will like that that is used, because it reduces the chance that a packager makes a mistake and increases their support burden).
And as an end user of multiple distros, I really appreciate it because I also have to make services on occasion and it's nice that there's one way to do it and it's pretty easy to do correctly.
Usually, this is not good enough. I as a software developer often make use of the package manager built into the language of choice and use that to distribute my software. I also commonly make use of package managers of languages that I don't use to install software.
We are overdue to package manager interop and common interfaces.
I think you are beating a somewhat dead cow here. systemd wars are over. It's in most mainstream systems nowadays, but there are also lots of cool projects out there doing different things. Everything's fine, nobody wants to go into those old pro and con flame wars any more.
> systemd wars are over
Well yes but actually no.
With every new Ubuntu version I have to carve out new metastasis no one asked for. For example, 24.04 (or maybe even 23.10) changed the way sshd is started up - by systemd listener instead of sshd on its own like it was for decades. This way they saved a few megabytes of RAM (solely on computers that are not exposed to the internet, of course).
While fighting against systemd-as-PID1 is futile for many years, fighting against the spread is definitely worth it.
Fair, point taken: Some people are working on systemd replacements because they want to build some cool things in that area. Just like there are multiple programming languages and no one says "Why don't you just use Java/C++" it should be OK to work on Linux systems without systemd and not think too much of it.
Everything is fine, unless/until many developers begin to assume systemd is present and make software ports to non-systemd Linux (or *BSD) systems prohibitively expensive.
> Everything is fine, unless/until many developers begin to assume systemd is present and make software ports to non-systemd Linux
Nothing wrong with this if a system service is going to be present on 99.999% of installs and frees the developer from having to do work.
e.g. GNOME swapped its service manager for subprocesses (e.g. bluetooth) to systemd user units because it does a far better job.
> Nothing wrong with this if a system service is going to be present on 99.999% of installs
Is there a sign linux installs will hit this metric in our lifetime? I don't think there's any strong indication of this. There are multiple distros devoted to not moving to systemd.
> GNOME swapped its service manager for subprocesses (e.g. bluetooth) to systemd user units because it does a far better job.
Not on computers without systemd it doesn't! Besides, Gnome still runs just fine on systems with init scripts like *BSDs with no visible loss of quality or stability so this was a purely political choice to spite their own linux user base.
> it gets the job done
Except exactly the opposite is true: it is sysvinit (and derivatives) who had the job done. In a very basic way, slow and perhaps not even compatible with modern requirements and expectations, but the job was done.
Systemd on the other hand does the job it thinks should be done, not you. Your opinion does not matter.
You can spend however much time you want editing /etc/ssh/sshd_config and then restarting sshd and then pulling your hair out on why tf sshd ignores certain options while still definitely parsing sshd_config. Only to later find out that systemd/ubuntu crowd decided to listen on port 22 via systemd, sort of like inetd did back in the days. It's like sshd directly listening on port was not good enough for the last 30 years, definitely had to be changed. Oh yeah, and to make your life miserable, they mask the name of the listening process with "sshd" in it, so you get confused even more.
And people can come up with countless of similar examples.
Incredible attitude and arrogance is what makes people hate systemd.
I'm sure you have other examples (and I'm not really asking for them) but your sshd example would make me dislike the choices Ubuntu made, not systemd. Like I don't blame systemd for snaps being so awful.
You are technically right.
My view is that there is an attitude/approach spillover from systemd crowd into other teams. Switching port 22 from sshd to systemd was not something that any sane person could come up with. It's a stream of incredibly hostile decisions from systemd upstream that allowed that kind of thinking.
Big monolith that imposes requirements on your system and robs one of the feeling of knowing how the whole thing works?
At least that’s me. I use systemd in most of my installs for reasons similar to yours, but nothing feels more sublime to me than installing a simple init system and a few other daemons for system features I actually use.
What requirements does it impose?
Also, feel free to "rob that feeling back" by learning how systemd works
> What requirements does it impose?
Numerous kernel features, reliance generally on it by itself and by third party programs (running ceph w/ openrc is hard bc it assumes systemd is present). I’m buying the full car when I use it, when what I really want is a kit that I can optimize for purpose. Honestly though, this close integration is worth it. My main OS build at the moment is pretty much just systemd and podman on top of linux.
> Also, feel free to "rob that feeling back" by learning how systemd works
I really want to! I just don’t know any good resources that can help get me familiar with all it’s doing for me in the background. All I know about it is what I have gleaned from tutorials, I don’t yet feel I know what’s possible with it yet.
Ok, try to go off the well trodden path of a default systemd setup.
Eg. make your system "login interactive" before networking and other unneeded services (database, web server, whatever) are even attempted to be set up/started.
Use just drop-in configuration fragments (*.service.d/override.conf) without making an unmaintainable mess (ie. without making your own copies of whole, OS installed unit files).
That should get you the feel. :) And it's not something crazy, it's just basic re-ordering of dependencies.
Its not that hard, just a matter of reading the systemd documentation and learning about default dependencies: https://github.com/lukasstraub2/systemd-delay-services
Indeed, nothing crazy.
>learning how systemd works
Waste of time. It's easier to get used to a systemd-free distro
That's a really negative comment with little to no contribution to the discussion. Care to elaborate more on that, so that we can discuss detailed points instead of blanket statements?
> Can anybody explain to me again why systemd is so bad ?
See the slides of the linked talk, starting at page 7: https://cfp.cccv.de/media/38c3-community-stages/submissions/...
> Guix solves the following problem: – I love scheme and want to minimize the number of hours I spend dealing with any other programming language.
This is a pretty common feeling after writing a couple of nix packages.
In the last two years I have spun up new-ish, actively supported versions of ubuntu for pre-production rollout that were shipped with a systemd-resolvd that would occasionally just stop responding for no reason. Logs said nothing was wrong, process was UP and saying it is ready to do work. strace shows a hung process.
Stuff like this is possibly where the complaints from some people begin.
Fortunately, I can find a tracked bug that is active. New updates get pushed, as the honestly phenomenal community of people intended this process to go. But How may years have some of those people been patching bugs like this in systemd on a regular basis? Did that time have to be spent if systemd's architecture was better from the get go?
The Trail of Bugs to get to the point we are at today has truly taken a monumental effort from MANY people. Why wasn't systemd's community doing things well "enough" from the beginning before being folded into so many OSes?
Let's be real. From then till now they have put in hard work, in the face of huge community pushback, because someone had to do it.
Diehards feel it felt "foisted" upon us before it was fully baked, everyone knew sysvinit was way past its prime. Put up or shut up. Plug in a different init for your OS and move on.
But, you know, people like talking and complaining to each other. It's a very important part of solving technical problems!
Resolvd is not part of systemd's core. Would some KDE app misbehaving be a fair criticism of the whole project?
Also, I would be delighted to see that mythical program that requires no maintenance and just works^TM.
Also, what does it have to do with systemd's architecture?
> Would some KDE app misbehaving be a fair criticism of the whole project?
...yes? If dolphin sucked then that's a fault in KDE.
> Resolvd is not part of systemd's core
It sure feels like it because Ubuntu insist on installing this incredible piece of software even on the server installs.
I think the previous poster made it clear they were just explaining where the complaining comes from. Why are you trying to debate their description of other people's motivations for complaining?
> Diehards feel it felt "foisted" upon us before it was fully baked
That was the minor problem. The major meta-problems are that:
1. The baked form itself is broken. It has numerous fundamentally flawed aspects to its design (and to its existence as a project). More baking would not have helped this.
2. It is not intended as an option, nor even just the default option - but to make more and more utilities and libraries for managing various system facilities and services become unusable and incompatible, to be taken over by systemd. It's not like foisting, say, Thunderbird instead of Evolution as the default mail client; if you don't like it, you run the other thing. Or even version X of the kernel instead of version Y of the kernel and so on.
> everyone knew sysvinit was way past its prime
At this point we can say with clarity that systemd has almost nothing to do with the choice of init system. You could replace the init system with any number of things - some already existing 15 years ago, some which could be developed in the mean time. In hindsight, this is an excuse and not a reason.
systemd has done nothing but make my life easier. The people still moaning about it simply haven't used it and refuse to learn.
Nothing makes my life easier than pulling my hair on why tf sshd listens to port 22 after editing /etc/ssh/sshd_config and restarting multiple times. Oh, of course, it's now systemd that listens to port 22, not sshd.
Nothing makes my life easier than cleaning out crontabs of things that wake my box in the night and find out that something still gets launched. Oh yes, systemd now has timers no one asked for.
Nothing makes my life easier than disabling a service then masking a service then masking it's sockets, then blanking files then chattr +x those files and end up having broken ubuntu instance because there are so many ways to launch a service it's not even funny at this point.
Nothing makes my life easier than finding out multi gigabytes /var/log/journald folder that has exactly zero reasons to exist because text-based logs are still collected and properly rotated in a place where any sane person would expect them to be.
Shall I continue or do you get the gist? :-)
An important skill in life in general is to understand that your personal needs and requirements are not the same as everyone else's.
Some people may be at the other side of bell curve of "understnanding systemd on X axis" and "liking it on Y axis" of the graph. :)
Some defaults are not good for servers. For example, systemd gives up after a few tries to restart a service. This is really annoying for server administrators when they don’t know about the bad defaults.
https://michael.stapelberg.ch/posts/2024-01-17-systemd-indef...
If a service fails to startup after n times, I most certainly want to take a look at it as it might as well just end up corrupting its state even more - I don't think it's a fair assumption that most errors will just go away on their own. Nonetheless, it can be configured declaratively as a single line, and as you mention, the default can be changed.
There is a wonderful talk by Benno Rice a few years ago. Insightful and entertaining. Not focussed only on the negatives, BTW.
https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s...
https://www.youtube.com/watch?v=o_AIw9bGogo
HN discusion: https://news.ycombinator.com/item?id=19207533
LWN comments: https://lwn.net/Articles/777595/
For the GP: This is not a talk which explains why systemd is bad, it's a talk which argues which systemd is good and misunderstood. Which I don't agree with, plus isn't what you asked.
Indeed, as the LWN reported stated: "His attempt to cast that story for the pleasure of his audience resulted in a sympathetic and nuanced look at a turbulent chapter in the history of the Linux system."
I believe "nuance" is the key word here.
I think OpenRC is easier to use.
But overall, I agree on this point. Having been a Gentoo purist during Uni time, I'm now full on NixOS. NixOS has fully abstracted away any interaction I have with SystemD, so I don't think it's useful to replace it.
SystemdD does too much and it's like a monopoly, because it's so much work to replace, it can piss you off a lot, it needs to be very shitty for you to replace it.
It might be just psychological not technical.
Humans have a natural tendency to change resistance. This tendency tends to be higher in sysadmins who are often deep into autistic spectrum.
Sorry, but there many people who do not like bloat, bad practicies and daily security bugs, partially because of the aformentioned bloat. If we settle this "gets the job done" mindset we are never going to improve.
For me, it's primarily its scope. I had a system for 10 years that changed, but fundamentally worked the same. With systemd, the changes exceeded my threshold and continue to expand into something that to me, seems ugly.
I'm not a typical example. My view is inarticulate, subjective and maybe even irrational, but I remember the system I came to love and that was Linux. My overwhelming impression with systemd is that it's not Linux and it should not be referred to as Linux or even in the context thereof. It's not evil or bad or anything but itself, but it's not Linux. In my abstract, medieval view, Linux has a soul, albeit, at times, a tormented one. Systemd exorcises this soul for me.
Now despite me disclaiming the subjectivity and abstraction of these perceptions, I'm pretty certain there will be some hostile replies, possibly with valid points. If you're really trying to understand the creature, I suspect it's very improbable that it will happen here. There are existing strong, well written arguments both for, against, and even neutral. Definitely worth one's time if understanding is the true objective.
For me, it's scratching a chalkboard and smells bad. It frightens me and makes me sad. It's worse than brussel sprouts and freaks me out.
It's incomprehensible. I make some changes to config files and they don't apply so I have to find whatever poorly-documented systemd thing is controlling it instead. It is taking over every important area of the operating system. Init, login, boot, it just keeps spreading. I think on other Linux systems I am better able to reason through and modify aspects of the system or fix a problem I am having.
I have been trying out atomic Fedora and enjoying it. I like ostree, read only root, podman, building the distro from containers. I think I have had enough of systemd, though, and might move on because of it.
Just see `systemctl $command $unit` to discover that systemd it's not designed by sysadmins, while it's built for them. That's it's problem, like stratis/btrfs vs zfs.
These are software designed by people who have no experience in user-centric design, they design in theory, reasoning in theory, ignoring practice.
> Can anybody explain to me again why systemd is so bad ?
it isn't, it's great. it is different, though.
and then come in two phenomenon:
1. people resist to change, often out of ignorance.
2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
> Yes, it is maybe monolithic (but so is the Linux kernel).
it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other. systemd appears to be monolithic from outside, but it really isn't.
> Maybe some of them will get bloated as they achieve feature parity.
they will, most likely. it's easy (as a piece of software) to be lean and clean when you're doing very little (with little error checking and recovery).
> However I can't understand why systemd is the point of so much disagreement.
systemd was essentially pushed down everybody's throat by Red Hat when they realized it was high time to level up the boot process for the whole ecosystem. systemd made a bunch of things not only feasible (concurrency, on-demand service activation, multiple-instances of the same service running, proper log management) but so easy they're trivial.
so 10+ years, it's definitely a net positive.
some people are still complaining but meh, some people will complain anyway, so let them talk, whatever.
> systemd appears to be monolithic from outside, but it really isn't.
If it looks like a duck, walks like a duck... systemd is modular solely in theory. In practice, I am grateful that I can still remove journald and resolved from current Ubuntu installs and I'm pretty sure that's not going to be possible quite soon.
Systemd itself may be modular, but practically distros are not going to bother.
> 2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
And from that the systemd crowd tend to draw the following conclusion: if something was done a certain way for decades then it is bad and should be replaced.
>> Yes, it is maybe monolithic (but so is the Linux kernel).
> it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other.
So where are all small the projects trying to replace the small parts of systemd? AFAIK there are no stable or convenient APIs in all those parts, so even though technically systemd consists if many binaries, it is monolithic.
This is exactly what people call "forces distributions to use it", i. e., you must choose all or nothing.
I don't believe Linux userspace maintainers are lining up en masse, plus if your alternative implementation doesn't significantly improve the status quo, why even bother?
Here in the comments you can find a lot of complaints about non-main parts of systemd, which could be improved easily if it was actually non-monolithic.
> So where are all small the projects trying to replace the small parts of systemd?
you should go ask that to "small projects" developers, not to systemd developers, i guess
There are always people improving small things as a hobby - except for the systemd components. It tell us that it's harder than it seems.
The usual arguments against systemd border on religious drivel. I've seen the talk and while I very much value the work that the speaker has done I did not appreciate that the reasons for doing this are the usual vitriolic cat-v talking points.
systemd is very good because it makes many things that the Linux kernel can do very easy. I would like to know how the people who swear against it implement features that I regularly use in systemd like socket/mount/dbus activation, services that dynamically create a user and group on activation and keep their service and temp directories private from other services, syscall filtering, user session services that start when I log into a graphical session (very useful when you have issues with your system tray's config, for example), network mounts that get mounted asynchronously only when you're using them, actual service management and restarting a service when it fails and service dependencies (which some init systems still don't do!), and so on and so forth...
Yes you could do all of these things by composing other programs, but there is lots of value in having them all bundled together and only having to consult one resource for documentation on them, and the fact that these are all designed to work together reduces the friction that you would get by composing other "general-purpose" tools.
On the other hand, systemd is bad because the implementation is messy, when it does fail it tends to do so in odd and obscure ways, it comes bundled with tons of components that most people won't need, and yes the fact that it's essentially the only option you're given and that it's not portable to BSDs is not very nice.
I would encourage people to read dinit's comparison page and Chimera Linux's FAQ section on systemd for good arguments that are not fueled by religious belief as to both why systemd is valuable and in which ways it is bad.
https://github.com/davmac314/dinit/blob/master/doc/COMPARISO...
http://chimera-linux.org/docs/faq#what-is-the-projects-take-...
> I believe in the "Let a hundred flowers bloom" philosopy. However I can't understand why systemd is the point of so much disagreement.
Your first sentence explains, to a great extent, your second. You see, systemd is designed to _prevent_ a hundred flowers from blooming. Unlike most Unix-like system components, the idea is for systemd not be an alternative replacable component, but the whole installation above the kernel. You don't choose things; you get those services and facilities which live within systemd; and those which don't - mostly won't work. That is, unless you tear out everything related to systemd. Which is difficult, since GNOME and some other packages over time have introduced dependencies on systemd, rather than on services or facilities it provides via a common protocol or interface.
This was also how the big Debian debate exploded, causing the fork of Devuan: The "opposition" did not demand "No systemd in Debian!", but rather, that the user would be able to choose not to have systemd at all, if they so please. I am paraphrasing from memory of course, but I believe that was the gist of it.
And the speaker in this video faced this situation.
I am not well-versed in NixOS and certainly not in this new project, but I imagine that if the author could easily just configure NixOS not have systemd, they might not have bothered starting this project and would more likely have published some kind of recipe/how-to page on
>However I can't understand why systemd is the point of so much disagreement.
I think the simplest way to describe it is that it's a religious conflict.
A not insignificant segment of people who develop and/or use Linux are fervent followers of POSIX philosophy, the Unix heritage, Free Open Source Software development, and the Anti-Microsoft Church (note: Poettering is a Microsoft employee).
These people have a religious duty to hate systemd, it's essentially heresy. It's not a disagreement based on technical or even practical merits, so the conflict can't be addressed with technical debates and will continue for the foreseeable future.
> disagreement based on technical or even practical merits
Philosophy can't be reasoned based on merits. Of course there are technical merits as to why systemd-as-PID1 was (not today!) an extremely good piece of software compared to sysvinit, there's no question about that. Likewise there are valid technical reasons why systemd-timesyncd should be abolished and never mentioned again.
But how do you decide LP's attitude on merits? How do I argue with Red Hat who shoved systemd down everyone's throat?
So yes, it's a religious question of sorts. The religion that made Unix unix.
You think you get to just declare the opinion that differs from yours invalid by calling it religious?
Don't the holders of that opinion get to call your position equally religious?
"not a disagreement based on technical or even practical merits" indeed, right there in the mirror.
The first few minutes of this video absolutely articulated some perfectly technical and practical merits. So have some comments here on this hn post. I don't see how it's valid to say no one has ever produced any.
I think the debate on systemd as regards to its merits was decided already years ago when all the major Linux distros adopted it. You need to go way out of your way to run Linux without systemd now, people who want that setup have clearly become a (very small) minority while the rest of the Linux world moved on.
The conflict as parent commenter witnesses it continues because that small minority continue to (very loudly) disagree not on the merits. It is their prerogative to disagree if they desire, but their basis is much more about beliefs than superiority.
It's like Polandball memes where UK crazily chants "Britannia rule the waves...!" while US goes off to freedom some oil with its boats.
Good thing all decisions over at CorporateLand (Ubuntu, RedHat etc) are made on merit alone!
And that their merits align with the merit of everyone else. /s
Here's my hot take: systemd is the best thing that happened to Linux.
I genuinely believe it's the reason Linux has dominated the other operating systems in the server space in the past decade. As someone who manages servers I wouldn't even consider the other options in space right now, and the features systemd provides is a substantial part of that decision.
As a person who manages thousands of servers I genuinely fail to see systemd as anything but a problem. I can certainly see systemd on Desktop, where the environment (network, screen resolutions, peripherals) are always changing on the go, but on server where everything is more or less fixed... systemd? The worst. Unlimited source of problems.
This is pretty cool. I especially like the better encrypted boot support and that it seems to harmonize better with nixpkgs (https://discourse.nixos.org/t/sixos-a-nix-os-without-systemd...). Curious about the infusions bit.
It not having systemd seems like a bit of a distraction from all of the other stuff that has gone into it.
> I especially like the better encrypted boot support [...]
For some reason I can't directly reply to transpute's comment, but it's relevant to this thread so here goes:
> Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground [...].
Desolder the EEPROM and read the secrets - the loophole is open wide without a TPM/SEP.
The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors, while desoldering and reading the flash is trivial for a hobbyist with cheap tools and some patience.
However this is still an enormous step forward. All of the recent attacks on secure boot chains on Windows[1] and Linux[2] are due to usage of partially-unencrypted core system components in a complex boot chain. Sixos takes the correct approach - minimise the attack surface. All it takes is to stop rejecting the "voodoo" and take what the hardware already offers.
[1]: https://news.ycombinator.com/item?id=42747877
[2]: https://news.ycombinator.com/item?id=42733640
You're right. The slides about infusions and the discussion at the end about them were unexpectedly the most interesting part of the talk.
amjoseph focused a lot on the s6-init stuff, but I really think that infusions and the way they lead to more composable system configuration is the key thing here.
NixOS' module system works, but I don't think there's anybody who thinks it's particularly pretty or generalisable. As soon as you want to run one service twice with slightly varying config you're SOL ...
https://github.com/NixOS/nixpkgs/pull/372170 is a promising step towards running multiple instances of a service with separate configurations and decoupling from systemd.
systemd already has encrypted boot support. I suppose when you rip something out you have to reinvent all its functions. At that point, any rational person would question the reasons for doing so.
Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
So removing a transmission and installing/testing/improving a new design or way to solve the problem that hasn't been popularized isn't a worthy cause? How do you think we developed the first transmission? Or the various improvements we all take for granted these days? Yes, systemd can do this, but that isn't a reason to imply developing an alternative that can do the same, albeit in a different way, is irrational.
> systemd already has encrypted boot support.
It has all of those words next to a bullet point, but the implementation is quite different, and I (like the presenter and probably many many others who are clearly not you) have more confidence in a simple fuse than with systemd[1].
[1]: https://app.opencve.io/cve/?vendor=systemd_project&product=s...
> At that point, any rational person would question the reasons for doing so.
That is excellent advice. The presenter has done something you clearly cannot. You should be rational, follow your own advice, and try to figure out what those reasons are (hint: some of them are actually in the video). That might take a few hours to a few weeks of reading depending on your own experiences, and that's just how life is sometimes.
> Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
When I have a new gadget I want to produce, I'm responsible for all of the code in it, so productivity, reliability, performance, and size are important to me whether I have written the code or I have merely used it in my product. I do not understand the way these things are important to the systemd people (or even if they are important at all), so for me, systemd is off-the-table to begin with.
Or to put it another way: I never needed a car in the first place, because I'm making boats, and I'm not starting with a car just because I like the people who made the engine. Ignoring "solved problems" can just make everything more expensive, and maybe I only know that because I've seen enough people make that mistake, but sometimes this is true.
Keeping an open mind means allowing yourself to be convinced too.
Hear hear!, It's like flogging packages and frameworks at a problem without ever considering if it was easier/more efficient to roll your own.
I hope this lesson has become clear more clear with the recent deepseek upset. That proved that simply throwing more money and hard to wear at a problem doesn't guarantee a better outcome, innovation seems to favor the opposite. As as Germans say the German saying goes: "
NixOS checks/enforces its own reproducibility via systemd in various ways. It seems unlikely to me that replacing something battle-tested with a bunch of self-rolled brittle scripts will make it more reliable.
This is somewhat ironic, given that it was systemd that replaced the battle-tested systems that came before it, and variants of your comment were used to argue against it.
See this is how we end up with things like electron.
Or ripping the combustion engine out to make a better car with electric and then realizing you ALSO don't need the transmission!
And then later finding out that a transmission in an electric car will help you both with top speed and mileage, so you have to put it back.
This is just the same old "systemd sucks, let's rip it out" and then later reinvent everything it provides, because it was needed. Also commonly known as reinventing the wheel, the curse of any IT project.
> Also commonly known as reinventing the wheel, the curse of any IT project.
Continuing with the vehicle metaphors, the wheel has been reinvented many times for different purposes. The wheel on a tractor is different from that of a Formula One car.
The good thing about this that it is a Nix OS without systemd, not NixOS without systemd. systemd is so well integrated in NixOS that any attempt to introduce an abstraction to make it pluggable would come with serious disadvantages.
I am all for an alternative Nix OS trying new approaches though, and sixos seems quite innovative.
Guix also does not use systemd, but its own service manager Shepherd. Edit: the author of sixos mentions it, boils down to personal preference of not liking Scheme.
As a simple linux user that recently tried nixos to power a very small server, I would say that systemd wasn't part of the issues I encountered at all. It was the confusion tooling, the documentation all over the place, and the lack of ressources on specific topics.
I struggled through that phase and now nixos is pretty comfortable to me. Some of the improvements in sixos are attractive, but I'm afraid to try it because it's going to be the same thing but way worse. There's no sixos community, there's just this video, a forum post or two, and the codeberg repo. That's it.
It's a shame there isn't a distribution (at least that I'm aware of) which is dynamic and modular enough to allow choosing your own "process manager" at install or even on boot.
Artix Linux does this. Arch sans systemd, and you have a choice between openrc, runit, s6, dinit, or even some combination of the 4. Any daemon type package will have a -runit/s6/dinit/openrc variant that includes the relevant scripts/configs.
In a sense, nixpkgs is that.
And AIUI that's exactly that the author refers to by "95% is nixpkgs".
The NixOS part (the module system and modules) is in no small part integration between the init-agnostic nixpkgs and the init system (systemd).
That's what enables this project, as well as nix-darwin (integrates with launchd) and NixBSD.
The traditional way (pacman, apk, apt...) is for packages to carry the init files for the service they package.
I believe Gentoo supports multiple init systems, but it's definitely a challenge no matter what.
Gentoo is fun and does indeed give you the choice but…
But.... nothing. Gentoo is awesome. I have free KoolAid.
Compilation is so fast on modern processors that it’s not even much of a hassle.
Portage is the best package manager out of any distribution.
There are no buts. Gentoo is awesome.
YMMV, I spend a couple of days last summer trying to get a Gentoo install with KDE running and after I changed something which caused a libc recompile, which took over an hour, I was so fed up I went back to Arch.
...granted, my potato only has an i7-6700 Skylake with 4 cores+hyperthreads for 8 threads at 3.40GHz, it's not one of those AMD Ryzen things, but still: I'm not running GNU/Linux because I want to buy a new PC every year.
I am told that there actually are precompiled packages available in Gentoo now.
this is correct, there's even a precompiled kernel (dist-kernel), it works great! and when packages doesn't match your system settings, portage will pull the source and compile them. it's great!
That's exactly what Devuan does. You pick your init system at install.
https://www.devuan.org/os/init-freedom
For those looking for a Linux that works like BSD, https://voidlinux.org/.
Also see https://www.gentoo.org/
Or a linux that actually uses the BSD coreutils https://chimera-linux.org/.
Does it make ZFS on root stupid easy and has ZFS boot environments?
The normal, systemd NixOS does actually make it "stupid easy". It will fetch the latest kernel that is compatible with ZFS and has single-line config options for auto-snapshots, and the like.
Did not know this. Very cool. Does it also make it easy to replace grub with zfsboot environments?
I don't have personal experience with zfsboot - I have used UEFI/systemd-boot previously with ZFS root, and now use an initrd which loads the encryption key to ZFS root.
But NixOS itself does something similar, it has generations and if you change some setting and rebuild your system, the previous' link will be available in the boot menu, so you can easily try out stuff and just revert if it doesn't work - it is file system independent, but it only handles nix-specific stuff.
I am struggling to get systemd to cooperate with a TPM on boot right now, let alone ZFS. I'll probably drop back to initrd.
I just want encryption at rest for when it comes time to dispose of the disk, there's not supposed to be unencrypted sensitive data on it anyway.
Alpine does. Just boot from the extended ISO and modprobe zfs and install zfs tools.
Nope.
Void generally plays well with ZFS, including kernel updates, but installing on ZFS root is very much a DIY process.
Better yet just use Alpine IMO.
Is the XBPS thing kinda like BSD ports?
kinda. https://github.com/void-linux/void-packages/
Not really, no. It's just binary package system, ala apt or apk or whatever.
Is there any video demo of the booting sequence?
A nix OS w/o Linux would be interesting as well.
Microkernel multiserver systems could use more exposure.
https://github.com/nixos-bsd/nixbsd
Guix can run on top of the hurd https://guix.gnu.org/en/blog/2024/hurd-on-thinkpad/
I had tried chimera-linux with dinit (on a VM with GNOME desktop) it was a good experience while it lasted and loved the TL; DR that chimera writes and it was DIY distro which was quite good like arch in it's initial days.
But now I'm back on fedora for want of packages and not being on a mainstream distro is all rainbows and unicorns until we hit the corner case or a missing package which is available only as flatpak and won't integrate with the look and feel of the desktop environment.
The new dead end is approaching, fast.
I wish more distros would start picking this up. Systemd is awful
Why do people insist on living in the 1980s? systemd has enabled so much missing and previously convoluted functionality. There is a small but vocal coalition of admins that refuse to learn new skills. As if we didn't have enough "systemd free" novelty distros.
If you want to live in the past, go run SunOS. You might need a dusty old tape drive, though.
the dismissal of systemd criticisms by saying they’re unimportant (for you) or that admins are living in the past has got to be one of the most annoying things about the topic. It devolves into a flamewar because of it, since nobody can actually engage constructively once that happens.
I’ve laid my actual criticisms bare multiple times on this site.
1) The tight coupling of the userland with systemd means that while systemd replaced a pleathora of inits (not just sysv): the target is now too large to be replaced even if there are better ones. Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
2) The non-optional/default features have been buggy and difficult to replace. Journald has no replacement; systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
There are more, but these are my main ones. Throwing away the corpus of admin muscle memory is not an an issue anymore.
To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken. Part of what gives me pause is that I know how utterly undebugabble it is when it fails: it just hits those causes less frequently as the world is forced into using it. It becomes battle hardened.
Oh, and the obvious criticism agains the maintainers who have been very unapologetic to bugs and undesired behaviour, in a much worse way than the Apple “you’re holding it wrong”.
Did you ever consider that it’s also free software nerds who are the most likely to hate being told what to do?
> 3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
have you considered the reality that the "unix philosophy" results in incredibly brittle systems? byte streams ("""plain text""") are untyped and prone to mishaps.
Some of the most reliable systems in the world were unix ones.
SunOS was famous for being incredibly reliable, and its a more pure unix than the current linux environment.
And even if we ignore that, the majority of the web was functioning and functionally reliable atop linux with these text stream systems.
bytestreams are less debuggable, which feels silly to say openly since we are all aware that higher level interpreted languages are easier to write/debug/test and iterate on, but we seem not to be bothered by this not being true for the underlying systems.
Systemd clearly is working though, I’m just levying a criticism of opacity.
> bytestreams are less debuggable
Text streams are considered "better", because the standard UNIX userland (unlike e.g. DOS) provided excellent tools for dealing with text streams: grep, sed, awk, find, tr, etc and of course the shell itself.
But once you get your hands on excellent tools (like jq) for dealing with other kinds of data (like JSON), it turns out everything is even more powerful - you can now work with JSON as easily as with text, it just plugs into the existing ecosystem. But even though JSON has a human-readable text representation, it is no longer just text - it is dynamically-structured, but strongly-typed data. A JSON array is a JSON array, you can't just awk it.
There are byte stream formats (e.g. msgpack) that have feature parity with JSON. jq can't accept msgpack-encoded byte streams, but suppose a hypothetical tool, msgpack2json, is widely available - just plug it into jq. You're still working on the same level of abstraction (shell pipes), but easily dealing with complex byte streams.
And of course, what we understand as "text" in the modern era, are UTF8-encoded byte streams. If your "text" kit deals with ASCII rather than Unicode runes, it's that much less powerful, and likely full of painful edge cases that you now have to debug. (Note that UTF is a 1992 thing, it's been invented when UNIX was 20-something yro, and it's been around for 30+ years.)
Debuggability of anything is entirely up to your toolkit, the quality and comprehensiveness of that toolkit is what decides the battle.
I don't think the most reliable systems in the world were Unix ones. At least, if you compare systems at that time, you should compare with what the telephone operators were using. They had legal requirements you would not find in the computing world.
> 3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc
I prefer an introspectable, typed, and efficient communication protocol over streaming text because of the "Unix philosophy" whatever that may be.
Is the philosophy documented somewhere or is it just in our hearts? Because the Systemd Bus interface has great docs right here: https://www.freedesktop.org/software/systemd/man/latest/org....
> “ Write programs that handle text streams, because that is a universal interface.”
—Douglas McIlroy
Its difficult to pinpoint a single origin of “everything is a file”, but its referenced in Kernighans memoirs, which is a good read: https://www.cs.princeton.edu/~bwk/memoir.html
Yeah, such a tool will be definitely stable and portable! Until you change the locale and the whole thing breaks apart, with no error message whatsoever..
Also, not even Linux believed in "everything is a file". Everything is either a file or a stream. The two is not the same.
The parent asked a specific question so I gave an answer.
If you disagree that text streams are a good universal medium then thats totally valid, but then perhaps don’t use a unix-like and go for something like VMS, VAX or Windows.
> systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
While I have nothing to say about your general points - I am pretty neutral to systemd, but I really dislike how it makes porting software to BSDs harder - I have one question:
Why are you not using networkmanager on a desktop computer? I have only used networkd on a server where I needed things like MAC matching and device renaming.
Genuinely curious. On my desktop I used a wired connection, so NM is probably overkill, but I like how I can have a tray icon to manage my VPN and wireguard connections.
I typically use what's provided by my distro, because in my experience from Fedora (heh), fighting the distro is a surefire path for pain.
Even arch has opinions, even if they're much happier to mute them in the name of choice, but it's clear that your life is better if you stick to the happy path.
Without replying to specific parts, I'd like to point out that you and others bring up parallels between Systemd and closed source proprietary software shops like Apple and Windows. I view this as bad faith because Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.
There's nothing apple-esque about any of this. 'If you're unhappy fork it', is a common adage that is definitely applicable here.
> Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.
You cannot fork systemd in practice; it's enormous, and its components are tightly coupled with complex, non-stable interfaces between them. So while you have access to the source code, you do not have the practical ability to exercise the FSF's four freedoms.
GNU/Linux was created as a rewrite of Unix not because Unix was the best operating system around, but because it was a design that could be replaced, changed, and improved piecemeal. GNU were able to write improved open-source versions of the components of a Unix system - such as init - piece by piece, and test them out and use them on existing Unix systems, rather than having to rewrite everything before they could do anything. If those older Unix systems had been designed like Systemd, that would not have been possible, and Linux would never have got off the ground.
This doesn't track with me at all: Nothing about the four freedoms is restricted by systemd's architecture, it's all open source. You're comparing with an effort to replace a proprietary system. And secondly, the variations between different UNIX systems in terms of compatibility were much greater in practice than the variety in systemd interfaces between different components (which aren't that tightly integrated, anyway. Systemd-networkd, for example, is basically just another systemd service, and has multiple replacements. Same with basically everything else. And even the things that aren't 'officially replaceable' are still just as amenable to piecemeal replacement as the UNIX utilities: there are various projects that do, if they object to systemd's core for whatever reason).
I think the main reason that there isn't a systemd fork is that it's just not particularly worth it: it works well enough for enough people that no-one is motivated enough to try to improve on it outside what the project is doing anyway. And those that do strongly object to it tend to reject the whole approach and so they start from scratch, and then lack traction because they don't interoperate at all.
> GNU/Linux was created as a rewrite of Unix
GNU is a bunch of utilities no different than various terminal programs. The attempt at the "GNU OS" failed because the Hurd was never really usable.
> The attempt at the "GNU OS" failed because the Hurd was never really usable.
Pre-systemd you could get Debian with Hurd and it was fine. There was never much reason to use it - hardware support was worse than Linux and there was no real killer feature in practice - but it worked.
It's more like Chromium; you could fork it, but it's big enough that that's difficult, and doesn't really do anything about its influence on the ecosystem.
A browser is quite literally the most complex project out there - systemd is absolutely tiny compared to it, so I don't think that would make a fair comparison, at all.
Except for the fact that chromium is a feeder project for a proprietary closed source work and so often bends to the will of that project.
Morally there's no equivalence here.
Well, as far as your first point goes: Systemd has been a suite of tools instead of just an init system for a while now.
The Linux kernel is de facto pretty tightly coupled with GNU stuff, but you don't get irate about that, so why does Systemd deserve your ire?
> The Linux kernel is de facto pretty tightly coupled with GNU stuff
No it isn't, or Android, Alpine Linux, and Chimera Linux wouldn't work nearly as well as they do.
> you don't get irate about that, so why does Systemd deserve your ire?
And even if it were, systemd has a lot of problems that the classic GNU utils don't. We don't hate systemd just because of the tight coupling.
> The Linux kernel is de facto pretty tightly coupled with GNU stuff
No it isn't. They go to great lengths to e.g. make sure they can be built with clang and not just gcc. And in the other direction, prior to systemd you could even swap out Linux on Debian for a different kernel.
> To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken
This was Fedora 15, in 2011. I would say using this as a baseline qualifies as living in the past?
it was more about how my muscle memory has evolved, that I know how it works and the benfits of it- not that I think systemd is the same as it was back then; clearly not as I mentioned things that are <5 years old.
In these comments I have so far seen "resistance to change from dusty admins older than tape drive mainframes," "it is religious," and "autism."
> Systemd is the last init linux will have
I'm fine with that.
> and increases the barrier to port software to other unix-likes.
Don't care about "other Unix-likes", and in fact I wish they didn't exist.
> The non-optional/default features have been buggy and difficult to replace.
Let's not pretend as if the pre-systemd crap wasn't even more buggy.
> The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
Dbus is a text-based protocol based on files though. What a silly complaint.
P.S. Dbus sucks, but thankfully it would be pretty easy to replace in systemd if somebody got sick enough of dbus.
So you don't care about anyone else. How noble. Why then should anyone care about you or your opinions or deep thoughts?
When comparing systemd to things, I find it more fruitful to compare it to something like SMF, which actually does the things people wanted systemd to do:
* socket activation
* dependency management of startup
* log control
* service supervision.
Except, it did so by interfacing with the operating system in its native language, for example: log files were text.
It is not useful to complain about bash scripts, the original design of init was indeed dated and you’d be hard pressed to find people who don’t think so; so its an invalid point to make in this discussion.
>Don't care about "other Unix-likes", and in fact I wish they didn't exist.
Why?
> Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
Why would you write portable software that has a dependency on an init system?
> systemd-networkd is one of the most common causes of failure for my desktop
What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
It is easier to settle on one method (like literally every other OS) and fix the bugs than continually come up with newer, equally buggy and broken, ways of doing it.
> Why would you write portable software that has a dependency on an init system?
Ask the GNOME project.
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
"Linux has 26 different incompatible ways to configure networking. Systemd solves this problem by introducing a 27th way that's buggier than most of the others"???
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
False.
One of those 26 incompatible ways works just fine in the situation where systemd is clearly not working.
It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
> It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
I never said this.
Fix the bugs. Don't fill the well with yet another equally shite solution.
> Why would you write portable software that has a dependency on an init system?
Because it's not just an init system; it manages to make itself important to a rather lot of the system. A nice page is https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd#Pa...
Nothing in there looks particularly big or important, though. There was a lot of noise about GNOME and mutter requiring it, but that has been changed as noted on that page. Dbus is a big one, but a) the socket activation feature of it requires integration with or reimplementation of a service system, and b) There is an implementation that works with openRC instead (just not the one mentioned on that page).
Why everything is inflated and bloated? It is foundational to our computer systems.* There is alternative way, functional programming, that is much harder to learn than Object-Oriented, but makes cleaner code without side effects. So Six/NixOS is very promising and going to install it when I have learned Haskell first to understand it's foundations more deeply.
* "Can programming be liberated from the von Neumann style?" https://dl.acm.org/doi/pdf/10.1145/359576.359579
> but makes cleaner code without side effects
No, that is an urban legend.
> when I have learned Haskell first to understand it's foundations more deeply
Nix is nothing like Haskell.
Also, the functional and lazy nature if Nix is not an ideological decision, it's a necessity when you have a giant monorepo config for 200000 packages. (Without laziness you'd have to wait for an hour just to evaluate the config options.)
[dead]