3 ms·

In the old days, the age-old cry of the beleaguered developer was “My code isn’t buggy, it works on my machine!”, to which the response was “We’re not shipping

by teddyh 3y ago

In the old days, the age-old cry of the beleaguered developer was “My code isn’t buggy, it works on my machine!”, to which the response was “We’re not shipping your machine to the customer!”. Well, science marches on, and we’ve invented a way to do exactly that. Instead of, you know, writing actually robust and simple-to-deploy software. See also: <https://blog.brixit.nl/developers-are-lazy-thus-flatpak/ https://blog.brixit.nl/developers-are-lazy-thus-flatpak/>

viraptor 3y ago
> Instead of, you know, writing actually robust and simple-to-deploy software. This is unfortunately much harder to do than doing docker images. If you're trying to ship a robust and simple to deploy app, you will fail at some point - you just haven't seen a system where that happens yet. You can't be robust vs unknown unknowns and what a system will look like in a couple of years (next LTS) can be very surprising.
- teddyh 3y ago
  Hacking on some code and making random changes until it works (”It works! Ship it!”) is much easier (or at least feels easier) than designing the code carefully and using tests to verify the correctness of our code. Yet for good reasons we do it the harder way. For mostly the same reasons, I’m very wary of a system image of some pre-installed software instead of packaged software which is meant to run in a variety of environments, and to be easily configured to do so. Note also that a system which is robust and adaptive to different environments today is also robust to different future environments. And nobody can escape the march of time. Everybody needs updates. TLS updates. Time zone updates. Security fixes. I’d rather have a system designed with robustness against differences as a primary concern than a system where it’s assumed that it will run in an unchanging static universe.
  - pas 3y ago
    but it is much easier to test something in a container, and even to update everything in a container "fearlessly". simply considering that we had untouchable, unreproducible and totally undocumented servers running for years in basements/cabinets as a meme (classic anecdote, common experience) can allow us to infer that laziness is not inherent to containerization
    - teddyh 3y ago
      > but it is much easier to test something in a container, and even to update everything in a container "fearlessly". Test, maybe. Develop and modify, not so much. > simply considering that we had untouchable, unreproducible and totally undocumented servers running for years in basements/cabinets as a meme (classic anecdote, common experience) can allow us to infer that laziness is not inherent to containerization Yes, but this is a cautionary tale, not an example to be followed.

by teddyh 3y ago

viraptor 3y ago

> Instead of, you know, writing actually robust and simple-to-deploy software. This is unfortunately much harder to do than doing docker images. If you're trying to ship a robust and simple to deploy app, you will fail at some point - you just haven't seen a system where that happens yet. You can't be robust vs unknown unknowns and what a system will look like in a couple of years (next LTS) can be very surprising.

teddyh 3y ago
Hacking on some code and making random changes until it works (”It works! Ship it!”) is much easier (or at least feels easier) than designing the code carefully and using tests to verify the correctness of our code. Yet for good reasons we do it the harder way. For mostly the same reasons, I’m very wary of a system image of some pre-installed software instead of packaged software which is meant to run in a variety of environments, and to be easily configured to do so. Note also that a system which is robust and adaptive to different environments today is also robust to different future environments. And nobody can escape the march of time. Everybody needs updates. TLS updates. Time zone updates. Security fixes. I’d rather have a system designed with robustness against differences as a primary concern than a system where it’s assumed that it will run in an unchanging static universe.
- pas 3y ago
  but it is much easier to test something in a container, and even to update everything in a container "fearlessly". simply considering that we had untouchable, unreproducible and totally undocumented servers running for years in basements/cabinets as a meme (classic anecdote, common experience) can allow us to infer that laziness is not inherent to containerization
  - teddyh 3y ago
    > but it is much easier to test something in a container, and even to update everything in a container "fearlessly". Test, maybe. Develop and modify, not so much. > simply considering that we had untouchable, unreproducible and totally undocumented servers running for years in basements/cabinets as a meme (classic anecdote, common experience) can allow us to infer that laziness is not inherent to containerization Yes, but this is a cautionary tale, not an example to be followed.