Technically, init is also a program that launches other programs with its own special config file; it's just so much more limited than systemd that it has to hand startup over to scripts.
You don't need a special program to read logs; you can use whatever syslog daemon you want; you just don't have to. I really enjoy journal's ability to filter the logs precicely by all sorts of fields.
Actually, it's just the opposite of "relacement of files with APIs". A program's command-line is an API that you call using a program; that program is being replaced by a file.
I don't think you've actually used systemd if you claim that it "sucks the fun out of computing". I find the the "systemd-analyze" and "systemctl dot" tools to be a lot of fun.
The lack of hackability is not fun. And some strange new programs won't make up for it. Bash might indeed be not the perfect thing for an init system but having no scripting capabilities at all forces systemd to implement everything hard-coded. What if that hard-coded Blob lacks a feature I require? What if that hard-coded blob contains errors? What if that hard-coded Blob contains security risks?
systemd opens a lot of doors for potential new Errors. I agree sysvinit sucks but worse is better in this case. Ideally an init system would be a lean and smart turing complete scripting language and every feature is implemented on top of it.
Hi, I'm the developer of NCD. I've experimented a little with using NCD as the init process, with some success. It's a very simple system now: http://code.google.com/p/ncdinit/
I think using NCD as init or otherwise makes a lot of sense in embedded systems, and with some work it could work for desktops and such too (consider adding services on the fly without reboot).
You don't need a special program to read logs; you can use whatever syslog daemon you want; you just don't have to. I really enjoy journal's ability to filter the logs precicely by all sorts of fields.
Actually, it's just the opposite of "relacement of files with APIs". A program's command-line is an API that you call using a program; that program is being replaced by a file.
I don't think you've actually used systemd if you claim that it "sucks the fun out of computing". I find the the "systemd-analyze" and "systemctl dot" tools to be a lot of fun.