4 ms·

I feel there must be a middle ground here. It's similar to free food. Giving food to anyone does not entitle them to more food in the future. They are not ent

I feel there must be a middle ground here. It's similar to free food. Giving food to anyone does not entitle them to more food in the future. They are not entitled to complain free food is not up to their standards or demand changes. But they are entitled to not being poisoned. Basic sanitation is still required. You should remove free food from the public once it's rotting.

bee_rider 1y ago
Food is not really that similar to software. Food going bad is a universal problem of food, we should optimize our handling of food (and write all our laws) under the assumption that it is always in the process of going bad. Code doesn’t just turn dangerous on its own. Good code is good code, it can be turned bad by conscious effort on the part of somebody, but that’s an active decision that somebody makes and is responsible for. Also, all food is for eating. Code has different uses. Most is not hardened against security threats, because it is only designed to be run locally by the user, and it is total fine in that use-case. Designing code that is appropriate to be exposed unprotected to the internet is unbelievably difficult, so most code won’t be up to the task. We shouldn’t lose useful code just because it can be used out-of-scope dangerously. The risks with food are also generally higher, because almost everyone is able to ingest it. And potentially get very sick or die. So, bad food is a big risk. Bad code is not such a big risk because anyone who knows what to do with it has already passed some skill hurdles as far as understanding it goes. And it is rare to get sick or die from code. Most code should be left up, maybe with a note that says it is unmaintained, if it is unmaintained.
Cthulhu_ 1y ago
It's a broken analogy though, because in software, people (should) do some research first before picking a tool. But to extend your analogy, it's like someone comes into the free supermarket, picks peanut butter, then demands the manufacturer changes the recipe or complains after a few years because there's a new type of peanut and they want their old jar of peanut butter to be updated. I dunno, I'm stretching the analogy lol.

bee_rider 1y ago

Food is not really that similar to software. Food going bad is a universal problem of food, we should optimize our handling of food (and write all our laws) under the assumption that it is always in the process of going bad. Code doesn’t just turn dangerous on its own. Good code is good code, it can be turned bad by conscious effort on the part of somebody, but that’s an active decision that somebody makes and is responsible for. Also, all food is for eating. Code has different uses. Most is not hardened against security threats, because it is only designed to be run locally by the user, and it is total fine in that use-case. Designing code that is appropriate to be exposed unprotected to the internet is unbelievably difficult, so most code won’t be up to the task. We shouldn’t lose useful code just because it can be used out-of-scope dangerously. The risks with food are also generally higher, because almost everyone is able to ingest it. And potentially get very sick or die. So, bad food is a big risk. Bad code is not such a big risk because anyone who knows what to do with it has already passed some skill hurdles as far as understanding it goes. And it is rare to get sick or die from code. Most code should be left up, maybe with a note that says it is unmaintained, if it is unmaintained.

Cthulhu_ 1y ago

It's a broken analogy though, because in software, people (should) do some research first before picking a tool. But to extend your analogy, it's like someone comes into the free supermarket, picks peanut butter, then demands the manufacturer changes the recipe or complains after a few years because there's a new type of peanut and they want their old jar of peanut butter to be updated. I dunno, I'm stretching the analogy lol.