> On Wed, Mar 19, 2008 at 02:40:28PM -0700, Darren Reed wrote:
>> My personal theory on why is simple:
>> SMF was developed by developers and not system admins.
>
> As a former sysadmin I believe what's missing is remote access. The
> rest is fine. You're generalizing.
No, what's missing is a simple way for the human sysadmin to view and
search (and change!) the system's current configuration. SMF's style of
burying config info in opaque databases makes this difficult, and many
people find the configuration interface very obtuse.
While SMF does a good job of managing processes, it is not the tool for
managing the configuration of those underlying processes. The power of
UNIX comes from the "one tool, one task" philosophy, and you ignore that
at your peril.
The key to making useful software is simplicity and cleanliness of design.
The core idea of SMF -- process management and ordered startup and
shutdown -- had the potential for a simple design. But adding all the
associated configuration data management turned it into a nightmare of
needless complexity. It's enlightening to compare SMF to the {Free,Net}BSD
rc.d framework. rc.d solves most of the problem using using a few shell
scripts and a simple C program that solves the start-order dependency
graph. Layering a process restarter on top of it would be almost trivial.
Now I don't claim rc.d can (or should) replace SMF, but from an
engineering standpoint it's interesting to compare the complexity of the
two systems in relation to the functionality they deliver.
As for remote access being a requirement, rdist solves that problem quite
nicely. (If remote access is a *requirement*, you're almost always pushing
configs out from a central configuration management system, anyway.)
--lyndon
Good judgement comes from experience. Unfortunately, experience
comes from bad judgement.
