What Permacomputing Is Not
Because the boundaries of Permacomputing are not subject to a hard and formal definition, there is a lot of confusion around just what exactly "counts". When looking into the topic, you may have found some prominent examples of the practice, or some other things that feel synonymous. In reality, the scope of what we mean by "Permacomputing" can be more or less than the image these sources conjure in your mind.
This essay is an attempt to help bring some of these boundaries into clearer focus. They will never be sharp lines with firm rules, but we can identify some practices that are orthogonal (or even antithetical) to the practices observed by Permacomputing communities in the 2020s.
I hope to illustrate the ways in which Permacomputing is not any of these things:
- hierarchical
- ascetic
- nostalgic
- individualist
Permacomputing is not Hierarchical
One of the reasons that people have trouble understanding definitions is that we deliberately avoid them. We have certain shared concerns and goals, but don't define "permacomputing kits" or formal lists of "permacomputing tools". There is no Permacomputing Certification Authority to rule on how "perma" your computer is.
One resource that shows up prominently in search results is the Hundred Rabbits talks on Permacomputing by Devine Lu Linvega. Their practice involves low-power disconnected living on a sailboat in the Pacific Ocean, and they have developed tools such as Uxn in service of this. A lot of the writing about Permacomputing comes from their lived experience and that of their shared communities of practice online.
It would be easy to read through these materials, then, and think "Is Permacomputing necessarily built on stack-based concatenative assembly languages? Is this only about Forth?"
It is most certainly not limited to Forth! It's true that Forth has become something of a meme in permacomputing circles, and newcomers may not understand how much of this is tongue-in-cheek.
To illustrate this principle, here are some living projects that prove this. These things, and others similar to them, can be Permacomputing. They range from 8-bit BASIC and Forth computers to 32-bit Lua programming tools and low-pixel-count photography festivals. They include Linux distributions you can install on old phones or tablets, power monitoring for your existing devices, and ways to distribute site hosting on solar-powered nodes so your traffic "follows the sun".
I say "can be" because it's always possible for a project with noble aims and incredible promise to change. Goals shift, and sometimes people make trade-offs that ultimately thwart the original aims. Permacomputing is about those goals, and that is why our descriptions of methods and approaches are so fuzzy.
So let's understand these "can be"s by looking at things that don't fit. Many of these things are fine on their own, or for their own different goals, but they simply aren't Permacomputing.
Permacomputing is not Nostalgic
Researching practices for low-powered computing on older hardware requires reaching into the past. The historical record has a lot to teach us, and there are approaches to programming and using computers that have become neglected or even forgotten in the present day.
But someone finding fault with modern practices and seeing a solution in the past may risk thinking "Truly, things were better, then!" This is a trap.
Such a sense of longing likely says more about your relationship with your own past than it does about building sustainable practices into the future. It may be a true experience that provides personal insights, but Permacomputing is about the potential inherent in existing resources and finding new possibilities for them.
Permacomputing does not hope to "RETVRN" to any sort of "golden age", and as students of History we are deeply sceptical of such a lens.
Permacomputing is not Aesthetic
Or, put another way: Permacomputing is not Retrocomputing. This may surprise a lot of people, as both practices work to preserve and use old systems.
Permacomputing practitioners may take time to step back occasionally and admire the aesthetics of older computing systems. They may relish the design language of hardware and manuals, or the coding styles of older generations of programmers. There is absolutely room for the appreciation of beauty in Permacomputing.
But while this may be a sufficient condition for some Retrocomputing enthusiasts, it is not even a requirement for Permacomputing. Retrocomputing folks may buy brand-new hardware to experience older systems, or use unethically-generated "AI" systems to produce art in the style of 1980s computer graphics or packaging. Neither of these fit the sustainability goals of Permacomputing.
Permacomputing is not Ascetic
Making do with less can be difficult, at first. Early responses to energy shocks in the 1970s involved quick patches like individuals lowering their thermostat settings and living in slightly colder conditions. The real response came later, as people installed insulation in their homes, allowing them to achieve more warmth while consuming less energy.
It might be frustrating to get used to new computing practices, whether they're end-user tools, patterns of network connection, or programming techniques. We may need to do more ourselves, and rely less on the services of large corporations. But these frustrations are not themselves the goal.
Permacomputing puts its hopes in the communities we build to help us all make computing more pleasant and enjoyable, while consuming less energy and producing less waste. We do this not to prove our own endurance, but to help one another.
Permacomputing is not Individualistic
There is a movement known as "Suckless", who aim to keep software simple enough that the source code can be understood by its users. They decry the waste of resources in modern systems, and write tools that still work on hardware from the 1990s.
This would seem simpatico with the Permacomputing, until you look deeper. The primary attitude of the "suckless" community is right there in their name. They just want you to feel like you "suck" unless you're doing things their way. Their advice for any computing system they enjoy is effectively "get good". To them, the answer to any computing problem is one of personal improvement.
And when you speak to many of the advocates for this system, you will discover that among the features that they see as "overcomplicated" or "wasteful" are accessibility aids. They gleefully rid themselves of affordances for visually impaired or Deaf users of their software, or anyone who isn't fluent in both English and C89.
It is perhaps no surprise, then, that the most prominent hits on YouTube for this movement include channels that mix technical commentary with self-improvement talks and hard-right-wing political essays.
There is no political purity test in Permacomputing. Some have blanched at the phrase "post-marxism" on the front page (and somehow misread it as "Marxist-Leninist" or something), but that's just one of many frameworks used to approach the topic. The unifying factor is our focus on building communities rather than individuals. This inevitably leads to strong scepticism around Libertarian schools of thought.
This is not to say that personal empowerment is seen as a problem in Permacomputing circles! If anything, we hope to build systems that free individuals to make more choices than they could under modern corporate-controlled computing. But we do not require individuals to pass some sort of skill test to join in.
So what is it?
Permacomputing aspires to take the enormous number of technological artefacts we already have, and make the best use of them to improve the future for everyone. It's a vast, expansive definition with active and healthy discourse all around its perimeter. I don't intend to resolve these debates in a single essay, but I hope newcomers might find this list of antipatterns instructive for gaining an intuitive feel for the shape of the movement.
-- spacehobo