Stories
Slash Boxes
Comments

SoylentNews is people

Suggestions for Init System Features?

posted by LaminatorX on Sunday November 23 2014, @01:39AM   Printer-friendly
from the first-do-no-harm dept.

Subsentient writes:

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
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 0) by Anonymous Coward on Monday November 24 2014, @03:36AM

    by Anonymous Coward on Monday November 24 2014, @03:36AM (#119303)

    So you can see that adding storage requirements isn't always good? Especially when it is tied to RAM size. What if you have a device with a lot of RAM and little/no writable storage. What if the RAM is cheap and adding extra storage devices would screw up cost scaling. What if it is an embedded device that by design starts and stops and is not connected to power in between? Why would it be better to have a crippled system that is actually worse at the normal case, and precludes some use cases entirely, just so the programmers don't have to understand basic things like ordered requirements trees and concurrency? Your excuse that it doesn't normally hurt is weak, because a full-featured system doesn't normally hurt, either.

    We've got users on this site who don't even do anything that interacts with the init system except run a config tool that turns software on/off, and yet they've been convinced that they're being oppressed by a bloated init.

    It is perfectly reasonable to want to choose a slow init system for subjective reasons. It doesn't mean others are somehow wrong for wanting a full-featured one, however. It is just different choices.

    I edit config files with vim, and source files with emacs. The benefits in each scenario are entirely subjective.

  • (Score: 2) by cafebabe on Tuesday November 25 2014, @01:43AM

    by cafebabe (894) on Tuesday November 25 2014, @01:43AM (#119637) Journal

    It is perfectly reasonable to want to choose a slow init system for subjective reasons.

    Some people want a sequential init system for reliability and security. These are objective reasons.

    I edit config files with vim, and source files with emacs.

    Heretic!

    --
    1702845791×2