I was starting to write a really big thing about permacomputing--I'd already made an outline and was drafting--but then I read this article and feel like I see things very differently now: https://applied-langua.ge/posts/terminal-boredom.html
the Alan Kay "metamedium" idea that runs through this article is powerful; reframing the discussion around the concept of "what do I do with it" rather than "how old of a computer can I do my work on." more like the @stevelord "heirloom computer," less like an old DOS laptop that is still useful.
I'm sure there are critiques of Gemini in the article that are unfair; I don't really care one way or another about Gemini. But the bigger point--that a lot of what passes for "minimalism" is very misguided--still rings true. All these ARM SBCs are still more powerful than the laptop I got for college.
Instead, what would a "permacomputer" be if it were a way of working supported by hardware that lasted a very long time?
Plan 9, Emacs/Lisp machines, Smalltalk, hell even something like AS/400s--these kinds of "paradigm" environments seem like the thing we should be figuring out how to make "perma" instead of Linux on ARM or the Commodore 64.
The reality is that the "retro" part overtakes the "perma" and the two become intertwined. The reality is that you can buy a Pentium M laptop for $25.
Another stray thought: think about something like Open Firmware. Something about "it's a regular PPC Mac laptop or Sun workstation, but you can also just boot it straight into a Forth REPL" feels like a future we shouldn't have left behind, a basis for a different relationship with our computing tools.
@kl Somehow your thread this morning got me to click through and read your https://systemstack.dev/2022/05/waking-up and https://systemstack.dev/2022/06/things-i-might-write. Thank you!
I dislike https://applied-langua.ge/posts/terminal-boredom.html just like everything else the authors have written. But thank you for getting me to focus on the few sentences in between about the meta-medium idea. They don't ooze contempt. But here's the thing: they'll have the same problems if a community coalesces around them. This stuff is hard.
@kl Nobody building minimalist systems is saying the problems are solved. The thing the authors are missing is that minimalist systems are a _reaction_, a backlash to the problems of mainstream systems. Of course they have problems. But when you're sick of the hegemony of one set of problems, it's sometimes a relief to leave behind the bugs you know for new bugs you don't know about for a while. Above all, it's a relief to depend on software created with less inscrutable motivations.
@kl So far I've come up with a few ways to phrase the core problem:
- How to get the nice things we've gotten used to under the current regime of software development, but replace the governance process with something more democratic. Oh, and how to sustainably maintain some minimal level of grassroots citizen engagement with that process, something unsolved even outside software. Because if you don't do that last bit, your democratic machinery will quickly rot away.
- How to make over-engineering more apparent, make it pay a cost in adoption in the marketplace of ideas. The problem we have today is that we have over-engineered systems piled high on other over-engineered systems (making the latter load-bearing and not over-engineered? :grimace:). A minimalist system at least gives us some freedom to try again. Maybe even learn something. People built houses for millennia to get good at it. Imagine if all houses were `git clone`s of some trunk branch.
- How to avoid the complexity ratchet of backwards compatibility. If we can't take out features we don't use, any nice initial design will eventually get swamped.
Ok, three phrasings should be enough. The thing they all share is an acknowledgment of costs, and that is something I rarely see outside the minimalist community. I suppose that's tautological. Anyone who cares about the costs will tend to build what seem like toys. Everyone else will continue infantilizing their users.
A constructive critique of minimalism needs to at least propose how we manage costs. A VM, ok. But who controls the VM, decides how to evolve it? How do programs built on the VM interoperate? Who decides how those interoperation mechanisms evolve?
Minimalism doesn't have answers to these questions either. But at least we're playing in the kiddy pool, far away from the abyss, where we only have to deal with the easy versions of these problems. Walk before you can run and all that.
But there's also been hope, right from the start. Hints of a "shadow computer" that is possible. Vannevar Bush's memex, Licklider's "man-computer symbiosis", Engelbart's "augmenting human intellect," Ursula Franklin's "real world of technology", Bonnie Nardi's "small matter of programming," etc.
We can't choose the world we're born in, we can only choose what aspects of it we put our energies behind.
Computers are dual-sourced, much like the Internet itself.
The Internet's dual-sources are the government-backed ARPAnet and the home-grown BBSes.
Computers dual-sources are machine-room computers and the kit computers. The terminals to connect to the machine-room computers have changed, but it has always been big business that loves control.
We thought home computers fell on the side of kit computers, but these days they're just fancy terminals to the machine-room systems.
Time-sharing systems are older than kit computers. They're the bread and butter of the machine room computer, and they always have been. How we do time-sharing is different, but the overall concept hasn't changed. We pay to have our software run and are billed for just the time that our software runs. (The AWS model is the original model.)
Minimal computing, to me, is about embracing the kit computing ethos, even if only doing it in software.
@yam655 You've really got me thinking now. It's not enough to just put some software out there and say, "it's easy to hack, hack on it for anything more you need" as I do with http://akkartik.name/lines.html. I think maybe we need to refuse to provide software that just works. Our credo must be, "some assembly required".
Heh, "some assembly (but no Assembly) required."
That article you mentioned really does fit with what I was saying.
Think of software like an early automobile. It does one thing well, but the design is clean enough that anyone can add and extend it.
Some people _might_ want to swap out the engine, but others might just want to upgrade the seats.
You could go for a DIY kit-based system where you have a thorough collection of parts, but that tends to make most sense for game systems. (Some of which totally take that approach.)
@akkartik the Memex and Project Xanadu are two of the things that got me started down this whole path back when I was an undergrad. I think the search for that "shadow computer" is a tragic unrealized goal from a previous epoch, but like you say, it may still be out there somewhere, lurking.
Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.