I want the next Slackware init system to be ...
 

Assuming that Slackware will have to switch to a newer init system in the future, vote for the one you want. Having said that I know Mr. Volkerding is the BDFL and it is his decision, but I think a poll may be useful.

Before you vote, make sure to inform yourself about each of the init systems, their features and pros and cons.

I do NOT want this post to turn into a flame war about systemd, take that to the many other threads on that topic. Focus mainly on the PROS of each system, maybe that will keep the flames at bay.

Links to the project pages:
http://troglobit.com/finit.html
http://smarden.org/runit/
https://gentoo.org/proj/en/base/openrc
http://skarnet.org/software/s6/
http://mmonit.com/monit/
http://upstart.ubuntu.com/
http://b0llix.net/perp/
http://supervisord.org/
https://gnu.org/software/dmd/
http://www.freedesktop.org/wiki/Software/systemd/

Vote for "other" and add a link below if I haven't mentioned one. No dead projects please, and no joke sites (uselessd).

EDIT:
The assumption here is that the init system will remain the same until it needs to be upgraded. You cannot vote for it to stay the same, because it will already do that, but if you feel you must it would go under "other".

I don't see an option for "Exactly the same as the last one..."

*** EDIT ***

I don't wish to hijack your thread, so I'll respond here and duck out...

If it MUST change then I don't have a horse in that race and will trust Patrick to make the best possible decision. I will then make effort to accept his choice, and If for some reason I cannot, I will move to FreeBSD as I install new systems.

I do not concede it to be inevitable...

No, we're assuming it is going to change not stay the same. We are assuming it is inevitable, which is probably true.

Other - Exactly the same as the last one.

I completely trust Pat to make choices about the developmental pathway of Slackware.

That immediately flashed my mind, after I've read through poll options.

I've also serious doubts about inevitability of leaving current SysV init with BSD-like scripts, esp. in favor of some tangential one. If Linux devs would crap out to systemd pressure, then there would be only one real option anyway.
I'd really like to hear arguments supporting urgency of switch. I'm aware of current spoiled state of udev, but it's loosely related to init, with one exception.

Here's my thoughts:

I honestly don't know much about Finit to really give an opinion, so I can't say yes or no.

Runit might work well, and does retain many aspects of BSD mannerisms, but it requires a lot of fore-thought into porting. Many daemons that use PID files and fork out must be ran through FIFOs and in the foreground without the traditional forking ability. Needless to say, it's Stage execution phases are very simplistic, and with the right scripting you can slide Runit into a distribution with ease, but any sysvinit utilities must be effectively replaced outright. The runit-for-lfs project was able to replace many parts of sysvinit with a special halt binary and a special shutdown shell script. Plus you need to relearn how to use effective runlevels, and using the chpst utility for effective permission executions requires a lot of planning on effectively managing users and groups. You also have to write some run scripts that can check for service dependencies as well. It's a venture, but with some effort it can be done.

OpenRC from Gentoo might be a worthwhile venture but only if it had better documentation, examples, etc..

s6 is nice, but it requires even more planning than Runit does. It's a lot more complex as well, and you actually have to create your own init program as an execline script or a standard shell script. It has it's own libraries as well it uses, skalibs. This would be one for the books if it could be implemented, but Laurent has said even in the mailing list that s6 is not really geared for mass produced system, and more for custom systems.

As with Finit, I don't know much about it.

Upstart is a tangled mess of config files, event trigger scripts, and service management scripts. No... just no.

Perp might work. It uses sysvinit as a backbone so once it starts it manages services with sysvinit sitting quietly waiting for reboot/shutdown. It uses many of the same principles as s6 and Runit.

Don't know much about it, so can't say.

Has this even been ported out of HURD?

May Bob should slap you for suggesting it.

Other than GOD, init-ng, and several other service supervision tools, there's not much else that's really feature complete like systemd, runit, OpenRC, Upstart, or s6. As it stands bsd stylized sysvinit is the best way to go at the moment.

And yes I voted Other to keep bsd-sysvinit.

Just to avoid mixing up my post with this I double posted. Sorry:

GOD - http://godrb.com/

I like the BSD style init scripts.

I also trust that, if Pat decides a change is necessary, he will continue the path of excellence that he has trod in the past. (That means, natch, no SystemD, if only because its lead developer seems to be--er--unduly fond of himself.)

Patrick has my personal permission to use anything from runit-for-lfs as and if he so needs, especially for the sysv replacement utilities. That is, unless he doesn't like the MIT license.

In about one or two months, I will finally be able to focus on s6 full-time.

My plan for 2015 is to analyze what systemd does that distributions want, and implement the same features in an extension of s6, in a more Unixish and less obnoxious way. It is to turn s6 into a fully fledged, complete alternative to systemd.
This will not happen overnight, but I am committed to it, and it will happen.

If Slackware has decided to go for alternatives, I'm interested in hearing their needs, in terms of functionality. Exactly what features must the init system have ? You guys have the opportunity to be there at the very beginning and make your voices heard, so please tell me what you want.

Welcome back Laurent! :)

Good luck on your quest, but the questions that people seem to be avoiding are:

In what ways is Slackware's current init not sufficient for our purposes?

Can these (perceived) shortcomings be addressed in any manner other than replacing the whole thing?

Surely, in a keep-it-simple system, projects like these would have to be seen as adding real value before they can even be considered, no? If the end result is a system which runs no differently, then what's the point?

The system we have is flexible, extensible and (thanks to some superbly commented scripts) easily maintained by anyone who has even a slight amount of knowledge. What do we need it to do that it currently doesn't?

...

The only thing we actually lack is service supervision to be perfectly honest, but that's a weak argument to make a full case over since Slackware has always been about learning to do things manually.