I am the maintainer of the Epoch Init System, a single threaded Linux init system with non-intrusiveness in mind, and I'm preparing to release 2.0. It's mostly a code cleanup release, but while I'm at it, I thought I'd ask the Soylent community what features they'd like to see. I'm open to all good ideas, but I'm wary of feature creep, so as a result, I won't consider the following:
* multithreaded/parallel services, because that goes against design goals of simplicity and harms customizability
* mounting support or networking support; it's an init system, use busybox if you need a mount command.
So what do soylentils want to see in the next release of the Epoch Init System?
(Score: 2) by Pav on Monday November 24 2014, @02:53AM
I honestly don't think ANYONE knows what makes a good forward-looking init system should look like. That's not to say the information isn't out there, but noone has collected it. Developers seem to have just solved the parts of the problem they understand and are motivated by. Perhaps one day someone will do the hard yards and query all the different init developer subcultures from Linux, BSD et. al. (openrc, upstart, daemontools, launchd etc...), sysadmin communities, developer communities, users etc... and actually join the dots somehow to develop a wholeistic understanding of the problem space. Perhaps one solution really is required everywhere, or multiple solutions for irreconcilable goals. Perhaps no good idea will come, and new thinking will need to happen from a position of better understanding. Perhaps it would be down existing solutions understanding their shortcomings better, then competing some more. I can't help feeling that a compilation of current knowledge would see elegant and simple connections of ideas fall out. IMHO noone right now knows what a good init system should look like.
(Score: 2) by cafebabe on Tuesday November 25 2014, @02:17AM
At a guess, a good init system should be like a make system. This is especially true when parallelism is considered. One of the modern requirements is multiple chroot jails or even nested chroot jails. This could be implemented easily with a make system.
1702845791×2