not-systemd status in Bullseye?

Wed Mar 11 09:18:42 GMT 2020

Hi Matthew,

this is a bit longer but I wanted to give you my complete perspective 
about that.

Matthew Vernon - 10.03.20, 21:42:57 CET:
> Is the expectation that sysvinit will plausibly work in Bullseye? I
> see elogind and libpam-elogind are in bullseye, but
> libpam-elogind-compat is still only in experimental.

It works remarkably well on this Debian Sid installation. I even 
consider to switch the system to runit-init but I like to try this out 
in a VM first whether it generally works and uses init scripts where no 
runit service definitions exist. One reason I like to switch is that 
thinkfan does not seem to be completely reliable and after a reboot the 
process is not there and something it disappears during running the 
machine as well… runit would restart it.

What I found with Sysvinit:

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

2) A lot of strange behaviors simply have gone since the switch. The 
only thing I had sometimes is that the system did not properly shut 
down, standing on TTY1 after stopping the GUI without me be able to do 
anything about it.

3) Even the PolicyKit stuff has been fixed. I am able to change SDDM 
configuration from Plasma's Systemsettings meanwhile.

So yes, it works remarkably well. And that it just due to the fine work 
people have done! Thank you!

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

% LANG=en apt purge libpam-elogind-compat
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  bluedevil drkonqi gvfs-common gvfs-libs libblockdev2
  libcolorcorrect5 libibus-1.0-5 libk3b7 libk3b7-extracodecs libndp0
  libnotificationmanager1 libopenconnect5 libtaskmanager6abi1
  libteamdctl0 libudisks2-0 qml-module-org-kde-solid
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  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*
0 upgraded, 0 newly installed, 21 to remove and 79 not upgraded.
After this operation, 84.3 MB disk space will be freed.
Do you want to continue? [Y/n]

Yeah, I do use Network Manager, since that is nicely integrated in KDE 
Plasma and… meanwhile usually works well enough. I considered switching 
to wicd tough as I am still not completely happy about it.

Aside from that not much seems to be affected by the dependency issue the 
compat package fixes.

> I have a fresh bullseye system that has systemd on (because no option
> in the installer), which runs fvwm and lightdm, but I'm not sure how
> likely a move to sysvinit is to work - AFAICS, systemd prerm will
> refuse to run if systemd is init, making switching hard...

Yeah… it was a hassle on another system that I switched to Devuan Ceres 
(aka unstable) or was it Beowulf (aka testing) completely – it asked to 
remove all of KDE Plasma…  AFAIK it was due to the issue that in the end 
Sam Hartman started the GR about. But I see Mark has detailed about 
that.

> Any suggestions / pointers / help, please?

> I think it'd be worth asking the installer folk to add an init system
> choice (even if only in expert mode); but even given that, It'd be
> nice to switch my system without total chaos...

Sure. It would be nice.

For me it is one of the reasons why I switched all but one system to 
Devuan… cause there it is offered in the installer as a choice (in expert 
mode, otherwise it just uses sysvinit, but that may have been changed 
and it may be there even in non expert mode). So there is prior work to 
base this on. I have one of my servers running with just sysvinit still 
and another one runs OpenRC, although I did not really dig into it all 
that much. I am very interested in runit.

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.

Another reason is when something does not work regarding init system I 
have a higher chance this is treated as a serious issue, cause that is 
the whole point of Devuan after all.

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) 
and all that.

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

This laptop is still Debian, cause I still maintain two packages in 
Debian. But after a mail exchange with Sam after the conclusion of the 
GR I felt like leaving Debian behind me altogether. Cause after that 
mail exchange I did not feel welcome in the Debian project anymore.

OTOH I still did not decide on it, cause… I do have some bonds with 
Debian people and I like to continue work with Qt/KDE debian team from 
time to time… and… as Devuan is basically Debian with quite few changes 
here and there, it would make sense to do the package maintenance work, 
at least for packages Devuan developers do not change, with Debian. I 
may just go on maintaining the packages but not subscribe to debian-
devel mailing list again to avoid the toxicity I experienced there. It 
is sad to write, but Debian for me is a happier place if I avoid certain 
mailing lists.

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, 
deepening the split, instead of healing it. But I have spoken out 
clearly and publicly about it. I am not a Debian developer I just 
maintain some packages, so I feel that has been all that I could do 
about it.

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 
integration issues. But it has not been easy, especially for Mark about 
the elogind thing. I admire your patience and endurance with this, Mark!

I do not feel in a position to put up with that at the moment but I am 
very grateful for anyone who does! Also cause without that work, this 
laptop would not run Debian anymore.

So kudos to all who are still into init freedom in Debian¹!

[1] I do not agree with all the writes, but I certainly understand why 
he left:

https://kaction.cc/posts/2019-12-28_tragedy_in_debian.html

[2] I like that wording that I found on Devuan homepage, I prefer it 
over init diversity:

https://devuan.org/os/init-freedom

Ciao,
-- 
Martin