(2023-04-08) On permacomputing, frugal computing and other buzzwords
--------------------------------------------------------------------
First off, I was delighted to know that there already is an IRC client
written in pure Bash, so that I don't have write it myself. It's called
Birch and I gave it a shoutout on my main hoi.st page. It's a nice proof
that everything is possible if you're involved enough. It's great. I'm proud
of whoever made it. It's cool to know I'm not alone in it. Let BashNet
flourish!

Now, onto the today's topic. One of the many things that eventually brought
me here was some (not big, but some) practice in contribution to the
computing minimalism world: reading about VTL-2, CHIP-8, BytePusher, Uxn,
creating a CHIP-8 emulator for KaiOS, creating a 999-byte BytePusher engine
in JS, implementing a KaiOS-compatible Uxn core, SPARTA/ESOP specs that
probably may never be finished (although ESOP is closer to a working model,
but that's it, a model), and finally, inventing my own Equi and NRJ-OISC VM
architectures (I guess I'll dedicate another post to them someday soon) that
I still have to write most of the standard library for, and implementing
them in pure C. Again, it's not much, and I don't even try to compare my
experience to the creators' of Uxn/Uxntal or even BytePusher, but I dove at
some depth into all this and naturally have read some supporting material.

So, among this material, I frequently encountered terms like
"permacomputing", "frugal computing", "salvage computing", "sustainable
computing", "degrowth computing" and even "vernacular computing". While the
overall idea behind all this looks simple, I really was a bit dazzled by
this amount of buzzwords coming at me to highlight this idea and different
aspects of it. But if we remove all this fancy cover, what's left that
actually matters? If you look up any of these buzzwords on the "big Web"
(which, ironically enough, doesn't have a place in any of these models that
would truly work), you'll see all the history of the terms and who coined
them, but again, it's not so important. What is important is that they all
point to the same single fundamental fact:

1. We consume much more resources than we really need to fulfill our
day-to-day computational tasks.

And that is the essence everything boils down to. Now, different authors may
go differently about what kind of resources we're talking about. All of them
agree that it's about energy resources users themselves consume, most of
them also add the energy required to manufacture the computing devices and
also to maintain all the networking infrastructure and so on. Some authors
even count all the material resources as a whole, from start to finish.
Like, if your ancient Spectrum consumes more electrical power than your
(still old but newer) Symbian phone but you got the Spectrum for free and
it's still working but you had to spend some money on the phone, then your
Spectrum is considered more frugal overall, especially when considering all
the resources required to manufacture that phone and deliver it to you as
well. Now, that's a radical kind of vision even to me but I even know some
people IRL who stick to it. Then, the "permacomputing" and "sustainable
computing" notions also bring us to another point that is no less
fundamental for them:

2. Computational hardware and its software must be designed in a way that
makes repairing it, replacing its parts or, when it's necessary, recreating
it entirely from scratch as easy as possible.

Now, if we return to our example, that's where your Symbian phone definitely
loses to the Spectrum. I knew some folks who soldered Spectrum clones
themselves, but I know no one who built their own GSM cellphone. With their
own baseband and everything, I mean, not some ready-made baseband module
boards like SIM800C (although I think a phone with pluggable SIM800's would
be a great start). Because, despite its size, it's much more complicated
inside. If you were building your own cellular radio module from scratch,
then AMPS (not even DAMPS) or basic unscrambled NMT would be your best bet.
They were simple and reliable enough to be reimplemented by anyone, maybe
that was the _real_ reason why they were phased out. But for the time being,
I guess, real wireless permanetworking lives on the amateur radio bands with
all their stuff like AX.25, APRS and other data transfer protocols. With the
initiatives like HSMM, if you're careful and skillful enough, you can even
repurpose spare WLAN routers to create independent networks on a longer
distance. Also, for shorter transmissions, don't forget about FM repeater
satellites ([1]). Why? Just because.

But I digress. Let's go back to the buzzwords. For my own vision, I've
decided to stick to the term "low-power computing" that reflects what's most
important to me in all this, and, I believe, doesn't require any explanation
to anyone new to the scene. This term encompasses both low wattage
consumption, which automatically means energy footprint reduction, and low
processing speed, which automatically means keeping old devices usable these
days and designing software to be able to run on as many of them as
possible. I guess I just can't find a better term for my ideal model.
Low-power computing. LPC.

Of course, not all LPC hardware that suits my model necessarily suits
viznut's "permacomputing" vision. A bright example would be an old
scientific+programmable calculator given to me by a close friend of mine,
the Casio fx-3400P, which I consider a near-perfect piece of LPC hardware as
it runs off a single battery for over 5 years provided you calculate
something every day for an entire hour, and also has a solar panel enough to
power all the calculations without a battery. I don't know how old this
particular calculator is (although they say the model was introduced in
1988, so probably older than me) but it still works like new. But the thing
is, everything is so thin inside that I really was afraid to damage
something when replacing the battery. Yes, it still works and I hope it will
for a long time, but when it doesn't, it doesn't forever. No repairability
that we can talk about here. On the other hand, there is a soviet
Elektronika MK-52 programmable RPN calculator, the one I had been using for
at least 2 years before getting my first PC. It's a perfect example of fully
repairable hardware with full internal schematics available, and I guess it
fits the "permacomputing" vision, but in no way is it an LPC device, as, for
its capabilities, it was a powerhog that quickly ate four AA batteries or
had to be powered via the mains adapter with a proprietary connector.

Over time, at the beginning of the 2010s, the EEPROM block in that MK-52
started malfunctioning and the adapter also went dead. And guess what - it
was manufactured after 1990. Yes, I could repair it now, but why would I do
this if I got an irrepairable programmable Casio that still works in 2023
like it did in 1988 or 1989 or whenever it was manufactured, with its only
theoretical point of failure being the LCD screen (which still is fine
though), and it has a completely autonomous hybrid power circuit that lasts
virtually forever with my usage rate and its overall some-dozen-microwatts
energy consumption? What I'm trying to say is that repairability is cool
(and, under some circumstances, even essential), but overall build and
(internal) design quality that doesn't ever give you the need to repair your
device is even cooler. And, as long it doesn't involve any planned
obsolescence or any other sort of pushing you to buy a new product to
fulfill the same functions every now and then, it's entirely up to you which
side of the scale to be closer to.

And again, this is where "stop babbling, start acting" principle still holds.
Posting anti-consumerism and frugality ideas solely on the commercialized
Web that requires a ton of resources to browse and maintain it is akin to
trying to find a virgin in a brothel. Meanwhile, I have yet to see a single
viznut's page on the Gopherspace or even on Gemini, as opposed to the
Facebook, Twitter and YouTube links he posted in the footer of his website.

--- Luxferre ---

[1]: https://www.amsat.org/fm-satellite-frequency-summary/