Debian Developers Decide On Init System Diversity: "Proposal B" Wins

[oiaohm]

And with the advent of that change most maintainers involved in systemd-based distributions have lost the skill and ability to debug shell scripts.

The ablity to debug shell scripts was long gone from maintainers well before systemd. http://www.linuxfromscratch.org/lfs/...ts/apds02.html You are ignoring the existence of /lib/lsb/init-functions

So init scripts have not been written in plain old shell script for over 20 years now. Instead you have basically every init script in sysvinit, openrc and upstart calling /lib/lsb/init-functions or it past name results in all those functions in there shoved into the environmental variable storage that bleeds across when services are started so meaning you are not memory effective. Of course the init script is writing in mostly LSB function calls so the person who writes the init script really does not understand how to debug shell script at all.

Basically its not most maintainers involved in systemd-based distributions don't know how to debug shell scripts. The reality is most maintainers is all distributions no matter the init system they use don't really know how to debug shell scripts. Systemd distributions are not a special case.

Shell script has been a horrible round peg square hole for service management patched over by even more shell script that still don't fix that its a round peg in a square hole instead add even more creative ways to screw it up silently

Even if you look at the bsd init solution you will see another include this file to provide basic functionality so you don't have to know how to debug shell script. So this lack of maintainer knowledge to debug shell scripts even extends to your BSD based distributions.

So the idea that init scripts run by shell script means maintainers understand shell scripts is a totally bogus idea. The one who write the assist shell script knows shell script the remainder are lambs following the flock and hoping it works. This is why systemd doing this stuff in C I don't see a large problem with this way it does not leak into the environmental space and the other maintainers really did not have the skill to work on the master part anyhow in most cases.

[starshipeleven]

I agree with the comments about computers that could be bought back in the late 1980s and 1990s. You got books of documentation, sometimes just 1 and sometimes a few. Those books were very informative, and some still are. Nowadays the older young ones look at books and ask, "Where do I put the batteries?" while the younger young ones ask, "Where do I plug in the charger? And where is the charger?"

Why people post this "ye olde times" bs?

The people that needed manuals back then still need them now, it's just that now these people are now called "IT guy" or "power users" while back then they were the whole userbase.

The pressure to drop a manual and make "intuitive" interfaces to replace them was to expand the userbase to mass market where most people won't want to read a manual to program a PC to do some basic task to do the basic task.

It's not entirely a wrong thing per-se, as long as the interface is done well. The issue is that many times it isn't, and some service or troubleshooting info is important for IT people in the field.

[oiaohm]

It isn't like there's a list of non-SystemD-using Debian-derivatives the Devuan devs could steal from.

Yes there is a list.

https://sysdfree.wordpress.com/2019/10/12/135/

Its not SystemD its systemd. Yes there is a List of distributions that are not using systemd. The list every year is getting shorter.

I am starting at the bottom of list working up.

On that list you could straight up cross out XBain as it is basically based of upstream raspbian has not updated to support raspberry pi 4 yet and is most likely zombie walking that will either swap from upstart to systemd or disappear.

Then you cross out windows maker live because it has not been update since 2016. . So no functional development to get resource from at all.

Vine is already migrating so marked as gone.

Postx next release https://www.techtimejourney.net/post...1-is-released/ systemd so it gone.

Elive last release is systemd so its gone.

If you don't look at the ones based off devuan

1] TRIOS Mia OpenRC/ZFS this is still alive they have no interest in sysvinit stuff. Might be useful to devuan if they drop sysvinit.
2] MX Linux might be some help with the sysvinit side.
3] knoppix is a rare one to switch away from systemd but they are also doing their own thing optimised for livecd not general.
4] Free of Boxes most likely not useful solo developer. More like to want to take from Devuan than do anything useful.
5] antiX Linux this you might class as duplication as nothing about sysvinit you get here will not be in MX Linux.

Out the devuan list there is also mistakes lets go though that list. VenenuX if you look at the alpha release in 2018 it in fact systemd and straight debian based with systemd same with the release being worked on.

Dynebolic project is gone.

Vuu-Do Linux, Star, Nelum-Dev1, Good Life Linux, and FluXuan Linux without decent update cycles showing under resource and are one man teams so totally just a live cd maker with not even enough resources to put up a website or have decent update activity. So no resources here.

1] EterTICs GNU/Linux decently resourced with a fairly decently sized team.
2] Maemo Leste 3 person team
3] maybe] MiyoLinux 2 person team maybe some resources here decent update activity.
4] maybe] CROWZ is a 2 person team has not managed to put decent update activity.
5] maybe] Exe GNU/Linux is also a 1 person team but manages to get up a basic website and decent update activity.
6] maybe] refracta is really a 1 person team but has managed to get a website up. Of course the team members page is a broken link so it appears to be more people than it really is.

When you get rid of the maybes and stick to only debian based distributions you end up with this list for source of development on debian based distributions not using systemd..

1] devuan/EterTICs GNU/Linux I put EterTIC with devuan here is they would mostly be picking up the devuan work and upstreaming stuff.
2] TRIOS Mia OpenRC/ZFS
3] MX Linux/antiX Linux joint here because their development on sysvinit basically lockstep.
4] knoppix

Basically you can count them on one hand and not use your thumb and all the developers working on that would fit in 1 conference room.

Knoppix way of doing it a special snow flake way of doing it so devuan most likely cannot use what they have done. Trios will only help devuan with openrc and at this stage MX Linux/antiX Linux might help a little with sysvinit. If they ever change devuan will be absolutely alone on sysvinit in debian based distributions.

Its basically to the point devuan need to look outside debian based distributions for help. Even outside Debian based distributions sysvinit usage is coming rare.

Openrc is coming reasonably popular.

[jason.oliveira]

Its not SystemD its systemd.

Oh, it's definitely SystemD from now on. It triggers people enough to make them correct you. Thanks for the heads-up!

The rest of your post reads like that old MAD Magazine comic about why it's destined that you will win the Publisher's Clearing House Sweepstakes, because every calamity will happen to everyone that isn't you. But instead it's about how Devuan will lose because init is just so damned tricky, that you can't just make a text file called /linuxrc to replace it. No sir, only rocket surgeons should dare touch PID1. Plus, there are only four active Debian-derivatives that will do much of the lifting for them. I hope you understand if I treat your post with the appropriate TL;DR.

And you're the only person in the thread worth responding to. Consider that a relative compliment. Happy Holidays!

[Terrablit]

I, for one, am glad about the result. It means we stick with the most developed solution and keep using declarative init files, while leaving the window open for groups who are willing to do enough of their own work to write a better replacement instead of trying to complain everyone else into conscripts. And nobody else has to bend over backwards to support half-baked crap. I don't mind seeing a replacement that offers similar functionality. I look forward to the wheel of progress. But I get annoyed at the bloatkin who claim that new features aren't "necessary" just because they're not skilled enough to use them.

Dear Diary, Came back to the thread after the storm blew over. A bunch of genuine pseudonymous shills called me a shill while they tried to do damage control over SystemD's loss.

My point was proven 100%. No anti-SystemD comment will ever last as the final post in a thread.

You're not a shill. Shills are people related to a position or project who don't disclose that. Unless you're contributing to Devuan or some random init project that you're super tearful didn't win Sports Day, you can't be a shill. Just like nobody telling you off is related to systemd. Systemd contributors clearly couldn't give a shit what you think. They're very used to anti-systemd trolling by now and they usually ignore it as long as it doesn't cross into harassment. It's rather like when some crazy homeless guy you don't know is rude to you. You don't waste time hating him because he's clearly got issues. And you clearly don't engage. You just cross the street and move faster.

So, nobody's a shill here. Let's just have everyone step away from the precipice of insanity. Especially you, who started out playing on the edge of the cliff on stilts. You're the fool who started throwing around the "shill" word without actually knowing anyone's relation to the subject matter. You're just so self-centered and narcissistic that you think everyone who doesn't share your opinion is part of some secret astroturfing conspiracy.As if the only reason there's opposition to your words is because "the man" makes it happen. When really it's just that nobody values your opinion. A lot of us think it's bad, and that it should probably feel bad for being so bad.

Shilling in FOSS is actually pretty rare. I've encountered it twice in the past two decades. And that's always been in regard to a paid product or service. Normally people are more than happy to advertise their connection with a project when it's relevant. And they're also usually happy to stay away from flame wars in stuff they work in. Especially if they've worked on it for a while.

[jason.oliveira]

Remember kids, an anti-systemd opinion being unable to end a thread is totally organic. The only person using his real name is the shill/crazy/homeless/unperson.

And shilling is rare. Go back to sleep, citizen. You saw nothing here.

[ArcosFan]

Is there anything more cringe than sysvinit?

[oiaohm]

But instead it's about how Devuan will lose because init is just so damned tricky, that you can't just make a text file called /linuxrc to replace it. No sir, only rocket surgeons should dare touch PID1.

Its kind of the reverse. Everyone presumes the old Unix developers behind System V and Posix were rocket surgreons who new what they are doing. When really they did not.

Init is self is not that tricky but has to be coded in C because Unix/Posix said that posix PID1 should process particular Posix signals it recieves including at times sending signals back to the process that sent PID signal yet the posix standard does not include anything to send signals dependably to a process let alone return a message dependably. Hello totally impossible to write a 100% correct PID1 for most of the history of Linux. pidfd at long last means that you could write a PID1 that in fact works correctly. Its only taken 28 year of Linux development and all the time of Unix history for us to finally get this.

Its doing the service management that is a complete different problem. Those coding up services really are not master developers either so they will screw up. So miss behaving services is normal. There is a error in the way Linus did the process table in Linux that is not posix that results in child processes end up not connected to their parent process or session id. This is where we need cgroups. Then add on that the scheduler need more information that it use to because of our modern multi core cpus. Only recently are we starting to get cgroups with all the functions we need for service management.

Basically 29 years that there was no way todo service management properly Linux the API/ABI just did not exist.

Systemd includes a lot of attempted work around and due to having issue has lead to cgroups being improved and the pidfd stuff getting into kernel.

This may sound horrible be we really do need someone to go hey I will start a new Init/service management system today that will use all the improvements that the Linux kernel has now.

Yes you could make something like sysvinit except it starts services from the script in a cgroup isolated from the environmental crap of the processing scripts disappears when the processing script stops so its truly low memory. Something like this would also have the tracing for miss behaving services what is basically normal.

Its hard to accept right that deamontools, s6, upstart, openrc, systemd.... all the init/service management solutions we know contain hacks attempting to work around lack of functionality from kernel level leading to multi bugs as they failed to succeed in lots of cases.

I am not saying systemd should win. But we do need to wake up what the hell was broken and how badly. From that start having people make init and service management solutions that can in fact work without stack of hacks. I really see projects like Devuan wasting resources on items that could never be techically competitive.

Plus, there are only four active Debian-derivatives that will do much of the lifting for them. I hope you understand if I treat your post with the appropriate TL;DR

Out of those 4 in the debian camp knoppix init development is 1 solo developer and so is the antix linux but these have a long history. If you are talking solid number of people you are only talking 2 in the debian camp. Devuan and TRIOS Mia OpenRC/ZFS. TRIOS is in fact looking outside to gentoo and other non based debian distributions to share resources.

Reality is the debian derivatives that are not systemd in personal power to have enough hours in the day are getting to the point of trouble.

Gentoo on Openrc has a team 12 so working with them is a good move to increase your development resources.

[Danielsan]

Basically will not change anything unless someone would decide to introduce another "init/services manager" and patching all the dependencies necessaries in a timely manner; but it seems that Debian prefers messing up with the "init/services manager" downstream: Debian is committed to working with derivatives that make different choices about init systems.

So far I know only GuixSD and Gentoo use Gnome3 without systemd, hence I don't see so many available alternatives out there...

[Britoid]

Is there anything more cringe than sysvinit?

The people who defend it.