not-systemd status in Bullseye?

[Thorsten Glaser]

On Wed, 11 Mar 2020, Martin Steigerwald wrote:

> 1) It does not boot any slower than with Systemd. For me higher boot 
> speeds with Systemd are a myth.

I force sequential boot with sysvinit, so it’s a bit slower,
but much more reliable.

On the other hand, it shuts down very fast, as opposed to
systemd’s famous 90-second countdowns…

> I do use elogind with the libpam-elogind-compat package from 
> experimental. Removing it is not yet safe for me:

Ah, interesting. Could you do an “aptitude why” on it,
so we see precisely the packages in question, not all
depending on them?

>   gvfs* gvfs-backends* gvfs-daemons* k3b* k3b-extrathemes* k3b-i18n*
>   kde-plasma-desktop* kde-standard* kinfocenter*
>   libpam-elogind-compat* network-manager* network-manager-openvpn*
>   network-manager-vpnc* plasma-desktop* plasma-mediacenter* plasma-nm*
>   plasma-widgets-addons* plasma-workspace* plasma-workspace-wayland*
>   sddm-theme-breeze* udisks2*

This list surprises me, my laptop has kde-plasma-desktop
installed… perhaps I have one alternative dependency somewhere.

> So a third approach in addition to the two Mark mentioned could also be 
> to install Devuan and *then* back to Debian, cause then you already have 
> Sysvinit. However I am not sure whether someone ever tested that.

Even if, this requires one to trust Devuan in the first place, and
I’m not willing to extend the trust I have in Debian to them, plus
you’d likely need to apt-get inatall --reinstall everything anyway.
Also, Devuan people told me they were about more than just init, so
it’s likely this will pull in other/unsupported stuff or change more.

Switching to sysvinit from the installer is actually rather easy,
just Alt-F2 then “in-target apt-get -y install sysvinit-core”,
although do it rather late (I had one system install systemd back
after I did that). Undoing UsrMerge isn’t possible though there
exist hacks (patching debootstrap inside d-i also on Alt-F2) to
avoid it.

I *really* need to allocate time to create a custom build of d-i
again. One including mksh, ed and jupp (for sane editor) and extra
expert mode menu items for UsrMerge and init system. (Once finished
as PoC, I could even submit patches.) I’m also building them as
“monolith” image so they can be used standalone… currently still
using my d-i build from 2013, which always complains it can’t find
wheezy and requires me to manually add aptitude to succeed…

> And I made the experience that while being a much smaller team, they do 
> have an professional approach about things. It feels safe for me to run 
> the servers with it. They receive security updates (mostly from Debian) 

The problem is with how they’d almost certainly survive if Debian
were to ever completely remove sysvinit support. Also, even harm‐
less-seeming patches can have bad impact… remember OpenSSL?

> But enough of that, on this list it is about Debian:

Thanks. I’d prefer that.

> I am not sure about the long term perspective of alternate init systems 
> in Debian, especially after KAction / Dmitry who contributed a lot to 
> sysvinit and co left the project after the outcome of the GR which was 
> raised by Sam¹.
> 
> I still think this whole GR thing was harmful to Debian community, 

Agreed, it was unnecessary, hurried, and a loss-loss situation.

At least we now know where we stand :/

> I think it can work, as long as enough people put up with the work on 
> supporting other init systems in Debian, which includes dealing with 
> other developers who do not have that priority whenever required for 

The GR outcome that required them to cooperate when patches exist
(that are not otherwise bad), unfortunately, did not pass either ☹

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg