Debian Adds Another Option For Its Init System Diversity General Resolution

[Britoid]

How about I continue perfectly fine on OpenRC without that steaming pile of crap from Lennart... I even bothered to figure out all my issues with pulseaudio so I wouldn't have to run it to get sournd with firefox, asound for instance acutally works if you poke all the right bits, my system is *Lennart Free*™

that's fine, but people who do this can't expect companies (like Firefox) to bend over backwards to support uncommon setups.

[oleid]

When all the init systems and distributions have their own in-house tool to read init stuff from other init systems because [...]

The thing is: systemd's service files are descriptive - as in: It's an ini file and one should be able to generate a bash init script from it just fine. The other way around is a lot harder (if possible at all).

EDIT:

By conversion from init script to ini-file, I don't mean calling the init script, of course. I mean creating an idiomatic ini file.

[Britoid]

The thing is: systemd's service files are descriptive - as in: It's an ini file and one should be able to generate a bash init script from it just fine. The other way around is a lot harder (if possible at all).

EDIT:

By conversion from init script to ini-file, I don't mean calling the init script, of course. I mean creating an idiomatic ini file.

I remember seeing a project on Reddit that converts systemd unit files to LSB init scripts, of course it could only do a fraction of the functionality references in the unit file.

[Terrablit]

Well wouldn't you do everything you could to stop some crap for brains from your main competitor (RedHat) from taking over large aspects of how your distro functions?

No, I wouldn't. Not ever. I'd leave first. And I'd expect the same out of any functional adult.

If I worked in a democratically-governed FOSS project, I wouldn't try to sabotage that project based on a conflict of interest (like Ian who worked at Ubuntu and wanted Upstart to win). That's quite an asshole thing to do. I actually found a reddit thread from when all the drama was happening (found on page 2 by searching for "ian jackson debian multiple propsals hijack" on DDG. Or page 3 if you fix the spelling issue). I shrunk it down to the relevant context. Ian was massively out of control. He was the goddamn Mitch McConnell of Debian back then. He even tried to force the Chairman to resign when people caught onto his tricks.

I have zero respect for him in a position of authority because of all of this. And I have little patience for all the whiners claiming that systemd got "shoved down their throats" when the most democratic process in all of Linux-dom voted in favor of it. If anything, it was the detractors that refused to respect the process. All those "veteran sysadmins" did little more than brag about how smart they were and patronize the people who didn't agree with all their "well ackchyually" nonsense in the mailing lists.

I can believe in a process or a group of people. I can believe that one solution has more technical merit than another. And I can believe that a group of intelligent people can be misinformed. It could even be me. But I can't believe in sabotaging a system designed to ensure that a project represents the interests of its members just because I don't like the results I get from following that system. And I certainly don't believe in claiming conspiracies or malfeasance when my choice isn't as popular as I thought it would be.

As has been mentioned before, democracy isn't just about putting the system in place, but also about respecting the results of that decision.

Also, given that Red Hat has consistently been one of the largest contributors to the Linux kernel and userspace for over a decade, I'd have to be a massive idiot to rage quit every time they contributed something. It already "controls large aspects" of every distro just by funding linux development. A significant percentage of contributors work or have worked at Red Hat. Those contributions still go through a review process. Not everyone agrees with it, and they don't always get their way, but they don't contribute in bad faith. They make what they want and share it. Scaling that out is how Linux works.

[Delgarde]

I remember seeing a project on Reddit that converts systemd unit files to LSB init scripts, of course it could only do a fraction of the functionality references in the unit file.

That's the problem with the idea, yeah... it only works with the lowest common denominator. If the only thing your systemd unit does is start and stop processes, it'll probably work. But if it's doing anything even remotely complicated, you're going to end up with lots of special cases... e.g. anything doing socket activation won't work that as an init script, etc.

[skeevy420]

The thing is: systemd's service files are descriptive - as in: It's an ini file and one should be able to generate a bash init script from it just fine. The other way around is a lot harder (if possible at all).

EDIT:

By conversion from init script to ini-file, I don't mean calling the init script, of course. I mean creating an idiomatic ini file.

I don't really have anything to add that Britoid & Delgarde didn't already say other than "to systemd" should be easier than "from systemd" since the "to systemd" part is mainly init scripts that need to be ran in the right order.

I still think it's a cluserfuck and a bad idea. init systems and package managers, IMHO, are the two main reasons for forks and new distributions to exist due to how inherently exclusive they are to themselves.

Just think about it like this -- damn near 30 years of distributions and there still isn't a tool to convert RPMs to Debs, PKGBUILDs, ebuilds, etc that's all in one and covers all major formats. Init system conversion will likely be the same since the "to systmed" will be relatively trivial compared to everything else....like how RPM to Deb is relatively trivial compared to RPM to PKGBUILD or ebuild since ebuilds are source based files and PKGBUILDs contain the -dev packages.

[Delgarde]

I don't really have anything to add that Britoid & Delgarde didn't already say other than "to systemd" should be easier than "from systemd" since the "to systemd" part is mainly init scripts that need to be ran in the right order.

No, because the init scripts are _scripts_, making them difficult to automatically convert. That's the point of the systemd unit files — they're not freeform programs that can do anything the author wanted them to do, they're standardised configuration files that enforce that things are done in a consistent manner. And there are tradeoffs to that, of course, since you lose some flexibility... but flexibility doesn't come for free either.

[ermo]

How about I continue perfectly fine on OpenRC without that steaming pile of crap from Lennart... I even bothered to figure out all my issues with pulseaudio so I wouldn't have to run it to get sournd with firefox, asound for instance acutally works if you poke all the right bits, my system is *Lennart Free*™

Also RedHat hasn't been the company it was in a long time, and is now a subsidary of IBM... so yeah maybe you should educate *yourself*

Let me try to show you why the above is perhaps not the best way to make your point by deconstructing your argument:

"How about I continue perfectly fine on runit without that steaming pile of OpenRC crap from Gentoo/Roy Marples/William Hubbs ... I even bothered to figure out all my issues with pulseaudio. My system is *Gentoo/Roy Marples/William Hubbs Free*™

Also Google hasn't been the company it was in a long time, and is now a subsidiary of Alphabet Inc... so yeah, maybe you should educate *yourself*"

Now, if you had made your argument based on technical merits instead, offering particularly useful features that work on OpenRC and which have no equivalent in e.g. systemd or even just showing off a particularly well implemented and useful feature of OpenRC, and if you had refrained from taking potshots at RedHat and a single person in their employ, it might have been possible to engage in constructive discussion with you.

As it stands, your post just comes off as the opinionated rantings* of someone who is way too emotionally invested in their software choices and software authors.

*: You're obviously free to offer your opinions -- this *is* a discussion forum after all.

Also note that systemd existing doesn't preclude you from tinkering with whatever distro it is you are running and upstreaming patches to make things work well with said distro and its preferred service management software.

FWIW, I have no dog in the fight. I care about having a single, de facto standard for managing Linux systems which ISVs and upstream projects can target and rely on. At this time, that target happens to be systemd. That doesn't mean I can't enjoy "init system diversity" and play around with other ideas of course. And I'm specifically not suggesting that anyone who doesn't appreciate systemd's qualities must be deluded. After all, systemd exists in addition to (not to the exclusion of) all the other init/service-management solutions on various platforms.

Have a lovely day.

[skeevy420]

No, because the init scripts are _scripts_, making them difficult to automatically convert. That's the point of the systemd unit files — they're not freeform programs that can do anything the author wanted them to do, they're standardised configuration files that enforce that things are done in a consistent manner. And there are tradeoffs to that, of course, since you lose some flexibility... but flexibility doesn't come for free either.

I just meant the more simplistic init scripts, like what Android and OpenRC use, are trivial enough since most of them can be dumbloaded via something like "EXECSTART=sh /some/dir/*" or via a script that does the same thing (which shouldn't be too hard to get in the correct order since most are named in order of how they're loaded with 00_start and 99_end and crap like that).

Now, the starting and stopping of daemons...stuff more difficult than echoing a value somewhere like I'm remembering with the stuff I mention above...yeah, that'll be the "fun" part and why this is a noble, yet stupid, idea.

If I were them, I'd go here and make a Debian fork for every single init system Gentoo supports for the Debian 11 release cycle, use Debian 11 & 12's Testing to merge them all together, and have them all merged and back to normal w/o forks by Debian 13....get them working separately before trying to get them to work all together. I'm genuinely surprised that no mainstream distributions hasn't gone that route yet.

[Britoid]

I don't really have anything to add that Britoid & Delgarde didn't already say other than "to systemd" should be easier than "from systemd" since the "to systemd" part is mainly init scripts that need to be ran in the right order.

I still think it's a cluserfuck and a bad idea. init systems and package managers, IMHO, are the two main reasons for forks and new distributions to exist due to how inherently exclusive they are to themselves.

Just think about it like this -- damn near 30 years of distributions and there still isn't a tool to convert RPMs to Debs, PKGBUILDs, ebuilds, etc that's all in one and covers all major formats. Init system conversion will likely be the same since the "to systmed" will be relatively trivial compared to everything else....like how RPM to Deb is relatively trivial compared to RPM to PKGBUILD or ebuild since ebuilds are source based files and PKGBUILDs contain the -dev packages.

I thought most distros were forked these days because someone didn't like another distros theme or desktop configuration?

It's a bad idea to convert RPMs to debs and vice versa, RPMs also support a large amount of functionality not present in debs. You've also got different package names, file locations etc.