If you’re a new user you’d be better off moving on from here and not paying much attention. It’s a hot topic full of opinions that everyone will want to force on you.

If you really want to swap out the init system there are some things you need to know.

First, do you need a desktop environment(DE)/window manager(WM)? If so you’ll need to find a DE/WM that is not going to demand you use the mainstream init choice which currently is SystemD. If you want to use Gnome from your chosen distro repo’s then chances are it will pull SystemD with it.

If you want Gnome but not SystemD you’re gonna be building that beast from source every update and for the most part you’ll need to go direct to Gnome for any issue/bug you fall over and this too will be painful.

Simpler WMs will be more forgiving and will only rely on either xorg or wayland and will happily run on any init.

There will be other packages out there that also demand you use SystemD, so you’ll have to find them and decide if you need them or if there are alternatives that don’t have a hard dependency on SystemD.

All the current usable inits are written in C or C+ (except for GNU Shepherd, this is written in guile).

The benefit of swapping out the init system is mainly down to choice, necessity but again this all boils down to what the installation is for and what will it be doing.

For a good run down of the features of the init systems refer to these 2 urls: https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.archlinux.org/title/Init

All of the init’s (except for epoch) provide parallel service startup so if boot time is a focus test each to find the fastest for your platform, Not all of them provide per-service config.

For example one can cobble together: minirc, busybox, syslogng, crond, iptables, lighttpd.

And the end result would be a relatively secure webserver with a small footprint, you could further extend this with nginx to sit in front of lighttpd to provide waf and cache features.

The biggest bug bear with SystemD is that it writes to binary log files and even though it can be configured to generate plain text, if it falls over in a bad way you will still only get a binary log file and if you’re in a situation where your only access is say busybox for emergencies. In this instance your only option is to boot from another systemd distro and mount the broken install and run:

$ journalctl --file /var/log/journal/system.journal

Other than that many take issue with SystemD trying replace parts of the system that many say don’t really need replacing like sudo, fstab, resolv.conf, etc but again these statements get full of opinion and don’t help us truly way up the differences and some of the SystemD alternatives misbehave or become hard dependencies other projects which makes it harder to disable parts and swap out to your chosen package.

I’ve tried to be more objective with this response and keep as much of my personal opinion out of this, But here is mine:

I don’t really like it but to make it easier to get support for my OS I put up with it, I daily drive arch and so must accept it. I could rip it out or run artix, I’ve gone down this path and got fed up with jumping hurdles to get what I wanted so went back to Arch and now I disable parts of it I don’t need/want, have it generate text log files, use openresolv and other choices.