Mailinglist Archive: opensuse (856 mails)

< Previous Next >
Re: [opensuse] Re: interesting reading about systemd
  • From: Knurpht - Gertjan Lettink <knurpht@xxxxxxxxxxxx>
  • Date: Fri, 07 Oct 2016 12:53:23 +0200
  • Message-id: <4592707.gmyu7efPaE@knurphtlaptop>
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 <suse@xxxxxxxxx>

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".

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups