6 ms·

> You don't need to reproduce that working state: The work has already been done! My background is physics, and the philosophy there is "If you can't reproduce

by adekok 10y ago

> You don't need to reproduce that working state: The work has already been done! My background is physics, and the philosophy there is "If you can't reproduce it, it doesn't exist." In my experience with software, sharing opaque binary blobs is a Bad Thing. It doesn't matter if the blob is a proprietary firmware image, or a "open source" docker image. It's a magic unreproducible image. And (to me, at least) therefore suspect. > Docker package management is like that: You make some changes, you commit often, fork your instance and try lots of different things. Eventually you find something that works and you tag it. Again, the physics philosophy is "If you don't know what you did, you didn't do it". For software, programming by randomly trying things is one of the worst methods available. You should understand what you're doing, and understand the system you're building. > You share your tags with other people. This is an extremely productive way to get work done. Sure. It's a way to quickly create, test, roll back, and share opaque binary blobs. It's "productive" in that you get things done. But you have no real idea what you got done. You just have a magic image that "works". I would not hire a programmer with that kind of attitude. I've been burnt by that method, and those kind of programmers, too many times.

Keats 10y ago
We wrote an article about the same thing https://blog.wearewizards.io/why-docker-is-not-the-answer-to-reproducible-research-and-why-nix-may-be https://blog.wearewizards.io/why-docker-is-not-the-answer-to... (Tom has a background in physics as well)
- geocar 10y ago
  You are assuming "that reproducibility is good". I believe this assumption needs to be challenged.
  - coldtea 10y ago
    Any significant contribution you might have for software engineering in regards to that? Aside from merely believing that. I can't even tell what you mean. If I want to rebuild my machine same as before, or deploy build 100s of servers at different points in time with the same setup, reproducibility is necessary. There's not even one argument against that. If you have any, please oblige us. Should deployments be a surprise?
    - geocar 10y ago
      > If I want to rebuild my machine same as before, or deploy build 100s of servers at different points in time with the same setup, reproducibility is necessary. No it isn't. Reproducible is talking about the process or steps needed to make a machine. You do not need to repeat the steps to produce the first machine to produce the second machine. You can simply clone the first machine, and Docker makes this very easy to do. Keats begins his article with the statement offered, without justification: In this post I'm going to assume that reproducibility is good and necessary. Since I don't believe that, and in fact believe the opposite, I take issue with the entire article. Indeed, he goes on to construct a straw man comparing the exact opposite of what I propose -- a non-interactive "dockerfile" and not even a particularly good one, with a very well thought-out "purely functional" build system. > Any significant contribution you might have for software engineering in regards to that? I don't know of any big technology company that doesn't design their live infrastructure around ephemeral machines cloned from a template. They don't all use Docker, and they don't all use interactive development, however, but these two tools can make it easier for people who (for example) don't have Google's economy of scale. > Should deployments be a surprise? No they should not. Deployments take less time with my interactive method because you do not have to wait to "rebuild everything" which can take hours. Remember heartbleed? People using nixos had to rebuild every component that used OpenSSL, then test them, then find something else broke and repeat the process. Only once they had finished building their new process could they roll out this process to all machines, doing one more final rebuild. Even if done perfectly this has a minimum of two iterations. I could simply create a new clone, get it working, then tag it as the next release. New instances can then be cloned from the release, monitored, and the old instances destroyed. The entire process took under an hour for the entire fleet, including reading about heartbleed on HN. This is clearly almost as fast as running `apt-get dist-upgrade` on each of the live systems, but without any of the risk. The organisational complexity, however is admittedly much higher than "wash, wait, repeat", which is why most system administrators could not even begin to use live clones until virtualization and tooling had become much more commonplace. > I can't even tell what you mean. And yet you feel qualified to tell me I'm wrong.
      - coldtea 10y ago
  - Keats 10y ago
    So let's say you are deploying 10 servers. Are you fine with all of them being different? Or to get out of computers, you have a drug where they say it cures cancer 100% of the time and no one can reproduce the results, it's fine for you?
    - geocar 10y ago
      Straw man. Reproducible in this case is talking about the process or steps needed to make a machine. You do not need to repeat the steps to produce the first machine to produce the second machine. You can simply clone the first machine, and Docker makes this very easy to do. That I can clone a machine does not mean that I can clone the interaction between a patient and their drugs, but if I could it would most certainly be preferable to trying to repeat the experiments with larger and larger populations.
loudlambda 10y ago
> If you can't reproduce it, it doesn't exist. I can't reproduce me, so do I not exist?
geocar 10y ago
> In my experience with software, sharing opaque binary blobs is a Bad Thing And yet you don't know why. This is called dogma, and dogma is bad: It leads people to make stupid decisions over and over, all the while repeating that the alternative is worse.
- Singletoned 10y ago
  No, this is called learning from experience. If you put your hand in a fire 5 times and it burns you 5 times, you don't have to understand anything about fire to know that you should probably stop putting your hand in. And if you saw other people about to put their hand in, you would mention to them that everytime you put your hand in, you end up regretting it.
  - geocar 10y ago
    And yet, here I have asbestos gloves and I can put them in the fire just fine. This allows me to work faster and get done without waiting a day for the fire to run out of fuel. We don't need religion to keep from getting burned when we have tools.
    - Singletoned 10y ago
      And again, you don't need to have any understanding of asbestos in order for the gloves to work. You can believe that they are magic gloves from God, and they will work just as well.
- adekok 10y ago
  > This is called dogma, Then you don't know what the word "dogma" means. What I said was "In my experience." i.e. practice learned over time. This cannot be interpreted by any reasonable person as "blobs are bad, just 'cause." That kind of straw man argument leads me to conclude that similar issues are being your inability to understand the use of reproducability.
  - geocar 10y ago

by adekok 10y ago

Keats 10y ago

We wrote an article about the same thing https://blog.wearewizards.io/why-docker-is-not-the-answer-to-reproducible-research-and-why-nix-may-be https://blog.wearewizards.io/why-docker-is-not-the-answer-to... (Tom has a background in physics as well)

geocar 10y ago
You are assuming "that reproducibility is good". I believe this assumption needs to be challenged.
- coldtea 10y ago
  Any significant contribution you might have for software engineering in regards to that? Aside from merely believing that. I can't even tell what you mean. If I want to rebuild my machine same as before, or deploy build 100s of servers at different points in time with the same setup, reproducibility is necessary. There's not even one argument against that. If you have any, please oblige us. Should deployments be a surprise?
  - geocar 10y ago
    > If I want to rebuild my machine same as before, or deploy build 100s of servers at different points in time with the same setup, reproducibility is necessary. No it isn't. Reproducible is talking about the process or steps needed to make a machine. You do not need to repeat the steps to produce the first machine to produce the second machine. You can simply clone the first machine, and Docker makes this very easy to do. Keats begins his article with the statement offered, without justification: In this post I'm going to assume that reproducibility is good and necessary. Since I don't believe that, and in fact believe the opposite, I take issue with the entire article. Indeed, he goes on to construct a straw man comparing the exact opposite of what I propose -- a non-interactive "dockerfile" and not even a particularly good one, with a very well thought-out "purely functional" build system. > Any significant contribution you might have for software engineering in regards to that? I don't know of any big technology company that doesn't design their live infrastructure around ephemeral machines cloned from a template. They don't all use Docker, and they don't all use interactive development, however, but these two tools can make it easier for people who (for example) don't have Google's economy of scale. > Should deployments be a surprise? No they should not. Deployments take less time with my interactive method because you do not have to wait to "rebuild everything" which can take hours. Remember heartbleed? People using nixos had to rebuild every component that used OpenSSL, then test them, then find something else broke and repeat the process. Only once they had finished building their new process could they roll out this process to all machines, doing one more final rebuild. Even if done perfectly this has a minimum of two iterations. I could simply create a new clone, get it working, then tag it as the next release. New instances can then be cloned from the release, monitored, and the old instances destroyed. The entire process took under an hour for the entire fleet, including reading about heartbleed on HN. This is clearly almost as fast as running `apt-get dist-upgrade` on each of the live systems, but without any of the risk. The organisational complexity, however is admittedly much higher than "wash, wait, repeat", which is why most system administrators could not even begin to use live clones until virtualization and tooling had become much more commonplace. > I can't even tell what you mean. And yet you feel qualified to tell me I'm wrong.
    - coldtea 10y ago
- Keats 10y ago
  So let's say you are deploying 10 servers. Are you fine with all of them being different? Or to get out of computers, you have a drug where they say it cures cancer 100% of the time and no one can reproduce the results, it's fine for you?
  - geocar 10y ago
    Straw man. Reproducible in this case is talking about the process or steps needed to make a machine. You do not need to repeat the steps to produce the first machine to produce the second machine. You can simply clone the first machine, and Docker makes this very easy to do. That I can clone a machine does not mean that I can clone the interaction between a patient and their drugs, but if I could it would most certainly be preferable to trying to repeat the experiments with larger and larger populations.

loudlambda 10y ago

> If you can't reproduce it, it doesn't exist. I can't reproduce me, so do I not exist?

geocar 10y ago

> In my experience with software, sharing opaque binary blobs is a Bad Thing And yet you don't know why. This is called dogma, and dogma is bad: It leads people to make stupid decisions over and over, all the while repeating that the alternative is worse.

Singletoned 10y ago
No, this is called learning from experience. If you put your hand in a fire 5 times and it burns you 5 times, you don't have to understand anything about fire to know that you should probably stop putting your hand in. And if you saw other people about to put their hand in, you would mention to them that everytime you put your hand in, you end up regretting it.
- geocar 10y ago
  And yet, here I have asbestos gloves and I can put them in the fire just fine. This allows me to work faster and get done without waiting a day for the fire to run out of fuel. We don't need religion to keep from getting burned when we have tools.
  - Singletoned 10y ago
    And again, you don't need to have any understanding of asbestos in order for the gloves to work. You can believe that they are magic gloves from God, and they will work just as well.
adekok 10y ago
> This is called dogma, Then you don't know what the word "dogma" means. What I said was "In my experience." i.e. practice learned over time. This cannot be interpreted by any reasonable person as "blobs are bad, just 'cause." That kind of straw man argument leads me to conclude that similar issues are being your inability to understand the use of reproducability.
- geocar 10y ago