Frequently asked questions

(not really)

Q: Why did you create yet another init system? Don't we have enough?
A: I wanted something small and unintrusive that doesn't splatter it's
configuration all over the disk, yet has enough features to be good enough for a desktop system.
The reason the Epoch Init System was created was for personal reasons,
but it's design goals are clear.

1. Small and fast.
2. Stays out of the way, can be swapped out -- unintrusive.
3. One configuration file holds everything, everything. Partly with goal #2.

People complain about too many options in the Linux world, from desktops
to shells to file managers to init systems, but personally, I shudder
to think of the day that those choices go away, the day that we are all
forced to use a sub-par solution that is so embedded that we cannot escape.
Be grateful things like the Epoch Init System exist.


Q: You're just one person. How do I know you won't just abandon Epoch at some point?
Isn't this kinda just a hobby project?
A: Epoch is not a hobby project. I would not have spent months of my life,
putting everything else on hold indefinitely, if I wasn't serious about Epoch's worth. I would not have released Epoch to the public
if I was not prepared for the responsibility of maintaining it. I will continue to support and improve Epoch as long as I'm able.
If the time comes when I cannot support it actively, I will be absolutely certain to put the project in the hands
of someone I trust, who will follow Epoch's design goals and who will not abandon it.

Q: Does the Epoch Init System support parallel/multithreaded service launching?
A: No. No it does not. I don't want it to unless I can
make it every bit as un-irritating as the current single-threaded implementation,
and I don't see that happening any time soon. Implementing this would be a massive job,
and would likely increase CPU usage, memory usage, and binary size dramatically.
That is against the goals of the Epoch Init System.

Q: Does the Epoch Init System support runlevel inheritance?
A: Yes. the 'RunlevelInherits' configuration attribute is what you want.
Find out more here.

Q: Does the Epoch Init System have dependency support?
A: Yes and no. The start/stop priorities are usually used to take care of this.
This is the one notable downside to the priority system, 
because while you technically can set the dependencies by using priorities,
they aren't named. You can name them with DefinePriority.

Q: But what about manually started objects' dependencies?
A: No other init system I know of is going to go and start all the crazy things
some object requires during a user-triggered manual start, so the Epoch Init System doesn't either.
I think that's probably a good thing.

Q: I hear about logging, but where is the logfile?
A: Ah, yes, there was a gap in documentation on that.
It's /var/log/system.log, unless compiled to be elsewhere.

Q: Does the logging system use syslog? Why not?
A: I don't use syslog because it's just another dependency.
Epoch is designed to depend on as little as possible for bootup. I don't think Red Hat/Fedora's boot.log
is sent through syslog, but if it is, I'm still not going to make Epoch depend on syslog.

Q: Does the Epoch Init System have support for SysV init scripts? How about systemd .service files?
A: No, sorry, because again, that would go against the spirit of
smallness and unintrusiveness that the Epoch Init System was designed for.

Q: Does the Epoch Init System run on BSD/Solaris/other UNIX flavor?
A: I'd like that, but currently, no.
/proc is the biggest anchor to Linux right now. I will
welcome any help porting Epoch to these other platforms with
open arms, just make sure you only work to get it running
as well as it does on Linux, and don't go off writing a bunch
of new features at the same time.

Q: I have a patch to contribute. Will you accept it?
A: I try to control what goes into the source code with an iron fist,
since this is my project done my way for what was originally my purposes.
Granted, there are some bad spots, but I would much rather know exactly what's going in.
However, if you have a critical bugfix or want to add support
for another operating system, I'll consider your proposal, no guarantees.
I will probably NOT accept patches so long I cannot read them
within three minutes. Keep that in mind. It's too hard for me to be sure I grasped everything you did.
You are prohibited from taking offense if I say no, I'm just really touchey here.
That doesn't mean, however, that I won't implement your request, just that I might not implement
YOUR implementation of the feature or fix.

If you do submit a patch, be advised that you must automatically release it into the public domain.
No GPL code, etc. Public domain. Unlicense. That's it.

Q: You know a programming language is named Epoch too, right?
A: Yes. That's why I generally try to refer to this project
as 'The Epoch Init System'. I was having trouble finding
a name I liked that wasn't used, and then, of course,
I think I found one, but after I change the repos
and rename the headers and comments, I remember about
this language I never bothered to try and nearly rip
my scruffy hair out in bloody chunks. I decided not
to change the name again, because I really like it.
I shouldn't need to say this, but the Epoch Init System
is completely unaffiliated with the Epoch Programming Language.

Q: Is the Epoch Init System compliant with the I.T.S.U.K.X 1932 UNIX standard
on the implementation of init systems named after words that start with an 'E'?
A: Probably not. If you hound me in IRC to make it so,
I'll have my IRC bot aqu4 throw old burritos at you. I won't break things, but I won't go out of my way to conform
to some standard.

Q: But! But! Staaaandards!
A: Don't make me bring aqu4 in here.

Q: Why are you so awesome?
A: Because somebody has to be.