Mailinglist Archive: opensuse (856 mails)

< Previous Next >
[opensuse] Re: interesting reading about systemd
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread