Opinions on SMF

Outback Dingo outbackdingo at gmail.com
Thu Sep 5 08:17:01 PDT 2013


On Tue, Sep 3, 2013 at 8:47 AM, Chris Turner
<c.turner at 199technologies.com>wrote:

> 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
>


guys really?? you would be better suited to port lanchd as it would be
easier to integrate, and has all the same features
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20130905/428f806d/attachment-0001.htm>


More information about the Users mailing list