> Anecdotally, it doesn't seem to be possible to start a mainstream Linux distribution w/ less than about 128MB of RAM, perhaps due to the initramfs-based boot that's ubiquitous nowadays.

Depends on what you call a mainstream Linux distro. Maybe if you only include "desktop" style Linux distributions, which don't tend to be the most mainstream use for Linux.

dd-wrt is extremely popular. It generally requires somewhere between 2-4MB Flash, and the smallest amount of RAM I saw when going through the supported router list was 8MB.

U-Boot is an extremely popular Linux bootloader, that generally runs the mainline ucLinux kernel, which has support for STM32 microcontrollers, where you'll be looking at much, much less RAM. More likely to be measured in kilobytes than megabytes. It could be argued this isn't complete enough to be called a distribution.

> And a i686 class CPU is needed.

Not at all. Debian, Ubuntu, Gentoo, Arch, all have ARM based versions, before you go diving into what else they support. (Keep reading if you meant the kind of x86)

And whilst some have dropped the 486 (Debian even dropped the 586 in 2016 [3]), Gentoo still supports it if you follow along with the mostly manual installation guide. (Though this [0] spells it out in a much easier way.)

However, running Linux on a 386 is difficult and unsupported (the kernel dropped support in 2012 [2]), NetBSD still actively maintains a port. [1]

As to the 286... Linux never supported it as far as I know.

So the upshot is, if you have a 386, 486, or 586 you can still run Gentoo.

[0] https://github.com/yeokm1/gentoo-on-486/

[1] https://wiki.netbsd.org/ports/i386/

[2] https://www.pcworld.com/article/2020196/linux-3-8-will-drop-...

[3] https://distrowatch.com/dwres.php?resource=showheadline&stor...

You could chooch along quite nicely in Kolibri OS all the way down to 8MB of RAM it seems and have a relatively okay experience in it [1]. Seems as though something like Puppy Linux will get you going on 64MB of RAM or lower [2].

If you really want to take Linux to the extreme, probably the place to start would be the efforts made to use it on embedded devices [3].

[1] https://kolibrios.org/en/

[2] http://wikka.puppylinux.com/MinimumSystemRequirements

[3] https://elinux.org/Main_Page

I still have a very old USB key with Puppy Linux on it from, back a darker time when I didn't have my own computer.

I've booted quite a few very old systems with it, probably down to Pentium-era machines, and things usually ran well. I do remember it was quite RAM intensive due to having a relatively large filesystem in RAM. I'd say 64 MB is a minimum if you actually want to use it for anything.

I ran modern GNU/Linux on a laptop with a 333 MHz Pentium II processor and 96 MB of RAM until 2010. I still have the laptop and it probably still works, though I lended its charger and I don't know where it landed.

It was a bit slow. You had to avoid opening more than two or three browser tabs and avoid swapping at all cost because of the relatively slow HDD. You had to be patient.

The computer was designed for windows 95 and 98. It ran Windows 2000 quite well. XP was slow.

I was amazed by the fact that a live CD of Ubuntu 5.04 ran pretty good on it, with an early version of GNOME 2. Late versions of GNOME 2 were unusable on it. It also managed to run mandrake 9 with kde 2 (?) well too.

Now, current distributions are removing support for x86-32. Debian would probably be the best bet (or slackware ?), if not a specifically lightweight distro.

I tried Arch on it but I would not install a rolling distro on anything with a slow drive today. Too painful because of the updates.

I wonder if its silicon motion GPU would still work under X11. I'm not sure the vesa driver worked on it. I remember having issues with X11 with this laptop the last times I used it.

I used a pcmcia card for the Wi-Fi that I sill have. I needed to use ndiswrapper to use the windows driver on Linux. It didn't handle WPA. Fortunately, almost all Wi-Fi networks were open or encrypted with WEP. Today, I would probably need to use Ethernet, or the only USB1 port it has to plug a Wi-Fi stick.

One web page of today would send this computer to swap hell though.

> It was a bit slow. You had to avoid opening more than two or three browser tabs and avoid swapping at all cost because of the relatively slow HDD. You had to be patient.

Perhaps try a modern CF card? There are passive notebook-PATA bridges still made and sold for under 5$ IIRC - did this to save an old HP Z2100 from a disk failure recently. The bus is still a bottleneck in terms of speed but latency is a no-issue compared to HDDs.

I'm a big fan of replacing old laptop HDDs with an mSATA SSD in a 2.5" 44-pin IDE adapter. The JM20330-based ones have had the best compatibility for me. Just be sure to disable any auto-defrag that old OSes like Windows 98 come with by default :)

Win98 didn't have auto-defrafg. IIRC the first one to ship this was Vista. Win98 still had that atrocious defrag program that would restart every time it noticed that any program modified the file system in any way. So you had to make sure to shut down any program or daemon running in the background. Looking back it's quite amazing you could actually shut down everything that was running and accessing the disk.

I assume the defrag program directly accessed the raw disk and understood FAT, bypassing the kernel, and just used it to get notified about write access to the disk.

I doubt the initramfs is (completely) at fault, mine is rather small (and I haven't done anything to try to minimize its size):

    $ lsinitcpio -a /boot/initramfs-linux.img
    ==> Image: initramfs-linux.img
    ==> Created with mkinitcpio 26
    ==> Kernel: 5.3.7-arch1-2-ARCH
    ==> Size: 9.87 MiB
    ==> Compressed with: gzip
      -> Uncompressed size: 25.97 MiB (.379 ratio)
      -> Estimated decompression time: 0.184s
    ...

Mine (same arch kernel) is twice the size, both compressed and uncompressed, for what it's worth; I have a handful of vfio modules included explicitly, as well as amdgpu; so it's still doable. My fallback initramfs is a little over 128MiB compressed.

I was disappointed to learn that the official builds of golang support "i386", but require SSE :(

AFAICT, the lowest requirement which happens to also have SSE is i686.

Tried installing Debian 8 or 9 with 128MB a while ago. The installer warned that this wouldn't be enough to finish setup, and sure enough, during installation the OOM killer got in the way. I restarted the installer, spawned a shell and killed some processes that looked non-essential, and this time I managed to finish. Using the actual system was obviously slow given two 233MHz CPUs, but even X11 with i3 worked. I then used it as a secondary screen via VNC. For about an hour. Then I shoved the machine back into the basement.

You can using uLinux . It too small, that you can get a working X11 desktop using a few floppies

I think lubuntu comes relatively close to that requirement, but really it is becoming a needless exercise other than being intellectually stimulating. You could just download the older releases of Linux for such machines

> You could just download the older releases of Linux for such machines

You could also run Windows 95 in 2019... Both are really good plans if you want to get 0wned.

2019 malware likely won't run on Windows 95. The kind of malware you'd stumble across in your normal online activity will mostly target Windows 10 and back to XP, and will be written to that environment and its APIs. Given the need to minimise size and detectable features.

Naturally I would not rely on this for my own online safety. A motivated adversary with a specific target in mind would no doubt learn that a vintage Windows 95 install was present, or maybe just throw everything at it.

> Both are really good plans if you want to get 0wned.

It is wise to point that out; running an old OS on old equipment or in a VM is perfectly viable, but one should NEVER connect those machines to the open Internet.

This assumes that the user plans to go online using these OSs. For offline use (legacy/classic gaming, or embedded tasks) there'd be no problem.