Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
init diversity in Debian
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
Sounds like our beloved Leader is keen for that not to happen:
The bit that caught my eye was this:
And he proposes a GR vote to formally decide on support for elogind.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.
The bit that caught my eye was this:
Does Devuan supply the missing init scripts for all of those packages?Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
deadbang
Re: init diversity in Debian
Like that worked so well last time. Well, it did for ass-covering and non-action. For those who are unaware of how the last GR went down, I present dasein's drill-down analysis:Head_on_a_Stick wrote:Sounds like our beloved Leader is keen for that not to happen:And he proposes a GR vote to formally decide on support for elogind.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.
http://forums.debian.net/viewtopic.php?f=20&t=120652
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:Head_on_a_Stick wrote:The bit that caught my eye was this:Does Devuan supply the missing init scripts for all of those packages?Sam Hartman wrote:There are 1033 non-overridden instances of lintian detecting a service unit without an init.d script [7].
https://git.devuan.org/devuan-packages?page=1
May the FORK be with you!
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
Might be worth considering then, quite a few important services are on the list.golinux wrote:No we don't.Head_on_a_Stick wrote:Does Devuan supply the missing init scripts for all of those packages?
deadbang
Re: init diversity in Debian
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.Head_on_a_Stick wrote:Might be worth considering then, quite a few important services are on the list.golinux wrote:No we don't.Head_on_a_Stick wrote:Does Devuan supply the missing init scripts for all of those packages?
May the FORK be with you!
Re: init diversity in Debian
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.
¹ 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
Buster amd64, Intel Xeon E3-1240 v3
Sid ppc, PowerPC 7447a
Sid ppc64, PowerPC 970FX
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
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.sjukfan wrote:Is the systemd unit file the best of them?
deadbang
Re: init diversity in Debian
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
https://wiki.gentoo.org/wiki/Elogind
Re: init diversity in Debian
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.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.
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
Unit files can be integrated into antique inits as shown above.So yes, systemd unit files are the best. IMO.
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
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.edbarx wrote:Unit files can be integrated into antique inits
deadbang
Re: init diversity in Debian
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.
===========================================
===========================================
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!
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
So the voting options are in: https://lists.debian.org/debian-devel-a ... 00002.html
My vote would be
Ian Jackson ftw!
Anybody else want to play?
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
Anybody else want to play?
deadbang
Re: init diversity in Debian
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!
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!
-
- Posts: 1939
- Joined: 2006-04-21 11:19
- Location: Sol Sector
- Has thanked: 1 time
- Been thanked: 2 times
Re: init diversity in Debian
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.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].
Phil
Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Re: init diversity in Debian
Looks like there may be a workaround from Jessie Smith: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
Nov 17 at 10:29am
Converting systemd units to init style shell scripts
May the FORK be with you!
- oswaldkelso
- df -h | grep > 20TiB
- Posts: 1490
- Joined: 2005-07-26 23:20
- Location: UK
- Has thanked: 1 time
- Been thanked: 58 times
Re: init diversity in Debian
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.
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.
My oldest used PC: 1999 imac 333Mhz 256MB PPC abandoned by Debian
Ash init durbatulûk, ash init gimbatul,
Ash init thrakatulûk agh burzum-ishi krimpatul.
My oldest used PC: 1999 imac 333Mhz 256MB PPC abandoned by Debian
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
The GR results are in: https://lists.debian.org/debian-devel/2 ... 00212.html
tl;dr: proposal B won.
Salient extract:
tl;dr: proposal B won.
Salient extract:
So it is now OK for developers to start enabling systemd-specific features that won't work with other init systems.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.
deadbang
Re: init diversity in Debian
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.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.
Does this not potentially pull the rug out from under Devuan going forward?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.
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: init diversity in Debian
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=3074Lysander wrote:Does this not potentially pull the rug out from under Devuan going forward?
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
deadbang