💾 Archived View for freeside.wntrmute.net › log › 2020 › 20201217.gmi captured on 2022-03-01 at 15:44:39. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Heirloom computing

2020-12-17 13:37 PST

now listening: The Mountain - Gunship - Gunship

Jeremy pointed out an article on some site called Heirloom Computing, with the thesis that we should be designing computers as heirloom devices meant to last 100 years. This ties very strongly into some of my ideas on personal and community computing. I was thinking of some of my machines that had lasted a decade or more, but lately I've been thinking of things like the Kaypro from 1983 - still haven't powered it on but that would be 37 years old. Now, there are concerns like storage mechanisms (e.g. the 5.25" floppy disks), but the answer to these is standard interfaces that can be emulated in hardware. I'm not a huge fan of the FAT32 file system, but it's a lowest-common denominator and easy to implement. I like the idea of CP/M as the common operating system because it is simple and it works and it's fairly robust. I think there's even source code for CP/M 2.2 floating around somewhere, so we can extend and update and patch as needed. Not that there's many features that I think we *really* need.

Heirloom computing

Thoughts on off-grid computing

Working towards the idea of long-term computing is going to require investing time into building those systems; writing an OS, perhaps CP/M compatible but meant to be used with FAT32 SD cards. The PCM4 is going to be a good vehicle for exploring ideas related to handheld computing and what that looks like.

As part of this, I've dusted off my copy of "Writing an Interpreter in Go" (that I never actually read) and trying to follow along in C++ as that's the language that's going on the board. Also, having to translate stuff will make it stick in my head and means I won't just be copy-pasting code. Hopefully the skills from this book will be transferrable to writing a Lisp.

Writing an Interpreter in Go

Things I've learned (all while writing the unit tests):

raw string literals (so I could store sample source code as a single string)
returning a lambda function and captured variables

Most of my C++ experience has been writing tight code for microcontrollers, so I usually avoid fancy stuff. For tests, though, it's nice to be able to write something like



static std::function<bool ()>
makeExpect(std::string lit, TokenType t)
{
	return [lit, t]() {
		token_t	tok;
		l.NextToken(&tok);

		if (tok.type != t) {
			return false;
		}

		if (tok.literal != lit) {
			return false;
		}

		return true;
	};
}

In other ideas, it'd still be nice to build out an exocortex. Part network node (e.g. exposing notes over Gemini?), part notebook. Need to develop some TUI skills, or maybe figure out how to make the PCM4 an exocortex.