Replacing Systemd with OpenRC in Debian | Hacker News Reader

Replacing Systemd with OpenRC in Debian

danielcordova.me

63 pointsnogajun162 comments

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 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?

Which law though?

Which country/state/region? Does it even apply? We're talking about an open source project that is not being sold, with contributors from all over the world.

The laws which any contributors to the OSS project are subject to. Some projects geographically restrict who can contribute to avoid issues like this, but when laws are passed by a jurisdiction in which existing maintainers reside those maintainers have the choice to either comply or move to a different jurisdiction. Moving is extremely disruptive & expensive, so they often comply.

IIRC laws in some US states will require OS's to collect the age of the user so services can age restrict, it does not mandate any kind of ID verification.

It doesn't matter it's an open source project, ultimately it ends up in commercial products which do require following the rules.

The commercial products can patch it then if they so wish.

The field does nothing when left untouched, which it is by default.

If having the ability to set a piece of metadata worries you, don't set it.

One field doesn't worry me. IBM being in charge of a core linux component does.

The expressed intention behind adding the DoB field is to comply with age verification laws. Intent matters a whole lot here.

> comply with age verification laws

Do you want the developers to ignore the law and in the case of companies like Red Hat etc be vulnerable to law suits?

There's multiple laws, and they all conflict with each other.

They are obeying some by violating some others. In this case I'd personally do nothing.

Yes. Stand up and be a test case like Bernstein. Show some guts.

In the case of a company there’s even less at risk, and a lot of good will to be farmed.

These are laws passed by democratically elected legislatures. It’s not a legal issue, it’s a political one. Ostensibly, the will of the people. But these wimpy geeks passively-aggressively protest by arguing about code online, instead of engaging in real political activism.

When lobbyists push legislators to enact laws that violate the Constitution, and voting differently does not resolve the problem, the next recourse is the jury box. Courts are a check on the other two branches.

You can't foist this on an ethereal other that we can just blame for all our ills. Pretending American democracy is somehow broken to the point voting doesn't work is an insane take. Especially because you literally watched republican grassroots vote in their man and he's giving them what he campaigned on to give them.

Pretending there's nothing to done is just an excuse to do nothing

I was just as unhappy with Biden, with Obama (by the end of his term), and with Bush. So no, voting doesn’t work.

Regardless of the face you put on the presidency, we are always going to have to fight for privacy and freedom at the grassroots level.

Fortunately, economic decline has brought with it a decline in state capacity, which does bring new problems, but enforcement is becoming an issue across the board. That’s a form of freedom, even if it sucks to deal with stuff like petty crime on a daily basis.

Are you offering to pay for their lawyers?

If it’s a good test case, EFF would surely represent an individual pro bono. Depending on the importance of a corporate case, they would contribute heavily. But you can think of the expense as marketing, especially for a company like Red Hat who gets a lot of unnecessary grief from the community.

I don't think there's anything SystemD has to do in order to comply with age verification laws. They could just ignore it. They're not an operating system.

If any distro made their own way to store a DoB field, it'd be a nightmare of interoperability.

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.

[0] https://walian.co.uk/arch-install-with-secure-boot-btrfs-tpm...

My searches for "systemd partition autodiscovery" lead me to [0]. In the table labeled "Table 1. Partition Type GUIDs", we find this in the Explanation section for 'SD_GPT_HOME'

  The first partition with this type UUID on the same disk as the root partition is mounted to /home/.

...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unless all of the partitions of interest (including your /boot/) are on the same disk? Seriously? There's also no indication that this works with LVM... which is -if true- is extremely inconvenient. The document at [1] only mentions LVM in passing, and [2] is Poettering saying "Fuck off, I don't want to support doing this with LVM".

Did I misread a document or fail to find a relevant one? If not, is this really limited to single-disk, "legacy" [3] configurations?

[0] <https://www.freedesktop.org/software/systemd/man/latest/syst...>

[1] <https://uapi-group.org/specifications/specs/discoverable_par...>

[2] <https://github.com/systemd/systemd/issues/1727>

[3] Yes, I'm considering any fixed-partition mechanism, whether MBR or GPT to be "legacy". The flexibility you get from LVM is sooooo nice.

> you can't spread your /home and / partitions on separate disks and use this

No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do, like multi-disk setups, LVM, and FDE with unsupported configurations. It's great if it works for you and a very minor change if it doesn't.

I don't recall ever installing a system with / and /home on separate partitions, though.

> No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do...

It's just shocking that autodiscovery is so extremely limited. I'm aware that if you want to do something that autodiscovery can't do, then you cant use autodiscovery for that thing... I'm pretty sure that was covered in a recent Tautology Club meeting.

> I don't recall ever installing a system with / and /home on separate partitions, though.

I'd wager that that's the configuration of vast majority of the consumer systems out there... which makes it even more confusing how anemic partition autodetection is.

Its target user is one who bothers to partition out space for subdirectories, but doesn't use either multiple disks or LVM? That's a very particular sort of user.

> I'd wager that that's the configuration of vast majority of the consumer systems out there...

I'm not so sure. Most people I know, including developers, only have one SSD, maybe a hard drive for photos or whatever that's not mounted inside /home.

The most popular mainstream Linux distributions (Android, ChromeOS, SteamOS) all default to a single disk setup, as do most virtual machines (which must exceed the number of home installs by at least a thousandfold).

For a particular brand of enthusiasts, running multi-disk is definitely more popular (I have 4 in my desktop), but I don't think those are the majority, and even among those splitting partitions across disks rather than just using a /media (or equivalent) to access the larger disk like you would an external drive is quite popular.

Multi-disk detection would be nice, but I can already imagine the absolute mess that would happen if you were to try to boot on a multi-distro PC, or even just a recovery flash drive on an existing Linux image. My recovery boot drive only has a root partition so auto-detecting the drive will work fine, but auto-mounting my home directory to /home would mess up the entire system.

The code would be so full of edge cases and weird guards that it'll inevitably just break without configuration, making the entire thing pretty damn useless.

> I'm not so sure. Most people I know, including developers, only have one SSD...

Right. My intent was to say that a single disk, probably with everything under "/" in a single partition is what the overwhelming majority of personal computers out there are using.

> Multi-disk detection would be nice, but I can already imagine the absolute mess that would happen if you were to try to boot on a multi-distro PC...

This would be trivial if the thing supported LVM. [0] Given that the bootloader needs to use a protocol to tell the automagic fstab creator what is the root device, [1] update that protocol to have the bootloader pass the VG name to search for, and then search for LVs named "$VG_NAME-$MOUNTPOINT" and do the obvious thing. [2] No need to either fuck around with or remember magic GUIDs or worry about what happens when you have multiple partitions with the same magic GUID, and you support all sorts of power-user features for free.

[0] While it's true that I haven't used a ton of Linux installers, every Linux installer I've used for the past ten, fifteen years that offered to let you partition your disk also had an option to set up LVM. I know that many people think that LVM's an "advanced" feature, but it has been around for ages and is well-supported.

[1] <https://news.ycombinator.com/item?id=48727809>

[2] That is, if the bootloader passes in 'gentoovg', you'd do the obvious things with 'gentoovg-root', 'gentoovg-home', 'gentoovg-opt', etc, etc, etc.

> ...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unless all of the partitions of interest (including your /boot/) are on the same disk? Seriously?

How would it choose from 2 home partitions on other disks?

A little better than how you'd handle having multiple '/home' lines in fstab? Either pick one to mount, or have the bootloader give a hint as to which one to mount (as there's apparently a whole protocol the bootloader must use for this to work). [0]

But. Having said that, why would you have two home partitions on other disks? Having a bigass disk for your home partition [2] is way more common than having multiple entirely-independent Linux installs that you all want to use this automagic mount point detection on. Do you disagree?

[0] > Note that automatic discovery of the root only works if the boot loader communicates this information to the OS, by implementing the (Boot Loader Interface)[1].

[1] <https://systemd.io/BOOT_LOADER_INTERFACE/>

[2] ...because where else would you store all your porn?

Btrfs and zfs don't need an fstab at all, they manage their mountable filesystems internally.

Sure. After you have located root and the boot partition which is what this addresses.

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.

Suppose someone wants to play this game, what's the point? Not to mention the fact that Gnome, even though is not a GNU project, literally means GNU Network Object Model Environment.

Can't these features be toggled?

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?

See: https://www.amutable.com

> converting Linux to a locked-down immutable OS

That approach is part of why Valve has been able to ship Linux to general consumers.

I don't know exactly why you'd go for amutable specifically, but not handing users the key is a huge benefit to any company-owned hardware out there.

Having an immutable OS for some scenarios makes sense. However, I find waving the whole layer into systemd and kernel permanently, instead of having it as a layer which you can install and enable if you need so is a bit sinister.

This enables the danger of locking out every Linux distribution out there, esp. with new IPC protocols, new image based installation methods, encryption and whatnot systemd brings in with all these modules.

One day, Microsoft can disallow disabling of secure-boot for PC certification and stop signing 3rd party bootloaders. The rest will be fun.

> instead of having it as a layer which you can install and enable if you need so is a bit sinister

I don't really get it. If you don't want systemd, you can install your own OpenRC-based immutable OS. I don't know if that currently exists (Android does, I suppose? maybe ChromeOS?) but it's not like systemd is forbidding everyone from doing anything.

The biggest difference between systemd and alternatives is that systemd builds out the architecture that makes things like building immutable distros easy. If you have a thousand different components, all with slightly different roles, the amount of coordination necessary to get everything to play nice together makes it near impossible to achieve the same things a coordinated system can achieve.

I'm sure that if someone would build an alternative to systemd-sysext and prepare a prebuilt set of tooling and configuration that does what systemd does, there will be distros that will use them.

Secure boot can be overridden by just adding your own keys. At worst, Microsoft will refuse to boot Windows because you added a key yourself. The exception is extra expensive, specially labeled Enterprime (TM) hardware built for Windows sysadmins and Microsoft tablets built for consumers, but I don't know why you'd buy either if you don't want to give MS that much control.

Lennart Poettering will not rest until all software is completely unusable.

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.

You probably also want to run udev, and logind comes close. Everything other than these four is absolutely optional.

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 "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.

> 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'm not sure that's a good argument because it goes both ways.

Sure, times have moved on but having dozens or hundreds of machines is now nothing compared to thousands, but at some point it was - and people have experienced it then.

And even without the number, I'm not really sure it's a good thing to count professional users (who often have access to support and resources) more than hobby users.

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.

> 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.

Wayland is very much a monolith compared to X. I guess people never really realized how much desktop environments could be mix'n'matched under X, bringing window managers, system trays, hotkeys bindings, and a whole bunch of other things not designed together but that could still work together. Under Wayland it's all smushed together and you have to accept whatever your chosen desktop environment chose to implement. It's very similar to how systemd is going.

???

Wayland is a protocol, that sentence is in and of itself faulty.

And there are multiple independent implementations of said protocol. Unlike in case of X, that has basically 1. With proprietary modules (that's how nvidia proprietary drivers work). With a goddamn printer inside. Don't mistake an X "window manager" which is basically just an extension on top of an X server with a whole display manager implementation of Wayland.

Like an X window manager is more akin to a Gnome shell plugin that adds a dash to your screen.

> Like an X window manager is more akin to a Gnome shell plugin that adds a dash to your screen.

Yes, that's exactly my point - on the user's side, X was modular, not monolithic. Wayland is the monolithic one where everything is "batteries included" (except not always everything) with no ability to add/replace functionality.

Please continue reading the remainder of the sentence from my first comment:

> and you have to accept whatever your chosen desktop environment chose to implement.

The biggest advantage systems has is also it's biggest disadvantage: the amount of functionality. Even with lot of functionality being optional this days, dlopened at runtime if present, it's still bigger then a simple shell script or.tpur own 20 lines of C-code. The later may, in some cases like running anyways only one app in full screen, more then enough. In some embedded setups you may not even need that but just run your app as pid 1 and be fine.

Both systemd and wayland were quite broken when they were first being pushed onto everyone... they're mostly fine now.

It's the bazaar. No one is pushing anything on you, you have a wrong mental model if you think anything can be pushed.

You forgot pulseaudio to the list!

Wayland's big problem right now is that libinput developers gatekeep improvements so if your device isn't on the golden list it will work badly and there is no escape. Which is why I'm not using wayland.

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 traded one set of problems for another set of problems.

The people who are happy now don't complain (or are too new to init systems) and the people you hear are the ones who now have more problems than before. I suppose the majority either shouldn't comment because they never used anything before it to some degree, or they're just more, or they're really happier, good for them.

I count myself as part of the latter group (nothing was broken, now I have some problems) but it's not catastrophic. I'm not arguing systemd is worse, I'm just saying I've repeatedly have problems I didn't have for the first 15 years of using Linux.

I ran into issues early on, I used (and needed) an 'expect' script to run as part of a daemon startup, and that just didn't work with systemd. And then on another computer 'udev' spiked to 100% CPU after Debian switched to systemd, and I never managed to find out what on earth triggered that. I didn't want to spend a lot of time to solve these things, so I simply switched all my computers from Debian to Devuan (aka Debian without systemd) and I've had zero problems with that switch, which happened years ago.

systemd replaces the duct-tape-and-tie-wrap systems that many Linux distros used to run with a unified set of tools, which can be interchanged, but often aren't. You don't have to enable container support, DNS servers, or disk mounts in systemd, but support is there in case you need it. Some distros stopped shipping bespoke DNS servers, others still do, it depends on the distro; it's not like distros are forced to enable the whole set. I don't know any distro that actually does, actually.

If you're the kind of person that wants to deliberately choose what software handles your DNS and what software configures your TTY and which cron daemon you use, then systemd limits your options somewhat. If you want to go in and re-write the init scripts for a system daemon because you have specific requirements, you still can but it adds a level of indirection to the whole thing.

systemd works great for the 95% who can do with a reasonable set of defaults. The remaining 5% will run into annoyances about defaults and obscure configuration, and a small (but extremely loud) subset of those people hate the idea of one set of software taking over so many tasks.

In reality, the option not to use systemd has always been there, but many distros find it much easier to use and most software doesn't bother with the ancient init scripts anymore. You can install openrc, but you're going to need to write most of your service management configuration (often shell scripts) yourself

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.

Fragmentation is what makes Linux great imo. I'm not against systemd per se but I am against monoculture.

The Linux Kernel is a monolith.

They said monoculture. That said, I'll happily argue that the Linux monoculture is real and a problem.

The linux kernel is only the kernel though. MacOS is not XNU.

That's not what I mean.

And what are your thoughts on deploying software to a fragmented system?

Just like it's done now, every distro having their own system. It containerization for people who like that.

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...

KDE is not an app, it is a fully blown DE.

Not the OP, but the historical answer was POSIX (https://en.wikipedia.org/wiki/POSIX, https://dl.acm.org/doi/10.1109/2.56856).

That didn’t work perfectly, but it did work to some extent.

POSIX is great! For basic command line apps which don't really need to interact with the system other than reading user provided files and directories.

For graphical stuff, or stuff which wants to interact more deeply with the system, you need so much more than a common C API and rudimentary shell specification.

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.

> Systemd does not solve the deployment problem, and will not unless it adds something like a systemd package manager.

It really doesn't need to provide a package manager. Systemd already basically has all the knobs for launching services in their own little world (`RootImage=`, `RootDirectory=` and recently `RootMStack=` (for a de-OCI'd layered container images)) or systemd-portabled. There are probably more things I forgot.

Well no but that has some other reasons outside the fragmentation.

Businesses in general hate the MIT license because anything they contribute can be used by their competitors without opening the source.

I personally like this about FreeBSD. I hate the way Linux has been infiltrated by all the business suits and it's now an OS with billions of dollars of interests pulling at it. Look at the linux foundation board, it's all suits, they're not community guys. Or all the contributions that are mostly done by people doing it as part of their work at big tech.

In my opinion the big tech companies' interests are completely opposite to my own, I don't believe in 'win-win' when it comes to enterprise participation in open source. As such Linux is not a great option for me, but for many people it is because they don't care so much about that.

FreeBSD isn't really a monoculture either by the way. There are many different distros there too, they are just really fringe because FreeBSD itself is fringe.

You define the supported target and that's it. RHEL and Ubuntu LTS, kubernetes, docker/podman or flatpak are popular ones.

Linux will still be viable when systemd is gone. There will always be a need for open software.

I'm confused... isn't Devuan exactly this?

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.. ?

Writing a basic init script is less intensive than having to learn the entire "schema" for both script formats, which you'd probably want to know if you were writing the generator.

Yes, but one only needs to write it once, and then everyone could use it. It could probably even be packaged as an official Debian package.

It's wild to see people having this argument in the subjunctive in 2026. I've had a convert-systemd-units tool since 2014, and provided Debian packages for the toolset that it is part of for around that long.

* https://jdebp.uk/Softwares/nosh/guide/commands/convert-syste...

* https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni...

* https://jdebp.uk/Softwares/nosh/debian-binary-packages.html

> Yes, but one only needs to write it once...

...and then keep up with behavioral changes that the Systemd Project people introduce and load-bearing bugs that services end up relying on for lifecycle management.

OpenRC service files are easy to write, and their schema is far far simpler than that of Unit files. [0] It's really not worth the effort to write and maintain an converter, if for no other reason than you need to understand the semantics of both systems' service files to double-check the results of the converter.

[0] <https://news.ycombinator.com/item?id=48717056>

Writing a script is easy. But converting a whole system of .service files seems like a great time to automate.

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.

Debian is an OS, not a kit to build an OS using lots of different components.

FTA: “Before deleting systemd, need to be sure that OpenRC will be installed, to so the command will be
sudo apt purge --allow-remove-essential systemd && sudo apt install openrc sysvinit-core
”

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.

For people interested in "less systemd" there's also the gardenhouse bits at https://git.pinkro.se/

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).

> 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.

* 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...

Yes, exactly.

"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]

[2] <https://news.ycombinator.com/item?id=48716382>

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.

Because if you dare criticise or say "I encountered a bug" the mob will get you.

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]

[2] <https://news.ycombinator.com/item?id=48716382>

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 great from a philosophy point of view.

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.

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.

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).

You are precisely part of the mob I was describing. Perhaps you did not say exactly word by word "neckbeard" but you are dismissing all the arguments as FUD.

As I said, when distributions were already using systemd by default I installed it and tried it for one hour and found 3 different ways it was losing data sent to journald.

According to you when a logging daemon loses log entries, stating that it's not ready for real use is FUD. Funny how you think of yourself as being the reasonable one here :)

Right, why did you feel the need to straw man me to somehow justify your victim complex?

You can cite me for when I said all arguments are FUD, or even that yours was.

And if your issue is that it's not ready, okay? That had nothing to do with my point.

So let me repeat, do you swear to never use a certain Linux kernel module because it has critical bugs? If yes okay good that is a most likely temporary technical argument so why spread FUD about it?

> 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.

> 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...

Sorry for nitpicking, maybe you didn't think through the choice of word, but what is a "technical" argument and how is it different from other types of arguments?

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?

Technical as in there a precise and empirical reason for it such as a technological reason for it.

The bloat argument is perfectly suitable once you remove its derogatory meaning and instead say resource constraints such as when working in embedded.

If Unix philosophy is what's keeping systemd from requiring a Microsoft account during install, I'm all for it.

If everything followed the UNIX philosophy then we wouldn't be here, because for opening this single page, or the author's one you need a gigantic and monstrous program like a browser that has a lot of features and functions that the philosophy would forbid.

Why you need systemd for that when you can just enable pam_microsoft_account.so?

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.

why don't you try searching on the internet?

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.

A Linux system is build around many tools. Systemd replaced the init + gradually many othe parts, it can now handle logs, schedule jobs, manage containers, be the local dns resolver, etc. All the bricks that makes a linux system without systemd still exist. All those additional functions of systemd are optionnal but afaik they depend on systemd to handle the init to work. This is the reason openrc is often seen as a replacement as you first need to change the init to replace other functionnalities anyway.

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.

How about age sniffing though? :)

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.

Like they added a field to be possibly law-complient?

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?

You can just ignore them. What are they going to do about it?

You can just compile it without that.

Alpine Linux and Void are the only mainstream enough distro I can think of as an interest for my planB.

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?

> Alpine Linux and Void are the only mainstream enough distro I can think of as an interest for my planB.

Consider Gentoo as well? They have decent binary package availability now which reduces the compilation needed.

> 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.

How do you mean? You can install whatever graphical system you want on Alpine. I've got Alpine boxes running i3 and KDE, which seems like the full spectrum.

> Anyone with any experiences?

Alpine is great. I've run it on desktops, laptops, headless, and a Steam Deck and it's been mostly a good time. As you kinda allude to, it really shines on underpowered machines by being so light.

>How do you mean?

Alpine was more for container environment right? So I was wondering how it has been for normal usage and apps. Especially with MUSL etc

IIRC Alpine was originally built largely for embedded networking gear, then because of its small size came to be favored in container images (where smaller images are a selling point), but it's a general purpose distro and I've had a good time daily-driving it on laptops. If apps/musl are a problem you can just install flatpak, but off the top of my head I've only needed that for Steam and non-firefox browsers (but `apk add firefox` works fine).

Actually, a funny thing is that I used to daily-drive Void, and I do remember having more problems there because of musl. But I think that may have been mostly a chromium or webkit problem with... something about how Void+musl did memory allocations? I forget. Anyways, I'm pretty sure even that would be fixed with firefox or flatpak so w/e.

Thank you! I'll definitely try it out this or next week.

> Currently OpenRC does the work.

That is a shame, but I wonder if you tried this with devuan you may have better luck ?

https://www.devuan.org/

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.

> systemd desperately needs competition

Maybe it's too late.

LP is cooking a way to deny system modifications [1]

[1] https://news.ycombinator.com/item?id=46784572

I do agree that systemd could use some competition, but until someone builds one, we're going to be dealing with some systemd defaults. Canonical's attempts seem to have been most complete, but outrage at change and different ideas have shut down most of Canonical's attempts to improve the situation.

It's far from janky, at least compared to what else is out there for Linux. If you're not writing systemd service files, you're almost surely back to writing unpredictable 80s style scripting jank.

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.

where is it janky?

The output devices (/dev/stdXXX) being sockets-only constantly trip people up.

His imagination.

Try porting svcs from Solaris to Linux...

GNU Shepherd maybe?

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?

Not long in the future we'll have "Systemd Linux".

It can reasonably be argued that Systemd is a very substantial chunk of what the operating system actually is.

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.

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.

Just install devuan?

This devuan? https://lwn.net/Articles/786593/

That was pre-covid, and the guy stepped down. But I can see your point. My point is that they had time to re-think what happened.

That was my initial thought.

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.

Not all code are equal.

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.

[0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>

I've never *ever* broken a production system by reconfiguring a sysvinit service, at all, no no no, not me...

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.

Absolutely not!

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.

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...>

Reply on news.ycombinator.com