I'll keep on repeating these mantras:
openSUSE is you, me, all of us.
This means including the members of the board.
Who are as much "community" as any other person involved in or using (parts
of) the openSUSE project.
Hence there is no "community vs. board"
In other words: there can be no "team vs. it's members". (dot)
Gertjan Lettink, a.k.a. Knurpht
openSUSE Board Member
openSUSE Forums Team
Op donderdag 6 oktober 2016 14:37:22 CEST schreef Linda Walsh
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.
I won't accept this statement as an accurate representation of reality.
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.
Nor this statement.
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".
Start giving it a try,
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.
That's an explicit and very serious accusation of the developpers of systemd. Please reread and think again.
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"?
Reread what's been called "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
and simultaniously check which of the anti-systemd distros of the past now happily use it ....
---- 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.
Well, you've made your point, you don't like systemd, and you're still frustrated about the fact that systemd became the de facto standard. And you're convinced sysVinit is a better future. Now what? What a project basically needs is people who step up and do the job. Like the ones that wanted KDE3 to stay and started the Trinity project.... -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org