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: 2) by LoRdTAW on Sunday November 23 2014, @07:11AM

    by LoRdTAW (3755) on Sunday November 23 2014, @07:11AM (#119048) Journal

    I don't think people are scared of it. I just think that is is very clumsy to implement so people just avoid it altogether. But I only think of threading as a problem when using C/C++ as there is a lot of code to be added to create, manage and terminate threads. If you want to know difficulty, just try writing a simple fork() program that uses IPC to move a variable from one process to the other. That is enough to send anyone running. pthreads are a bit easier and they share the same global memory space. But they are still a pain to implement.

    But hopefully that will change with the new generation of programming languages that feature concurrency (even though Ada has had it for god knows how long.) I have been playing with Rust and man, that language is kicking some serious ass.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by hendrikboom on Sunday November 23 2014, @08:02PM

    by hendrikboom (1125) on Sunday November 23 2014, @08:02PM (#119187) Homepage Journal

    As far as I know, you don't need systemd to have a parallel init. For some time not, the scripts in init.d have prerequisites listed at the start so that the init system can read them and act accordingly. Or wait a minute, did that start with systemd?

    In any case the information on what needs to be started before what is there, and you may as well use it and start independent things in parallel.,

    -- hendrik

    • (Score: 1) by rleigh on Monday November 24 2014, @10:49AM

      by rleigh (4887) on Monday November 24 2014, @10:49AM (#119374) Homepage

      This is correct, we did have parallel boot with sysvinit for years before systemd. SuSE developed insserv and startpar which were later adopted by Debian and formalised in the LSB. insserv reads the dependency information from the init script headers and computes a dependency graph to start and stop scripts in parallel in the correct order (similar to make). At boot startpar can read the graph and start up services in parallel.

      This isn't quite as clever as systemd units, but it works well. And if you can to debug it, the graph is saved in /etc/init.d/.depend.* so you can read them, and insserv itself can do various diagnostics as well. When originally converting to dependency-based boot this was run on all init scripts distribution-wide to make sure a complete graph of everything was correct.

      Regards,
      Roger