Debian Developers Take To Voting Over Init System Diversity

[microcode]

Do you think systemd should be the only init available for containers? Do you want to see people stop using Debian-based images to build containers?

Why even bother using an init system in most containers? How many independent services are you ever initializing?

[Candy]

No matter how reasonable systemd is, somebody will be derailing conversations to complain about it in the abstract, without providing any actual concerns that could be addressed.

This is so retarded!

First something has been thrown inside our throaths with dubious arguments. Then - once it made it inside the throaths - we (so the audience that got basicly overrun by this - also needs to raise up "valid" arguments, why this and that is our concern.

If you can't deal with shit thrown towards you, then you should avoid playing with fire.

It sounds more like "we stick that bolt inside your ass and now you complain why we should remove that bolt again..." better ask yourself why you sticked that bolt in peoples arse first....

[danmcgrew]

Choice 9: Focus on systemd and leave the rest to Devuan

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.

[microcode]

This is so retarded!

First something has been thrown inside our throaths with dubious arguments. Then - once it made it inside the throaths - we (so the audience that got basicly overrun by this - also needs to raise up "valid" arguments, why this and that is our concern.

If you can't deal with shit thrown towards you, then you should avoid playing with fire.

It sounds more like "we stick that bolt inside your ass and now you complain why we should remove that bolt again..." better ask yourself why you sticked that bolt in peoples arse first....

Nobody did anything to you. You can install the old version of the thing you got for free. Nobody is obligated to provide perpetual support for your weird legacy software, and you have given them to good reason to do so.

[kgonzales]

There are three groups within Open Source:

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

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.

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.

Finally, in case you are wondering, I’m a blend of a little bit of #1 and more of #2.

[oiaohm]

Why even argue about this? Debian is going to vote systemd only.

https://www.debian.org/vote/2019/vote_002

Really would not be too sure than that.

Proposal D, Proposal H and Proposal E sort out their differences and come down to 1 option they will have more support than Proposal F that is systemd only.

There is kind of a horrible fragmentation in the init freedom camp of debian that is really undermining their position.

[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.

[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.

[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.

[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.