5 ms·

I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle;

I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle; I have a proof of n>0 that this is not the case compared to many other solutions, this post making that point too. Sh/bash/perl(8) have been around forever, they don't break after update etc. I sadly don't recommend it for my day job, simply because of liability. When something messes up with ansible, terraform, docker, cloudformation etc, no-one gets any blame because 'complex systems', 'it happens' etc etc; with a simple script going wrong, they would hang me high even though it probably saves a crap load in maintenance, compute etc over the 10s of years. Same reason we use clusters and IaC while of course nothing we do needs it; if an aws cluster goes down, no-one but aws gets blamed, while if the $2 postgres vps@cheapafhosting (with an higher uptime than that aws cluster by the way; human error downed it a few times, short, but still) is down even for a ping, everyone is upset and pointing fingers.

cqqxo4zV46cp 3y ago
[flagged]
- adamtaylor_13 3y ago
  If we’re using the script in the post as an example, that’s hardly a “mess” of shell scripts. I’d rather maintain that than almost any other build system I’ve ever seen.
- mattbuilds 3y ago
  It’s funny because in my many years of development I don’t think I’ve ever encounter a “mess of shell scripts” that was difficult to maintain. They were clear, did their job and if they needed to be replaced it was usually simple and straightforward. Can’t say the same for whenever the new abstraction of the day comes along. In my experience what the OP is saying is exactly my experience. The abstractions get picked not because they are best but because they reduce liability.
  - from-nibly 3y ago
    Hello. I have found the mess of shell scripts. Please don't do this. I was able to deal with the weird skaffold mess by getting rid of it, and replacing it with argocd. I was able to get rid of jenkins by migrating to github actions. I have yet to replace the magic servers with magic bash scripts. They take just enough effort that i can't spend the time. Use a tool i can google. If your bash script is really this straight forward and takes you from standard A to standard B, and it's in version control then bash is AMAZING. Please don't shove a rondom script that does a random thing on a random server.
    - Danjoe4 3y ago
      Bash is good but can grow out of control. The problem is solo engineers and managers who push/approve 500+ line bash scripts that do way too much. A good engineer will say it's getting too complicated and reimplement it in Python.
    - ffsm8 3y ago
      Wasn't there a rule about that? Something like "in software development the only solution that sticks is the bad one, because the good ones will keep getting replaced until it's so bad, nobody can replace it anymore"
  - kragen 3y ago
    i have encountered messes of shell scripts that were difficult to maintain; in my first sysadmin job in 01996 i inherited a version control system written as a bunch of csh scripts, built on top of rcs but they were messy not because they lacked 'abstractions' but because they had far too many i think shell scripts are significantly more bug-prone per line than programs in most other programming languages, but if the choice is hundreds of thousands of lines in an external dependency, or a ten-line or hundred-line shell script, it's easy for the shell script to be safer
    - chasil 3y ago
      If it was in RCS, then you could directly move the archives under a CVSROOT and use them natively. CVS had been out since Brian Berliner's version of 1989. I actually moved a PVCS archive into RCS->CVS this way, and I'm still using it.
- runlaszlorun 3y ago
  I don’t think ‘axe to grind’ was what I took away from the comment. And if it’s a ‘mess of shell scripts’, I can’t imagine any of the mentioned solutions to this being better. I think we lose focus of the fact that we invented a whole new career track- devops. And it basically is about getting code from developers’ machine or environments to production. And we’re still terrible at it. Perhaps that should be a signal that we’re doing it wrong…
  - candiddevmike 3y ago
    There is a constellation of companies (living and dead) that have attempted to solved this problem in different ways because everyone thinks we're doing it wrong. The reality is every company has different needs. There isn't (will never be?) a one-size-fits-all approach to deployments because they're the fun intersection of people/process/technology. The best deployment pipeline is the one that no one notices. Everything else is yak shaving/bike shedding.
- forinti 3y ago
  Just yesterday I was working on a monitoring agent that was a python script deployed through gitlab-ci, and executed inside a docker container through logstash. I bet you could do the same with about 5 lines of shell (wget|grep|curl -XPOST). It would be simpler, easier to modify, and it wouldn't ever break. Shell scripts aren't necessarily messy or complex.
  - kragen 3y ago
    python is a particularly bad choice for things that are not supposed to break; the python maintainers have adopted a new policy of intentionally breaking new things every release. recent casualties include asyncore, distutils, and imp https://docs.python.org/3/whatsnew/3.12.html#removed https://docs.python.org/3/whatsnew/3.12.html#removed there are people who foolishly depend on python for things that need to work. i hope that at some point they band together behind a fork that doesn't pull this kind of nonsense, but for the time being, that hasn't happened. if you wrote stuff in python in 01995 or 02000 or 02005 it probably still worked in 02015, but today, basically no python from before 02015 works
    - icedchai 3y ago
      Perhaps don't upgrade your Python willy-nilly? That seems like a sane solution to this problem.
      - kragen 3y ago
        debian stable no longer has python 2. debian's pypy package has its own fork of cpython 2 in order to be able to build itself. numerous other projects are doing similar things debian's versioning system for packages doesn't really contemplate needing to install old versions of a package because the maintainers are deliberately breaking new versions of it, so in 'bookworm' debian 12.5, the only cpython available to install is python 3.11. so if you want to 'not upgrade python' you are going to have to take on the maintenance burden of the old versions yourself; debian isn't going to help some other package managers handle this kind of situation better (nix is notably excellent at it) but that doesn't really help with the maintenance burden of keeping up with security fixes
- yjftsjthsd-h 3y ago
  Are you sure you're not the one grinding an axe? Shell scripts are a mess but YAML isn't? On the happy path they can both be fine, and on the unhappy path they both suck.
- icedchai 3y ago
  Most CI/CD configurations are also a mess. Often YAML, shell command snippets, weird conditional syntax... I can't say it's better.
- mdekkers 3y ago
  > nobody wants to maintain your mess of shell scripts. Have you seen the scripts in question? Are you in any kind of way able to make such a value judgement over this persons work? Have you considered the impact of your choice of words on others?
- dang 3y ago
  You've been breaking the site guidelines frequently lately by posting much too aggressively. We have to ban accounts that won't stop doing this, so if you'd please stop doing this, that would be good. HN is for thoughtful, respectful, curious conversation—not attacking other users or elbowing. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

cqqxo4zV46cp 3y ago

[flagged]

adamtaylor_13 3y ago
If we’re using the script in the post as an example, that’s hardly a “mess” of shell scripts. I’d rather maintain that than almost any other build system I’ve ever seen.
mattbuilds 3y ago
It’s funny because in my many years of development I don’t think I’ve ever encounter a “mess of shell scripts” that was difficult to maintain. They were clear, did their job and if they needed to be replaced it was usually simple and straightforward. Can’t say the same for whenever the new abstraction of the day comes along. In my experience what the OP is saying is exactly my experience. The abstractions get picked not because they are best but because they reduce liability.
- from-nibly 3y ago
  Hello. I have found the mess of shell scripts. Please don't do this. I was able to deal with the weird skaffold mess by getting rid of it, and replacing it with argocd. I was able to get rid of jenkins by migrating to github actions. I have yet to replace the magic servers with magic bash scripts. They take just enough effort that i can't spend the time. Use a tool i can google. If your bash script is really this straight forward and takes you from standard A to standard B, and it's in version control then bash is AMAZING. Please don't shove a rondom script that does a random thing on a random server.
  - Danjoe4 3y ago
    Bash is good but can grow out of control. The problem is solo engineers and managers who push/approve 500+ line bash scripts that do way too much. A good engineer will say it's getting too complicated and reimplement it in Python.
  - ffsm8 3y ago
    Wasn't there a rule about that? Something like "in software development the only solution that sticks is the bad one, because the good ones will keep getting replaced until it's so bad, nobody can replace it anymore"
- kragen 3y ago
  i have encountered messes of shell scripts that were difficult to maintain; in my first sysadmin job in 01996 i inherited a version control system written as a bunch of csh scripts, built on top of rcs but they were messy not because they lacked 'abstractions' but because they had far too many i think shell scripts are significantly more bug-prone per line than programs in most other programming languages, but if the choice is hundreds of thousands of lines in an external dependency, or a ten-line or hundred-line shell script, it's easy for the shell script to be safer
  - chasil 3y ago
    If it was in RCS, then you could directly move the archives under a CVSROOT and use them natively. CVS had been out since Brian Berliner's version of 1989. I actually moved a PVCS archive into RCS->CVS this way, and I'm still using it.
runlaszlorun 3y ago
I don’t think ‘axe to grind’ was what I took away from the comment. And if it’s a ‘mess of shell scripts’, I can’t imagine any of the mentioned solutions to this being better. I think we lose focus of the fact that we invented a whole new career track- devops. And it basically is about getting code from developers’ machine or environments to production. And we’re still terrible at it. Perhaps that should be a signal that we’re doing it wrong…
- candiddevmike 3y ago
  There is a constellation of companies (living and dead) that have attempted to solved this problem in different ways because everyone thinks we're doing it wrong. The reality is every company has different needs. There isn't (will never be?) a one-size-fits-all approach to deployments because they're the fun intersection of people/process/technology. The best deployment pipeline is the one that no one notices. Everything else is yak shaving/bike shedding.
forinti 3y ago
Just yesterday I was working on a monitoring agent that was a python script deployed through gitlab-ci, and executed inside a docker container through logstash. I bet you could do the same with about 5 lines of shell (wget|grep|curl -XPOST). It would be simpler, easier to modify, and it wouldn't ever break. Shell scripts aren't necessarily messy or complex.
- kragen 3y ago
  python is a particularly bad choice for things that are not supposed to break; the python maintainers have adopted a new policy of intentionally breaking new things every release. recent casualties include asyncore, distutils, and imp https://docs.python.org/3/whatsnew/3.12.html#removed https://docs.python.org/3/whatsnew/3.12.html#removed there are people who foolishly depend on python for things that need to work. i hope that at some point they band together behind a fork that doesn't pull this kind of nonsense, but for the time being, that hasn't happened. if you wrote stuff in python in 01995 or 02000 or 02005 it probably still worked in 02015, but today, basically no python from before 02015 works
  - icedchai 3y ago
    Perhaps don't upgrade your Python willy-nilly? That seems like a sane solution to this problem.
    - kragen 3y ago
      debian stable no longer has python 2. debian's pypy package has its own fork of cpython 2 in order to be able to build itself. numerous other projects are doing similar things debian's versioning system for packages doesn't really contemplate needing to install old versions of a package because the maintainers are deliberately breaking new versions of it, so in 'bookworm' debian 12.5, the only cpython available to install is python 3.11. so if you want to 'not upgrade python' you are going to have to take on the maintenance burden of the old versions yourself; debian isn't going to help some other package managers handle this kind of situation better (nix is notably excellent at it) but that doesn't really help with the maintenance burden of keeping up with security fixes
yjftsjthsd-h 3y ago
Are you sure you're not the one grinding an axe? Shell scripts are a mess but YAML isn't? On the happy path they can both be fine, and on the unhappy path they both suck.
icedchai 3y ago
Most CI/CD configurations are also a mess. Often YAML, shell command snippets, weird conditional syntax... I can't say it's better.
mdekkers 3y ago
> nobody wants to maintain your mess of shell scripts. Have you seen the scripts in question? Are you in any kind of way able to make such a value judgement over this persons work? Have you considered the impact of your choice of words on others?
dang 3y ago
You've been breaking the site guidelines frequently lately by posting much too aggressively. We have to ban accounts that won't stop doing this, so if you'd please stop doing this, that would be good. HN is for thoughtful, respectful, curious conversation—not attacking other users or elbowing. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html