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 have also as a consultant not observed it much in the wild in the past 12 years. I've seen a lot more chef/puppet/saltstack and in past 5 years, ansible installations especially in big enterprise companies. I was surprised to hear it is still kicking apparently though
It almost like Python vs Haskell. In theory you can solve the same problem with either. In practice approach would be very different. Same can be said about Ansible vs CFEngine - you can automate infrastructure with either but approach is substantially different.
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.
[+] [-] raziel2p|5 years ago|reply
[+] [-] slap|5 years ago|reply
CFEngine isn't in a strong position, it has been completely replaced by Chef/Ansible everywhere. It's barely used with some legacy systems.
[+] [-] 7ArcticSealz|5 years ago|reply
[+] [-] betaby|5 years ago|reply
[+] [-] skinkestek|5 years ago|reply
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.
[+] [-] readams|5 years ago|reply
CFEngine being based on Promise Theory is circular, since Promise Theory means whatever it's convenient to mean, or possibly maybe "whatever CFEngine does"
[+] [-] Kednicma|5 years ago|reply
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.
[+] [-] robbyt|5 years ago|reply
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.
[+] [-] hibbelig|5 years ago|reply
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?
[+] [-] slap|5 years ago|reply
Chef/Puppet/Ansible are all enforcing a state which is usually defined by a package being installed, a file present, a service/process running.
Nothing groundbreaking.
[+] [-] bromonkey|5 years ago|reply