4 ms·

This is a perfect example of the problem in the devops world. People want to do something that has slight variations from time to time. There is a well establis

This is a perfect example of the problem in the devops world. People want to do something that has slight variations from time to time. There is a well established concept for this, called a function. Programmers use functions every day and understand their semantics. Devops tool developers do not implement functions but some other abstraction with different semantics. Programmers use this abstraction and confusion ensures. Why the people who implement these tools, who presumably are very accomplished programmers, cannot 1) see they are implementing something that is already well known and/or 2) implement it with standard semantics, is baffling to me. Kids, just say NORWAY to devops.

sherburt3 2y ago
What does NORWAY mean?
- steve_rambo 2y ago
  https://www.bram.us/2022/01/11/yaml-the-norway-problem/ https://www.bram.us/2022/01/11/yaml-the-norway-problem/
- pdimitar 2y ago
  Likely a joke with the YAML parsers that parse `NO` as the boolean value `false` when the writer of the YAML file intended to put Norway's 2-character code as a key in a map.
- svieira 2y ago
  Norway's 2 character country code abbreviation is "NO". Which is one of the many ways to spell the boolean `false` in YAML 1.0. Which is yet-another-way-to-shoot-yourself-in-the-foot with DSLs written in YAML.
- deleted 2y ago
  [deleted]
pdimitar 2y ago
That's why I plan on migrating all my shell scripts to Golang programs f.ex. using https://github.com/bitfield/script https://github.com/bitfield/script -- it already has a number of simulations of shell commands and I'd contribute others if I had the time. sh / bash / zsh scripts are just fragile and that's the inconvenient truth. People who devised the shell interpreters had good intentions but ultimately their creations grew to a scope 1000x bigger than they intended, hence all the "do X but if Y flag is set then do Z... unless flag A is also set in which case do Y and part of Z". It's horrendous and I seriously don't get what's so difficult in just coding these scripts in a programming language that provides single statically linked binaries (like Golang) and just distribute it with your images -- or run them in CI/CD and have init containers and never include them in the images in the first place. Inertia, of course. But I'll be actively working against it until I retire.
- Sebb767 2y ago
  > It's horrendous and I seriously don't get what's so difficult in just coding these scripts in a programming language that provides single statically linked binaries (like Golang) and just distribute it with your images -- or run them in CI/CD and have init containers and never include them in the images in the first place. It takes longer to develop (for sufficiently small scripts), it's harder to verify, it's harder to debug, it requires a build step and it's a lot more effort to modify it in-place. The process for calling other programs is also extremely streamlined, making it perfect for integration tasks like CI/CD pipelines. Some of these issues don't exist when using an interpreted language like Python instead, but this comes with its own problems. Shell is pretty universal, well-known and is, for sufficiently small problems, the quickest solution.
  - throwaway482945 2y ago
    Python's facilities for calling subprocesses are pretty inconvenient compared to bash IMO. It defaults to binary output instead of UTF-8 so I almost always have to set an option for that. I wind up having to define threads in order to run programs in the background and do anything with their output in real time, which has an awkward syntax. The APIs for checking the exit code vs raising an error are pretty non-obvious and I have to look them up every time. And I always wind up having to write some boilerplate code to strip whitespace from the end of each line and filter out empty lines, like p.stdout.rstrip().split('\n') which can be subtly incorrect depending on what program I'm invoking.
throwaway290 2y ago
Let's all write configuration in imperative turing-complete languages, what could go wrong...
- deleted 2y ago
  [deleted]
- playingalong 2y ago
  False dichotomy. You can also employ DSLs (domain specific languages). Plain ones or my favorite ones - as subset/SDK of generic purpose languages.
  - throwaway290 2y ago
    Imperative vs declarative is false dichotomy now? Do you know what it means
    - noelwelsh 2y ago
      It's unclear to me if your original post was claiming that Docker is a Turing-complete imperative language, or that a Turing-complete imperative language is the only alternative to Docker. It's a false dichotomy that the only points in the design space are 1) Docker and 2) a Turing-complete imperative language.
      - throwaway290 2y ago
        There is not one but two true dichotomies, one between imperative and declarative, another between tiring complete and not. If you were recommending everyone to use some general purpose language with functions that is not turing-complete then sure. Which one is it? Otherwise I will repeat, declarative purposefully limited configuration languages that you are trying to mock in your comment by picking on YAML (which relates to Docker how?) have their place and were created to solve real problems. For every Norway there are dozens of bigger issues (including security) in any regular programming language

sherburt3 2y ago

What does NORWAY mean?

steve_rambo 2y ago
https://www.bram.us/2022/01/11/yaml-the-norway-problem/ https://www.bram.us/2022/01/11/yaml-the-norway-problem/
pdimitar 2y ago
Likely a joke with the YAML parsers that parse `NO` as the boolean value `false` when the writer of the YAML file intended to put Norway's 2-character code as a key in a map.
svieira 2y ago
Norway's 2 character country code abbreviation is "NO". Which is one of the many ways to spell the boolean `false` in YAML 1.0. Which is yet-another-way-to-shoot-yourself-in-the-foot with DSLs written in YAML.
deleted 2y ago
[deleted]

pdimitar 2y ago

That's why I plan on migrating all my shell scripts to Golang programs f.ex. using https://github.com/bitfield/script https://github.com/bitfield/script -- it already has a number of simulations of shell commands and I'd contribute others if I had the time. sh / bash / zsh scripts are just fragile and that's the inconvenient truth. People who devised the shell interpreters had good intentions but ultimately their creations grew to a scope 1000x bigger than they intended, hence all the "do X but if Y flag is set then do Z... unless flag A is also set in which case do Y and part of Z". It's horrendous and I seriously don't get what's so difficult in just coding these scripts in a programming language that provides single statically linked binaries (like Golang) and just distribute it with your images -- or run them in CI/CD and have init containers and never include them in the images in the first place. Inertia, of course. But I'll be actively working against it until I retire.

Sebb767 2y ago
> It's horrendous and I seriously don't get what's so difficult in just coding these scripts in a programming language that provides single statically linked binaries (like Golang) and just distribute it with your images -- or run them in CI/CD and have init containers and never include them in the images in the first place. It takes longer to develop (for sufficiently small scripts), it's harder to verify, it's harder to debug, it requires a build step and it's a lot more effort to modify it in-place. The process for calling other programs is also extremely streamlined, making it perfect for integration tasks like CI/CD pipelines. Some of these issues don't exist when using an interpreted language like Python instead, but this comes with its own problems. Shell is pretty universal, well-known and is, for sufficiently small problems, the quickest solution.
- throwaway482945 2y ago
  Python's facilities for calling subprocesses are pretty inconvenient compared to bash IMO. It defaults to binary output instead of UTF-8 so I almost always have to set an option for that. I wind up having to define threads in order to run programs in the background and do anything with their output in real time, which has an awkward syntax. The APIs for checking the exit code vs raising an error are pretty non-obvious and I have to look them up every time. And I always wind up having to write some boilerplate code to strip whitespace from the end of each line and filter out empty lines, like p.stdout.rstrip().split('\n') which can be subtly incorrect depending on what program I'm invoking.

throwaway290 2y ago

Let's all write configuration in imperative turing-complete languages, what could go wrong...

deleted 2y ago
[deleted]
playingalong 2y ago
False dichotomy. You can also employ DSLs (domain specific languages). Plain ones or my favorite ones - as subset/SDK of generic purpose languages.
- throwaway290 2y ago
  Imperative vs declarative is false dichotomy now? Do you know what it means
  - noelwelsh 2y ago
    It's unclear to me if your original post was claiming that Docker is a Turing-complete imperative language, or that a Turing-complete imperative language is the only alternative to Docker. It's a false dichotomy that the only points in the design space are 1) Docker and 2) a Turing-complete imperative language.
    - throwaway290 2y ago
      There is not one but two true dichotomies, one between imperative and declarative, another between tiring complete and not. If you were recommending everyone to use some general purpose language with functions that is not turing-complete then sure. Which one is it? Otherwise I will repeat, declarative purposefully limited configuration languages that you are trying to mock in your comment by picking on YAML (which relates to Docker how?) have their place and were created to solve real problems. For every Norway there are dozens of bigger issues (including security) in any regular programming language