Comment by languagehacker

2 years ago

Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi.

The ever-evolving threat landscape at both the OS and application level makes this unviable for projects with any amount of money or sensitivity behind them. Imagine needing to handle an OS-level update and learning that you can no longer run Python 2 on the box you're running that project on. Fine for a blog, but calamitous for anything that handles financial transactions.

> Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi.

I think it would be the other way around. A low-impact hobby project can use exciting, fast-moving technology because if it breaks, there is not so much damage (move fast and break things). But something with high business impact should use boring, tried-and-tested technologies no external network dependencies (e.g. a package being available in a third-party repository at compile time or runtime). For something like that, the OS updates (on the LTS branch if Linux) would be planned well ahead, and there would be no surprises like the Python 2 interpreter suddenly breaking.

If you are a bank, a store, or handle PHI, you will have contractual obligations to maintain it. However, I still think that can be "cold-blooded" maintenance. When I update a Go project after running `govulncheck ./...`, it is generally easy. I vendor; builds and runtime only rely on systems I control.

  • Many large companies and business like banks and manufacturers run legacy code in ancient runtimes. The projects can be so frozen in time that nobody has the courage to touch them.

Meh, just keep a container around with py2 in it, maybe just containerize the whole app. The ultimate in vendored dependencies, short of a whole VM image.