Richard Brown wrote:
The only choices that matter in opeSUSE are the choices which the openSUSE community bothers to put together.
First problem -- don't say it is the 'community' -- it's the "board" that makes the directions and allows those who wish to help that direction to work on creating the next distro. The community, OTOH, submitted compatibility patches for various things (before systemd) in the past that were rejected, since the board choice was to disable the choice that could have been supported w/the patch. That story has been played again and again.
If the openSUSE community worked together to support sysvinit as well as systemd, sure, I'd support that.
you might, but the board wouldn't.
But unlike GNOME + KDE, or vi + emacs, or Firefox + Chrome, supporting 2 init systems is a totally different situation
--- Not really -- unless they are not just limited to "init".
With your other examples, those alternatives co-exist happily with no effort from either 'side', worst case you need the two sides to get together and work on shared solutions every once in a while
Supporting two init systems requires a huge amount of work, ESPECIALLY when that other init system is sysvinit.
---- Not at all. The first reason it became "impossible" is that systemd refused to allow co-existence, and absorbed compatibility interfaces to disallow it working with other parts. Second major reason -- is systemd didn't develop an "init" system, then stop. It's has absorbed several - scores of other functions and is continuing to do so. So you can't have systemd handle "init" and then use something else to manage cgroups, power, your system log, login, system-console, mount, device management, cleaning-tmpfiles, etc, etc, etc. You can't just drop in systemd, and continue to use a BUNCH of things that are NOT sysVinit. Logging, mounting, udev -- they are all being rearchitected to merge w/systemd and won't function without it. That's the MAIN reason why choice was eliminated, as systemd provides all the choices -- it is one monolithic (yes, it is -- because the parts won't inter-connect with anything but systemd-parts) piece of SW that is designed to crowd out and extinguish any competing part that it has taken over.
EVERY SINGLE SERVICE will need to have a systemd unit file (normally easy) AND a sysvinit script (normally complicated as heck).
Laugh! LSI included a 39-line auto-converter to generate sysd-unit files on the fly, from existing scripts. It's automated in a 39-line shell script -- and you call that "complicated as heck"?
EVERY SINGLE MAINTAINER of EVERY SINGLE SERVICE will need to do extra work to continue to support sysvinit, and that work is typically harder than the support required to continue to support systemd
Turn that around -- They need do nothing to extra to support systemd (the sysVinit scripts were already written) -- just run the converter on the fly.
you only need to look at anti-systemd distributions to see that creating a maintaining a non-systemd distribution in this day and age is a huge amount of work
It's only because systemd has made it hard to do the opposite, because it's not just an init system. If developers only wrote startup-and shutdown scripts according to the LSB guidelines, then auto-generation of systemd unit files would be automatic and involve no work on their part.
Linux isn't about choice[sic].
It's not linux that isn't about choice, but systemd. linux was designed based on unix principles where parts interacted in well defined ways and parts were *interchangeable*. It's systemd that has broken that interchangeable parts paradigm and it's systemd that is working to change all of linux to be without choice, since choice threatens the large "status quo" corporations. MS would have required secure boot with Win10 to only allow MS-signed binaries to boot on all PC's, if it wasn't for the prevalence of alternatives. So what to do? Convert linux to another closed ecosystem that will only let corporate signed binaries run. Just like Anton complained about JavaScript programs written to run anywhere javascript runs, not running on google devices -- because it's not about js being "closed source", but the ecosystem being closed, with only google-allowed binaries to run. Similarly, systemd and linux will be used to create a closed "linux"[sic] ecosystem, and then the other close-OS providers will be able to compete and fully close their systems, as there will only be fringe distros/providers that provide open-OS's and they won't be able to run on the majority of HW platforms that will then be available. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org