4 ms·

That's correct but you can't learn all the nuances and specifics of every tool there is.

dozzie 9y ago
Of course you don't, but those nuances and specifics are usually superficial and don't change how you approach your environment. You think there is that much of a difference between running Puppet, CFEngine, or Chef?
- holydude 9y ago
  They are not superficial and they definitely change how you approach your environment. I have worked extensively with both CFEngine and Puppet and I can assure you that they have enough differences especially when you consider large heterogenous environments that in no way you can consider using one as a substitute for the other.
  - dozzie 9y ago
    > I can assure you that [CFEngine and Puppet] have enough differences [...] that in no way you can consider using one as a substitute for the other. Like what?
    - holydude 9y ago
      memory footprint, performance,different "runtime" etc ?
      - dozzie 9y ago
        And how these affect operator's workflow? That is, the ways an operator interacts with the tools? The facts that Java is garbage collected or that it runs on virtual machine don't fundamentally change how programmers write code in it compared to e.g. C++. It's the same type of tool ("paradigm"). Erlang, however, is substantially different.
        holydude 9y ago
        You are comparing apples to oranges (in my opinion of course). I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels. Sure the implementation of the known algorithms will be similar in Java and C++ but the overall usage and how it connects with everything (aka the workflow) will be very different.
        dozzie 9y ago
        > I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. 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). > Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels. How does workforce availability affect the way you work with your system? How does availability of libraries affect the way you work with your system, apart from amount of code for you to write (libraries have to come from somewhere)? The architecture and strategies stay exactly the same. With this regard, there's very little difference between CFEngine, Puppet, and Chef. > Sure the implementation of the known algorithms will be similar in Java and C++ but the overall usage and how it connects with everything (aka the workflow) will be very different. It will hardly affect how you think about the system and how you approach it. It will only affect where you get your code from. Unless you think about yourself as a guy who only puts together different libraries/modules and never ever writes own code, then of course it's a new paradigm, but I don't think you had this scenario in mind.
        holydude 9y ago
        > 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.
  - cat199 9y ago
    Yes, but this also doesn't mean that one person trained in one tool can't learn the other in fairly short order, provided they understand the core principles behind it and haven't been 'brainwashed' into thinking 'this is how things work'

Of course you don't, but those nuances and specifics are usually superficial and don't change how you approach your environment. You think there is that much of a difference between running Puppet, CFEngine, or Chef?

holydude 9y ago
They are not superficial and they definitely change how you approach your environment. I have worked extensively with both CFEngine and Puppet and I can assure you that they have enough differences especially when you consider large heterogenous environments that in no way you can consider using one as a substitute for the other.
- dozzie 9y ago
  > I can assure you that [CFEngine and Puppet] have enough differences [...] that in no way you can consider using one as a substitute for the other. Like what?
  - holydude 9y ago
    memory footprint, performance,different "runtime" etc ?
    - dozzie 9y ago
      And how these affect operator's workflow? That is, the ways an operator interacts with the tools? The facts that Java is garbage collected or that it runs on virtual machine don't fundamentally change how programmers write code in it compared to e.g. C++. It's the same type of tool ("paradigm"). Erlang, however, is substantially different.
      - holydude 9y ago
        You are comparing apples to oranges (in my opinion of course). I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels. Sure the implementation of the known algorithms will be similar in Java and C++ but the overall usage and how it connects with everything (aka the workflow) will be very different.
        dozzie 9y ago
        > I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. 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). > Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels. How does workforce availability affect the way you work with your system? How does availability of libraries affect the way you work with your system, apart from amount of code for you to write (libraries have to come from somewhere)? The architecture and strategies stay exactly the same. With this regard, there's very little difference between CFEngine, Puppet, and Chef. > Sure the implementation of the known algorithms will be similar in Java and C++ but the overall usage and how it connects with everything (aka the workflow) will be very different. It will hardly affect how you think about the system and how you approach it. It will only affect where you get your code from. Unless you think about yourself as a guy who only puts together different libraries/modules and never ever writes own code, then of course it's a new paradigm, but I don't think you had this scenario in mind.
        holydude 9y ago
        > 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.
- cat199 9y ago
  Yes, but this also doesn't mean that one person trained in one tool can't learn the other in fairly short order, provided they understand the core principles behind it and haven't been 'brainwashed' into thinking 'this is how things work'