Debian Developers Take To Voting Over Init System Diversity

[rtfazeberdee]

In my Opinion Debian should advance the Idea of a Standard API to treat Services..
LSB Already have the LSB Headers, it could be not enough, maybe needs to be worked out.. but something Standard, and not deciding in favor of the Init A or the Init B..

Propose a standard API, the InitSystems around, should follow.
Debian users will win with that..

Seems like you've written a job description for yourself. Let us know when its done.

[J.G.]

I agree with you, R41N3R .

Regarding your point about maintainers: judging by how aggressively some people push to want other people to do work for them, there are not enough people willing to maintain these alternatives. Otherwise they would simply contribute to Devuan and live happily ever after in their utopia.

Regarding your point about politics: I wonder how much that is even real at this point. Like the person on the first page of comments, who used the large text size, is likely just someone who gets a laugh out of getting a few reactions on the internet. Sure, there might be the few people who find it more comfortable to work using SysVinit and who do actively contribute to Devuan, but those surely would just be happy working with Devuan without all the drama.

If anything, if I would be happily contributing to Devuan, I'd prefer to dissociate from those noisy people before all the sysadmins would say "ok boomer" to me.

[quikee]

The Unix init system is great for servers but terrible for desktop systems. Its is very bad at handling responses to dynamic events (i.e. I just plugged a second monitor, I just changed my resolution etc etc).

Even servers have dynamic events, like monitoring of the services and hardware, daily / monthly procedure, graceful service restart. It is actually hard for me to imagine just to have an critical server without dynamic events, but I'm not not an admin. However, I worked on insurance software for small and middle sized insurances and was helping the admins to set up the procedure.

[Iksf]

No way the Debian team are dumb enough to vote for this. There's not an infinite amount of monkeys to do all this work, if you want no systemD use one of the many good available systems that cater to that.

[tuxd3v]

Because that's how it works, you make the claim, you get to carry the burden of proof.

Look...
You are not so important to me, to waist my time proving something to you that you can sort by yourself!

You have doubts take both images, install a minimal one from each side and see for yourself.. you don't need "a babysitter"..
Don't get me wrong,
But the Idea of me, working for free to you...its an insult to my person..

That type of requests I get from Friends, also by my Contractors, not from a stranger..

[r_a_trip]

This is a non-issue. Regardless what everybody thinks about it, the development focus is on systemd. There is not enough will- or manpower to keep the wanted alternatives viably going, so it is only a matter of time where defacto systemd becomes the only game in town. The sysv init diehards are also speedily approaching retirement after which unit files will rule the roost. No amount of vocal protest is going to change that. The only thing changing this is actual, written code and it seems that hasn't happened by the people wanting this, despite all the clamoring.

[oiaohm]

The Unix init system is great for servers but terrible for desktop systems. Its is very bad at handling responses to dynamic events (i.e. I just plugged a second monitor, I just changed my resolution etc etc).

This is also wrong. Solaris has SMF because hot plugging stuff on servers can also be important so is knowing if a service has anything running or not..

Systemd useage of cgroups lines up with SMF usage of zones to know if a service has fully stopped or not.

Hotplugging stuff. On Unix mainframes it would pay to read.
https://www.fujitsu.com/cn/Images/c120-e690-03en.pdf

Servers instead of just plugging in a second monitor it can be plug in a completely different IO card or hey lets plug in some ram while the system is running because the system is running a little low or hey lets in extream designs of mainframes lets plug in a complete extra set of cpus. Dynamic events supported well is a Unix mainframe feature so in this regard there is no difference between the desktop and server.


Please note I use SMF as example but if you look at AIX Ibm Unix instead of zones(SMF) or cgroups(linux) its using subsystems(AIX). Basically zones, cgroups and subsystems(AIX) are all doing the same thing from service management with Solaris, linux, AIX, have the OS kernel wrap something around the service to track it. And the default service management on Solaris, AIX and linux with systemd are automatically using this feature. One of the most common complains on HPUX was that at kernel level it has "Secure Resource Partitions" that is another thing like cgroups but when you got to HPUX service management you had to set it all up manually and hope you got it right.

Yes systemd is very like the highly liked by Unix admins service management systems with its heavy use of cgroup. Yes lot of these Unixs you put sysvinit based init scripts in they are not working at all or if they work its by sysvinit emulation (just like systemd again).

The servers don't need something like systemd arguement is absolutely wrong. Anyone stupidly comparing systemd to windows is horrible wrong. Windows current versions still does not have anything like "Secure Resorce Partitions" (hpux), Zones(solaris), subsystems(AIX) or cgroups(linux) and since windows does not have anything like this it service management is not using it either.

Systemd like it or not is very commercial Unix like.

[reavertm]

I think this poll is flawed and unless all except the first options are combined in final decision, it seems to be constructed in a way to make 'systemd only' option prevail yet silence those who wanted diversity by 'hey, we gave you a chance'.
Essentially there are just two options:
- 'fascism'
- 'freedom'
And 'freedom' option, if selected by majority, should be followed by separate poll regarding the actual preferred approach.

(I'm not arguing against systemd here, for Debian the best is probably to stick with systemd, there are distributions that provide better freedom and less excluding environment for developers and sysadmins)

[mdedetrich]

The servers don't need something like systemd arguement is absolutely wrong. Anyone stupidly comparing systemd to windows is horrible wrong. Windows current versions still does not have anything like "Secure Resorce Partitions" (hpux), Zones(solaris), subsystems(AIX) or cgroups(linux) and since windows does not have anything like this it service management is not using it either.

Systemd like it or not is very commercial Unix like.

To be frank, I didn't say that servers don't need init systems like systemd, I am just saying that they need it less compared to lets say a desktop (also note that servers have also gotten more complex over time). My personal opinion is that systemd is far suprior to the unix based init system (albet more "complex") and it should be the default, I don't even know why this is an argument in debian.

[oiaohm]

To be frank, I didn't say that servers don't need init systems like systemd, I am just saying that they need it less compared to lets say a desktop (also note that servers have also gotten more complex over time).

This is the wrong idea. Servers today are way more complex. You have gpu acceleration in servers these days. Desktop computer most cases putting in two graphics card these days nothing is going to use it in most cases. GPU accelerated server workloads 4 cards per server is nothing strange and will be 100 percent used.

Bad system latency in fact is bad for different server workloads as well.

Everything the desktop needs the server in fact needs at some point of time. Include means to hotplug in a monitor for a server this would be diagnostic reasons. Where laptop hotplugging a monitor would be you are doing a presentation. Desktop system hotplugging a monitor would most likely be that something like a cat by mistake pulled out a monitor cable. All cases the same kernel side and service manage software is needed. In fact diagnostic reasons if it crashes the server is really bad as you have possible lost the data you were after by plugin monitor in..

The hard reality the desktop for what the init system and service management need to-do is the simple case. The server init system and service management is the complex case. You think about it you are going for 99.999 uptime. you cannot just reboot a full system because some service screwed up like you can with a desktop.

So systemd due to having lots of the features server side wants it could truly be overkill at times for a desktop. But items like sysvinit and other old init systems like runit are the exact other way massively feature lacking for desktop or server.

My personal opinion is that systemd is far suprior to the unix based init system (albet more "complex") and it should be the default, I don't even know why this is an argument in debian.

I can understand if the arguement was between openrc and systemd. Both technically have the means in time to do all the features need. With openrc being portable to more kernel types. Any arguement about go back to sysvinit is just foolish.