Debian Developers Take To Voting Over Init System Diversity

[phoronix_anon]

Docker-style containers do not use an init system in the traditional sense.

LXC-style containers are not different from a normal system.

Therefore, yes: whenever an init system is used at all, it should be systemd.

Isn't it needlessly costly to increase the size of containers by many megabytes when a simple init like init.d or supervisord provide identical functionality with smaller attack surface and footprint? Every byte should be audited in a container especially during development when pushing and pulling remote repos.

[tuxd3v]

Choice 1: F: Focus on systemd
Bye Init Freedom!

Next to that will be :
Choice 1:F Focus in Chome Browser
Bye Browsers Freedom

[intelfx]

Isn't it needlessly costly to increase the size of containers by many megabytes when a simple init like init.d or supervisord provide identical functionality with smaller attack surface and footprint? Every byte should be audited in a container especially during development when pushing and pulling remote repos.

You appear to be talking in slogans and catch-words, which is not a terribly productive way to lead a discussion.

Leaving aside nitpicks like neither init.d nor supervisord being actual inits, I will attempt to explain where you are wrong, again.

Docker-style containers do not use any of the traditional init systems at all (not systemd, not upstart, not sysvinit, not openrc, not runit nor anything else from the list that's up for discussion in Debian today). Most of the time, the application process itself is PID 1. Otherwise (in a very minor share of cases), if the application in container is badly written and can't be bothered to reap its own children, a stub init process like tini may be involved — nobody is talking about these.

LXC-style containers, on the other hand, are what you may call "thin VMs", complete with multiple processes running at once and everything else you expect from a GNU/Linux installation, requiring supervision, activation, logging and sometimes interactive control, so "a simple init like init.d or supervisord" won't be providing identical functionality. Anyways, the question of "which init to use in a full-fledged [Debian] GNU/Linux installation" has long been decided in favor of systemd.

So, no, there are no use-cases when "a simple init like init.d or supervisord" will suffice. In one case they are already several orders of magnitude too heavy, and in the other case they are not enough.

[tuxd3v]

There is no good reason to impose the cost of maintaining non-systemd init scripts on every Debian package maintainer, to satisfy a group of people who appear to have few or no valid practical concerns.

Can you please clarify that statement?

[tuxd3v]

So, no, there are no use-cases when "a simple init like init.d or supervisord" will suffice. In one case they are already several orders of magnitude too heavy, and in the other case they are not enough.

That should be why Debian, in a minimal install, takes lots of Ram compared with Devuan right?

[intelfx]

That should be why Debian, in a minimal install, takes lots of Ram compared with Devuan right?

I'm not using either distribution. But I doubt the accuracy of your statement.

[tuxd3v]

I'm not using either distribution. But I doubt the accuracy of your statement.

Like you see, having different opinions doesn't hurt.
Maybe diversity won't kill you too..
You should experiment.. and maybe you will find out that what somebody told you here on phoronix after all..is true.

[intelfx]

Like you see, having different opinions doesn't hurt.

In case I was too vague, that was an invitation to share a proof of your claim.

[tuxd3v]

In my Opinion Debian should advance the Idea of a Standard API to treat Services..
LSB Already have the LSB Headers, it could be not enough, maybe needs to be worked out.. but something Standard, and not deciding in favor of the Init A or the Init B..

Propose a standard API, the InitSystems around, should follow.
Debian users will win with that..

[tuxd3v]

In case I was too vague, that was an invitation to share a proof of your claim.

Why asking me to prove something to you...when you are the one not with sufficient certainty about what I said?

You can prove it yourself.. install both images and see.. its free software