Alt account of @Badabinski

Just a sweaty nerd interested in software, home automation, emotional issues, and polite discourse about all of the above.

  • 0 Posts
  • 136 Comments
Joined 2 年前
cake
Cake day: 2024年6月9日

help-circle



  • For future reference, you should remove set -euo pipefail and then add manual error handling to all commands which could fail. set -euo pipefail is one of the biggest, most disgusting foot guns in bash (a shit language cursed with many horrible foot guns) and does nothing but mask your problems. If every command has a unique error message, then you can much more easily track down your problems.

    To make things more ergonomic, remove the foot gun and add a die function that accepts an error message and optional exit code and calls it like this:

    echoerr() { echo "$@" 1>&2; }
    
    die() {
      message="$1"; shift
      exit_code="${1:-1}"
      echoerr "$message"
      exit "$exit_code"
    }
    
    fallible_command || die 'shit is so fucked yo'
    

    source: bash was my first language and I’ve been dealing with its bullshit personally and professionally for over 13 years now.













  • The segmented caching request thing is… weird. I worked for a company that developed a caching proxy and it very much did not work that way. Like, random access in a caching system is usually kinda bad and you should try to avoid it. Like, our proxy manually controlled the disk (it wasn’t a mounted filesystem) so it could constantly sweep the head across the disk and cue up reads and writes optimally. This gets much harder when things are fragmented as fuck.

    If the concern was about what would happen with multiple connections for the same cache miss, then the caching proxy should just combine the client-side connections into a single upstream one. You can still cache the first part of the response if your upstream connection gets terminated and then restart it from that point.