not-systemd status in Bullseye?
Martin Steigerwald
martin at lichtvoll.de
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
More information about the Debian-init-diversity
mailing list