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.
Try porting svcs from Solaris to Linux...
Replacing Systemd with OpenRC in Debian
91–100 of 168 posts
Re: Replacing Systemd with OpenRC in Debian
#92Tbh, 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 syst…
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...
Btrfs and zfs don't need an fstab at all, they manage their mountable filesystems internally.
Re: Replacing Systemd with OpenRC in Debian
#93Earlier quoted context omitted.
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.
Re: Replacing Systemd with OpenRC in Debian
#94Earlier quoted context omitted.
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…
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.
Re: Replacing Systemd with OpenRC in Debian
#95Curious 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
> 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...>
Re: Replacing Systemd with OpenRC in Debian
#96Earlier quoted context omitted.
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...
Re: Replacing Systemd with OpenRC in Debian
#97Earlier quoted context omitted.
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.. ?
Re: Replacing Systemd with OpenRC in Debian
#98To 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.
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?
Re: Replacing Systemd with OpenRC in Debian
#99Earlier quoted context omitted.
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.
Re: Replacing Systemd with OpenRC in Debian
#100Earlier quoted context omitted.
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...
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.