Adam Williamson wrote:
I beg to differ. I've had to create or modify initscripts quite
often,
either as a sysadmin or a packager. If this is now going to require C
coding skills, I'm not going to be able to do it. I don't think it's
safe to assume that everyone who needs to write or modify an initscript
is going to know C. What about people who write apps that need
initscripts in some other language?
What about a compromise? The initscripts are plain text files that get
compiled after you edit them.
Solution 1 Example:
viinit postgresql
Make your changes
:wq
viinit compiles your script into a binary.
Solution 2: Give Bash JIT.
OTOH, why is this even a sub-topic in this sub-topic of a thread? I'd
love to see some numbers from the complainers about scripting being
slow. I have a normal Fedora 13 x86_64 system that boots through
initscripts in under 10 seconds. Normal services are starting as I have
not "tweaked" my service list. Unless Fedora needs a 1 second boot time
(hey I wouldn't complain) do we really need to spend time on 100+ email
threads and jump through multiple init systems to find that perfect
solution? I've read similar claims of salvation when upstart was being
marketed to replace SysVinit. "Everyone will switch to native scripts
and everything will be better!" Has everyone switched to native upstart
scripts? AFAIK - No. Will everyone switch to systemd native scripts? I'm
betting - no.