Which Linux distributions run in a browser

The distribution on your laptop will not boot here, and size is not the reason. Nobody compiles it for a 32-bit processor any more. Arch ended i686 support on 8 November 2017. Ubuntu's last 32-bit desktop ISO was 17.10, the month before. Fedora stopped building the i686 kernel — and therefore every bootable 32-bit image — in Fedora 31, October 2019. Debian held out longest and then gave up too: Debian 13 «trixie», August 2025, ships no i386 kernel and no i386 installer. The machine underneath this site is a 32-bit PC, and there is no workaround, because upstream there is nothing left to download.

That is less of a loss than it sounds. The systems that still fit were built by people who sat down and decided, component by component, how much a working system has to contain.

The machine you are aiming at

Every guest runs on the same emulated hardware: a 32-bit BIOS PC with IDE, a floppy controller, VGA, PS/2 input, an 8250-compatible serial port and the usual timers. No GPU, and no host CPU running guest instructions directly — every one is translated to WebAssembly (how that works). RAM is the other hard limit: machines here get 16 MB to 1 GB, most of them 128 or 256. That memory is a typed array inside the page, and there is no swap device, so a system that expects to page out just allocates until something fails.

Five things that decide whether it boots

1. Whether an i386 build exists at all

Somebody has to have compiled a 32-bit kernel, and the list that still does is short: Alpine, which treats x86 as a supported architecture alongside x86_64 and aarch64; Tiny Core; SliTaz; antiX and its derivatives; Slackware; Gentoo if you will compile it yourself; and Debian 12 «bookworm», the last Debian with a 32-bit installer. Everything else is a 64-bit project carrying 32-bit compatibility libraries, which is not the same thing.

2. Kernel size and decompression time

A bzImage is a real-mode setup stub, a decompressor and a compressed kernel, and the decompressor runs before a single line of the kernel proper does. Here that is one of the more expensive parts of a short boot: pure arithmetic over several megabytes with no I/O to hide behind. make tinyconfig sets CONFIG_KERNEL_XZ=y, the smallest file and the slowest unpacking; CONFIG_KERNEL_GZIP or CONFIG_KERNEL_LZ4 give a larger image that starts sooner. Fetched once and run once, larger and faster wins.

3. What runs as PID 1

systemd parses unit files, builds a dependency graph, mounts cgroup hierarchies, starts a journal, brings up D-Bus and waits for udev to settle the device tree — each a stream of small operations against emulated hardware. Busybox init reads /etc/inittab, runs one shell script and spawns a getty. On metal the gap is a second or two of pride. Here it is the difference between a system that reaches a prompt and one that appears to have hung.

4. Whether it insists on a graphical stack

There is no accelerated driver to find, so X falls back to the generic framebuffer path and every pixel becomes a write into emulated video memory. A full redraw at 1024x768 in 16-bit colour is 1.5 MB of guest writes, each crossing the emulator boundary. Window managers that repaint conservatively — FLWM, JWM, Openbox, Fluxbox — are usable; compositing and animated menus are not. The small distributions all ship the same handful of window managers because they were chosen for machines from 2003, which is roughly what you have.

5. How the root filesystem arrives

Three answers, an order of magnitude apart. A full image must be fetched, though the larger ones stream with HTTP range requests so a 1 GB disk boots after a few megabytes (disk images explained). 9p over virtio goes further: the guest asks for files by name, so the gigabytes you never open are never transferred. An initramfs avoids the problem — a cpio archive shipped beside the kernel and unpacked straight into a RAM filesystem, with no block driver, no mount and no device probing. That is why a Buildroot machine reaches a shell before an ISO has finished its first read.

The small distributions, one by one

Tiny Core

Three downloads that people constantly confuse. Core is about 17 MB — kernel, busybox, no X. TinyCore is about 23 MB and adds FLTK and the FLWM window manager, a genuine windowed desktop. CorePlus is around 248 MB and is not a bigger system but an installation aid. The stated minimums are 28 MB of RAM for Core and 46 MB for TinyCore. Everything runs from RAM: the ISO is read once, unpacked, and the CD becomes irrelevant. Software arrives as .tcz extensions — squashfs files that tce-load loop-mounts and symlinks into place rather than installing — so a reboot returns the same clean system unless you arrange persistence. On a machine that vanishes with the tab, that is the right model.

SliTaz

A complete graphical desktop — Openbox, file manager, editor, browser and the tazpkg package manager — in an ISO under 50 MB, with a busybox userland on a normal glibc. The measure of how carefully it is built is the project's own low-RAM documentation: the standard live CD wants 160 MB, slitaz-loram compresses /usr and still runs entirely in RAM in 64 MB, loram-cdrom leaves /usr on the CD and runs in 24 MB, and there is a documented path down to about 9 MB. Almost nobody writes documentation at that granularity any more.

Damn Small Linux, then and now

The 50 MB DSL everybody remembers is the 4.x line from the late 2000s: a window manager, Dillo, a spreadsheet and a startling pile of utilities on a business-card CD. That is what the catalog boots, and it is a precise snapshot of what a usable desktop cost in 2008. In 2024 John Andrews, the original author, revived the name after twelve years. DSL 2024 is built on antiX 23, and its ISO is roughly 700 MB rather than 50 — still small by 2026 standards, still 32-bit, but not a browser-tab distribution. Boot the 4.x image here; install the new one on a real old laptop.

Alpine and musl

Busybox userland, OpenRC init, apk for packages, and musl instead of glibc. musl is the part that matters here: far smaller, and it links statically without the caveats glibc attaches to the same operation, so binaries come out self-contained and tiny. The honest caveat is Alpine's own requirements table — 128 MB of RAM to start, 320 MB to run the installer — comfortable on the emulator, but not what anyone means by tiny. It is not in the catalog, so you would supply your own ISO at /new.

Buildroot, and ELKS at the floor

Buildroot is not a distribution but a build system: it cross-compiles a toolchain, a kernel and a busybox root filesystem from one .config. make qemu_x86_defconfig gives a working i686 machine — the defconfig sets BR2_x86_pentiumpro=y — and swapping BR2_TARGET_ROOTFS_EXT2 for BR2_TARGET_ROOTFS_CPIO=y produces an initramfs instead of a disk. The catalog's entry is 5 MB of bzImage with an editable command line and its console on the serial port; to know what those 5 MB contain, build one yourself.

ELKS — the Embeddable Linux Kernel Subset — is not Linux with parts removed. It is a Linux-shaped kernel rewritten for 16-bit 8086 and 80286 machines, built with an ia16 toolchain and its own small C library. It multitasks, it has a filesystem, a shell and a recognisable set of Unix tools, and the kernel is measured in tens of kilobytes.

Arch, the heavyweight exception

Arch dropped i686 in 2017, so what boots here is not current Arch. It is a preserved 32-bit userland — bash, coreutils, python, gcc, pacman — served over 9p, with a pre-booted snapshot on top so you land on a login shell in seconds. The cost is that a snapshot pins the machine: RAM, video memory and ACPI must match the moment the state was captured, which the Arch guide goes into.

The comparison

Pick one in thirty seconds

1. A shell, now — Buildroot. You are at a # before an ISO would have finished its first read.
2. A package manager — Arch over 9p for real pacman and gcc with nothing to download; Tiny Core for the same idea in 17 MB.
3. X, windows and a mouse pointer — TinyCore for the smallest desktop that exists; SliTaz for the smallest that feels finished.
4. To see how small it goes — ELKS. Multitasking Unix on a processor design from 1978.
5. A dated piece of history — Damn Small Linux 4.x, a desktop as understood in 2008.
6. Something you made yourself — a kernel and initramfs of your own, uploaded at /new.

What will not boot, and why

• Any current mainstream desktop ISO. No i386 kernel is on it, so there is nothing for a 32-bit CPU to execute. The x86 boot stub checks the processor before decompressing anything and prints This kernel requires an x86-64 CPU, but only detected an i686 CPU.
• Anything requiring UEFI. The firmware here is a BIOS, with the sixteen-bit handoff and the 0xAA55 signature that implies. An image with only an EFI system partition has nowhere to start.
• Anything that expects to page. Give a modern desktop 256 MB and it does not degrade gracefully; the allocator fails and something dies badly.
• Anything whose first move is DHCP. Guest networking needs a WebSocket relay and is experimental; an installer blocking on a lease blocks for a long time.

The systems that boot in a browser tab are the ones whose authors treated every megabyte and every millisecond as something to be justified. That was once ordinary engineering and is now a minority interest. Booting one recalibrates how much of a modern operating system is actually load-bearing.