Slashdot Mirror
Ask Slashdot: Feature Requests For Epoch Init System 1.3.0?
New submitter Ben Dibell writes: My name is Subsentient. I maintain the Epoch Init System, a single-threaded init system for Linux designed to be easy to configure and customize, as well as staying out of your way.
Epoch uses a numeric priority system to determine the boot order of objects, supports a wide range of customizability, and doesn't require much anything except libc and /bin/sh (though /bin/sh can be omitted, not recommended). Epoch also features advanced service status reporting features and has service supervision.
I'm just here to ask the Slashdot community what they'd like to see in the next release, 1.3.0 "Fluoxetine", before I wrap it up.
There are generally 2 things I can't consider:
* Parallel service startup, because that can be done manually, and implementing it would make Epoch too complex IMHO.
* Switching away from the numeric priority system to "true" dependencies. I implemented the priority system because I liked the freedom it gives the end user.
Despite these omissions, your feedback matters to me. I want to make something everyone will want to use.
-Subsentient
Epoch uses a numeric priority system to determine the boot order of objects, supports a wide range of customizability, and doesn't require much anything except libc and /bin/sh (though /bin/sh can be omitted, not recommended). Epoch also features advanced service status reporting features and has service supervision.
I'm just here to ask the Slashdot community what they'd like to see in the next release, 1.3.0 "Fluoxetine", before I wrap it up.
There are generally 2 things I can't consider:
* Parallel service startup, because that can be done manually, and implementing it would make Epoch too complex IMHO.
* Switching away from the numeric priority system to "true" dependencies. I implemented the priority system because I liked the freedom it gives the end user.
Despite these omissions, your feedback matters to me. I want to make something everyone will want to use.
-Subsentient
Why do you think a numeric priority system gives "freedom" to the end user? To me, having to manually mess around with numbers is an annoyance, and it means that the init system is getting in the way.
Having numbers means that some dependency info gets lost. If you have an S10 and S20 script, is there any dependency between them, or were they just arbitrarily numbered? It's impossible to tell unless you go and read through the script and figure out for yourself. This makes it hard to debug when things go wrong. You also just end up with a bunch of scripts that all start with S99 or K99.
The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output. "Runlevels" were implemented with dummy scripts (i.e. scripts that just had dependency information in them, and didn't perform any actions).
Other than that, it's as simple as the traditional sysvinit, but without meaningless numbers everywhere. You can read more about it here: http://www.mewburn.net/luke/pa...
It's 2015, we should be naming things not numbering them.
He does not understand UNIX. stderr output should never be ignored, much less deleted
Here is a link to a bug report dealing with the stdout / stderr problem. If you read through it, you will find that the systemd folks are very responsive, and fully agree that the bug existed and quickly had a fix.
Amazing, a bug report that almost matches their paranoid fantasies.
High points:
1. stderr was lost because it was written to the terminal, just like it would have been with sysvinit -- someone had overriden the systemd default of logging to syslog.
2. someone else found another case where errors were being lost due to a misconfiguration of selinux, an all-pervasive system written by the NSA, something the paranoid anti-systemd trolls never seem to worry about, even when they try to claim systemd is a NSA plot.
I'm sorry that you lost customers relating to systemd, but if they switched to systemd, and the only failures they had were your code, then I have to ask why that is. If they had other failures in the conversion, and still insisted that you were the problem (enough to drop you as a service provider), then I would worry that there was some other agenda going on.
If, on the other hand, you were the one who switched to systemd, and managed to have unstable code make it to a client... Thats a whole other ball game.
I very much doubt he has any customers.
Watch this Heartland Institute video