So, what is this 'eINIT'?

eINIT is a replacement for /sbin/init -- the programme that is responsible for booting your computer -- that is all about not wasting resources; that's not wasting CPU cycles, but also not wasting RAM either, which should make eINIT very well suited for embedded applications. However, that's not to say eINIT wouldn't work fine (and swiftly) on regular desktops, laptops or servers.

The primary objective, not wasting CPU cycles, has the most obvious effect: eINIT tends to be a lot faster than most regular sysvinit/rcscripts combinations out there; a lot faster meaning that when booting, all the stuff you need is usually started in under 10 seconds after eINIT gains control. We try to achieve this goal by coding as close to the machine as possible while still keeping things as flexible as possible, meaning that these 10 seconds tend to represent the time those programmes that need to start will actually spend executing, instead of eINIT slowing things down too much due to massive overhead. Additionally eINIT utilises massive threading in order to make sure that your CPU will not be idle waiting for one programme to finish when it could actually be put to better use spawning both programmes at the same time, while simultaneously thinking about what to do next.

The secondary objective, not wasting RAM, is especially important on embedded devices: adding massive amounts of RAM is just plain not practical on these devices, so the applications should be as small as possible. Since eINIT is actually able to cut corners in a few cases and basically may work without even using a shell at all, it may be possible to construct embedded devices with only eINIT, libraries and the target programmes on them, provided the modules are carefully adjusted (or written in C right away) and the target programmes themselves don't rely on a shell. By reducing the need for a shell, there is also no need to have the shell in-memory most of the time while booting, which saves RAM, nor is there any need to actually run the shell's code, which again saves some CPU time. Also eINIT is very, _very_ modular, so in an embedded setting the developers may decide to radically trim eINIT's list of modules and thus save even more RAM. It's so modular, you could, in theory, link all the .so modules you need into eINIT and then remove the module that is designed to load .so modules, along with all the other things you have no use for.

There is another, tertiary, objective: Making sure things just work(tm). eINIT is admittedly not quite there yet, but this is actually quite important, at least in my honest opinion it is. No programme should be allowed to act stupid or require arcane whizzbang magic configuration file formats, things should be kept simple instead (if possible). For example, if eINIT is supposed to bring up a service yet is unable to bring up the preferred programme to do so, but it does know an alternative, eINIT will try to use that alternative before bailing out completely. Also eINIT's structure is very modular, which will ultimately allow for special OS/distribution/alternative-init support modules that could re-use a distribution's existing scripting that shipped with your OS (or, let's say launchd's or initng's scripting) in cases where eINIT doesn't have its own yet (one actual example of this is the ex-baselayout-2 (now openrc) support code that allows using gentoo's init scripts just as if they were native).

Now, obviously eINIT isn't quite there yet, but we're progressing fine. Most of the current effort is on making things work smoothly on Gentoo/Linux, which is actually supported just fine, and we're also trying to make eINIT work on FreeBSD soon.