Jonathan Frederickson silverskullpsu@gmail.com writes:
this one example underscores that "freedom" - having access to the source - is no longer the only factor, meaning that we are heavily and critically deependent on decisions made by distro maintainers.
Again, this has always been the case! Unless you're packaging things yourself, you're dependent on the distro maintainers (or sometimes the upstream developers) to package them for you, or you have to install them outside the package manager which carries its own set of risks.
The distro maintainers have to manage their (often limited and unpaid) time wisely. In Debian's case, choosing systemd as the init system means that package maintainers only have to write much shorter systemd service files instead of longer sysvinit-style startup scripts. As a developer, I can certainly understand that decision.
It's unfortunate that systemd is seen as necessary to get these shorter service files for service declaration. Or that sysvinit requires you to write long complicated init scripts.
Rather than replacing the init system, it would be possible to write a standalone tool to interpret service files that sysvinit can call.
This works because sysvinit and other early UNIX init systems are written as separate components, that interact by running other exectuables/commands. This is the opposite to how systemd is architected where it moves more functionality into the same executable, making it less flexible and extensible as a result.