Debian General Resolution: Init systems and systemd

Debian General Resolution: Init systems and systemd
Voting from 12/7 - 12/27!
<https://www.debian.org/vote/2019/vote_002>

My blog entry today
<https://jausoft.com/blog/2019/12/06/debian-general-resolution-init-systems-and-systemd-on-12-7-12-27/>

Just in case they vote on
"Choice 1: F: Focus on systemd",
i.e. completely disabling another init script,
I have to pick up a new distribution.

Today, I mostly run Debian on desktop and server.
Most server use a non-systemd init system for sanity.

Easing systemd dependencies via 'systemd-shim', 'libsystemd0'
and using 'sysvinit'.

Documentations of not using systemd are

- Debian: Installing without systemd
  <https://wiki.debian.org/systemd#Installing_without_systemd>
- Use Devuan (init freedom initiator, dunno status)
  <https://devuan.org/> and <https://devuan.org/os/init-freedom/>
- Linux distros without systemd (2019-05-20)
  <https://ungleich.ch/en-us/cms/blog/2019/05/20/linux-distros-without-systemd/>


IMHO the only good proposals are

- Choice 3: A: Support for multiple init systems is Important
- Choice 6: E: Support for multiple init systems is Required
- Choice 7: G: Support portability and multiple implementations

Problem is, the more lenient a policy is towards init abuse,
i.e. only supporting systemd and creating hard dependencies on it,
the less likely it is most packages will work w/o systemd
running nor installed.

Risk: Who controls systemd will control the Linux desktop.

An init system originally only handles process
initialization and management,
which was usually done in a few lines of code
and was always considered very security critical.

It is a long debate, but I get goose bumps when
an init system and its environment takes over
more than half of a Unix like system's services,
especially when the user land applications
start to make it a hard requirement.

I didn't keep too much track of systemd,
but after keyboard and console control,
networking, harddisk partitions and what not
- now they want full user identity control,
naming it 'Home Directories' or 'systemd-homed'

<https://github.com/systemd/systemd/blob/8be2ce8895bf457a7e0bef27c219824f3937a21a/docs/HOME_DIRECTORY.md>

This not only includes home partition setup
but also control of key management for encryption etc.

Is all the systemd work still coming solely from Red Hat giving us a single
service provider concentration risk, which other distributions intended to
avoid? Now being reintroduced and enforced via systemd?

Good evening and let's hope init choice
can be still be made in the future.

Cheers,

~Sven

Revised my opinion a little after a bit more reading ..
- Choice 3: A: Support for multiple init systems is Important (compromise 1)
- Choice 4: D: Support non-systemd systems, without blocking progress
(compromise 2)
- Choice 6: E: Support for multiple init systems is Required (ideal)

However, it is a very complex issue and important maybe
to understand the driving force w/o getting too much into
the field of conspiracy.
(Even though 2013-19 were the years of the proven conspiracies.)

Devuan’s take on the vote in a post, as Debian is essential for Devuan and all
other distributions based on it willing to provide a non-systemd system.
<https://www.dyne.org/devuan-cannot-exist-without-the-help-of-debian/>

In this sense, KUDOS to Debian and hopefully they can make the right
choice[tm] ;-)

~Sven

Hello

Personally, I call the SystemV scripts in the SystemD services and it works correctly. I did it for Jetty, I contributed, it has worked as expected for months. If Debian drops SystemV, you'll still be able to call your SystemV scripts but it will require some redesign.

All options that makes it possible to write a minimal init in java that for example populate /dev/ and enable GL hardware acceleration. Is good.

I totally understand that SystemD may give a lot of power to IBM that owns Red Hat, it doesn't reassure me. However, SystemD helps in configuring services that must work similarly on several distributions.

On 12/7/19 10:36 AM, gouessej [via jogamp] wrote:
> Hello
>
> Personally, I call the SystemV scripts in the SystemD services and it works
> correctly. I did it for Jetty, I contributed, it has worked as expected for
> months. If Debian drops SystemV, you'll still be able to call your SystemV
> scripts but it will require some redesign.

Disclaimer: My intention is to provoke a reasonable debate,
sometimes I might exxagerate a little bit.

As we say in Germany: Potatoes are not eaten as hot as they are cooked ;-)

+++

Julien, my point as laid out
<https://jausoft.com/blog/2019/12/06/debian-general-resolution-init-systems-and-systemd-on-12-7-12-27/>

is not so much about init scripts, but the overall control over the
whole free software ecosystem.

"Risk: Who controls systemd will control the Linux desktop."

"... especially when the user land applications
start to make it a hard requirement."

Yes, there are alternatives like Gentoo and FreeBSD.
But will they have the manpower to impact and survive?

Gentoo resurrected an independent udev via eudev
<https://wiki.gentoo.org/wiki/Eudev>,
i.e. removed hard requirements to udev.
Worse: udev merged into systemd and ended its existence
for non-systemd platforms - AFAIK.

Now imagine not only GTK but many other upstream
source projects claim systemd as a hard requirement
for dependency.
Majority will then move over to systemd only platforms
and other 'systems' outside of this GNU/Linux/Systemd'
bubble will cease to exist.

Yes, a bit dramatic, but that is the risk.

Why is Red Hat pushing for this change?
It's their cloud biz, stupid! ;-)

+++

Today we hear from the cloud protagonists
and hence cloud service provider that
micro-services, container and management
of the very same is the new cool thing to do.

A problem or functional block (some call it monolith)
is split into parts and deployed across the network.
Remembering such capabilities with Apache and Cocoon
(an early MVC XSLT web solution) as a great thing to
have - scaling your application and supporting good desgin
by separation and encapsulation.

However .. before doing so, you have to properly resolve
the design to achieve this networking capable design.
State-full or REST-less, it is not about just using
tools, Docker'em, Kubernet-fire and Ansible-forget,
it is about the old school
software architecture to achieve this excellence.

Modularization and having fully functional building blocks
allows you to scale your application across the network.

But keep in mind that adding containers and so forth
will again not lessen complexity but increase.
Know what you are doing.

BTW, a Java'ish runtime package is also a good
platform agnostic container ;-)

+++

So back to system dependencies, IMHO it is outrageous
to force a feature to the masses which only serves
the biz model of a few.

At least they should call it what it is, a brick in THEIR
wall to sell platforms for other companies micro services.

So when bringing in hard dependencies to the average
software package in the open source universe,
which potentially cuts off other systems (non-systemd, non-Linux),
it might have some costly impact, if not irreversible.

+++

Yes, the core functionality of systemd is desired and
great like OpenRC, initng, runit, monit, s6, daemontools, and Shepherd.

If systemd would keep it at that and also would embrace
other platforms (cgroup alternatives on FreeBSD etc),
one could thank Red Hat for doing so.
However, it seems the opposite is true.

They bash the old system design style, show more systemd appetite
to take over even more functionality of the system as systemd's
mission statement says and potentially leave others behind.

Red Hat's Daniel Riek also ran their show in this regard last weekend at
Fosdem: <https://fosdem.org/2020/schedule/event/riek_kubernetes/>

Surprised that some others start to differentiate
in a reasonable manner now.
See Kelsey Hightower (GOOG Cloud):
<https://changelog.com/posts/monoliths-are-the-future>

+++

Still running Debian on my machines one way (systemd)
or the other (systemd-shim).

As long the ecosystem survives, capable of compiling 'em for other systems,
we should be good and my many words here gladly 'just wasted'.

Having an eye on Gentoo, Alpine Linux and also FreeBSD.

Laters, Sven