On 2/12/2010 2:04 PM, michoski wrote:
>
> I'm partially to blame for starting it, but I'm honestly not sure where this
> discussion is going...

I'm still trying to get the 1000-foot view of the potential pain/benefit 
ratio to expect from cfengine before committing to the effort and 
expense of building a framework around it.  This is probably the wrong 
place for such a discussion, but I don't know where else to find 
experienced users.

> I agree perl has uses (e.g. text processing in
> Python is generally slower), and cfengine certainly does too.

I'm not obsessed with languages that make it easy for the machine. The 
days of wooden computers and iron programmers have passed.  Java might 
even be reasonable now with something like hyperic.  I don't have 
programmers at my disposal but could bend someone's ear if I needed help 
in something popular like perl, java or C++. With anything else, I'm 
mostly on my own.

> My point when originally raising an eyebrow over the new syntax was that
> something simpler than even perl would generally be a good thing for system
> admins (not programmers).  The more immediately readable a policy, the more
> like documentation it becomes and the easier it is to maintain.  The fact
> cfengine now has in-built documentation features (like other full-blown
> programming languages) seems to support the obvious fact complexity has
> increased at an expense to readability.

My opinion has always been that the more compact and self-contained the 
code is, the more you can see at once and the easier it is to 
understand, but I don't think that is a popular view.  People seem to 
love to redefine and overload things all over the place and pretend that 
you don't need to know about those details - until the hidden part breaks...

> Looking back to the car/engine analogy Mark presented...  I disagree.
> Cfengine is not really like the engine at all.  That is the source code, as
> another pointed out.  Going further, cfengine (in my mind of course) is
> really much more like the interior controls.  It's an interface between the
> driver (admin) and rest of the car (what we want to control).  I shouldn't
> need to be an ACE certified technician to drive a car.  Better car interiors
> (Audi/Porsche typically receive high ranks) are more minimalistic, and
> functionally driven (so as not to distract from driving).  There is not a
> button for every variable one could control by connecting to the ECU.

I just wish I didn't have to build my own custom chassis to fit around 
it before being able to tell if the engine vibrations will be annoying 
after getting up to speed.  Is there anything like a set of vmware 
appliances to demo the features and the interface to control changes?

 >> If that's not the case historically, should I expect it
>> going forward any more than I should for python?
>
> Having worked in shops where we built our own internal system (perl with
> shell glue) -- I am painfully aware of what he's talking about.  The extra
> care and feeding required to maintain all your own modules and supporting
> bits (irrespective of what versions the base OS or other installed
> applications may use) does require thought and can bite you if mishandled.
> It's not hard, but it is one more thing to think about.  I like that
> cfengine really only needs openssl and bdb.  Granted...  I have had to work
> out how to upgrade those packages outside of cfengine (especially openssl).

I think in terms of hardware, the OS, and applications.  If this isn't 
included and set up to the point of being self-sufficient as part of the 
OS base, then it is just another application to install, configure, and 
maintain.  I'm having a hard time seeing past that to where it becomes a 
net win, especially in our environment of frequent application upgrades 
and network interdependencies that it doesn't look designed to handle. 
But maybe I'm just over-analyzing.  Much of the theory does sound good.

-- 
   Les Mikesell
    lesmikes...@gmail.com
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to