Replacing Systemd with OpenRC in Debian(danielcordova.me) |
Replacing Systemd with OpenRC in Debian(danielcordova.me) |
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.
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.
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.
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.
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?
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?
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.
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?
Maybe it's too late.
LP is cooking a way to deny system modifications [1]
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.)
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?
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.
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 think all arguments about a technology like systemd need to have a technical part (what systemd does) and a (sometimes implicit) personal part (what I think about it). If it doesn't have the technical part then I don't think it's an argument about systemd at all.
The difference I can see between your example arguments is that the "technical" one is more precise. "Not supporting x" is pretty specific while "being bloated" is not very precise. But of course it could be more precise if you say something like "systemd is made of x megabytes of code. I only want the code I need which I think can be implemented in 1% of that" or just "systemd includes parts x, y and z which I don't want".
So did you by "technical" just mean "precise" or is there another meaning that I missed?
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.
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.
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.
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.
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?
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]
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
supervisor=supervise-daemon
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...>
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...
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.