Yes, unstructured. Every script is its own special snowflake that does things a bit differently.

There’s no guarantee of the verbs that the script implements. start, stop and restart are common, but the implementation is up to each individual script. I’m most familiar with Debian where some service (but not all) implemented it with start-stop-daemon, but other distros and OSes handled it differently.

Basic, commonly needed functionality, like restarting a crashed service after waiting for some delay, need to be implemented per app.

When sysvinit was widespread, there was a reason a lot of people used systems line supervisord to deploy services, rather than dealing with sysvinit scripts. It was a pain.

Systemd units were a logical progression from supervisord services.

Do you have any actual problems with systemd, or do you just want SysV init scripts to stick around forever?

Maybe systemd isn’t the best, but it’s way better than a bunch of mostly unstructured shell scripts, and more secure (it’s pretty easy to reduce privileges, sandbox the filesystem, restrict syscalls, etc per service just by editing the unit file)

I want more of these thanks.

I’ve been using Debian on servers for 20+ years, but ended up using Fedora on my desktop and laptop.

Debian is stable, meaning it doesn’t change often. Packages don’t get major version upgrades during the lifetime of a Debian release. That’s fantastic on servers, but can be annoying on clients since you don’t get the very latest drivers, the newest version of KDE, etc. Linux drivers move pretty quickly, especially for newer hardware.

You can run Debian testing, which is a more up-to-date development branch, but you need to make sure you pull security updates from unstable as the security team do not upload to testing. https://github.com/khimaros/debian-hybrid

If you’re new to Linux, then also consider Linux Mint Debian Edition.

The thing with drivers is that the hardware they’re written for doesn’t really change. A particular network card is always going to behave the same way. Once the driver works well, it’s pretty much complete, and the only changes that are needed are bug fixes, updates to handle new firmware, or adjustments if the kernel changes some implementation detail of how drivers are used. There could be months or years between updates to the driver.

Some manufacturers have great first-party Linux support. Intel is a good example - they contribute a lot of code to the kernel, and their drivers are maintained by employees.

A lot of Linux drivers are like this - just one or two people maintaining them. They usually eventually mainline the driver rather than having a separate Git repo though.