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 Arik on Sunday November 23 2014, @07:03PM

    by Arik (4543) on Sunday November 23 2014, @07:03PM (#119167) Journal
    I have the same model. I formatted 1gb of the internal SSD as a swap partition straight off, and it works beautifully. I'm not trying to be critical but it sounds like your mistake was not setting aside the space from the start, and then using too much disk afterwards. So delete or move things until you have enough space for your swap partition and fix it, rather than trying to re-architect the entire system around a poor decision made in the past?

    BTW it's a great piece of hardware but the bundled linux distro was so bad it looked like MS set it up. 
    --
    If laughter is the best medicine, who are the best doctors?
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by Foobar Bazbot on Monday November 24 2014, @01:32AM

    by Foobar Bazbot (37) on Monday November 24 2014, @01:32AM (#119274) Journal

    Note that I upgraded the RAM to 2GB (AFAIK it was never sold with more than 1GB), and AIUI suspend to disk in linux requires swap space equal to physical RAM*. And while I could probably have scrounged up the self-discipline to live with a 2GB root, 2GB swap scheme, I actually had a dual-boot with both Slackware and Arch. (Eventually, I replaced Slackware with Haiku, then finally blew away that partition for more space on Arch, so at this point scaling back to 2+2 is technically feasible, but it's a lot easier to keep a system small than to shrink it once I've got a ton of stuff installed...)

    *If you are actually suspending 2GB of RAM to 1GB of swap (using compression, I guess?), I'd really appreciate more info.

    • (Score: 2) by Arik on Monday November 24 2014, @01:48AM

      by Arik (4543) on Monday November 24 2014, @01:48AM (#119278) Journal
      I made do with 1gb RAM. IIRC it should still let you suspend to swap space less than your physical ram as long as your current free ram is greater than the difference between the two, but I never tried it and could be wrong.

      Other than that all I can say is you are pushing hard to do more than the hardware is really equipped to do. That's not always a bad thing, but I dont think the OS should be radically redesigned just for that use case. If you want it to work well, I'd heartily recommend the 2/2 partition though, because suspend to disk is really THE killer OS feature on that machine for me. It's very quick to suspend and to restart, and the battery loves it.
      --
      If laughter is the best medicine, who are the best doctors?

  • (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