SoylentNews is people
SoylentNews
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?
This discussion has been archived.
No new comments can be posted.
Suggestions for Init System Features?
|
Log In/Create an Account
| Top
| 50 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
No self-made man ever did such a good job that some woman didn't
want to make some alterations.
-- Kim Hubbard
(Score: 2, Insightful) by jmorris on Sunday November 23 2014, @08:26AM
Most people agree innovation in the init process is worth putting some effort into. Just remember you are working on the init to a UNIX like system and you have a good chance of creating something people want.
Don't try to reimplement svchost and eventlogger. Don't try to create an entire new OS in userspace. If you find yourself wanting to build in a vast virtualization/sandboxing/access management subsystem, stop because systemd already exists. And avoid adding a systemwide IPC mechanism, replacing most of gnu-utils, networking, etc.
Mixed on the no parallel start. I know admins fear it because it will almost always end up slightly non-deterministic but on the other hand there is a fair amount of performance gain to reap for everyone else. Probably best to add it but keep a clearly documented and assured to be well supported option to disable it. If there is any hope of stopping the juggernaut a common front with as many dissidents as possible is needed, splitting between an alternate for servers and another for desktops/laptops/embedded is therefore a bad idea.