This is a concept still in the making. I came across a few people discussing it, and I found next to nothing about it online. I thought it is important and I post it here to give it some traction.
The core idea that appealed to me is that it extends the idea that the processing power and bandwidth of modern devices is not used for our own sake, but to better funnel behavioral data to corporations.
So it is not just “so stupid design” that “we don’t even feel devices are 10x faster than 15 years ago”, but deliberate design to use the hardware capabilities for the sake of other people’s computers.
The countercomputing philosophy asks, down to the chipset, what is the most repairable, reusable component, that can help the user fortify their computing and harness it as independently as possible.
It is obviously a thought that resonates with the right-to-repair movement, privacy, and other politics related with renewable energy, but with a particular focus in selecting each and every component so that we own the hardware and we can use it as we see fit. Other links can be drawn to the smallnet initiatives such as gemini protocol, alternative nets like Reticulum, and of course open hardware.
The retro angle can offer flexibility to movements to rely on simpler components and adjust their needs, something that will also lead to greater independence from Nvidia and the like.
As I said, there are very few people discussing this idea right now, and you can’t find much online, but it is worth to “look out for” possible developments in the future.
To my limited understanding, better use of hardware requires both some level of standardization of hardware and better optimized software, with lower level programming languages if possible. Vibe coded Electron apps are never going to be as well optimized as something made to run a particular chipset. But how do we accomplish that when most programming is being done on high level programming languages? It seems that the industry has prioritized human readable code and improved UX over hardware efficiency, which at a surface level isn’t the worst trade-off.
I ultimately agree with this vision, and it’s a serious problem I’ve contemplated as well. That said, what’s the right balance between more efficient, repairable hardware and accessible, more readable code?