(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/