Tbh, the installer was inevitable after systemd integrated a bootloader, crafted a paritioning scheme for autodiscovery, took over user and home directory management, and topped it off with an updater and "system extensions" layering system that some immutable distros are using.
I'm not saying any of this is particularly bad but it's been very clear fot a while that systemd just wants to be an OS. With immutable systems the "distribution" part of it is reduced to a build system, and everything else can be provided by systemd and flatpak.
Partition autodiscovery is pretty neat. I did my archlinux install with it using this guide[0]. I have never touched /etc/fstab and I have had zero to worry about corrupting a boot with wrong fstab entries.
The various Red Hat affiliated projects have so much more reason to call themselves the "OS" than GNU at this point. A Linux system with systemd for the init, systemd-networkd and NetworkManager for networking, GNOME for the desktop, systemd-boot for the bootloader, RPM/DNF as the package manager, etc. probably contains orders of magnitude more Red Hat code than GNU code even if the system uses glibc and GNU coreutils.
They're separate programs and system services which all more or less just do their own thing, just developed under the systemd umbrella. So it can't be "toggled", you can just not use the parts of systemd you don't want.
But it's meant to work as a cohesive system when everything in systemd is used together.
FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things tend to interoperate better when they're explicitly written to work together than when every component is meant to be hacked to work with arbitrary other services through shell script soup.
It's great that the same someone has formed a company called Amutable which has the sole purpose of converting Linux to a locked-down immutable OS where the users doesn't have the key.
Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break?
Right, are any of the things mentioned in the GP really required if you only want this init?
I know they've attached all these projects to the systemd brand because they thought it would beneficial but it's hard not to wonder if we could avoid all those discussions if the umbrella project was called something different...
No, you can just run the systemd init system and not use any other systemd programs.
I would probably run systemd-journald just because it's really nice to have a logging system which knows about the system services, but it's not required.
I have a curious question. My local setup has worked for me for ages ever since arch decided to switch to systemd. Same on the servers I deal with, after Debian's switch. At the same time, I can say I'm not involved with inner workings of a Linux system enough, to be affected by init system change and the pain it might bring.
In other means consider me an average Joe of the Linux world.
Hence this question: If it sucks so much, why did it become so widespread?
It doesn't suck, people are just emotional beings and have some "football team" level takes on technical stuff as well.
The very same people that hate systemd for "being a monolith" and limiting choice are usually also love X and hate Wayland where they can manage to explain how being a monolith is suddenly good.
Especially that systemd is pretty modular - at least the actual systemd program running as PID 1. It also refers to a project with many optional modules running under the same name, but that's like KDE having a file manager and complaining that plasma DE is a monolith.
That is a straw man. Plenty of people have different opinions on different issues.
> but that's like KDE having a file manager and complaining that plasma DE is a monolith
On the other hand it would be very rare to use Plasma without the KDE file manger. You lose all sorts of integration. Similarly, once you use systemd init its going to be a lot easier to replace everything else with the systemd equivalent.
It doesn't suck "now". It sucked when fedora and arch switched to it. I mean it of course wasn't complete garbage but it had a lot of bugs and people generally don't like to be used as red hat's guinea pigs.
When red hat switched to it, it was stable enough. Before then people were complaining because they did find bugs and issues (I know I did) and were being told to STFU by inexperienced users who have the most basic and standard use case and weren't encountering the issues (or were but didn't even notice).
Very common is the case of some person who sometimes uses linux on their machine telling a system administrator who has thousands of machines under his responsibility what's what.
Systemd resistance is silly to me. Systemd is what is turning Linux into a viable modern OS. You need something to tie all the parts of the OS together with a unified API, otherwise you'll be fighting fragmentation constantly.
I don't like the age verification thing either, but all systemd did was add a field for it, it's still up to your distro to use it.
Systemd does not solve the deployment problem, and will not unless it adds something like a systemd package manager.
It is interesting that Linux is far more widely used than alternatives that are not fragmented (e.g. FreeBSD) and has not standardised on one distro. Different people have different needs and preferences. People using Debian, Alpine, and NixOS are unlikely to agree on what they want.
If you want to get a good idea of how different modern Linux APIs are now compared to before. Look at cPanel vs. cockpit.
cPanel had to maintain its own unified API above a slew of other interfaces, while Cockpit benefits from a unified OS API. And we're only getting started, we still have a long way to go.
Yes I love the diversity of the open source ecosystem, I love that people are free to create their own distros without systemd. But I love my distros with systemd too much to switch.
I don’t see that installing openrc before deleting systemd. It tries to delete systemd and, if that fully succeeds, to install openrc.
> Issue itself was that while uninstalling systemd somehow OpenRC was removed too or not installed at all.
I don’t see how “somehow OpenRC was removed” could be true if it wasn’t installed before. My hunch would be that uninstalling systemd failed halfway through.
This makes the mistake of confusing systemd the service manager and systemd the project. This is an easy mistake to make given they have the same name.
The systemd service manager does not have an installer, systemd-sysinstall is a separate tool that's part of the systemd project.
systemd has not integrated age verification. All that's been discussed is a simple field to allow a user to register a DoB and an way for services to validate the user is over a certain age.
You could arguably already do this by having a DoB field for the user, but that'd involve giving applications your full DoB which I'm sure is distasteful for many.
> usual "fight" against non-sense laws
Because developers have to follow laws like everyone else?
Devuan us a separate Debian with its own repositories (and presumably many packages patched to improve systemd-less life), while this is just replacing Systemd with OpenRC on a Debian system, while keeping Debian repos etc.
You're going to have to make a separate repo for everything anyways, because you'll have to change all the init scripts and whatnot that get supplied with programs... well, unless you install both and just leave the useless systemd files laying around forever.
My /usr/lib/systemd takes 6.4 megabytes, so I think I could live with that overhead. Or I suppose just delete them manually.
What would actually be useful would be a generic OpenRC wrapper that would ingest those service files and provide traditional start/stop interface for them.
You mean the inverse of systemd.generator? Probably wouldn't be hard to make, but you'd have to be pretty committed to your init system to not just write the script by hand...
Hmm, I perhaps didn't quite catch this. I thought having a generator would let you be less committed to it, as you wouldn't need to manually write all the init scripts you need.. ?
Well - it is an alternative to debian and in many ways is debian. But the counter-question is: why should debian users HAVE to use systemd? This is a much more fundamental question. Devuan solved it via forking. I think the proper way to handle this is to be able to offer both. I think gentoo went that approach. Debian went the "my-way-or-the-highway" route, which objectively is worse, even if understandable (less to maintain; see LFS/BLFS submitting to systemd finally in 2026: https://old.reddit.com/r/Gentoo/comments/1qy4xsc/might_gento... and https://www.phoronix.com/news/LFS-Dropping-SysVinit)
FWIW, debian did the gentoo approach for years. I used to run debian with OpenRC during a time when systemd was already the default. It and other init systems remained fully supported by the distro for quite a while.
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.
I mainly use Ubuntu, so I know about systemd, but what is OpenRC? Why is there such a split, and why are people arguing about it in the comments? Could someone kindly explain it to me?
I only know how to control Linux through systemctl, and I don't know much beyond that. It seems like the components are different, but I'd appreciate it if someone could explain it to me.
I gooogled it, but I still don't really understand why there's a debate.
Because OpenRC and systemd don't even seem like comparable things—OpenRC is much smaller. And from what Google shows me, one is written in C and the other is script-based.
So one is a lightweight service manager, and the other is a framework that manages the entire OS. I'm a Windows enviroment developer, so I don't really know, but they seem to have different roles. Yet there's still a debate, and I don't get it. Is this really just an argument about PID 1?
Its an argument about whether you want an init that is just an init, or an init that is designed as an extra layer of the OS.
If they were comparable (i.e. if systemd was just an init system) there would be no debate.
it does not help that the systemd devs are obnoxious and dismissive of concerns about compatibility. Lots of "its your problem" in their bug tracker on github.
Thanks to your summary, I finally understand. So it's about whether it's a small tool that only handles init, or whether it handles multiple layers. That's the issue.
Thank you. I didn't know why there was a debate since the size difference between them is quite significant. so I don't know much about the Linux side. Have a good day.
To this day I have not found a single modern argument against systemd that is a technical one (I tried systemd but it does not support x which openrc does), instead it's these vague bike shed arguments (Unix philosophy, anti-centralization and "bloat" ).
I can't wrap my head around it, since those 3 are a "you" problem, systemd is just a service manager it's you who decide to use other systemd parts.
> systemd is just a service manager it's you who decide to use other systemd parts.
What makes systemd different from other init systems is that it is specifically designed to work with the other parts. It aims to provide a standardised OS on top of the Linux kernel. That is the advantage, and the disadvantage, of systemd.
I found a few bugs where journald was losing data for example. I reported them and they got fixed in later releases.
Of course I still got called a neckbeard and got told that I didn't like systemd because I'm a dinosaur and so on. So I have a really hard time to take positions such as your seriously to be honest.
If you mean that there are times systemd has a critical bug; sure the same way x11, kernel modules or drivers have critical bugs are annoying.
You can always point to where I said you are a neckbeard, so I do not get the "hard time" angle.
You can not like systemd, but the arguments for it is silly, and that is fine it's your machine and I don't care as long as people stop spreading FUD on such awful grounds.
Say in contrast with BTRFS or BcacheFS there are genuine issues with those and there are technical philosophical arguments (I want journaling, I do not want or need CoW features, snapshot? never heard of her).
> systemd is just a service manager it's you who decide to use other systemd parts.
cough
> To this day I have not found a single modern argument against systemd that is a technical one...
Good for you. [0] The project is great until, very, very suddenly it is not. May you continue to have many happy and trouble-free decades with it.
But when you do hit a bug whose cause is dreadfully complex [1], or get some useful, documented behavior you depend on altered so that it's unusable for you for no better reason than "it was inconvenient to keep permitting people to do that", you'll understand why some folks strongly dislike the project.
[0] Genuinely!
[1] ...so much so that the maintainers refuse to work on it...
You do not have to use all resources that are under the systemd umbrella. That's just BS, sorry. And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?
Guys, pick your fights reasonably.
There's only the optionality because of the pushback though.
One element of the free software culture is pushback against monolithic software. It allows you to swap out components in this way. Without that culture there wouldn't be the choice. You could disagree with a particular manifestation of that culture, but at least understand and accept that culture and accept that the reason why you perceive this to be a non issue is precisely because of that culture.
Agreed. But you still need to know what to enable/disable, so more complexity is the outcome.
> And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?
Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code.
> Guys, pick your fights reasonably.
I don't see what is not reasonable here at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.
There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.
And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.
So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.
OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.
Init scripts should not need significantly more than a few lines.
I do not think that I have ever used an init script longer than 1 page of text.
If bugs are feared, it is always possible to invoke a script written in another scripting language.
While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs.
"scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc.
Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation.
With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration.
Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.
> OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.
Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree?
If you replace line 14 with
supervisor=supervise-daemon
and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure.
OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem.
For production systems, I started more than a quarter of century ago with FreeBSD, which at that time was still much more stable and more performant than any Linux variant.
Even then, the init scripts system of FreeBSD was much better than the traditional sysvinit. I have never ever had the slightest problem with it, since then until today, when I still run a mixture of Linux and FreeBSD servers.
In the following years, many features of the FreeBSD software package system and of its init scripts system have become available in some Linux distributions, especially in Gentoo.
I have never used in production any variant of the traditional sysvinit, while with the improved versions from FreeBSD, Gentoo and a few others I have never seen any difficulty and no feature that could have been improved by the use of systemd.
In my opinion, the way to an optimal init scripts system has been shown by Daniel J. Bernstein with his "daemontools", which I have also been using continuously 24/7 for more than a quarter of a century, for some essential services, on many servers.
Today, there are a few new init scripts systems that have been inspired by the DJB daemontools, and I think that one of them could become the best choice in the future.
I have seen a lot of Systemd presentations, for much more than a decade.
None of them has included even the slightest reason why I would want to use it, and on my computers, desktops, laptops, mini-PCs and servers, I have run only Linux or FreeBSD since about 23 years ago, when I have reformatted my last HDD containing a Windows installation, so I have a lot of experience with Linux.
One time, already a few years after Systemd had become mainstream and it was supposed that its early bugs had been fixed, I have tried to use Systemd for a month, thinking that the criticisms that I had heard about Systemd might have been exaggerated. However, I encountered then a bug myself, which was severe enough to convince me that I cannot trust the Systemd developers, so I never used it again.
We basically have it already. And we are all better off for it with software actually working as intended, without maintainers having to make heroic efforts of porting programs.
Interesting that it's kind of that simple. It looks almost like you could make a fairly straightforward fork that works with that, as long as they sysvinit packages are kept up-to-date.
I have to say while I dislike systemd it hasn't annoyed me enough to send me down that route yet.
Granted, this is not quite a thorough age sniffing requirement yet,
but with the legislation in the USA and other countries currently
changed, the operating system is de-jure forced to sniff off data
from people and send it over to others, be it state agencies or
companies. It's like the novel 1984 adapted to the modern days, but
crap. With tons of AI slop.
I find it fascinating how different people are with respect to being able to see the future, or at least caring about it. I find many people are like lumbering beasts in a forest complaining when a twig pokes them in the eye. While other saw the forest from miles away and just went around it.
Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago. This is exactly the kind of thing they saw on the horizon. Why does it take others so long to see the same thing?
>Why does it take others so long to see the same thing?
What thing, exactly? To me systemd has done what it has set out to do and I quite like it for it (not that it's perfect in every respect, but it's in general a welcome improvement on what came before it, especially in terms of consistency between distros instead of a million arbitrary differences). It's also important to note what systemd was offering to distro maintainers, as well. It substantially reduced the work involved in creating and packaging for a distro (though probably only Arch, which is explicitly a distro by and for the maintainers, really said that part loudly).
I am one of the happy Gentoo users, who have escaped from systemd until now.
Some years ago I have experimented with systemd for a month, by using Arch Linux. However I have encountered an ugly bug and eventually I wiped it out.
The problem was not that there was a bug, I assume that the bug must have been solved years ago. The problem was that the bug was not something that could be attributed to a random error, like a cut-and-paste error when editing. It was a bug that in my opinion demonstrated extremely poor judgment in the overall software system design. Thus I considered that the bug was too outrageous and I blacklisted systemd.
(The bug consisted in that the computer, could fail to shutdown, randomly, due to a race condition regarding messages sent on D-Bus, messages that were generated for some reason by systemd while shutting down, when the recipient of a certain message could have been killed before receiving the last message intended for it, or the D-Bus daemon could have been killed before the last attempt of a message transmission, which resulted in a stall. The fact that sending and receiving messages on D-Bus was necessary for being able to complete a shutdown, was in itself a proof of stupidity. In decades of using computers, from IBM mainframes and DEC minicomputers, until the latest computers of today, only with systemd I have seen a case when shutting down a computer could fail. Moreover, even when successful, shutdown was very slow, unlike the instant shutdown with which I am accustomed. For decades my computers have been optimized to boot in a few seconds, by using custom kernels, so the supposed fast boot of systemd had not brought any improvement in my case, while the shutdown was degraded.)
That's funny, because I've been converting all of my Gentoo systems to systemd... from my point of view, the writing is on the wall, most distros use systemd already, so there's no sense in not learning it.
I enjoy using systemd but I'm glad Gentoo exists and I'm thankful that people are using and maintaining alternatives. Diverse ecosystems are not just good, they are necessary.
> Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago.
As a Gentoo user for the past ~quarter-century, I'd say that it's more that -unlike Debian- Gentoo has been using a system service manager that's way better than the classic SysV init for approximately forever.
The early discussion of systemd-as-init [0] was pretty much 100% focused on how much better systemd-as-init was than classic SysV init. When restricted like this, systemd-as-init is an obvious winner. But, when you consider other init systems -such as OpenRC- that provide a bunch of useful scaffolding and support tools (rather than demanding you reimplement all that yourself) the benefits of using systemd-as-init are far less clear.
I've mentioned this before in an HN comment or two from way back when, but I'm really mad at myself for not recognizing how extremely important the "What should Debian adopt to replace the incredibly ancient SysV init?" discussion was and failing to take part in it. OpenRC was knocked out of contention for reasons that were never really clear to me, and I'd have loved to put a bunch of time and effort into fixing whatever deficiencies the Debian folks believed made it unworthy of consideration.
Oh well.
[0] ...as well as some-to-much contemporary discussion...
The OpenRC people in Debian only really noticed the discussion when it reached the technical committee. There was an effort to put OpenRC into contention, and all of the technical committee people who did evaluations included it in their evaluations. The problem was that OpenRC as it existed on Debian at the time was lacking. People argued that it could with a little work do the things that the technical committee people pointed out, but the counterargument was that the decision really had to be made at that point, given the argument that had built up. I do recommend reading the discussions by Russ Alberry and others about OpenRC on the technical committee mailing list back then.
Yes, everyone who has, in the succeeding 12 years, framed this as a choice between van Smoorenburg init+rc and systemd either didn't pay attention or is being woefully slapdash. Debian's choice was between Upstart, as established on Ubuntu at the time, and systemd, with OpenRC as a late entry.
People also made the argument that van Smoorenburg init+rc could be fixed. And in fact they did address some of it, The same year (2014), the sprawling shell scripts so characteristic of van Smoorenburg init+rc were being replaced by a new system, modelled somewhat after Mewburn rc on NetBSD and FreeBSD, where the scripts were much shorter, largely declarative, and reliant upon a new init-d-script interpreter that did all of the repetitive common stuff.
"Systemd-vs-SysV" was never the concern for me personally, it was always "Systemd as the last init we ever create" based on how it's being built, and I always tried to argue that it was a hard pill to swallow because there were already better foundations in the world (SMF, for my favourite example), people didn't want to have that discussion, they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
So, systemd is the last init we'll ever have, just like I feared.
> "Systemd as the last init we ever create" ... they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
Yeah, that rhetoric was maddening. Poettering and crew were -and continue to be- absolutely incapable of maintaining a project of such scope and importance.
Do you remember the fucking kdbus saga? I really wish the folks on the kernel side of that who were responsible for asking careful, technical questions, thinking deeply about the answers that they got, and cutting through the bluster and misdirection they received had been the ones in charge of deciding the new Debian init system for... Jessie, was it?
> But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
I've heard from many folks who have tried to reimplement substantial parts of the SystemD. [0] They report that the documentation is woefully inadequate, the interactions between components get incredibly complex, and the project maintainers have a habit of breaking things whenever they feel like it. This breakage doesn't matter to things they maintain, because they can make changes to account for it... but for "out of tree" reimplementations, well, they are -perhaps correctly- entirely disinterested in worrying about those.
> So, systemd is the last init we'll ever have, just like I feared.
Eh. I still hold hope that Debian or some other major distro will notice how unsuited the SystemD maintainers are to long-term stewardship of something so wide-reaching and critically important and cast about for alternatives. We'll see.
[0] This is a shorthand for "Systemd Project", not a slur against it. It sucks that systemd(1) and the project that contain it share the same name. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
Your comment is very poorly phrased, but, yeah, I've found both the SystemD [0] maintainers and boosters to be very, very unwelcoming to claims that the way something SystemD does is incompatible with a totally reasonable and long-standing way to use a computer.
As I've mentioned elsewhere, SystemD is great... until you hit a bug born of its accidental complexity, or you find can't do something because the SystemD maintainers -sometimes suddenly- decided that they didn't want to let people do it anymore.
[0] This is shorthand for "The Systemd Project", not a slur against it. It sucks shit that systemd(1) and the project it's part of share the same name... it's very confusing. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
From a practical point of view, though, Gentoo kind of struggled a lot. Archlinux kind of took away a lot of the user base here and I don't think Arch is necessarily worse than Gentoo, even if Gentoo may still be better due to offering more choice, which is also true. I myself fell victim to the GoboLinux philosophy, so versioned AppDirs are the only logical way to install something (I don't use the GoboLinux naming scheme though, my naming scheme is simpler, but also flexible, e. g. I could use /pkg/htop/3.2.1/ as example, even though I opted for e. g. /home/Programs/Htop/3.2.1/ instead, just feeling nicer to read).
> Why does it take others so long to see the same thing?
People will have different opinions. Many bought into the pro-systemd advertisement without challenging it ever. Over the years this has also changed, what with the more recent "we love age sniffing" code change to systemd, but even still people don't want to think on their own. They like to adopt what is given to them as an opinion. If you look back in history, many articles about systemd were clearly written by a systemd developer. Naturally these are very biased articles.
systemd desperately needs competition. it isnt just that it became a dependency for every low level service and a potential vector for privacy invasion, it's also janky to use.
I do agree it needs competition. The more the better. The dependency thing is bad but it's free software. It will always be possible to route around that if it ever turns into a problem. Especially now that we have LLMs.
I don't think it's janky though. It's pretty great. It has an answer to everything I've ever needed from it.
The article makes one key mistake, in that it compares systemd to openrc. Aka some monster-system with billion features, to a fairly small system that juts relates to initializing a few things.
The whole debate about systemd has always been very dishonest from the systemd devs. If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition. Systemd has NEVER been solely or primarily been an "init" system. People need to stop buying the propaganda 1:1. That includes self-promo.
It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not).
On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product.
As for "alternatives" to systemd, which is a misnomer IMO: I found that all the alternatives are pretty bad too. The best option is to try to stay as lean as possible without losing things that are objectively useful. Any init system that depends on shell scripts, already is a failure by design. (Systemd's unit files are also a failure; and the lack of transparency too. It is like the ultimate trojan horse.)
How does a field carrying age sniffing? It's open source, you personally run whatever you want.
But not all places are like that, Linux is run in places where abusing this law is mandated. The alternative is that that place can't run Linux - so by denying such a feature you actually deny the usage of Linux, limiting "user-freedom".
You are by no ways hurt if you choose to either ignore the law or live in a place where such laws won't be passed.
(With that said, I'm absolutely against age verification - but that in and of itself won't change the law)
> The whole debate about systemd has always been very dishonest from the systemd devs.
What did they debate? What about it was dishonest?
> If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition.
Why? Just because average lines of code per feature are by a factor of 5 or so lower for systemd in your example? What is the definition they will lose out on?
Also unclear to me what you are referring to with 5000 feature to generate random numbers...
> It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not).
What about it is sniffing if a person voluntarily enters that data to be shared with a service so they can use it? What is it about then if not kids? It sounds like you think all governments who think about enforcing age restrictions online have some shared hidden agenda.
> On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product.
It's linux, you can disable it or not enter your date. Alternative would have been that you are not able to use certain online services in those strict jurisdictions or that any tool that wants to support these services comes with their own implementation.
> As for "alternatives" to systemd, which is a misnomer IMO
Why? It's a daemon (and more) managing your system.
> Systemd's unit files are also a failure; and the lack of transparency too.
Why are they a failure? Which lack of transparency?
Curious how you're handling supervision after the switch. The remoteproc unit you converted by hand is the part that gets interesting: when it crashes, what restarts it, and what guarantees it came up only after its dependencies were actually ready rather than just launched? That dependency ordering and the cgroup resource accounting are the real work, and OpenRC hands both back to you.
> Curious how you're handling supervision after the switch.
In the service file, you put this
supervisor=supervise-daemon
and either ensure the program you're running as a service doesn't daemonize, or make use of 'command_args_background=' and 'command_args_foreground=' if you want to be able to swap between supervised and unsupervised use.
> That dependency ordering [is on you to manually manage]...
Nope. OpenRC has had dependency ordering for the quarter-century I've been using it. [0] It's a core feature, so it's probably had it for forever.
> ...and the cgroup resource accounting are the real work, and OpenRC hands both back to you.
I'm not saying any of this is particularly bad but it's been very clear fot a while that systemd just wants to be an OS. With immutable systems the "distribution" part of it is reduced to a build system, and everything else can be provided by systemd and flatpak.
[0] https://walian.co.uk/arch-install-with-secure-boot-btrfs-tpm...
But it's meant to work as a cohesive system when everything in systemd is used together.
FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things tend to interoperate better when they're explicitly written to work together than when every component is meant to be hacked to work with arbitrary other services through shell script soup.
Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break?
See: https://www.amutable.com
I know they've attached all these projects to the systemd brand because they thought it would beneficial but it's hard not to wonder if we could avoid all those discussions if the umbrella project was called something different...
I would probably run systemd-journald just because it's really nice to have a logging system which knows about the system services, but it's not required.
In other means consider me an average Joe of the Linux world.
Hence this question: If it sucks so much, why did it become so widespread?
The very same people that hate systemd for "being a monolith" and limiting choice are usually also love X and hate Wayland where they can manage to explain how being a monolith is suddenly good.
Especially that systemd is pretty modular - at least the actual systemd program running as PID 1. It also refers to a project with many optional modules running under the same name, but that's like KDE having a file manager and complaining that plasma DE is a monolith.
> but that's like KDE having a file manager and complaining that plasma DE is a monolith
On the other hand it would be very rare to use Plasma without the KDE file manger. You lose all sorts of integration. Similarly, once you use systemd init its going to be a lot easier to replace everything else with the systemd equivalent.
When red hat switched to it, it was stable enough. Before then people were complaining because they did find bugs and issues (I know I did) and were being told to STFU by inexperienced users who have the most basic and standard use case and weren't encountering the issues (or were but didn't even notice).
Very common is the case of some person who sometimes uses linux on their machine telling a system administrator who has thousands of machines under his responsibility what's what.
I don't like the age verification thing either, but all systemd did was add a field for it, it's still up to your distro to use it.
It is interesting that Linux is far more widely used than alternatives that are not fragmented (e.g. FreeBSD) and has not standardised on one distro. Different people have different needs and preferences. People using Debian, Alpine, and NixOS are unlikely to agree on what they want.
cPanel had to maintain its own unified API above a slew of other interfaces, while Cockpit benefits from a unified OS API. And we're only getting started, we still have a long way to go.
Yes I love the diversity of the open source ecosystem, I love that people are free to create their own distros without systemd. But I love my distros with systemd too much to switch.
That didn’t work perfectly, but it did work to some extent.
What I have an issue with is apps making themselves dependent on systemd like KDE is doing. https://www.reddit.com/r/kde/comments/1qi9vo5/comment/o0pzvq...
I don’t see that installing openrc before deleting systemd. It tries to delete systemd and, if that fully succeeds, to install openrc.
> Issue itself was that while uninstalling systemd somehow OpenRC was removed too or not installed at all.
I don’t see how “somehow OpenRC was removed” could be true if it wasn’t installed before. My hunch would be that uninstalling systemd failed halfway through.
The systemd service manager does not have an installer, systemd-sysinstall is a separate tool that's part of the systemd project.
> systemd already integrated it, why (age verification)
systemd has not integrated age verification. All that's been discussed is a simple field to allow a user to register a DoB and an way for services to validate the user is over a certain age.
You could arguably already do this by having a DoB field for the user, but that'd involve giving applications your full DoB which I'm sure is distasteful for many.
> usual "fight" against non-sense laws
Because developers have to follow laws like everyone else?
What would actually be useful would be a generic OpenRC wrapper that would ingest those service files and provide traditional start/stop interface for them.
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.
But I wonder how good Alpine is for desktop computing and development stuff. I know they have recently started shipping full DEs for desktop IIRC.
Anyone with any experiences?
I only know how to control Linux through systemctl, and I don't know much beyond that. It seems like the components are different, but I'd appreciate it if someone could explain it to me.
Because OpenRC and systemd don't even seem like comparable things—OpenRC is much smaller. And from what Google shows me, one is written in C and the other is script-based.
So one is a lightweight service manager, and the other is a framework that manages the entire OS. I'm a Windows enviroment developer, so I don't really know, but they seem to have different roles. Yet there's still a debate, and I don't get it. Is this really just an argument about PID 1?
If they were comparable (i.e. if systemd was just an init system) there would be no debate.
it does not help that the systemd devs are obnoxious and dismissive of concerns about compatibility. Lots of "its your problem" in their bug tracker on github.
Thank you. I didn't know why there was a debate since the size difference between them is quite significant. so I don't know much about the Linux side. Have a good day.
I can't wrap my head around it, since those 3 are a "you" problem, systemd is just a service manager it's you who decide to use other systemd parts.
What makes systemd different from other init systems is that it is specifically designed to work with the other parts. It aims to provide a standardised OS on top of the Linux kernel. That is the advantage, and the disadvantage, of systemd.
Of course I still got called a neckbeard and got told that I didn't like systemd because I'm a dinosaur and so on. So I have a really hard time to take positions such as your seriously to be honest.
You can always point to where I said you are a neckbeard, so I do not get the "hard time" angle.
You can not like systemd, but the arguments for it is silly, and that is fine it's your machine and I don't care as long as people stop spreading FUD on such awful grounds.
Say in contrast with BTRFS or BcacheFS there are genuine issues with those and there are technical philosophical arguments (I want journaling, I do not want or need CoW features, snapshot? never heard of her).
cough
> To this day I have not found a single modern argument against systemd that is a technical one...
Good for you. [0] The project is great until, very, very suddenly it is not. May you continue to have many happy and trouble-free decades with it.
But when you do hit a bug whose cause is dreadfully complex [1], or get some useful, documented behavior you depend on altered so that it's unusable for you for no better reason than "it was inconvenient to keep permitting people to do that", you'll understand why some folks strongly dislike the project.
[0] Genuinely!
[1] ...so much so that the maintainers refuse to work on it...
One element of the free software culture is pushback against monolithic software. It allows you to swap out components in this way. Without that culture there wouldn't be the choice. You could disagree with a particular manifestation of that culture, but at least understand and accept that culture and accept that the reason why you perceive this to be a non issue is precisely because of that culture.
> And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?
Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code.
> Guys, pick your fights reasonably.
I don't see what is not reasonable here at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.
There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.
And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.
So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.
OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.
I do not think that I have ever used an init script longer than 1 page of text.
If bugs are feared, it is always possible to invoke a script written in another scripting language.
While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs.
"scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc.
Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation.
With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration.
Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.
Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree?
If you replace line 14 with
and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure.OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem.
[0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>
Even then, the init scripts system of FreeBSD was much better than the traditional sysvinit. I have never ever had the slightest problem with it, since then until today, when I still run a mixture of Linux and FreeBSD servers.
In the following years, many features of the FreeBSD software package system and of its init scripts system have become available in some Linux distributions, especially in Gentoo.
I have never used in production any variant of the traditional sysvinit, while with the improved versions from FreeBSD, Gentoo and a few others I have never seen any difficulty and no feature that could have been improved by the use of systemd.
In my opinion, the way to an optimal init scripts system has been shown by Daniel J. Bernstein with his "daemontools", which I have also been using continuously 24/7 for more than a quarter of a century, for some essential services, on many servers.
Today, there are a few new init scripts systems that have been inspired by the DJB daemontools, and I think that one of them could become the best choice in the future.
The kernel has a very focused job to do. The hard work of running the show on top of the kernel - and it's a big job - is done by Systemd.
And it's awesome I love Systemd. If you dislike Systemde I can only imagine you haven't really taken the time to learn it and use it properly.
None of them has included even the slightest reason why I would want to use it, and on my computers, desktops, laptops, mini-PCs and servers, I have run only Linux or FreeBSD since about 23 years ago, when I have reformatted my last HDD containing a Windows installation, so I have a lot of experience with Linux.
One time, already a few years after Systemd had become mainstream and it was supposed that its early bugs had been fixed, I have tried to use Systemd for a month, thinking that the criticisms that I had heard about Systemd might have been exaggerated. However, I encountered then a bug myself, which was severe enough to convince me that I cannot trust the Systemd developers, so I never used it again.
I have to say while I dislike systemd it hasn't annoyed me enough to send me down that route yet.
https://github.com/systemd/systemd/pull/40954
Granted, this is not quite a thorough age sniffing requirement yet, but with the legislation in the USA and other countries currently changed, the operating system is de-jure forced to sniff off data from people and send it over to others, be it state agencies or companies. It's like the novel 1984 adapted to the modern days, but crap. With tons of AI slop.
What's the alternative, Linux should just not run in places where this will be the legal framework? How is that field limits your freedom?
Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago. This is exactly the kind of thing they saw on the horizon. Why does it take others so long to see the same thing?
What thing, exactly? To me systemd has done what it has set out to do and I quite like it for it (not that it's perfect in every respect, but it's in general a welcome improvement on what came before it, especially in terms of consistency between distros instead of a million arbitrary differences). It's also important to note what systemd was offering to distro maintainers, as well. It substantially reduced the work involved in creating and packaging for a distro (though probably only Arch, which is explicitly a distro by and for the maintainers, really said that part loudly).
Some years ago I have experimented with systemd for a month, by using Arch Linux. However I have encountered an ugly bug and eventually I wiped it out.
The problem was not that there was a bug, I assume that the bug must have been solved years ago. The problem was that the bug was not something that could be attributed to a random error, like a cut-and-paste error when editing. It was a bug that in my opinion demonstrated extremely poor judgment in the overall software system design. Thus I considered that the bug was too outrageous and I blacklisted systemd.
(The bug consisted in that the computer, could fail to shutdown, randomly, due to a race condition regarding messages sent on D-Bus, messages that were generated for some reason by systemd while shutting down, when the recipient of a certain message could have been killed before receiving the last message intended for it, or the D-Bus daemon could have been killed before the last attempt of a message transmission, which resulted in a stall. The fact that sending and receiving messages on D-Bus was necessary for being able to complete a shutdown, was in itself a proof of stupidity. In decades of using computers, from IBM mainframes and DEC minicomputers, until the latest computers of today, only with systemd I have seen a case when shutting down a computer could fail. Moreover, even when successful, shutdown was very slow, unlike the instant shutdown with which I am accustomed. For decades my computers have been optimized to boot in a few seconds, by using custom kernels, so the supposed fast boot of systemd had not brought any improvement in my case, while the shutdown was degraded.)
As a Gentoo user for the past ~quarter-century, I'd say that it's more that -unlike Debian- Gentoo has been using a system service manager that's way better than the classic SysV init for approximately forever.
The early discussion of systemd-as-init [0] was pretty much 100% focused on how much better systemd-as-init was than classic SysV init. When restricted like this, systemd-as-init is an obvious winner. But, when you consider other init systems -such as OpenRC- that provide a bunch of useful scaffolding and support tools (rather than demanding you reimplement all that yourself) the benefits of using systemd-as-init are far less clear.
I've mentioned this before in an HN comment or two from way back when, but I'm really mad at myself for not recognizing how extremely important the "What should Debian adopt to replace the incredibly ancient SysV init?" discussion was and failing to take part in it. OpenRC was knocked out of contention for reasons that were never really clear to me, and I'd have loved to put a bunch of time and effort into fixing whatever deficiencies the Debian folks believed made it unworthy of consideration.
Oh well.
[0] ...as well as some-to-much contemporary discussion...
Yes, everyone who has, in the succeeding 12 years, framed this as a choice between van Smoorenburg init+rc and systemd either didn't pay attention or is being woefully slapdash. Debian's choice was between Upstart, as established on Ubuntu at the time, and systemd, with OpenRC as a late entry.
* https://jdebp.uk/FGA/debian-systemd-packaging-hoo-hah.html
Interesting tidbit:
People also made the argument that van Smoorenburg init+rc could be fixed. And in fact they did address some of it, The same year (2014), the sprawling shell scripts so characteristic of van Smoorenburg init+rc were being replaced by a new system, modelled somewhat after Mewburn rc on NetBSD and FreeBSD, where the scripts were much shorter, largely declarative, and reliant upon a new init-d-script interpreter that did all of the repetitive common stuff.
* https://unix.stackexchange.com/a/480897/5132
* https://manpages.debian.org/trixie/sysvinit-utils/init-d-scr...
"Systemd-vs-SysV" was never the concern for me personally, it was always "Systemd as the last init we ever create" based on how it's being built, and I always tried to argue that it was a hard pill to swallow because there were already better foundations in the world (SMF, for my favourite example), people didn't want to have that discussion, they just wanted to talk about how bad SysV was and that systemd was progress... I was impeding progress...
But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
So, systemd is the last init we'll ever have, just like I feared.
Yeah, that rhetoric was maddening. Poettering and crew were -and continue to be- absolutely incapable of maintaining a project of such scope and importance.
Do you remember the fucking kdbus saga? I really wish the folks on the kernel side of that who were responsible for asking careful, technical questions, thinking deeply about the answers that they got, and cutting through the bluster and misdirection they received had been the ones in charge of deciding the new Debian init system for... Jessie, was it?
> But, we're here now, and replacing systemd at this point will require being API and bug compatible or else major software (like GNOME) won't run at all.
I've heard from many folks who have tried to reimplement substantial parts of the SystemD. [0] They report that the documentation is woefully inadequate, the interactions between components get incredibly complex, and the project maintainers have a habit of breaking things whenever they feel like it. This breakage doesn't matter to things they maintain, because they can make changes to account for it... but for "out of tree" reimplementations, well, they are -perhaps correctly- entirely disinterested in worrying about those.
> So, systemd is the last init we'll ever have, just like I feared.
Eh. I still hold hope that Debian or some other major distro will notice how unsuited the SystemD maintainers are to long-term stewardship of something so wide-reaching and critically important and cast about for alternatives. We'll see.
[0] This is a shorthand for "Systemd Project", not a slur against it. It sucks that systemd(1) and the project that contain it share the same name. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
[2] <https://news.ycombinator.com/item?id=48716382>
As I've mentioned elsewhere, SystemD is great... until you hit a bug born of its accidental complexity, or you find can't do something because the SystemD maintainers -sometimes suddenly- decided that they didn't want to let people do it anymore.
[0] This is shorthand for "The Systemd Project", not a slur against it. It sucks shit that systemd(1) and the project it's part of share the same name... it's very confusing. [1]
[1] For a real-world example of the sort of conversation this confusion causes, check out [2]
[2] <https://news.ycombinator.com/item?id=48716382>
From a practical point of view, though, Gentoo kind of struggled a lot. Archlinux kind of took away a lot of the user base here and I don't think Arch is necessarily worse than Gentoo, even if Gentoo may still be better due to offering more choice, which is also true. I myself fell victim to the GoboLinux philosophy, so versioned AppDirs are the only logical way to install something (I don't use the GoboLinux naming scheme though, my naming scheme is simpler, but also flexible, e. g. I could use /pkg/htop/3.2.1/ as example, even though I opted for e. g. /home/Programs/Htop/3.2.1/ instead, just feeling nicer to read).
> Why does it take others so long to see the same thing?
People will have different opinions. Many bought into the pro-systemd advertisement without challenging it ever. Over the years this has also changed, what with the more recent "we love age sniffing" code change to systemd, but even still people don't want to think on their own. They like to adopt what is given to them as an opinion. If you look back in history, many articles about systemd were clearly written by a systemd developer. Naturally these are very biased articles.
Maybe it's too late.
LP is cooking a way to deny system modifications [1]
[1] https://news.ycombinator.com/item?id=46784572
I don't think it's janky though. It's pretty great. It has an answer to everything I've ever needed from it.
The whole debate about systemd has always been very dishonest from the systemd devs. If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition. Systemd has NEVER been solely or primarily been an "init" system. People need to stop buying the propaganda 1:1. That includes self-promo.
It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not).
On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product.
As for "alternatives" to systemd, which is a misnomer IMO: I found that all the alternatives are pretty bad too. The best option is to try to stay as lean as possible without losing things that are objectively useful. Any init system that depends on shell scripts, already is a failure by design. (Systemd's unit files are also a failure; and the lack of transparency too. It is like the ultimate trojan horse.)
But not all places are like that, Linux is run in places where abusing this law is mandated. The alternative is that that place can't run Linux - so by denying such a feature you actually deny the usage of Linux, limiting "user-freedom".
You are by no ways hurt if you choose to either ignore the law or live in a place where such laws won't be passed.
(With that said, I'm absolutely against age verification - but that in and of itself won't change the law)
What did they debate? What about it was dishonest?
> If you have 3 million lines of code, for instance, and offer 5000 features, just to give out semi-random numbers, then every alternative with, say, 100.000 lines of code and only 50 features, will lose out by definition.
Why? Just because average lines of code per feature are by a factor of 5 or so lower for systemd in your example? What is the definition they will lose out on? Also unclear to me what you are referring to with 5000 feature to generate random numbers...
> It is the same with age sniffing; some still believe it is about protecting kids. Then they were flabbergasted when governments - who suspiciously smell like corporate-controlled governments by the way, in particular in the UK - declare total war against VPNs. The excuse they use is not convincing at all, IF you buy into the assumption that this is about kids (which it is not).
What about it is sniffing if a person voluntarily enters that data to be shared with a service so they can use it? What is it about then if not kids? It sounds like you think all governments who think about enforcing age restrictions online have some shared hidden agenda.
> On the other hand, when systemd decided to support age sniffing (https://github.com/systemd/systemd/pull/40954), I guess they went a step too far. People who weren't against systemd, look at it differently now. After all why is Poettering so defensive about systemd supporting age sniffing? All that tasty data that is to be amassed. Some private entities love that data. You have become the product.
It's linux, you can disable it or not enter your date. Alternative would have been that you are not able to use certain online services in those strict jurisdictions or that any tool that wants to support these services comes with their own implementation.
> As for "alternatives" to systemd, which is a misnomer IMO
Why? It's a daemon (and more) managing your system.
> Systemd's unit files are also a failure; and the lack of transparency too.
Why are they a failure? Which lack of transparency?
In the service file, you put this
and either ensure the program you're running as a service doesn't daemonize, or make use of 'command_args_background=' and 'command_args_foreground=' if you want to be able to swap between supervised and unsupervised use.> That dependency ordering [is on you to manually manage]...
Nope. OpenRC has had dependency ordering for the quarter-century I've been using it. [0] It's a core feature, so it's probably had it for forever.
> ...and the cgroup resource accounting are the real work, and OpenRC hands both back to you.
Nope. [1][2]
[0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>
[1] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>
[2] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>