On 2013-12-06 kre%munnari.OZ.AU@localhost wrote:
There's no need to impose anything in particular on anyone, just create
I started out disagreeing, but I think I somewhat changed my mind before hitting send :/. What you say makes sense to me in that modularity encourages more well defined interactions between simpler parts (dealing with packages, etc.), which makes it easier to figure out what is going on at each step of the way. I do think it is super important to have something that works well in the base system.
I've had two basic problems with most init systems: the most common is just having no idea WTF is going on or how to find out, and the much less common one is wanting to replace as little as possible if the system just doesn't do what I want. Being able to replace the whole system doesn't help if there is no other system that does all of what I want and at least means I need to learn how some other system works.
NetBSD seems to do very well on both of these basic issues and I think it is a major reason to use NetBSD. I've had the misfortune of being stuck mostly running various versions of Linux over the past year or two and NetBSD's rc.d is one of the things I miss most (sh, mtree, vis, and build.sh are other things that come to mind easily). My current Linux system uses systemd and netctl and when something fails it is either silent or tells me to check two different log files which have a bunch of lines but usually nothing more helpful than "... status: FAILED".
daemontools is one that uses the "don't fork" model with per-service monitors. I think it has some good ideas and is much simpler than the others I've seen. I don't think it deals with dependencies, though, which is a major issue. I think it would be great if something like that was merged nicely with rc.d and used by default.
daemontools has a fghack program to try to work around services that fork by opening some pipes before starting the service and exiting when they all get closed.
djb also wrote a single service inetd-like program (ucspi-tcp).OTOH, I'm personally not that fond of having an extra monitoring process for every service and I also think it makes sense for init to do generic "is it running" monitoring. I don't think it makes that much difference either way, though, and I don't think init should try to do anything more complex then checking if something is running and restarting it if not.
Another thing that I think should be part of a service monitoring system is dbus type "message bus" functionality and ability to deal with on demand services. Unfortunately, dbus itself has a quite unfriendly UI.
IMO, the basic Unix/BSD security model, while useful for servers, does not cover how users actually interact with a personal computer. Fixing that involves defining and limiting what any individual application and application instances can do (in a way relevent to the user, such as this app can only modify files in this particular directory or must get approval for files to be written through a notification mechanism or something like that). Which probably involves moving more things into a service realm with processing capability but not the direct ability to do things with side effects. With fewer and simpler programs doing things with side effects (and the OS enforcing this), it would be eaiser to visualize and control what those side effects are.
-Matt