Debian Begins Vote On Supporting Non-Systemd Init Options (phoronix.com) 225
"It's been five years already since the vote to transition to systemd in Debian over Upstart," reports Phoronix, noting that the Debian developer community has now begun a 20-day ranked-choice vote on eight different proposals for "'init system diversity' and just how much Debian developers care (or not) in supporting alternatives to systemd."
The eight options they're voting on:
The eight options they're voting on:
- 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
There's detailed descriptions of each option on the Debian developers mailing list. "This is a non-secret vote," the post explains. "After the voting period is over the details on who voted what will be published."
Oh, Debian is a Democracy now? (Score:2, Insightful)
Re:Oh, Debian is a Democracy now? (Score:5, Informative)
Re: (Score:2, Informative)
I don't see any options about making everything dependant on systemd there.
I'm not sure what the current vote is supposed to achieve other than to rubberstamp what has already been done.
Re: (Score:3)
Well, after the tc (elected) changed the default init system to systemd. The winning (technical) choice in the GR was "support for other init system is recommended but not mandatory". The text is pretty clear that it means the package should be systemd compatible, and if possible be compatible with other things that's better.
"packages may not require a specific init system" got the least vote.
It seems, that it is exactly was done in the last release for instance.
So I am not sure what you are talking about.
Re: (Score:3, Insightful)
The real problem is that the people doing the actual work of developing and maintaing Debian and all the many packages are happy with systemd dependency and don't want the extra work of supporting your favourite init system.
Re: (Score:3, Interesting)
are they happy, or are they in a position of having no realistic choice?
So many big packages are systemd dependant, that the distro ends up being systemd dependant, and then the developers find that they have to depends on systemd no matter what.
But here's the main thing - since when did userland programs even have to know about the init system? Its like Clash of Clans needing to develop specifically for the bootloader you use.
Re: (Score:2)
Fair point, and I suppose the Devil's Advocate answer is that systemd is not just an init system.
Most popular operating systems do have a more complex, integrated service management system like systemd has become.
Compare launchd (Score:4, Informative)
Most popular operating systems do have a more complex, integrated service management system like systemd has become.
I don't think holding Windows up as a exemplar is going to win any friends here :-)
For example, macOS has launchd [wikipedia.org], and illumos and Solaris have Service Management Facility [wikipedia.org].
Re: (Score:2, Interesting)
The people who actually have the brains to maintain the packages disagree with you. Maybe they know something you don't?
Re: (Score:3, Insightful)
If they had any business maintaining packages, they'd be able to write a shell script.
Then go be a Debian developer for fucks sake!! Don't like it? Put your damn money where your damn mouth is or shut it. I don't like systemd but damn the amount of 3-year old whining that happens here about it is a fucking depressing reminder of how little people actually fucking care about open source. They work on packages, you don't. So yeah you're full of shit here. End of story.
Re: (Score:3)
Re: (Score:3)
If they had any business maintaining packages, they'd be able to write a shell script.
Being able to do something doesn't make doing that thing as standard a good idea. Not in any world. I can build a house. I won't do it because there's better solutions for it and my time is more valuable than to sit around with a circular saw a nail gun and some wood.
Likewise package maintainers have better things to do than to sit around customising long shell scripts simply because PID0 can't do it's only job well.
Re: (Score:3)
As long as you just keep ranting about how terrible systemd is you are going to be ignored by the people doing the actual work to create the software you want to be systemd free.
You have to understand why it works for them and why they are sticking with it, and it's not because they are all morons enthralled by Pottering or just out to troll you. It has real benefits for them that the old init system didn't and if you want things you change you need to address that.
Re: (Score:3)
I don't see any options about making everything dependant on systemd there.
Of course not, Debian isn't issuing any marching orders. The opposite of "Packages may not (in general) require a specific init system" is that packages, like Gnome, may require a specific init system, like systemd, if they want. That didn't require a resolution because developers and packages are already free to do what they want by default. Basically, the project refused to have any official policy in the matter and let the chips fall where they may. Now you might say that certain key packages forced that
Re: (Score:2)
choice 1 (F) says:
That's effectively making everything systemd.
Gotta say it (Score:5, Funny)
Begun, the Init Wars have.
Re: (Score:3, Funny)
Systemd is the JarJar Binks of linux.
Re: (Score:2, Interesting)
Systemd is the JarJar Binks of linux.
Well put! After all, some people actually like Jar Jar (presumably they were very young at the time), but objectively he's bad software that spreads disaster, and may actually be a Sith Lord.
Re:Gotta say it (Score:5, Funny)
Or maybe just stop telling other people that a good init system sucks just because you're too simple to get your head around it.
We are talking about systemd, not a good init system.
Re:Gotta say it (Score:4, Insightful)
Begun, the Init Wars have.
Oh, but the end of this one is easy to predict:
The Russians will win the vote.
Re: (Score:2)
This is not the first 'init war', BSD rc vs SYSV makes this look like a sandbox fight. That morphed into the UN*X wars, which probably help create an opening for Linux.
Re: (Score:3)
The id, rstate and action fields in SysV inittab were intended to hold makefile type rules that would have ended all this nonsense had it been properly implemented and documented back in 1983.
Alternatives are required. (Score:5, Insightful)
However it does have its place. I do run Linux on my laptop and supporting suspend/resume and other modern features like that is important and in this case, while not ideal, systemd does seem to be working.
Severs are another matter. Servers are very rarely rebooted and a speedy boot isn't usually that important. Furthermore it isn't something systemd can help with (things like database servers and custom application code tend to be the biggest consumers of boot time for servers). Ease of administration, reliability, and simplicity are the design goals for an init system for servers.
Things like binary log files are a terrible idea for servers but livable for a desktop distribution. The two wildly different roles and different requirements to me are a clear reason why init system alternatives are a must. One size fits all usually is the worst of both worlds.
Re: (Score:3)
| Servers are very rarely rebooted and a speedy boot isn't usually that important.
I don't run any servers but it seems to me if I have to reboot my server, I want it back online pretty quick.
Old init mainly addresses service start and stop. Systemd allows for keeping those services running. I'd think that would be pretty important on a server too.
Re:Alternatives are required. (Score:5, Interesting)
I've been managing Linux servers for most of the last 20 years, including periods where the regular day-to-day sysadmin would call me only when there were problems. I've seen a lot services down because of a full disk many times. I've seen them down because a TLS certificate expired. I've seem them down because they lost communication with the server running the database. I've seen them down because they can't read the file server. Several times I've seen them down because the password store got zeroed by a certain bug.
I don't recall ever once seeing it down because the parent PID mysteriously dissappeared and the solution was to restart the service. Not in 20 years have I seen that once. So you're fooling yourself if you think systemd is usefully monitoring your service and going to do anything to fix it.
It IS a good idea to monitor your services, of course. One of my companies offered a free service where we'd check your web site from three locations every few minutes and raise an alarm if the response didn't include the words you configured. (The configuration was to distinguish between the regular page and some kind of error page). That's useful monitoring - it ensures the service is up and accessible, providing the service it is supposed to provide. Sure is costly - free. :) Knowing that the PID exists doesn't tell you anything about whether it's providing the service properly. You'd only be fooling yourself rather than having proper monitoring.
Re: (Score:2)
Guess you haven't worked with much big iron. The OS booting is usually the quick part.
Re:Alternatives are required. (Score:4, Insightful)
Old init mainly addresses service start and stop. Systemd allows for keeping those services running. I'd think that would be pretty important on a server too.
Everytime I see someone say this I'm reminded of how this whole situation began.
Before I go into this though I *did* have criticisms of initd at the time. When systemd arrived I thought whooo hooo, someone has done something about that crappy rc.d system. The main issue was initd needed a complementary to deal with system events, that's what I thought systemd was at the time to finally perfect the general architecture of linux systems.
So whilst initd wasn't perfect, the criticisms of it in the original systemd design document [0pointer.de] were flawed from day one. Second it was based on the premise that the crappy rc.d system was the *only* way to start up system services, when a read of the inittab manual shows that it isn't.
Ok, back to the original design document of systemd. This is a broad critique I noted to myself:
Process Identifier 1
Agree.
Hardware and Software Change Dynamically
Agree. This is where a complementary eventd to talk to a system bus and alter initd state would help and drastically widen the scope of what is possible when events happen on the system.
Parallelizing Socket Services
misunderstanding of initd. This is achievable using inittab by configuring the runlevel initd is going to enter *OR* configuring the runlevel it is in and then signal initd to re-read inittab and maintain those processes also.
Parallelizing Bus Services
again inittab *already does this exactly as above *OR* entire process groups can be started in For lazy loading, the initd equivalent is 'ondemand' however this functionality needs a complementary eventd.
Parallelizing File System Jobs
Agree autofs is a system service like any other and this is exactly what a large company I worked for did. They did it as a background service (on solaris and we also had NFS mounts to deal with as home directories so it was a little more complicated than the use case presented here)
Keeping the First User PID Small
Considering the size and scope of systemd now compared to how miniscule initd is in comparison this argument is really reversed now.
All of the arguments here a based on the assumption that the rc init scripts are the *ONLY* way to interact with initd when the core initd functionality is completely ignored. The rc scripts that are being used here are read hats idea, which were based on working around SCO holding onto some very simple pieces of code that interacted with initd, probably to drive this very wedge into the linux community so they could keep market share. They were "enable" and "disable" command which simply configured a system service or process group maintained by initd to be started and stopped in the background in parallel. So all I can guess is RH did what they could under the circumstances. (oh and btw fuck you SCO for that)
You could the enable/disable commands inside a rc script to force initd to start/maintain the process in the background whilst the system start-up continued.
Keeping Track of Processes
Here we see the double fork argument. With a claim that an initd process should keep them around and manage the processes that crash which is exactly why crashed processes become owned by init. Essentially this part of the document criticizes sysVinitd for not do
Re:Alternatives are required. (Score:5, Insightful)
SystemD is the WindowsNT kernel of Linux.
It works, until it doesn't. I live with it on my laptop because it's more work to work around it because of how ingrained it is.
But my servers are FreeBSD.
Re: (Score:2)
Re:Alternatives are required. (Score:4, Insightful)
With changing hardware, you have to remove no longer used services and start new ones on the fly.
Most reconfiguration for hardware is handled by udev, not by the init system. We had udev before systemd.
With changing hardware, you have to remove no longer used services and start new ones on the fly. With SysV init, you only have 5 different states.
So what? You run an init script to stop a service, A file in /etc/default gets twiddled, and you run the init script again. If the service is disabled in its /etc/default file, it doesn't run. If it's enabled, it does.
and you want to have them without the need of a reboot.
They don't require a reboot with init scripts. It doesn't look like you know what you're talking about.
The problem with SysV init and similar systems is that they don't really support flexibility.
You have way more flexibility with init scripts than you do with systemd unit files.
Every hardware change requires manual changes in the booting process.
No, it only requires changes in files in /etc/default.
You really don't understand how sysvinit works.
Re: (Score:2)
udev is another hunk of shit. I have a box with six ethernet interfaces. What order are they going pick this boot? Oh I manually have to stop them from changing? Great another problem in need of a solution.
Re: Alternatives are required. (Score:2)
Why are you booting with net.ifnames=0 (or similar to disable predictable interface names) when it seems you should be?
Re: (Score:2)
This is exactly the point. Why do we have to keep SysV init, if we have out of necessity, other systems there which do the same? Basicly, all we need in SysV init is /etc/init.d/udev, with Sudev and Kudev links in rc.0 to rc.5.
Re: (Score:2)
Perhaps. But not on my machine.
Re: (Score:2)
I suppose the fact that systemd is more than happy to write to syslog is completely irrelevant to you. After all, facts have a way of upsetting bigots.
Re: (Score:2)
systemd is not faster than any other init system at booting.
Re: (Score:2)
fast booting is pretty much a non issue these days, as all systems have much faster io then when systemd started development.
anyway, the fast booting argument is not really the selling point anymore, but it keeps on being repeated over and over again.
Re: (Score:2)
I think there's room for "slimitd" - that is, a systemd-compatible thing that doesn't try to take over the world - just boots the system and gets out of the way.
Systemd service units are quite good - you can get a shell script to be a daemon (safely) without really writing any code at all - and you get logging/rotation and restarts for free. That's pretty cool. FWIW, we probably need a "version 2" for the format of those service units, but even as they are, they're usable.
I know you could write an init.d sc
Re:Alternatives are required. (Score:5, Informative)
Arguably systemd makes a lot more sense on servers than it does on laptops,
I seriously have no idea why you think that. Your example of log aggregation is an anti-pattern, since log aggregation isn't something an init system should be doing (I recommend a Kibana stack but there are a lot of options out there).
Re: (Score:2)
Re:Alternatives are required. (Score:5, Interesting)
On the other hand, I have seen more systemd related failures tham I have SysV failures. It's even worse when SystemD goes to a rescue prompt without first bringing up sshd. It's not that uncommon that I then issue the very command that SystemD was waiting to issue when it failed and it runs without error.
SystemD needs a "shut up and issue the command" option.
Re:Alternatives are required. (Score:5, Insightful)
As for the administrative aspect of starting and stopping services: I'm sorry - this has never been a problem for me or anyone of my friends. Actually, it's never been a problem for any of us until systemd arrived. The old init system never fought you.
Re: (Score:2, Insightful)
Re:Alternatives are required. (Score:4, Insightful)
one of the most high profile open source developers in the world.
The appeal to popularity is a logical fallacy.
Here's a hint, you don't get to be in that position without being pretty competent.
At jerking dicks, apparently, because we know Lennart to be a terrible developer who ignores user feedback and also standards.
Re: (Score:3)
At jerking dicks, apparently, because we know Lennart to be a terrible developer who ignores user feedback and also standards
Okay, then let's see your repo of source then? Just go ahead and paste us a link to your source repo that you worked on and I'm sure we'll all be happy to rank yours with Lennart's. You obviously want to be big man here, so let's do it the objective way. Let's see what projects you're on.
Re: (Score:2)
Re: (Score:2)
Not saying Lennart is a good developer, but maybe he does listen to users. It's just that he doesn't regard you as the user, he's listening to the distro maintainers and that software developers using systemd APIs.
They seem a lot happier with systemd than you. It seems to be solving issues they have and making their lives easier. Given that a lot of them do that work for free as a hobby they probably appreciate systemd, flawed as it is.
There is no other reasonable explanation for its popularity - your "Lenn
Re: (Score:2)
He's not a terrible developer - he has written systemd after all, and it does work.
However he is rogue developer because he's written systemd against all standard interfaces, and all concepts of interfacing with others. He's a child who refuses to play nicely with others.
Imagine what he could have done if he had sat down and improved all the pieces that comprised old Linux.
Re: (Score:3)
Sure, but you aren't popular either so you lose on all counts.
Tell me all about how popular I'm not, guy who's even less popular than I am.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sure you do.
Re: Alternatives are required. (Score:3)
Unrelated issue you're bringing up. It's about systemd's head dev skills here, not anybody else's.
If people were only ever allowed to criticize things they've done better, virtually nobody could criticize the president (...because they're not the president, or ever will be by realistic expectation).
Re: (Score:2)
you don't get to be in that position without being pretty competent.
High levels on dev tems are often more a matter of social engineering skills. He's one of Red Hat's hot-dog prima donnas.
Re: (Score:2)
Re: (Score:2)
Having spent years administering servers in the pre system days, and dealing with various kinds of (and often incompatible) init scripts, I have to say it wasn't all roses. Many processes did their own logging too, outside of syslog. What a mess.
Re: (Score:2)
Which cloud provided uses systemd at their host layer?
Re: (Score:2)
How so?
eg if Debian decides that they will support 2 init systems, then a package maintainer must supply their packages configured to support both or debian will fragment into a "systemd supported" and a "initd supported" flavours. when you get a Debian system, you'll have to choose which packages you intend to use, and choose the right Debian that supports those.
Its not a strawman by any means. However, if they support one or the other, then maintenance becomes easier - but, obviously packages must then al
Standards (Score:2)
Useless options (Score:2)
Unless the maintainers can be expected to write scripts for them, they can hardly be said to be supported.
So the poll option should include what init systems get mandatory support if not just the d. I'd say the realistic options are any combination of d/sysv/runit.
what happened to (Score:2)
Re: (Score:2)
It was withdrawn because proposal F came later and replaced it.
Systemd is a security nightmare (Score:2, Insightful)
Systemd is incompatible with the UNIX philosophy!
Re: (Score:2)
Re: (Score:2, Troll)
Yes, the kernel is the core program that mediates interaction between the hardware and the running software processes. One job.
No surprise a systemd tard wouldn't know that and be utterly ignorant of the Unix way.
Re: Systemd is a security nightmare (Score:2)
You just described a driver. Not a kernel.
Re: (Score:2)
Absolutely false. I gave the textbook definition of a kernel which includes the management of all resources not just driver functions. What you're thinking of is too narrow minded.
Re: (Score:3)
Not .. really. Pretty much everything a kernel does, or at any rate should do, is mediate between different processes/threads and between software and hardware, one way or another. If it's not inter-process, scheduling, or hardware interaction, do it in user mode.
Re: (Score:2, Informative)
Re: (Score:2)
False, all a kernel does is included in that and what i gave was textbook definition of a kernel. You can't provide a single counterexample as the hardware includes all functions of cpu, memory management, io, interrupts, bus, etc.
Re: (Score:2)
Re: (Score:2)
Yes which deals with a information to and from a hardware resource. you don't get that all a kernel does is included in what I said which is TEXTBOOK DEFINITION. Your ignorance is astounding
Re: (Score:2)
What does systemd have to do with the kernel?
Re: (Score:2)
Re: (Score:3)
I don't think you know the answer. Because I don't think you know what a kernel is.
Hint: Linus officially took no position on systemd over other init systems. If you understand why, you will have taken the first step in your education regarding operating system kernels.
Re: (Score:2)
Re:Systemd is a security nightmare (Score:5, Informative)
Re: (Score:2)
Why are systemd users so angry? If they all sound like you no wonder people created entire distros just to distance themselves.
Re: (Score:2)
Re: (Score:3)
Do you really think all these coders are such idiots, yet still want to use their software?
No, I don't want to use the software from the idiot coders, like Lennart — who ignores bug reports, and published standards. And I don't want to use GNOME 3 either, they can stick that garbage where the sun don't shine. So why do I need systemd? To make some package maintainers lives easier? People too dumb to write init scripts are too dumb to be package maintainers.
Re: (Score:2)
So in other words you don't have an answer, Zero Kelvin.
Re: Systemd is a security nightmare (Score:2)
No shit. Apparently itâ(TM)s a feature that dns resolution now bypasses iptables.
Don't care (Score:2)
Slackware 15 will be out very soon.
Far too late (Score:2)
I'm a big fan of slackware , but its been 3.5 years since 14.2 and thats just not viable. I realise Patricks had money and health issues but if he can't do a release at least once a year he might as well not bother. My next distro will be Devuan - I'm simply not prepared to wait until 2023/4 until the following version of slackware.
systemd is like cane toads (Score:3, Informative)
Its proponents brought it into Linux to solve some problems, but it's wiped out working ecologies. And it's primary author is *trying* to get rid of stable, functioning tools to fit his own personal model of how the world should work.
* Binary system logs for no good reason except to break all existing log analysis tools /etc/resolv.conf as a symlink
*
* Killing the running processes of logged in users, which breaks "screen" and "tux" and tried to slip it in as a compile-time default with no notification ot suers
* Forcing encryption of user home directories to be unlocked by systemd when a user logs in, proprietizing your home directory to require systemd to read your own files.
That ballot is rigged. Doesn't anyone notice? (Score:5, Interesting)
Has anyone else noticed how completley rigged this ballot is?
-Choice F - Systemd is placed first ( there is a known bias towards the first item in a list )
-The "allow other init systems", choice is split into essentially 6 different choices. The six alternatives are all vaguely the same and so the people who want an alternative to systemd are not going to be able to co-ordinate to find the right choice.
-The 'ranked choice' system is a mis-direction and will do nothing to offset these biases.
-The systemd only option doesn't clearly say that.
The result is that Debian is going to go systemd only unless 6x as many people vote to stop it
Re: (Score:2)
Just like it was 5 years ago...
Re: (Score:2)
Luckily several hundred times as many people would vote against it as for it. Unluckily 99% of those people aren't given ballots to start with.
Re: (Score:3)
You can take a look at debian-vote to see how they came to be.
Debian works the way that if you don't like the options, you can propose an alternative yourself, get a few backers, and it's in. That's why there are so many options, they started with a few.
E E E (Score:2)
I feel it is important for embedded systems with limited resources to be able to use sysv-init
They're missing an option (Score:5, Insightful)
Does it have to be so obnoxious? (Score:3, Informative)
Why does journald have to be so obnoxious? Out of all processes on the system it uses the most CPU time by far. Currently 3500 hours. Also I didn't ask for and don't want binary logs.
Re:Does it have to be so obnoxious? (Score:4, Informative)
Out of all processes on the system it uses the most CPU time by far. Currently 3500 hours.
Man have you got something very wrong on your system. I'm currently sitting at 91 minutes of CPU time for journald on a system that has 245days of uptime.
And yet.. (Score:2)
opposite consensus (Score:5, Interesting)
You're completely clueless about the deep ramifications of choice architecture. It's way too easy for a simplified flow chart to manipulate the final answer.
Flat, ranked voting systems are by far the best at drawing out where people really stand.
If you think that impedes "consensus" you're using the opposite definition of "consensus" that I ordinarily use, fixating on top-down consensus (any choice at all is better than no choice) as opposed to bottom-up consensus (no choice is better than its final implementation). It is true that in sufficiently hierarchical social groups that a simplified voting system gets you to the rough consensus of some viable decision, and then the implementation follows because people fall into line within the hierarchy. I would not begin to describe Debian as "sufficiently hierarchical". The final decision for Debian will only be as good as its alignment with the worker bees. This is why the vote was designed with the exit ramp: more discussion.
I'm frankly appalled that someone wielding a vote of this magnitude, which could effect the future of all Unix-like OSes for an entire generation, would find it too time consuming or complex to rank these eight fairly simple items.
All the best books I've read on leadership say the same thing: encourage as much contentious (yet polite) back-and-forth on the ground as possible, and only if the dust fails to settle on its own, step in and sever the Gordian knot. A good starting point is Creativity, Inc. (2014) by Edwin Catmull, computer scientist and current president of Pixar and Walt Disney Animation Studios.
The subtitle on this one is extremely telling: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
Poorly conceptualized voting protocols motivated by fatuous simplicity would definitely quality as an "unseen force" in most organizations, because K12 doesn't yet teach choice architecture starting in Grade 3, where it properly belongs. If you don't think nine-year-olds are sophisticated about deciding as a group what game they are going to play that day, then you subscribe to the woeful theory of the human condition that we get smarter with age.
No, we don't. We only get better at sweeping our confusion under the carpet using a magic wand we pray and hope that others don't notice.
Re: (Score:2)
Any 'choice architecture' can be subverted by the selection of 'choices' presented. As with the original 'debate' 5 years ago, this is clearly designed in favor of systemd. Sometimes a straight up and down vote is the most honest way to go, whatever your books on 'leadership' say.
Re: (Score:3)
Yet the BSDs can run systemd programs because of certain stubs; systemd is a curable cancer
Re:Bit Late... (Score:5, Informative)
Yet the BSDs can run systemd programs because of certain stubs
Same for Devuan, which conclusively proves that Debian without systemd is possible.
Re: (Score:2)
You know, some of us don't care about the latest fashion in UI's - they all end up looking like airport signage. We value total reliability, we value clarity and readability over fashion. We have a core of stuff we use our computer for, and we want it to just work.
Perhaps when you grow up you will come to understand this.
Re: (Score:2)
Getting there, getting there...