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 kaszz on Sunday November 23 2014, @03:16AM
Then you are paying the price of two processes and IPC between them instead of one doing it the traditional way. Though it may have benefits, but they seem unclear at the moment.
(Score: 2, Interesting) by khallow on Sunday November 23 2014, @03:35AM
(Score: 3) by Subsentient on Sunday November 23 2014, @04:46AM
You can still do that. Epoch uses IPC to transfer its process state information to the updated copy. 'epoch reexec' is all that's needed to upgrade all the way from 1.0 to the current master. And it's a *full* update.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by sjames on Sunday November 23 2014, @02:16PM
Surely the state should be serialized to disk in case the new instance crashes.
(Score: 2) by maxwell demon on Sunday November 23 2014, @11:59AM
Given that the only thing that PID1 in that proposal does, other than starting PID2, is to re-parent orphans, I don't see a lot of IPC taking place. From my understanding the main problem is that PID1 is handled specially by the Linux kernel, and thus any problem with PID1 will cause the system as a whole to fail. Which means that you would want to put as little as possible there.
The Tao of math: The numbers you can count are not the real numbers.