Debian Developers Take To Voting Over Init System Diversity

[intelfx]

Because Debian is about community with a Social Contract not just technology like Arch, this is the reason why I don't use Arch; zero criticism toward technology is quite dangerous.

I don't see anything in that Social Contract that wouldn't apply to Arch.

What Debian has to codify on paper in form of various "Social Contracts", Arch simply understands as common sense.

[oiaohm]

I think that we should always have alternatives, alternatives are resources. For a long time GNU & Linux where alternatives to M$ and Apple as well as Gimp is an alternative to Photosciop etc... The lacking of alternatives is way more dangerous than the current fragmentation.

There is not really fragmentation and that is the problem. The idea that we should always have alternatives is a horrible one when it done unbounded.

http://siag.nu/ Siag Office is technically an alternative to Microsoft Office. Has not seen a proper release since 2006 and is extremely feature poor compared to modern alternatives. Like really anyone attempting to sell Siag Office as a alternative to Microsoft Office would have to be extremely foolish. Serous Alternatives would be to Microsoft Office would be like libreoffice.

We need quality alternatives. Pushing linux sysvinit is really like pushing Siag Office. In the init/service management space. Please note I called it init/service management. Not just init.

https://github.com/Yelp/dumb-init

There as such thing like above that are pure init items with no service management these are used in containers running 1 service per container what is not your normal desktop or general server case.

This is not sysvinit or systemd or openrc or shepherd or runit.... as all these are init /service management.

Pushing sysvinit is very much in the class of if someone was pushing Saig Office as alternative to MS Office due to noting being properly maintained.

Openrc has cgroup support underway and is under regular maintenance and development from gentoo developers so a valid alternative.

GNU Shepherd has cgroup support and is under regular maintenance and development from developers around GNU particularly guix stuff. So another valid alternative.

So we have alternatives here.

Lets say you found your self in a location you could not install photoshop and gimp on the same computer because they conflict.

This is where we are with elogind and systemd logind also with eudev and systemd udev. These conflits interfere with installing openrc and systemd on the same system so preventing you switching between them on boot and comparing them.

This brings a problem are alternatives good when they are like elogind and systemd logind that conflict with each other. This comes about because elogind is a fork off the systemd logind done in a way that it cannot any longer integrate back into a systemd install. This also duplicates the security fixing of faults found in systemd logind as those also need to be fixed in elogind and due to the way elogind has been made systemd patches don't straight up transfer from systemd logind to elogind..

There is such thing as unnecessary duplication. Unnecessary duplication does not make a good alternative and creates security nightmares.

As long as people step up to create and maintain those alternatives, and not simply complain about their perceived lack of alternatives. Generally, what I see is a bunch of complaining and not enough people coding.

We are seeing a lot of complaining and pushing invalid alternatives. So I absolute agree with this perceived lack of alternatives.

There is a lack of proper alternatives that work correctly in foundation parts. This is udev/eudve and logind/elogind issues. This is not that systemd itself alone is bad the way the alternative to the shared interfaces are done in a bad way and that really does not help the problem.

Yelling about give us sysvinit back is just avoiding up facing the future problems.

[kgonzales]

I think that we should always have alternatives, alternatives are resources. For a long time GNU & Linux where alternatives to M$ and Apple as well as Gimp is an alternative to Photosciop etc... The lacking of alternatives is way more dangerous than the current fragmentation.

As long as people step up to create and maintain those alternatives, and not simply complain about their perceived lack of alternatives. Generally, what I see is a bunch of complaining and not enough people coding.

[Danielsan]

I think that we should always have alternatives, alternatives are resources. For a long time GNU & Linux where alternatives to M$ and Apple as well as Gimp is an alternative to Photosciop etc... The lacking of alternatives is way more dangerous than the current fragmentation.

[Danielsan]

I still do not understand why this is so complicated for Debian. Political decisions seems to be the main focus judging from all these discussions. As an Arch Linux user I prefer simplicity, if it works it will be added and if it works better than it can become the standard. Systemd solved many long standing issues and it reduced the maintenance burden for the package maintainers, which is quite important from my point of view.

Because Debian is about community with a Social Contract not just technology like Arch, this is the reason why I don't use Arch; zero criticism toward technology is quite dangerous.

[tildearrow]

For an EDITOR?
Precisely my point: not much of a life, eh? You even have no idea when [sexual fetishism removed]
Thanks very much for the validation...which occurrence you probably have no idea or concept of.

Are you aware of the meaning of sarcasm?

Unbelievable that a poet cannot even comprehend the concept of sarcasm.

[danmcgrew]

Wow. Just... wow.

This is the most amazing rant I have seen in my whole life.

For an EDITOR?
Precisely my point: not much of a life, eh? You even have no idea when [sexual fetishism removed].
Thanks very much for the validation...which occurrence you probably have no idea or concept of.

[kgonzales]

oiaohm Customers are Type 2. To be a customer you must transact with me for services or products rendered.

Sure, lots of type 3 become type 2. But you have to know the types of customers you are going for. Most of the type 3's on this board who bitch and moan will continue to only produce more bitches and monaing, and will never give any funding or effort to anyone. They will just use, abuse and complain. I would never sell to them. I would however sell to their bosses who realized their people were putting them at risk.

[oiaohm]

1) Those who actively create and maintain open source software
2) Those who spend money to hire open source developers or to hire companies who produce open source software
3) Those who are none of the above so your opinion does not matter

I kind of agree with that to a point. Type 3 does matter if the issues are going be impossible hindrance. So far I have not seen any real arguments against systemd that are a impossible hindrance.

If you do not like systemd but you are neither creating/maintaining a new init systems or hiring people/companies to create/maintain a new init system, your opinion simply doesn’t matter. You can talk all day long but if you want to affect change you should shift yourself into category #1 or #2.

If you are creating a new init system you need to understand the problem space or you will create another pointless useless init system that as soon as 3 gets it they work out it does not work right.

Oh and the whole “old timers know best” horse shit needs to stop. Those old timers come from backgrounds where Unix systems were massive proprietary boxes that had to be multi-user because hundreds of people had to use a single system an organization can afford. Now Linux resides in IOT devices and tiny containers, the same methods don’t apply. The old timers, like the ones in every space, will assume all their collected wisdom is relevant. It is not. And I say this as a 20+ year tech “old timer” who worked with even more old timer.

I totally agree a lot of this old timers know best need to stop. I am truly an old timer and I don't back sysvinit or many of the old init solutions a single bit. There is technical reasons why. I am a old timer who is willing to learn new stuff if it makes things better long term. I would create a type 4. If you need to say you are a old timer to defend you point of view I would say that you are different type. A good old timer like me will be able to point to technical issues to defend point of view most of the time. I would say this would be type:

4) a person with rose colour glasses on who is no longer looking at the technical problem or what end users need who just does not want to change at all. I am guilty of this from time to time. Even if you are a active software developer or paying people to develop code you still should be disregard at this point until you wake up your are being foolish.

I will do up a list of requirements you should be looking for in a modern init/service management system. Remember sysvinit on Linux is service management done badly.

1) Until recently the Linux kernel could not safely kill the right process. it has been luck that when you do kill -9 [number] that the right process gets killed. Just read about all the pidfd stuff. So this need to be on the list.

2) The Linux kernel process tree has a nasty design fault child process can disconnect itself from parent. So either someone need to fix the Linux kernel or use some other way to track what processes are associated with the service. Upstart tried ptrace from the upstart experience this does not work as it screwed up service debugging. Systemd, shepherd, and openrc are working on the cgroup solution to deal with this problem. Cgroups we can use today fixing the linux kernel could take decades. This is not some optional thing you want either. Think you are running a website there is a fault some malware runs in webserver starting it own process it disconnects from parent process you restart the webserver it stays running under sysvinit/runit.... the old ones. Yet under systemd, openrc(with cgroups on), shepherd and even horible broken upstart the malware would have be stop when the server was restarted.

3) Yes the Linux process tree issue apply to user logins as well. Users would log out of gnome when it had a particular bug and be unable to log back in because part of gnome had remained running after the user had logged out. Systemd requiring you to particular say I want this to remain running is so that you don't get locked out. The means to start a process as a user and it stay running after you log out was cool but it was also result in users being unable to log back in when software did that behind the users back.

Anything put up as a service management solution/user management solution going forwards need to deal with these problems. Saying lets go back to sysvinit or a lot of the old trash init solutions does not deal with these problems. These problems adversely effect the type 3 the users and if are not dealt with are in the camp of impossible hindrance to them getting work done.

Type 3 End users expect there computer to work at least enough that they don't get magically locked out at random and that when they go to terminate a process they don't like by mistake kill another program that they have failed to save what they have done for the past 3 hours. I would not say your type 3 users option does not matter but it does need to be filtered to work out what the base line requirements of any option should be so you don't waste time coding up something that is going to be totally a waste of time long term. Yes those filtered things should be a technical list of requirements not just let us use X init/service management system so you can at least offer up suitable options.

Old sales saying. The Customer Is Always Right (Until They're Wrong). Handling a customer who is wrong is tricky. Best way is technical facts why presented in way they understand pointing to the right kind of solution.

Something to remember here the type 3 on your list is where a lot of type 1 and 2 come from. As in they start using the software they find they need X extra feature then either do it them self or pay someone to make it. So someone going out and creating a new init/service management system without considering the requirements of type 3 will be in most cases just making another init/service management system for the scrap pile we have enough in there already.

[tildearrow]

Michael Larabel works very hard at producing this amazing publication. So hard that perhaps he doesn't have time to make certain that the people he employs(?) work as hard as he does. [do 'Honorary Editors' do any real editorial work? Do they get paid for 'Honorary editing'?]

One would have thought that, to any rational individual who understands the English language, native speaker or not, the very first option in Michael Larabel's frontispiece...

"...After public comments, the eight options for voting by Debian developers include:

Choice 1: F: Focus on systemd
Choice 2: B: Systemd but we support exploring alternatives
Choice 3: A: Support for multiple init systems is Important
Choice 4: D: Support non-systemd systems, without blocking progress
Choice 5: H: Support portability, without blocking progress
Choice 6: E: Support for multiple init systems is Required
Choice 7: G: Support portability and multiple implementations
Choice 8: Further Discussion

The call for voting was announced a short time ago on the mailing list..."

...totally and completely covered the fantastic, and totally overlooked by Michael Larabel, New Option Number Nine as offered in Post #2 of this article.

But, of course, there's that all-important function--which happens so frequently--of pointing out to the world--Michael Larabel's occasional typographical error. And the need to increase the number of posts; let's face facts: three thousand, one hundred and fifty (3150) is just simply is not an acceptable number of posts for someone who holds such an important position.

Wow. Just... wow.

This is the most amazing rant I have seen in my whole life.