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.

▲

nubinetwork an hour ago | parent [-]

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.

▲

_flux an hour ago | parent [-]

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.

▲

nubinetwork an hour ago | parent [-]

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

▲

_flux 40 minutes ago | parent [-]

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

▲

nubinetwork 35 minutes ago | parent [-]

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.

	▲	_flux 20 minutes ago \| parent [-]
		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.

▲

shevy-java 3 hours ago | parent | prev [-]

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)

	▲	muvlon 2 hours ago \| parent [-]
		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.