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.
Unlike you, I'm not foundationally opposed to rent-seeking systems. Taxes are just the cost of doing business. The eternal goal of governance is to spread agency out using sustainable taxes. The real problem, as you point out, is paying rent to absentee and short-lived landlords.
Everything is coopted from its inception, but we can't let that take the fun out of our endeavors. From its inception, the computer has been a creation of large organizations. WWII, machines filling rooms, etc.
@akkartik my 0.02 of $MYCURRENCY. In what @yam655 said ("smol" computing is about kit computers) there is a hint that you are talking past @hayley 's blog ... the blog talks about user-facing software, not hobbyist programming.
@kl Plan9 is an interesting case. It really doesn't use any high-level programming languages and the graphics seem to mostly be about better fonts, but the thinking behind, say, strings as program return values is not "smol" either.
QOTO: Question Others to Teach Ourselves. A STEM-oriented instance.
An inclusive free speech instance.
All cultures and opinions welcome.
Explicit hate speech and harassment strictly forbidden.
We federate with all servers: we don't block any servers.