Debian To Seek A General Resolution Over Their Init System Policy

[F.Ultra]

Look who's talking when I've explained my concerns with the damn thing to you personally at least once and you've never even tried to explain why being a rat's nest of dependencies (hence being functionally monolithic), massive feature creep and having a development team that doesn't take perfectly many legitimate bug reports seriously all at the same time isn't an issue. Either that or try to disprove the issues that me and many others have raised.

So you are still hang up with your whole theory that independent components that communicate over defined channels are just one large monolithic piece of software. See that is why I wrote "opinions" in the last post, because you see that as a rats nest of dependencies when I don't.

Toxic replies to bug-reports is of course a bad thing but completely separated from "the implementation is botched".

[starshipeleven]

Ahhh, moving the goalposts are we?

Dunno, my main point was that everyone was abandoning SysV and then I asked you to provide examples where someone that isn't Debian is actually still using it seriously.

Slackware

Close but no cigar. Yes they are using SysV but scripts are different (and since scripts are 99% of what SysV does, that's significant). They are using BSD-style init scripts. Linux-style SysV compatibility is provided by a script.
Since version 7.0, Slackware includes System V init compatibility. Many other Linux distributions make use of this style instead of the BSD style. Basically each runlevel is given a subdirectory for init scripts, whereas BSD style gives one init script to each runlevel. http://www.slackware.com/config/init.php

PCLinuxOS.

Good, that's one confirmed user so far.

All others are BSDs or BSD-like.

[starshipeleven]

You are going to be hearing a LOT about MX, I can assure you, and not just from the DW fanboys. Move aside, Mint.

(laughing in OpenSUSE)

[oiaohm]

Ahhh, moving the goalposts are we? How very starshipeleven of you! I'll throw a couple at you - Slackware and PCLinuxOS. Let me know how that humble pie tastes.

http://www.slackware.com/config/init.php

Interesting enough slackware by default uses a BSD style init. There is work switch slackware to openrc instead.

https://docs.slackware.com/howtos:general_admin:openrc

Slackware has never support sysvinit and is in the future openrc camp.

GUIX shepherd was not mentioned but in a lot of ways it configuration system makes systemd unit files look nice.

PCLinuxOS is we are sysvinit for now with still debates on what the heck should they change to but in a lot of ways they have made a choice in stealth. eudev fork of udev from systemd is maintained by gentoo developers who long term objective is openrc not other init systems.

Openrc model with competing init systems is to make a interfaces to run those competing init systems inside itself.

The forks of eudev and elogind from systemd that are not done in a compatible way to have work merged back into mainline systemd are not good. This is like the myth of slowing increasing the water temp and frogs not noticing. Lot of these distributions claiming not to be systemd are using eudev/elogind that are directly derivative from systemd source that in time will force them to openrc.

You have redhat on one side with systemd that is in face that its linked. On the other side you have gentoo with openrc, eudev and elogind that don't appear highly linked but are also taking you down a fixed route as well.

The 100% init neutral udev item does not in fact exist. We are fairly much looking down the barrel of either systemd or openrc. A lot of distributions are not waking up choosing eudev/elogind is long term choosing openrc. Once you factor that into looking at your non systemd distributions 95%+ of them will go openrc in time by current choices unless something changes. That something is proper work on providing udev and logind features more neutral.

[mrugiero]

5000 clicks per day on some very obscure website does not make a distribution popular.

1. Some random on Phoronix mentions a distro nobody knows as being the next hot thing in distrowatch.
2. Go to distrowatch, *assuming you know what that is*.
3. Click on it.
4. Get profoundly disappointed.
5. Hey, it got one more click, it's the next hot thing!

That's literally my case, really.

The opposite is true: The kernel maintainers invest a lot of effort to keep up a dependable, stable, predictable ABI for userspace software. And they succeeded very well in that. Totally unlike systemd, whose maintainers could not care less about long term compatibility.

I perceive the same here, and I think that's an unfixable community issue.
However, I'd rather use systemd and have a somewhat efficient and easy to admin system than use sysvinit.
The proper solution would be to make an alternative that follows more or less the concepts (dependency tracking, process tracking, socket activation, you get the drill) while attempting a reasonable degree of backwards compatibility and non-toxic behaviors.

The toxic attitude towards legitimate bug reports is just the icing on the cake and the only people who even try to deny it are people who don't know about it. Even some the developers have admitted that particularly Pottering always respond to perfectly legitimate bug reports in a productive manner.

As much as I love systemd, I seem to recall reading a bug report which was quite poorly handled.
There's also the constant conflict between the kernel people and the systemd people.

Regarding the repetition, there's always the good practice of making a sort of blogspot and pointing to the link.
You'll save quite a bit of typing and frustration.

No. For the vast majority of services, it has always been totally sufficient to create one symbolic link from the installed executable into some directory dedicated to the purpose of starting everything that is linked in there.

Geez, even AmigaOS and Windows 3.1 knew the concept of some "autostart"-style directory sufficient for the purpose.

The problem is, this doesn't really solve all the problems. Simple start of programs doesn't really cut it when you, for example, has several services for which you need high availability: they go down, you need to figure out that happened and take action.
I agree this isn't the case for most services, but with a few needing it is enough to need a more complex system, so why bother having two different paths for it?

Well i don't care what you think, i don't want systemd. I don't care if it is the best thing ever, superior to Linux or what not, i don't want it, and i don't want any distro that forces its use. Same thing with Gnome, Emacs, or whatever, its MY freedom of choice NOT to use it. Is Wayland wonderful? But i like X11, it works, period. I don't care, do not want.

I don't mind if the OPTION is there, what i mind is when this is no longer an option. This is why i left Debian and any distro that forces people to use systemd. I went with Devuan, Artix, Void, Slackware, Gentoo among many others that still give people CHOICE.

So much has been said about package maintainers doing "extra" work to support other choices, and yet you see the aforementioned "small" distros doing it. Artix is like 1 or 2 people, Devuan a small group of ex-debian, and they have done what the mainstream distros with their legions of volunteers (and even employees) don't bother doing: Restore CHOICE. Some of those distros don't bother repairing systemd once removed, and i don't mind, You can always use one of those systemd only distros if you want it.

MX Linux is interesting, but its not much more than Debian set to use sysv, it is unknown for how long you will be able to run Debian that way. They should move to Devuan to avoid any nasty surprises. Debian has long expressed their disdain about losing non systemd init support, which is the very reason Devuan exists.

No distro "forces" you to do anything. They offer you something. It's OK to not want it. It's OK to not accept it. It's OK for you to want and use something else. But it's a downright lie to pretend you're forced to use it. You're not.
Otherwise, we can play the opposite game: Devuan forces sysvinit on you! How do they dare, them tyrants!

Finally, your freedom of choice mean you get to choose from the available options or even create your own, maybe with other like-minded people's help. It doesn't mean you get to tell anyone else what to do.
Likewise, it's great that the Devuan maintainers decided to make a distro to their liking.
And it's fine that Debian maintainers didn't want to do that work.
Because it's their time and their effor, and neither you nor I have any right over it.

If the window manager crashes, your X- session still lives on. And that really is a life saver. Which brings us to wayland... if the compositor dies (which is kinda like the X-server, and window manager in one), everything is gone.
Therefore, for POS systems I really only use a simple well known working bug free window manager: fvwm2 .
Although from performance and therefore lower cost of SoC, I am looking at wayland too. But what simplified compositor can I use that provides speed as well as rotation, but also stability. Samsung uses enlightenment, and they have years of experience with stable wayland.

Why use a window system at all? Back in the day I used Qt on KMS raw with QPA.

One of the basic users had to disturb me because his system was in a booting loop, and that's because systemd can't grok /etc/fstab.
When something is in there it cannot understand, it just reboots. It does not give the user an opportunity to pound some sense into systemd, or edit the system.
Fortunately it takes 60s or so to decide to reboot and somehow I could log into his system using ipv6 link local (because he already disabled network manager fortunately so it wouldn't break ipv6), and fix his fstab in that 60s between the boots.
The problem really is: what he did was correct. It's just that systemd thought differently.

This is some very valid criticism. However, this isn't a fundamental design flaw, this is simply a bad call that probably has a very simple fix, if reported.

Power users however will have the greatest problem trying to do some basic name resolving thanks to systemd-resolver, since it basically puts in a bogus nameserver in resolv.conf after which all DNS functionality as is standardized doesn't work anymore.
If you want to use things like dig, you need to stop systemd-resolved and disable it for life.

So does resolvconf or whatever its name was. And as you point out, it's just a matter of not using systemd-resolved. It's not tied to init.

The bugs are known and are not going to be fixed BTW, because it was not intended as a valid nameserver. Then why put it in the resolv.conf in the first place... That's what's nsswitch.conf is for.

They're not bugs per definition, and they're not relevant to this discussion: systemd-resolved is just another resolver. Being on the same umbrella doesn't mean it has anything to do with init systems, and as you said, most DNS functionality really goes through resolv.conf.

Primarily that it crams too much complexity into PID 1 so, when something goes wrong, you can't kill and restart the misbehaving code.

The proper solution would be to have as much as possible in a helper daemon which PID 1 knows to restart if you kill it. (Sort of like how X11 desktops learned to split the anchor process for your X11 session lifespan from the window manager or whatever else originally served to hold the session open.)

It'd also enable live updating of all the code in the helper daemon as long as the interface between it and PID 1 was designed with stability in mind. Just update systemd and then ask the helper daemon to exit so PID 1 can "revive" the new version.

But wouldn't you basically need to also keep all of the helper's state? What do you gain in that scenario?
Also, you seem informed enough but just in case, remember not all of systemd is the process systemd. Not all of it is PID 1.

[F.Ultra]

No. For the vast majority of services, it has always been totally sufficient to create one symbolic link from the installed executable into some directory dedicated to the purpose of starting everything that is linked in there.

Geez, even AmigaOS and Windows 3.1 knew the concept of some "autostart"-style directory sufficient for the purpose.

AmigaOS and WIndows 3.1 where monolithic designs where you could always find commands, settings and files at specific places regardless of setup. And even then on e.g AmigaOS that directory where only used to auto-launch the simplest of desktop applications, for everything else you used scripts (which is why e.g S:startup-sequence existed).

But it's not the old times any more, daemons today are far more complex and needs dependencies, sandboxing and so on and on.

[rtfazeberdee]

So you get a two init systems less with Devuan than you get with the init-freedom-hating Debian.

Always love the lack of accuracy of this quote. Actually, its Devuan that is init-freedom-hating distro as they don't offer systemd as an option on principle whereas Debian offers more than one option (currently)

[9Strike]

Devuan will die pretty quick if Debian truly becomes systemd-only.

They are barely able to ship a customized Debian, they won't be able to maintain init scripts for all Debian packages themselves.

Honestly that's their problem. All packages I have ever looked the code up use systemd-only startup scripts anyway. Most devs like systemd, and if you don't like it that's your problem. Start contributing to Devuan then, or just use Void or similar anyway.

[L_A_G]

So you are still hang up with your whole theory that independent components that communicate over defined channels are just one large monolithic piece of software. See that is why I wrote "opinions" in the last post, because you see that as a rats nest of dependencies when I don't.

Apparently you either missed or don't seem to understand the word "functionally" as I've used it every time I've described my issue with the way they have loads of unnecessary dependencies back and forth across the project. So while it technically isn't monolithic, the back and forth dependencies means that you have to use the whole bloated mess and as they're suffering from an ongoing case of feature creep the mess is only getting more and more bloated as time goes on. Also, as I've explained to you before those internal APIs are what's known as "unstable" APIs, i.e they're subject to constant change meaning that they're useless to any outside projects that may want to replace, fix, de-bloat or extend functionality.

In outer words; While it's not technically monolithic, the way it's implemented as a rat's nest of back and forth dependencies using unstable APIs it may just as well be because from the perspective of anyone on the outside, it's what's known as a "Distinction without a difference".

Toxic replies to bug-reports is of course a bad thing but completely separated from "the implementation is botched".

It's about as separate an issue as a regular drunk driver driving on bad tires. Both are bad, but when combined they only make each other worse.

[starshipeleven]

Honestly that's their problem. All packages I have ever looked the code up use systemd-only startup scripts anyway. Most devs like systemd, and if you don't like it that's your problem. Start contributing to Devuan then, or just use Void or similar anyway.

Oh I'm totally against Devuan myself, I can only be happy if they blow up.

And I wouldn't mind seeing some core services of Debian actually switch to proper systemd units.