Comment Re:My opinion on the matter. (Score 1) 826
A properly designed browser using *nix philosophy wouldn't do those things directly, instead it would use plugins to add that functionality.
An init system should do one thing and do it well, manage the startup of services when called. A proper *nix designed system for monitoring and restart would CALL init, but it shouldn't BE init, otherwise it violates the principle of modularity.
Consider for example looking for all the active settings in a standard Linux config file:
grep -v ^# ldap.conf | tr -s '\n'
By using two standard tools you can do something pretty fancy, basically stripping out all the comments. Could grep be enhanced to include the newline trimming feature? Of course it could, but that's not grep's job, its purpose is to match things not trim things. By keeping the scope narrow you reduce the error space and provide a more flexible toolset.
If you design the monitoring system into init then it can't be used generically to monitor other things and you lose half the value of the tool you've created.
egrep -v '^#|^$' ldap.conf ?
You're deciding boundaries arbitrarily. For example, who decided all the functions of tr belong in one command? Why are we even comparing userland tools to system functions? Why do you use dd to do EBCDIC-ACSII translation instead of
How old is SysV init? How has its "Well I assume I started something, JOB'S DONE!" interface with the rest of the system benefitted us all this time? How can you even connect that to something? You can't trust the exit codes from.. well anything, start/stop/or status because too many scripts just return 0. You can't trust status to exist everywhere or even work right. You can't trust a stop to actually kill all processes.
If nobody is going to make init in its current bounds _determinate_, then who really cares if the replacement is more or less modular.