I'd be ok with it if it's possible to use all the insights and software from after that, we'd just be constrained by the hardware - the Amiga 4000, Apple Mac Quadra 840av 128 MB or a Pentium 66 MHz or the 486 DX2-66 with 64 MB ram.
On the Amiga4000 and Apple you could run their 'native' OS, or you could run a modern day NetBSD or a BeOS version (HaikuOS wouldn't run).
On the Pentium-66, modern Freedos would run, Windows 3.11+win32s+calmira, Windows98SE, Windows2000sp5, XPlite, NetBSD and perhaps even an absolutely stripped down Linux 6 kernel with all the features that would be handy.
You could program in a modern i586 build FreePascal, Zig, Lua, juniper, micropython/shedskin, mruby/natalie, picoruby, juniper - perhaps a low memory JVM could run (OpenJDK 8 or JamVM).
It'd be possible to use sqlite, raylib and r3d-freepascal for efficient 3D games/apps next to Quake/Darkplaces, Doom2/GZDoom, Duke3D, Counterstrike 1.5, Halflife, perhaps Unreal1, Irrlicht and FTEQW.
Modern LambdaMOO's Toastunt/Moor could be made to run and inform6 and tads3 interactive fiction compilers.
Fairy-Stockfish could be compiled - so enough creativity for gaming.
I am just worried about getting Vassal, the java boardgame game engine to run comfortably... but the resolution would be pretty low to play many boardgames comfortably: the highest ATI card could drive 1280x1024. I would really like to use it so I don't have the real world board game setup time. Keldons Race for the Galaxy would compile and run though.
For internet, Dillo+ supports https, gemini and gopher.
https://github.com/crossbowerbt/dillo-plus
This can also be used to browse zim offline wikipedia files with kiwix-serve.
Now my only real problem is that we wouldn't have GenAI - probably EVER - would that be a blessing or a curse?
---
Handy Linux kernel 6 tweaks for low memory situations if you don't want to run NetBSD (which perhaps would be the best choice):
* zram + zstd
zram creates a compressed block device in your RAM. To the OS, it looks like a regular swap partition, but it lives entirely in memory.
When your 64MB fills up, the kernel sends data to /dev/zram0. The data is compressed (usually 3:1 ratio) and stored back in a small slice of your RAM.
Version 6.19 includes better compression ratios and rebalancing. It prevents the CPU from over-working itself on decompression.
* zswap + zstd
zswap is a front-end for a physical swap file on your hard drive.
It intercepts pages headed for the hard drive, compresses them, and keeps them in a RAM pool. If that pool gets too full, it evicts the oldest compressed data to the actual disk. Starting in 6.18, zswap transitioned to using the zsmalloc allocator by default. This reduces "internal fragmentation," meaning it packs those compressed bytes tighter.
* frontswap
API that allows the kernel to intercept swap-outs and store them in a transient memory pool; it works with Zswap to keep the system responsive during high load.
* Maple tree
Replaces old "Red-Black trees" for memory management; it reduces the CPU cycles needed to find data in RAM.
* SLUB sheaves
A modern memory allocator optimization that packs small objects into "sheaves" to reduce fragmentation.
* CONFIG_SLOB_BERBER
A specialized 2025 backport of the old "SLOB" allocator; a memory-efficient way to handle kernel objects, saving roughly 1-2MB of overhead compared to the standard SLUB used in modern PCs.
* Ext4 without journaling
Disable the "Journal" to save RAM and disk writes; it provides the best file-allocation speed without the memory overhead of Btrfs.
* Reiser4 patch
An efficient file system for small files; it packs them directly into the tree nodes, which saves disk space and reduces I/O.
* KSM (Kernel Shared Memory)
Scans RAM for identical pages (like duplicate library code) and merges them into one; it’s a "free" RAM upgrade if you run multiple instances of the same program.
* Very High Frequency (VHF) HZ Tuning
Manually setting CONFIG_HZ to 100 (instead of the modern 1000); this reduces the number of times the CPU "wakes up" per second, saving precious cycles for actual work.
* DevTmpfs
Automates device node creation entirely within the kernel; it saves you from running a heavy udev or mdev daemon in userland, freeing up roughly 2–5MB of RAM.
* LZ4 Compression for Kernel/Initramfs
Using LZ4 instead of xz, gzip or zstd for the kernel image.