From a software-complexity standpoint, something like 64 MiB of RAM possibly even 32 MiB for a single-tasking system seems sufficient.

Projects such as PC/GEOS show that a full GUI OS written largely in assembly can live comfortably within just a few MiB: https://github.com/bluewaysw/pcgeos

At this point, re-targeting the stack to RISC-V is mostly an engineering effort rather than a research problem - small AI coding assistants could likely handle much of the porting work over a few months.

Today, even if small DIY plotters were cheap to build, they’d mostly live in the “art / hobby” space: most users won’t wait several minutes for a page when a laser printer does it in seconds.

That said, it would be great if a simple, well-documented DIY standard (protocol + format) emerged that hobby plotters could implement and that common tools (Inkscape, CAD, etc.) could support out of the box.

These glasses were once ubiquitous in public middle-school cafeterias, so the emotional attachment runs deep across generations.

One of my teachers used to say: "In computing, 3 seconds is an eternity." These days, that’s enough time for 20 billion AVX-512 instructions.

It’s hard to accept that anything not truly compute-intensive needs more than that. Realistically, we should be able to hit 300 ms latency across the entire UX — and yet we don’t.

We were supposed to use better tools to build better systems. Instead, we used faster hardware to make it acceptable to ship ever-more bloated layers of abstraction. Everything depends on everything else, and no one knows what any of it does, just that it “works on my machine.” Until it doesn't.

It’s not just about performance — it’s about comprehensibility. You used to be able to hold a system in your head. Now? Good luck tracing anything across 8 layers of indirection, six config files, a microservice mesh and a runtime whose lifecycle even the maintainers don’t fully understand.

I find myself drawn to projects like Red[1], MIR[2], or even Metamath[3] — not because they’re production-ready silver bullets, but because they remind me what it’s like to work on systems that are conceptually finite. With MIR, you get a JIT compiler backend that’s tiny and knowable — and that still punches way above its weight. There’s elegance in understanding where every byte and cycle goes.

The rebound effect of Moore’s Law is real: more resources led to more indirection, which led to more tools, which led to more churn. And now we’re entering the AI era, where tools can generate “working” code faster than we can understand what it’s really doing.

And sure, it feels productive — but something subtle gets lost when we stop thinking through the system as a whole.

We’ve outsourced understanding to the machine. Now we just hope it’s right.

[1] https://www.red-lang.org/

[2] https://github.com/vnmakarov/mir

[3] https://us.metamath.org/

128MB RAM sounds huge for the early 90s - win 3.1 and word / excel of the time could fly with much less. Is the lack of hardware floating point support an issue to run modern apps ?

The speed difference with current systems is mind boggling. The original A1200 CPU is 2,000 to 5,000 times slower than a random N100 setup. one second wait nowadays means one hour delay on the A1200. This shows how much software bloat accumulated.

The English version has been crowd-translated into French, German, and Spanish, with more languages in progress, making the content more accessible.

https://github.com/sqlite/sqlite https://github.com/jart/cosmopolitan https://github.com/dolphin-emu/dolphin https://gitlab.inria.fr/mpfr/mpfr

What scares me is that some mixed works (PDF/on-demand prints) are not archived because the authors think the system is too clunky to deal with, which is really a shame for books like https://laurent.claessens-donadello.eu/pdf/lefrido.pdf, for example.

What really drives me mad is the latency of some file selection dialogs for example which can take like 10 seconds.

So with this reasoning maybe soon Windows = Linux but Android != Linux.