Debian Adds Another Option For Its Init System Diversity General Resolution

[phoronix]

Phoronix: Debian Adds Another Option For Its Init System Diversity General Resolution

A few days ago Debian Project Leader Sam Hartman laid out the proposals for the upcoming Debian General Resolution vote concerning "init system diversity" and just how much Debian developers still care in 2019 about supporting non-systemd init systems within the Linux distribution...

http://www.phoronix.com/scan.php?page=news_item&px=Debian-GR-New-Systemd-Option

[Ananace]

This sounds like a very reasonable option, and it's nice that it clearly defines exactly what is expected of the maintainers to do in order to support script-based inits.

It's nice to hear that Debian is planning on embracing more declarative-style configuration too, not just for service management. In my experience as one of the three Linux sysadmins currently handling ~600 servers, having to use/create/maintain scripts to do system management tasks can be such a minefield when you have to support multiple different distros each with their own nuances.
The declarative nature of unit files makes it so much easier to know what is needed and what is to happen - and to ensure that said facts correctly occur on each system, as well as being easier to handle with templates and config-generation. And the drop-in design that systemd went with makes it even nicer in the case of services, as I - as a sysadmin - can now just drop a few INI lines into a file that is guaranteed to be under my control, in order to do all the environment-specific modifications that the systems that I maintain require.

[Awesomeness]

Why don't they just write a tool that loads systemd .service files on systems that aren't compatible with systemd?

[Djhg2000]

While the proposal in general is reasonable, I can't help but think the last sentence of point 11 goes too far. This is about init systems, the enforcement of behavioral guidelines in forums is better discussed separately.

[Ipkh]

Proposal D has to have that bit about community guidelines. The discussion has been much too toxic as of late. Systemd is the current init system recommended by the Technical Committee. It is the default for new installs. So, support is needed and alternatives by proxy get short shrift. Allowing non- maintainers to add support is good and relieves some of the burden on the maintainer and will probably lead to better systemd support as well.

As an end user, it is better for debian and other distros to support a standard way if doing things and for better or worse systemd is taking that on.

[9Strike]

I just read through all of the proposals and except of A all sound good to me. I don't even think C sounds too bad for non-systend users, since "Debian is committed to working with derivatives that make different choices about init systems", which basically is what's happening right now anyway. Honestly most new desktop programs which have background tasks rely on systemd, because it's so easy and comprehensive. In a way kinda "universal", that's what Debian tries to be. Sure there are edge cases where systemd is " over-the-top", like IoT-devices or servers with just one never-changing purpose, but would they use Debian in the first place?

[pal666]

is it same ian jackson who had meltdown when he failed to block systemd in debian?

[skeevy420]

Well that just seems like a clusterfuck. Pick one and stick with it.

Why don't they just write a tool that loads systemd .service files on systems that aren't compatible with systemd?

When all the init systems and distributions have their own in-house tool to read init stuff from other init systems because it'll have to work both ways -- systemd has to load OpenRC and sysvinit scripts and Epoch configs just as much as runit, Epoch, and Shepard need to load sysvinit and systemd units so we're gonna need a tool to convert various config file formats that point to scripts, shell scripts themselves, config files themselves, and more all into each other so it's asinine to think that multiple people/distributions/corporations/etc won't all try to solve that problem differently in manners that may or may not be universal to all init systems.

Because this is the end result of that:



where instead of bickering over init systems, we'll bicker over init systems and init converters. Yay. Just what I wanted. More reasons for bickering on Phoronix

[Baguy]

I like this! Debian with Runit would be nice.

[Terrablit]

is it same ian jackson who had meltdown when he failed to block systemd in debian?

Glad I'm not the only one that spotted that. Last time around (about 5 years ago) he tried to hijack the process to get his way and then flipped out when it didn't work. IIRC, he proposal bombed everyone several times and often tried to rush them through with immediate calls for votes on his proposals. Also I think he did some dodgies in the wording trying to leave openings in opposing options for what he want. It's been a while and it was stupid enough I don't care to reread it for maximum accuracy.

Hopefully this time around he's learned a bit of chill. Still, I'd double-review anything he adds to make sure it's actually different enough to deserve its own option instead of just being vote-diluting bike-shedding soul-sucking minutia.

The 2nd worst part of that whole shitshow (after its very existence) was Russ Allbery's resignation from the TC. We lost a kind, level-headed committee voice because some people couldn't work together.