SoylentNews is people
SoylentNews
Hi, I'm Subsentient, the original author of the Epoch Init System. It's been around a while, and it does the job I gave it well enough for me, but Epoch has failed to reach its ultimate goal of becoming a viable alternative to systemd. This is for a few reasons, among them being a total lack of parallelism, difficulty for package maintainers to easily set up services, and a codebase even I myself am ashamed to admit I wrote. I got some things right too, like good documentation, powerful service management, lack of dependencies, and unintrusiveness, but it seems it wasn't quite enough, because the most commonly requested features were true dependency support and parallelism.
I'm doing a near-complete rewrite of Epoch, save for the few parts of code that were well-written, and it will be called Epoch-ng (next generation). While dependencies, parallelism and easy package manager support are the big things, I think I'd like to get feedback on what Linux users actually want from an init system, and I'll try to write an init system that does its best to meet everyone's desires.
So, what would you like to see in an init system? What would you like to NOT see? I'll be taking this feedback seriously. :^)
-Subsentient
(Score: 1) by stargazer on Thursday June 02 2016, @11:39PM
Since the System-D debacle has caused some of our servers to die after upgrade, we are moving slowly to FreeBSD. There goes 20+ years of knowledge. I'm hoping we can come back to Linux at some point, but for now, I can't upgrade our servers without System-D instability, so I'll put in my two cents. Maybe between your project and Devuan, I'll have the ability to actually use what I've learned.
I'd suggest marketing it as a "Server Grade Init System" since most of the people opposed to System-D's limits are like me, sysadmins. On my laptop, I don't care that much if it dies; I'll just go get the other one until I have time to reformat/reinstall. For my servers, it means lost revenues and some very pissed off clients.
The things I would like.
No parallel processing. It only makes for difficult to diagnose problems.
Dependency processing, maybe. I don't care that much as long as I have an error log and can change the order manually, but it is handy. However, dependency processing can cause problems sometimes, so maybe not.
Text based log files. No alternatives. If I am running out of space, I'll allocate more to my log directory. But, being able to grep a log file and find out what the hell is going on is essential. Inefficient, slow, lots of I/O, but finding the entries you need is up to your ability to use grep. Or write a script that finds what you want.
Emit all boot messages to a text log file for debugging. Text file should be opened and written to with no buffering as soon as the log device becomes available (cached beforehand, I guess). A few times, I've had to mount my log directory after a failed boot to try and figure out what exactly I totally screwed up.
Boot time is not an issue. It takes my DL-380 5-6 minutes just to boot BIOS. I don't care if it takes 30s or 50s to boot into the OS, I just want the freaking thing to boot.
Run levels are confusing, but if you change them, I'd suggest just naming them "GUI", "Console", "Shutdown" and "Single User". The current SysV is not horrible except I have to always remember what the hell Level x is used for. But, that is just my poor memory, not a reason to throw them away.
Easily edit startup configuration scripts. The current ones in SysV are not bad. Me, personally, I hate BASH, mainly because I'm not very good at it. But, it is reliable, damned near bug free, and gets the job done, so it is an excellent choice. Under SysV, I assume I could put a Perl script in /etc/init.d if I wanted (never tried it), but I want my sytem to boot every time, so everything is in BASH.
Above all, KISS. Do one thing, do it right, and don't get into scope creep (the big problem with System-D, from what I've seen). Boot the system and let the init scripts worry about how to start processes. Your job is to make sure the init scripts can be run at a certain run level (or whatever you want to call it), then get out of the way.
Most of these have been stated around here someplace, but like I said, I'm just adding my two cents.