init diversity in Debian

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

init diversity in Debian

#1 Post by golinux »

May the FORK be with you!

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#2 Post by Head_on_a_Stick »

Sounds like our beloved Leader is keen for that not to happen:
Sam Hartman wrote:I'm concerned that removing Elogind commits us to Systemd-based solutions with a very high cost to try new things or change direction. For me that's a step we should be very careful before taking.
And he proposes a GR vote to formally decide on support for elogind.

The bit that caught my eye was this:
Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
Does Devuan supply the missing init scripts for all of those packages?
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: init diversity in Debian

#3 Post by golinux »

Head_on_a_Stick wrote:Sounds like our beloved Leader is keen for that not to happen:
Sam Hartman wrote:I'm concerned that removing Elogind commits us to Systemd-based solutions with a very high cost to try new things or change direction. For me that's a step we should be very careful before taking.
And he proposes a GR vote to formally decide on support for elogind.
Like that worked so well last time. Well, it did for ass-covering and non-action. :lol: For those who are unaware of how the last GR went down, I present dasein's drill-down analysis:
http://forums.debian.net/viewtopic.php?f=20&t=120652
Head_on_a_Stick wrote:The bit that caught my eye was this:
Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
Does Devuan supply the missing init scripts for all of those packages?
No we don't. And I can't remember any discussion about a problem from the lack thereof. Either those packages aren't being used or those using them know how to create the missing bit. Here are the packages that we touch . . . a little less than 200:
https://git.devuan.org/devuan-packages?page=1
May the FORK be with you!

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#4 Post by Head_on_a_Stick »

golinux wrote:
Head_on_a_Stick wrote:Does Devuan supply the missing init scripts for all of those packages?
No we don't.
Might be worth considering then, quite a few important services are on the list.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: init diversity in Debian

#5 Post by golinux »

Head_on_a_Stick wrote:
golinux wrote:
Head_on_a_Stick wrote:Does Devuan supply the missing init scripts for all of those packages?
No we don't.
Might be worth considering then, quite a few important services are on the list.
If someone squawks, we'll have a look. We really don't need to do extra work if no one is experiencing an issue. Unless, you are offering to take on that project. And btw, if the GR decision been other than ass-covering, that issue wouldn't exist.
May the FORK be with you!

User avatar
sjukfan
Posts: 387
Joined: 2010-03-01 19:39

Re: init diversity in Debian

#6 Post by sjukfan »

Someone¹ should make a systemd unit file runtime, so sysV, openRC, and all those, could run unit files. Is the systemd unit file the best of them? Probably not, but there would be a whole lot less work everyone. (Except that someone ^^)

¹ With more programming experience than I.
Bullseye amd64, AMD Ryzen 5 3600
Buster amd64, Intel Xeon E3-1240 v3
Sid ppc, PowerPC 7447a
Sid ppc64, PowerPC 970FX

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#7 Post by Head_on_a_Stick »

sjukfan wrote:Is the systemd unit file the best of them?
The unit files are declarative in nature (inspired by INI files) so they just list configuration options and leave the heavy lifting to the (C-based) backend. For the alternative init systems shell scripts are used instead and these require more skill to create than a unit file and are consequently more likely to be buggy. So yes, systemd unit files are the best. IMO.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

vmclark
Posts: 184
Joined: 2008-07-30 15:16

Re: init diversity in Debian

#8 Post by vmclark »

Sometimes its hard to separate wheat from chaff. The articles are endless regarding systemd and mostly SysV. It appears they just want to go backwards without regard to current modern systems. Elogind is something I haven't heard of until now. The voices are loud regarding the init systems, but this read from Gentoo-Elogind explains some facts I wasn't aware of:
https://wiki.gentoo.org/wiki/Elogind

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: init diversity in Debian

#9 Post by edbarx »

Head_on_a_Stick wrote:For the alternative init systems shell scripts are used instead and these require more skill to create than a unit file and are consequently more likely to be buggy.
Shell scripts can still be replaced, provided a script or executable does their job. When I was still coding for Devuan, I made this suggestion, but it was thrown out of the window.

Any init that uses shell scripts to run daemons can be modified to run them using an alternative configuration format like unit files. The counter argumentation against my proposal, and here, I am being very polite, was the exaggeration that this would require a mammoth task.

Shell scripts can be kept where they exist, and unit files can be used simultaneously, if an init provides a way to do so. This can be easily done by a single shell script which runs a daemon, which in turn, handles unit files and shell scripts.

So, this would be like this:

Code: Select all

sysvinit/antique init => shell scipt => daemon initialisation process (starts 1 & 2)
1) sysvinit shell scripts
2) unit file execution
Essentially, Devuan's criticism was my suggestions are too generic. Like a group of primary school pupils they asked for hands-on experience, before looking at things from an abstract point for view.

So yes, systemd unit files are the best. IMO.
Unit files can be integrated into antique inits as shown above.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#10 Post by Head_on_a_Stick »

edbarx wrote:Unit files can be integrated into antique inits
Only if stripped of the extra features offered by systemd. And anyway why would you want to start units with bash rather than C? Seems like a peculiar choice to me.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: init diversity in Debian

#11 Post by golinux »

This from Jessie Smith the maintainer of sysvinit. Perhaps co-existence is possible:

===========================================

https://www.patreon.com/posts/31633933

Nov 17 at 10:29am
Converting systemd units to init style shell scripts

In the past I have hinted at the idea of including a tool (or tools) which would help packagers and developers convert systemd unit files into SysV init style shell scripts with LSB headers. While I was working on a C library for this, another developer (who goes by the name Trek) beat me to it.

Trek sent over a Bash shell script which accepts a systemd unit file as its sole parameter. It then digests the unit file and prints out an equivalent shell script and some debugging information. The shell script is called sysd2v.sh and is now included in the SysV init source code, under the "contrib" directory.

Now converting a unit file into a complete shell script is as easy as running a command like "sysd2v.sh /lib/systemd/system/ssh.service" to translate the OpenSSH service into a shell script.

While the conversion script is now part of the SysV init source archive, Trek has kindly made sysd2v.sh available as a stand-alone script on his website: http://www.trek.eu.org/devel/sysd2v/

Thank you, Trek. The new conversion script will be in the next stable release of SysV init, which will carry the version number 2.97.

===========================================
May the FORK be with you!

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#12 Post by Head_on_a_Stick »

So the voting options are in: https://lists.debian.org/debian-devel-a ... 00002.html

My vote would be

Code: Select all

[   ] Choice 1: F: Focus on systemd
[   ] Choice 2: B: Systemd but we support exploring alternatives
[   ] Choice 3: A: Support for multiple init systems is Important
[ 1 ] Choice 4: D: Support non-systemd systems, without blocking progress
[   ] Choice 5: H: Support portability, without blocking progress
[   ] Choice 6: E: Support for multiple init systems is Required
[   ] Choice 7: G: Support portability and multiple implementations
[   ] Choice 8: Further Discussion
Ian Jackson ftw! :)

Anybody else want to play?
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

User avatar
Danielsan
Posts: 637
Joined: 2010-10-10 22:36

Re: init diversity in Debian

#13 Post by Danielsan »

From my ignorance I see these discrepancies:

All the systemd alternatives, older and newer, are basically simple programs where services are managed by scripts, and the complexity are left to the scripts. And that makes a lot sense for me, I mean I think it should be easier maintain a script rather than a complex software.

Systemd is the opposite paradigm, is a complicated and monolithic programs with an easy way to manage services. It is easy to manage for anyone even without a proper background but it needs a dedicated team to work and to maintain it. And to lead the future development you will need a person that really know well how it works, I don't think that is really strategic when you have to depend by someone else.

What we would need is a compromise, compatible with systemd unit, but desktop oriented; server stuff can continues to be handled by systemd and the majority is happy with it!

pcalvert
Posts: 1924
Joined: 2006-04-21 11:19
Location: Sol Sector

Re: init diversity in Debian

#14 Post by pcalvert »

Head_on_a_Stick wrote: The bit that caught my eye was this:
Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
Here's a thought that just came to mind: Did any of those packages exist in Debian Wheezy and, if they did, did they come with an init.d script? If so, perhaps those init.d scripts could be used as is, or with some modifications.

Phil
“It is better to believe than to disbelieve; in doing so, it brings
everything into the realm of possibility.” — Albert Einstein

User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: init diversity in Debian

#15 Post by golinux »

pcalvert wrote:Here's a thought that just came to mind: Did any of those packages exist in Debian Wheezy and, if they did, did they come with an init.d script? If so, perhaps those init.d scripts could be used as is, or with some modifications.

Phil
Looks like there may be a workaround from Jessie Smith:
Nov 17 at 10:29am
Converting systemd units to init style shell scripts
May the FORK be with you!

User avatar
oswaldkelso
Posts: 1306
Joined: 2005-07-26 23:20
Location: UK
Been thanked: 1 time

Re: init diversity in Debian

#16 Post by oswaldkelso »

to follow on from here and this thread seems the most encompassing to me
http://forums.debian.net/viewtopic.php? ... 15#p712687

Everyone needs to take a chill pill step back, look at the history on this board and learn from it. imho those threads should not have been merged and I take some responsibility for not saying so when I thought it. I got sidetracked https://hooktube.com/watch?v=cEqoqIr0DVE and forgot :-)

There are several reasons and the merging of those threads demonstrate them well. Just look at the names of all those ex Debian users that left because of the systemd debacle. People that loved Debian and felt forced out. Feelings were high at the time and the was no chance of reconciliation. Now things have cooled a lot and with the work of some Debian devs and the likes of Devuan that chance of reconciliation could return.

It would be great if Debian took a look at Gentoo & Funtoo and Parabola that are actively working to give their users init choice. Debian could reclaim the title of the universal operating system again.
Free Software Matters
Ash init durbatulûk, ash init gimbatul,
Ash init thrakatulûk agh burzum-ishi krimpatul.

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#17 Post by Head_on_a_Stick »

The GR results are in: https://lists.debian.org/debian-devel/2 ... 00212.html

tl;dr: proposal B won.

Salient extract:
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
So it is now OK for developers to start enabling systemd-specific features that won't work with other init systems.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

User avatar
Lysander
Posts: 627
Joined: 2017-02-23 10:07
Location: London

Re: init diversity in Debian

#18 Post by Lysander »

oswaldkelso wrote:Just look at the names of all those ex Debian users that left because of the systemd debacle. People that loved Debian and felt forced out. Feelings were high at the time and the was no chance of reconciliation. Now things have cooled a lot and with the work of some Debian devs and the likes of Devuan that chance of reconciliation could return.
Really I think it's about acceptance. I left Debian because of systemd and wanting to explore other OSs, however, now I'm back with Debian on my main machine. Familiarity is important and I don't want to learn any other OS apart from Debian/Slackware. I have accepted Debian's choice, I don't like it much, but I'm willing to work with it for now.
Head_on_a_Stick wrote:The GR results are in: https://lists.debian.org/debian-devel/2 ... 00212.html
...
So it is now OK for developers to start enabling systemd-specific features that won't work with other init systems.
Does this not potentially pull the rug out from under Devuan going forward?

User avatar
Head_on_a_Stick
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: init diversity in Debian

#19 Post by Head_on_a_Stick »

Lysander wrote:Does this not potentially pull the rug out from under Devuan going forward?
That depends on how Devuan are faring for resources, they have a thread about the GR on their forums: https://dev1galaxy.org/viewtopic.php?id=3074

And this one's just started: Debian has fallen — pretty clear which way Yeti thinks the wind is blowing...

Discussion over at the MX forums as well: https://forum.mxlinux.org/viewtopic.php?f=6&t=54135
Black Lives Matter

Debian buster-backports ISO image: for new hardware support

User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: init diversity in Debian

#20 Post by golinux »

So missing Dasein's wisdom that would have put this into proper perspective.

(golinux sheds a virtual tear . . .)
May the FORK be with you!

Post Reply