It's like, yeah, that's a funny thing to also live in systemd.git, but systemd-resolved is functionally a separate product from systemd.
So when asked if I like systemd, it's a loaded question. It's great but absolutely sucks, both.
[note] It describes itself as "a suite of basic building blocks for a Linux system" - although in my opinion that implies more modularity than it posesses.
Principles aside, in reality, systemd has been a complete non-issue for me and a massive quality of life improvement for Linux as a desktop operating system.
Is it not possible to turn off things like systemd’s DNS server, etc? I imagine if you care about such things you should be able to reconfigure your OS to use something else instead.
It is possible to disable stuff like systemd-resolved or systemd-timesyncd but it takes extra work which should be done by installing another package that accomplishes the same task (unbiound, chrony) just like as one MTA replaces another on Debian.
However, you ask a good question. Lots of people do like it, supposedly. But I think there's a large clue to its controversial nature in that people still call it an "init system", and pointing out that it isn't is interpreted by some as an attack.
Basically, it started out as an init system, which was used by Red Hat / Fedora, which was positioned well at a time when certain distros, notably Debian, used crufty SysV init scripts which they wanted to move on from. When Debian adopted systemd, after some debate, every Debian-based distro did too. This wasn't considered a particularly invasive change at the time. But systemd started to expand into its "middleware" position, absorbing vital system functions like udev. Distros which adopted systemd found themselves along for the ride, while distros that didn't increasingly found that software was starting to break, forcing them to maintain forks, or chisel out the piece of systemd that made it work and run it standalone. So was created a network effect that forced even more distros down the path of least resistance into systemd.
Meanwhile, amidst all the grumbling that this bait-and-switch was provoking, the systemd project leaders had an astonishingly bad attitude towards the maintainers of software that they were breaking, which fomented considerable personal animosity on top of the technical resentment. Not only were they driving a horse and cart through the standard ways of doing things, breaking a lot of stuff in the process, they were being rude about it.
So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.
Your timing is off. udev became part of systemd in 2012. The big Debian debate was in 2013-2014, and was acrimonious enough to eventually cause several of the CTTE members to resign their position over it. One of the core issues driving the Debian systemd debate was the fact that GNOME was planning on dropping support for anything other than systemd-logind (or something like that), and there was definite concern that packages were already making decisions that were forcing everyone to adopt systemd as the only init system.
I eagerly await the publication of "SystemD: A History" and its subsequent adaptation into a dramatic screenplay.
Not true. From the start it was positioned as much more than an init system. This is clear just skimming the blog post announcing systemd http://0pointer.de/blog/projects/systemd.html
Among other things, it talks about:
-deferring launch of some services until they are needed, to speed up boot
-launching additional services and shutting down others in response to hardware changes (e.g. adding a usb device).
-taking some or all socket management away from daemons so that sockets can be ready before daemons are live or daemons can be shut down when there is no activity
-“babysitting” services including through cgroup based process management
-managing (some of the) access to /home and other directories
It’s quite a broad scoped announcement. Toward the end there is a “short list of other features”, numbered, ending at 20. Under “Where is this going?” he writes, “ The feature set described above is certainly already comprehensive. However, we have a few more things on our plate.”
systemd clearly started out as a broad based solution, and reading through that post, looking at the problems it addresses, and considering that launchd and upstart tackled similarly many issues, it’s clear why it is so broad - the world has changed. In the 70s on a pdp 11 it was sufficient to launch some daemons at boot, keep an eye on getty, and call it a day. Maybe ~50 years later a new, more comprehensive system makes sense? When Linux runs laptops and phones that are endlessly reconfiguring themselves in response to network, Bluetooth, usb, when systems are sleeping and waking routinely, when vastly more services run on a single machine, when conserving battery is important, when boot time can be reduced to seconds if things are better orchestrated? “standard ways of doing things” have changed in every other sector of society, basically, why wouldn’t they finally change in OS service management?
Now, no one will argue that systemd's service management capabilities far exceed what most historical init systems did. Heck, the traditional init system had interior service management to window's Service Control Manager implementation, since the classic init could not for example give a list of running services. And systemd is far more flexible and feature rich than Window's options now.
systemd-boot and timedated on the other hand are pretty darn disconnected from anything a classic init system was concerned with. It does feel like a lot of the non service/mount management parts of systemd are basically a grab bag of random stuff.
It was pretty invasive - I tried to keep using Debian without systemd, but indirect dependencies always brought it in. Until I switched to Devuan.
And the dependencies brought in EVERYTHING. You could no longer mix and match, pick one part from here if it worked for you, and another part from there.
Which lead to the criticism that "systemd is not modular". Which Poettering denied, pointing out that there are modules at systemd-compile time, completely missing the point.
> So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.
And I wouldn't have minded systemd as an INIT SYSTEM - the existing scripts WERE pretty bad. But systemd is like the Borg - it tries to assimilate everything. And it broke quite a bit of existing functionaility along this path.
Red Hat produced systemd. Red Hat is the major contributor to Gnome. Gnome now refuses to run without systemd. Every major distro wants to carry Gnome, so...
Well, at least some distros offer a choice. Some other distros (Alpine, popular for containers, Void, which powers my laptop) live happily without it. Various shims exist, logind exists to allow running things like Xfce without systemd.
Is that true? The gentoo documentation says that you can chose your init system independently of your desktop manager, and puts openrc+gnome as an example:
https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd/Gen...
You can also install GNOME on OpenBSD, which of course does not run systemd.
> After the transition from GNOME 2 to GNOME 3, configuring GDM is only possible through systemd as it no longer supports other init systems.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
You can see the same effect in e.g. politics.
It's one of those situations where the minority that doesn't like systemd is just a lot more noisy than the vast majority that likes it.
Easy as that.
The majority of people don’t give a hoot about it.
The short answer is...Red Hat has money and threw it behind systemd. Like them or hate them, they are in many ways the deciding fate of Linux systems. So, other distros fall in line. Ubuntu is a contender, but gave in and followed suit too.
Void and Solus are both good distros that don't use systemd. I'd go as far as to call Solus the best out of the box distro ive ever used.
IIRC the required parts of systemd are pretty much init-related, service-related (as in starting/stopping services based on certain conditions), udev and journald (which can and is often defaulted to forward to syslog).
Comments like yours make it seem like resolved, homed, nspawn, machinectl, networkd, cgtop, and all of the other utilites and optional daemons are required. They seem more like konquerour in your KDE analogy as in that they are nice if you want to buy into the whole ecosystem but by no means required to use the core program (and many seem to use alternatives instead).
I'm by no means an expert on this, so please correct me if I'm wrong.
I wrote a personal blog post about this (https://www.turek.dev/posts/disable-systemd-resolved-cleanly...) to try to help people out.
I suppose you could do that. although I prefer: systemctl disable systemd-resolved systemctl mask systemd-resolved
Then it's dead and will stay that way.
Does systemd want to be an init system? A logging system? a dnsmasq replacement?
Folks at Red Hat noticed that the Linux userland architecture is not convenient for what they would like to build. So they are building systems which replace the traditional mechanisms: first DBus, then systemd, which is an umbrella of many services: init + service monitoring + containers, logging, interactive login, some networking, etc. I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland.
'Doing many things, none of them well' is actually the opposite of UNIX.
Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX".
This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fantastic. And good luck using the alternatives to manage cgroups.
There is nothing bad about it. What I find bad is forcing everyone to jump on the same bandwagon, no matter which bandwagon. If I wanted choices made for me, I'd buy a Mac.
Nobody says things like "what is GNU? Is it a kernel, a compiler, a libc, a build system, a set of userspace tools?".
Likewise, the systemd project has many utilities under its umbrella, and most of them are completely optional.
What does all systemd software have in common? What's the unifying principle there?
Each distro used to have to roll their own initscript system (with varying degrees of compatibility), so they made `systemd`. Each distro had their own init script to save/load the backlight state, so they made `systemd-backlight` (if you're going to replace the initscript system, you'll also have to replace the things that the initscripts for that system did). Each distro used to have to roll their own network configuration scripts (Debian's /etc/network, Arch Linux's netcfg and later netctl, ...), so they made `systemd-networkd`.
Some of this class of thing got picked up by other projects; each distro used to have to roll its own initramfs system; today Dracut exists, so systemd won't be doing that (unless the Dracut folks decide to team up with the systemd folks--remember gummiboot? gummiboot renamed to systemd-boot).
In one of your other comments you wrote "in my opinion that implies more modularity than it posesses." While there are some nasty couplings (it'll take some patching to get systemd-nspawn to work on a non-systemd system), you can successfully use many of the systemd modules on an OpenRC system; it is a lot more modular than people give it credit for.
[0] https://www.freedesktop.org/software/systemd/man/systemd-res...
It wasn't quite the solution I was looking for. I wanted my DNS server to "just work" for people who downloaded it—I didn't want to force them to re-configure systemd to accommodate my software.
Tweaking my software to accommodate systemd.resolved took ~4 hours. It was an enjoyable dive, but I'd rather not have had to do it on the first place.
I continue to think it's a bit of an overreach for Fedora to include a DNS server by default.
systemd-resolved is a separate project from systemd whose only relation is that it’s in the same repo. It’s up to your distro builder to decide if they want to use it. And also up to your distro if they want to use the stub resolver. It’s not necessary for systemd-resolved to work. The reason they have the stub listener is because on Linux every application is supposed to use glibc nss to resolve names but there are real-world applications that try, incorrectly, to parse resolv.conf and do dns queries themselves. This breaks things if your assumption is that all dns queries are going through systemd-resolved. And this project isn’t the first. Ubuntu and others have used dnsmasq as the stub resolver for the same reason. Using just the dns nss module and resolv.conf is fundamentally broken and at this point unfixable when you are connected to multiple networks or with separate dns or split tunnel VPNing. You have to provide your own, smarter, nss module and/or use a stub resolver to cover these use-cases.
The nice thing about systemd-resolved is that it make enabling split-tunnel vpns a breeze.
Do Linux users really want their year on the desktop, or will they keep complaining at any change to get there?
Worth a shot! https://distrowatch.com/table.php?distribution=artix
I like Linux, but I have mixed feelings about systemd, especially when I discovered that systemd runs its own DNS server, which prevents the DNS server I wrote from binding to port 53 using INADDR_ANY. Instead, I had to write code to enumerate the interfaces & corresponding IP addresses & bind to each one separately. Systemd's decision to run their own DNS server is a bit of overreach, IMHO.