3 ms·

> So, in terms from programming analogy, you need how your runtime operates, how it can affect neighbour processes/services, and what can you do when the runtim

> So, in terms from programming analogy, you need how your runtime operates, how it can affect neighbour processes/services, and what can you do when the runtime breaks down. This still does not affect how you structure your code (at least usually, when you don't work closely with the OS, which I bet is majority of code in the wild). Working with CFEngine's "DSL" v2 was very different from using Puppet mainly due to its limitations and lack of features. This really affects the way you structure your code. There were / are many nuances in CFEngine that make it different from puppet. And this is also about availability and complexity that is what I meant.

dozzie 9y ago
> Working with CFEngine's "DSL" v2 was very different from using Puppet mainly due to its limitations and lack of features. This really affects the way you structure your code. In this case it only affected where you put which part of the code, not how you managed your servers with the tool. Note that the analogy with programming languages is <how you manage servers> =~ <how you structure code>, not <how you structure code> =~ <how you structure code>, what you're trying to put into use here. For judging the approach, it's irrelevant whether you write a shell script or use somebody's Ruby plugin to detect mounted filesystems or something like that. It doesn't change fundamentally how you structure maintenance of your environment. > There were / are many nuances in CFEngine that make it different from puppet. Of course, starting with their languages' syntax. Though both use the same underlying ideas, even if they call them differently, and both operate in similar way. If you know how one works, it's a knowledge that's easy to transfer to the other.