systemd is so complex, I've come to a conclusion, that it no longer fits my definition of free software.
We allow runaway complexity to obscure the inner workings of an important software package, to the point, where having source access no longer makes a practical difference to a "casual" power-user or even a software engineer. I can source-dive runit, s6, OpenBSD's rc, or OpenRC and within a weekend, have a pretty OK understanding, fix a bug, or add a feature. Having software as complex as systemd taking so many roles, and making itself so ubiquitous and irreplaceable, makes me feel that I no longer have any control or understanding of my system, bugs or misfeatures just become things you live with, or you riddle yourself with arcane workarounds. Portability suffers, monoculture takes root.
I've lost faith in "mainstream" Linux distros. I use macOS and OpenBSD for workstations, and Alpine where I need e.g. Docker. It must either be simple enough to understand, or provide enough utility/convenience that the lack of (practical) source access is compensated. systemd fits neither category.
Have you actually tried to dive into the part you're interested in? Where did you find the complexity? I've done it a few times for different components and found them pretty well separated and the source pretty straightforward. I have other issues with them, but complexity/obscurity of the is was not one of them.
Looking at using systemd to just run a binary automatically on boot (which some smart person on HN told me was the easiest way). Just looking at the systemd landing page overwhelms me.
Boot Loader Interface, Discoverable Partitions Specification, etc.
I’m sure the implementation details are very interesting.
But where is the “Configure and Start a Service” option? Which is arguably the most important.
The man pages are the reference manual. You might want to search for "systemd service tutorial" or something like that, there's a lot of blogs that explain how to make a simple service.
Their frontpage sucks, but that's not related to the code really :)
For a quick intro to new services, see the examples here: https://www.freedesktop.org/software/systemd/man/systemd.ser... (they should cover most basic needs) then read above for the details on the parameters. You stick the file in /etc/systemd/system/your_thing.service and enable/start it.
I'm not sure why this comment was downvoted. I've read all the systemd documentation and this comment is spot on. System is lacking good documentation along the lines of "the least you need to know to setup and manage a service".
No, it's not as easy as "man systemd.service".
What's probably most useful in that documentation is the "hello world" example, which is buried at the bottom of the documentation. Also, key details are elsewhere, in "man systemd.exec" and "man systemd.unit".
The systemd docs a great comprehensive reference, but the man pages are poor introductory documentation.
Some useful tips that are hard to find:
* man systemd.directives documents every directory and will tell you which man page as the full documentation for it.
* man systemd.index lists every man page related to systemd.
Yes, systemd has a ton of surface area and options. Yes, the man pages are long. No, you don't need to read them--the beauty of systemd is you control how much of the complexity you use. Unit files can be 10 lines or 30. Most of the extra options are for security and hardening, when you need them you'll be glad they're easy to turn on. For the other components, I think have a stable, familiar, and consistent set of core services (boot, ntp, logging, networking) is glorious
That's an interesting line to draw! Do you think this also extends to stuff like firefox or java vm, or are you only focusing on "system" software with that analysis?
The key is how necessary the complexity is. The existence of simpler alternatives to systemd (that work just as well to run a system with) prove that its complexity is unnecessary. For things like Web browsers, the complexity is necessary, for better or worse.
I'm trying to balance between idealism and pragmatism. Source access is pragmatic only in a situation where you feel confident to dive it. I admire projects like suckless, Alpine, or Netsurf, because they prove this kind of balance can be maintained. But I'm still posting this from Safari ;)
Good parts of SystemD are good, bad parts are bad. SystemD is easy to use when it fits your needs, but pain to use otherwise.
For example, `systemd-analyze` is a good tool for boot performance analysis, so + for systemd, but if I want/need to use perf for boot performance analysis, then systemd stands in my way, while for initd it's just yet another boot mode.
Responding to "I don't like this" with "just learn it" is effectively saying "anyone who disagrees with me that this thing is awesome only does so because they know less than me." I'm very familiar with systemd, and I make use of its features on systems I can't avoid it on, but I still hate it.
NixOS is based on systemd. But it also seems like NixOS would be a great foundation to use something besides systemd. It would take some work of course, but it feels like you'd be mostly working with the OS rather than fighting it.
However having used it, NixOS seems like it mitigates the worst aspects of systemd. It gets rid of that that /etc/systemd /lib/systemd symlink "cleverness" for overriding/enabling units. Being functional makes it so that when systemd mysteriously breaks - for example if there is a loop in dependencies - it's easy to track down the change that caused it. And rather than splaying the config out in a bunch of random "unit" files, it's all contained in the nix config. About the worst thing I can say is that defining your own service is a bit more obtuse that it needs to be, with the arbitrary terms of the systemd unit format carrying over into the Nix config.
The symlinking is one of the things systemd actually gets right on traditional distros. The files in /usr/lib are immutable data files shipped by the packages that you're not supposed to edit. The symlinks to them in /etc are configuration that you can change.
I get the rationale. it just makes for one more layer of indirection that you have to overcome when trying to figure out what the configuration actually looks like.
Why would you do this manually? You also have to remember to check multiple configuration paths (e.g. override units), all of which can have an additional `.d` include directory. This is the price you pay for the flexibility systemd provides (and I argue it's much better than random System V-style shell scripts that can include anything at all, maybe even some remote scripts piped from curl to sh if developers was mad enough).
Just use `systemctl cat`, it prints the whole effective configuration.
Does `systemctl cat` also work for creating/editing units? If I've got to navigate files and directories configure the thing, then I am going to default to reading the configuration the same way. Having to find out these random commands to view simple things about its own internal model is one of the the worst parts of systemd.
I'm no fan of SysV init either, and I appreciate the advancements that systemd does bring to the table. But it is hard to shake the feeling of it having done the system software equivalent of sucking in a bunch of bloated javascript frameworks. Sure they made life easier for the developer, but everyone else has to live with the mess.
For enabling/sequencing, I'd say the preferable way would be to have a top level config file that pulls in the specified units explicitly rather than stitching together units based on their internal contents (akin to persistent structure rather than mutable cells). Juxtaposition is the most syntactically powerful operator and prevents loops intrinsically. Whereas by splaying dependencies in unit files, if you make one errant backreference the system is likely to not boot at all. I'm sure there's another clever command to check for that, but shrug.
> Does `systemctl cat` also work for creating/editing units?
No, for that you would use `systemctl edit UNIT...` to create or edit a drop-in file, e.g. to add local overrides for an existing service, or `systemctl edit --full UNIT...` to open a copy of the existing unit file for editing which will replace the packaged version. Add `--force` to create a new unit file for a service which doesn't already exist.
I haven't bothered to have a beef with systemd, but some of us have discussed https://github.com/InitWare/InitWare to support non-Linux kernels. That would be really fun.
I doubt GuixSD would work on most modern hardware considering it uses the Linux-libre kernel. Using the Guix package manager itself sounds useful though.
Guix System works fine on modern hardware. I've been using it on new servers for the build farm at ci.guix.gnu.org and on laptops. Linux-libre has not been a problem.
The biggest recurring issue is with graphic cards that have poor support in Linux and require firmware blobs and with WiFi cards that have no free drivers / firmware.
It is trivial to use vanilla Linux with these machines as Guix System lets you use any other package for the `kernel` field in the configuration. The "nonguix" channel (hosted on Github) provides packages for vanilla Linux ("linux") in various versions, and also includes firmware packages that you can use in your config file.
If that's the only thing keeping you from using Guix System then I'm happy to say that it's a hurdle that is very easy to overcome.
> The biggest recurring issue is with graphic cards that have poor support in Linux and require firmware blobs and with WiFi cards that have no free drivers / firmware.
Intel, AMD, and Nvidia GPUS - all of them need firmware blobs to work as expected. Intel and AMD offer free drivers but not free firmware.
And if you want to WiFi 5 (ac) or WiFi 6 (ax), chances are that you'll need non-free drivers/firmware as well.
> The "nonguix" channel (hosted on Github) provides packages for vanilla Linux ("linux") in various versions, and also includes firmware packages that you can use in your config file.
Ah, that's good to know.
I'll probably give the Guix package manager a shot some day.
I've been running Upstart (well, a fork I maintain) for over 2 years on my laptops and SBC. I'd like to use that. TBH I think NixOS might make it easier than other distros to run a custom init. I just haven't gotten around to importing my configs into a nix derivation.
If you have a parser for systemd unit files then you might have a chance to get that to work.
If the whole reason you're doing it is to migrate back to upstart's syntax then it seems that would be not so useful, you might as well go in the other direction: write an upstart generator for systemd, and then you can just plug that into ordinary NixOS.
Edit: Actually I think at some point NixOS did support upstart? Not sure whatever happened to that.
I'm not planning on working on anything related to systemd in the near future. If anything, I will write a config generator/type spec for startup/Upstart in Nix.
Unfortunately I think you probably will have to work on it if you want to not break existing configurations, so maybe NixOS is not for you. You could try alpine possibly? But with that you will have to do the same with init.d, so it's going to be somewhat of an uphill battle either way I guess. This is generally why I would discourage maintaining a service manager outside of an established distro, I tried to do it for about the same amount of time as you and it became not worth it. Upstart in particular has been basically entirely replaced by systemd.
I already use upstart on void no problem. Alpine would be a similar deal with me just managing the configs as raw text files via rsync. In fact my fork is already packaged in Alpine. A few people use it as a session manager for sway.
There is no chance that my Nix changes would affect existing configurations. They would be completely self contained.
Those would probably be not so great matches for NixOS because they don't support the container stuff that systemd does, you would be throwing all that out.
With cgroupsv2 there seems to be very little benefit to doing that since the container runtime needs to sit at the top of the process tree anyway, so I'm not sure I understand what the purpose of that would be or why you would want that. If you were using containers to run services then I can't really think of a situation where you wouldn't also want it as part of the boot ordering process, so your services will just have it working immediately upon boot.
That is not true at all about cgroup2. Also think outside the box. Not everyone is using cgroups and namespaces. Some people are out there using gvisor, or KVM, or FreeBSD jails.