How CFEngine stays ahead of the pack

This article says nothing. It feels all sales to me. There are no concrete advantages mentioned that other systems don't also do (the way "promises" are described could just as easily be applied to all other config management tools for example), and the things that might actually be advantages (like reporting or ad-hoc commands in a UI) aren't described in detail.

>> I will go over a few of the items that lead to CFEngine’s excellence, longevity in the market, and current strong position.

CFEngine isn't in a strong position, it has been completely replaced by Chef/Ansible everywhere. It's barely used with some legacy systems.

I am interested in cfengine as I used to enjoy the "Principles of Networks and Systems administration" book by Burgess, but my feeling is one should post something more technical to HN as this looks very close to a marketing document from my point of view.

Edit: seeing that this post has gotten multiple upvotes but at the same time two others have posted almost the same as me simultaneously I guess that means a lot of people here are interested in cfengine, but this article is more likely to turn people away.

Also, the username who posted it seems similar to the author of the post (nothing wrong with that) so if you are the same person: would you mind posting a more technical resource? I'm actually interested.

I once attended a talk by Mark Burgess on Promise Theory. It turns out to be not so much a theory and more like an odd collection of sayings. For example, what is a promise in promise theory? Not really clear. What can you actually do with promise theory, and how might it inform the design of a system? Well, it's not really clear.

CFEngine being based on Promise Theory is circular, since Promise Theory means whatever it's convenient to mean, or possibly maybe "whatever CFEngine does"

I recall working at a place which was transitioning from CFEngine to Puppet. None of the fancy "promise theory" was used; sysadmins did whatever was necessary to get things configured, and that was it. As a result, Puppet was a breath of fresh air because, while it was no more intelligent about describing machines, it was certainly more direct about changing them.

To me, CFEngine has been behind the pack for a long time. I use Nix now, and right now in order to be ahead of the pack, a configuration manager needs not just declarative configuration, but atomic upgrades and rollbacks, dry-run builds and upgrades, service isolation, and service discovery or meshing.

Years ago, Mr. Burgess called me a "moron" on Twitter when I asked if there was a correlation between companies that choose cfengine and companies who have challenges with security and uptime.

My implication that cfengine is a bad tool was not directed at him. So I was surprised to see a person like him (a CEO, with PHD) respond this way.

I've used CFengine (long ago) and Ansible (more recently), and the way I remember it, they were similar: Both allow you to express "please ensure that this Debian package is installed" and "please ensure that the file foo contains this line bar".

So, as far as I can tell, in both cases you describe the desired target state of the box, and the tool examines the current state and migrates towards the target state.

I always assumed that Chef and Puppet were similar.

Am I overlooking something?

This is a name I haven't heard in several years.