OpenBSD version: Not relevant here... Arch: ? NSFP: Well...
The German hacker community is a relatively old community of people doing things with computers. To have a space to do things, an abundance of hackerspaces sprouted up in Germany. All these spaces are very different in their look, feel, and local social setup.
Still, they have one thing in common.
All of these hackerspaces experience the issue of ‘unreliable’ payments being provided for the drinks usually available via a public fridge, paid for in an honor system.
Usually and periodically, several tech-savvy people start to implement a complex digital cash-and-credit system to solve this issue, usually in a way that also includes a touch-screen and/or a RasberryPi.
Ultimately, that approach will suffer from limited adoption and the same issues as before, and a social solution will have to be found.
If the community is very unlucky, the technical solution also introduces new social problems.
The insufficient solution nevertheless stays in place, usually until the next generation of local nerds experiences this issue, and repeats the circle.
To summarize this with colloquial wisdom from the
Industry 4.0'' and production industry:Digitizing a shitty process won’t result in a better process, but in a digitized shitty process’’.
However, these (repeating) observations around a local communities of hackers trying to fiddle together a technical solution for a social problem lead to a long-standing dictum in the German hacker community:
“There are no technical solutions for social and societal problems.”
The point here is that we try to apply the same ‘solving social problems with technical solutions’ reasoning to problems we are facing at the much larger scale of the Internet. We are computer scientists, and the hammer we wield is that of technology. So every problem we encounter looks like a technology shaped nail.
We consistently face the impact of—ultimately—social and societal issues (operators announcing routes they should not}, attackers launching DoS attacks using amplifiers—and operators running amplifiers or failing to implement BCP38. To counter them, we developed technical solutions, for example, RPKI to handle the issue of routes being announced by entities that should not announce them.
Of course, this attitude is not only limited to the Internet and its own wealth of problems. Instead, ‘tech people’ are really good at trying to solve everything with an app.
Given the example of the drink accounting system, though, the real question is, what a better solution would be. And whether we shouldn’t, for a moment “stop wondering whether we could, and start thinking whether we should”.