Opinions on SMF

[Chris Turner]

On 08/27/13 06:44, John Marino wrote:
> Also, really there should be a front-end tool for designing SMF
> manifests, there's nothing saying it has to be written directly.  I'm
> guessing there are already such tools.

If you need a front end tool to configure your init system,
you're doing it wrong.

RCNG, in addition to being the 1st in the 'new school init' wave
(e.g. stepping out of traditional SysV vs BSD init), is
the only one that both kept things simple and also dynamic
and easy to understand. 'Rcorder' is a great tool. SMF, upstart, systemd
are all overengineered crap.

While I understand the latter two are trying to inject some layer of
flexability/dynamism into init systems, imho they do this in a clunky
and silly way, from 'within' init, rather than adding clean hooks
so that customization can be 'injected' from 'without' - which would
have kept things simple for the traditional, static case, but without
complicating the new-school dynamic/multiple-configuration case. If that
is desired, someone needs to add some flexibility 'the bsd way' imho..

As for 'why would sun invest' - it seems to me (based on pure speculation)
that the reasoning behind SMF is that it was designed
to make a more 'statically verifiable' init which in turn allows
for easier specification / packaging / various other PHB / proprietary
software garbage for binary-only and consulting vendors for
large companies and governments - and also allows for clearer/simpler
integration with their 'service managment' components - e.g. sun clustering,
JMX managment consoles, etc, as it is simpler to interface with from the J2EE
java bloatware application servers that run such items
(ever try to parse text in java? how about xml? now you understand why java
  devs are xml nuts) Also, since sun controls over SMF itself, and it is
hugely bloated, it allows SUN an innate 'lead time' on any managment products
developed against it (think microsoft / binary incompatibility), which at
the time was a key part of Sun's hybrid open/closed source strategy..

again, pure speculation, but it's the only reason I can see for such
overengineering into an init system.

E.g - it's designed for things that are wedged into a complex layer cake
of beaurocracy, which in some places makes tons of sense (e.g. when you
are required to work within a complex layer cake of beurocracy - e.g. 4x vendors
interfacing on a proprietary system which needs multiple layers of contractually
binding executive signoff and full-lifecycle budget planning to change any component
interfaces ), but probably not the best for those wanting a simple system onto
which they can add their own customization 'spice' (e.g. me - and I would dare
to say most of us)

All the other features mentioned:

- controlled shutdown
- restart
- dependancy map
- parallelism

could easily be tacked on to rcng with a bit of ingenuity, and probably by using
simple shell conventions or minor tweaks to 'rcorder'/'rc.subr', etc. rather
than strict / annoying / static verification, and without destryoing the
simplicity and elegance of rcng either for the common case

Plus it's CDDL, isn't it?

so, in short: opinion == ptooey!

Cheers,

- Chris