3 ms·

I interpreted it as "Software is crap, and it's hard to make crap work offline. The problem is not the offline, it's the crap." The question is where to lay th

I interpreted it as "Software is crap, and it's hard to make crap work offline. The problem is not the offline, it's the crap." The question is where to lay the blame for the crap, and how to change that. I would love to see the author's "lists" turned into a table of sorts, and then any given piece of software could be rated by how many situations on each list it works in without modification, works in with trivial config tweaks, works in with more elaborate measures, or cannot work in. Turn the whole table green and your software is more attractive to certain environments.

karmarepellent 2y ago
I don't think it's always the software that is to blame. Sure there is software that wants to self-update and only accepts one upstream update source run by the vendor, instead of allowing users to run their own mirror and control update distribution to some extent. But there are also cases where the software could be perfectly run in air-gapped systems but people are unwilling to put in the work (for some reason or another). For example everyone could run their own Docker image mirror that only contains images that are actually needed and pulls them from upstream with some delay. Docker allows you to pull images from your own registry. But not veryone is willing to operate their own registry.