HN Debrief

Linux on Older Hardware: The Complete Revival Guide

  • Linux
  • Hardware
  • Open Source
  • Developer Tools
  • Infrastructure

The article is a practical Linux-on-old-hardware guide. It recommends lightweight distributions for machines in the 2 GB to 4 GB range, basic desktop choices, SSD upgrades, and a set of tuning tips meant to squeeze a few more usable years out of old laptops and desktops. Readers quickly zeroed in on the weak spots. Several called parts of it LLM-like or outright wrong, especially the memory advice. The strongest correction was that low-RAM performance on Linux now depends less on picking the perfect distro and more on understanding compressed memory and page reclamation. MGLRU, zram, zswap, swap priority, and kernel tuning got far more attention than the article’s distro list.

If you are reviving old hardware, treat distro choice as a secondary decision after storage, RAM ceiling, GPU driver support, and browser workload. For truly constrained machines, test memory tuning and graphics compatibility first, because those are what decide whether the box becomes a usable desktop, a headless server, or e-waste.

Discussion mood

Positive about Linux as a way to extend hardware life, but skeptical of the article’s technical depth. The mood was shaped by hands-on advice, annoyance at weak swap and cache recommendations, and a recurring belief that modern browsers and web apps are the real reason old machines feel dead.

Key insights

  1. 01

    MGLRU tuning beats distro hopping

    Multi-Gen LRU, the Linux kernel’s multi-generation page reclamation system, was the biggest missing piece. The useful trick is not just having MGLRU enabled, but setting min_ttl_ms so file cache is protected longer, which can dramatically reduce thrashing on low-RAM machines with HDDs or slow flash. The same advice paired MGLRU with zram for anonymous memory so the system avoids pounding an old disk.

    On low-memory Linux systems, check whether MGLRU is enabled and test min_ttl_ms before reinstalling a different distro. If the machine still uses an HDD or eMMC, this knob can matter more than changing desktops.

      Attribution:
    • ValdikSS #1 #2
  2. 02

    Zram and zswap are not interchangeable

    Compressed swap got flattened into simple advice in the article, but the details matter. zram uses RAM itself as a compressed swap device and works best when it is the only swap target. zswap intercepts swap pages, compresses them in memory, and is the better fit when you also have disk-backed swap because it lets the kernel manage hotter versus colder pages more intelligently. Even people arguing for one over the other ended up agreeing that the right choice depends on whether disk swap exists at all.

    Pick a memory strategy, not a buzzword. Use zram when you want compressed swap entirely in RAM, and prefer zswap when you need a real disk-backed overflow path.

  3. 03

    Cheap RAM helps, but many machines are capped

    The easy answer to old hardware is often "just add RAM," and for many discarded desktops that is correct because DDR3 is cheap and upgradeable machines are nearly free. That falls apart on exactly the class of machines many people are trying to save. Early laptops, Chromebooks, and odd mobile chipsets can be limited by firmware, only have two slots, require expensive DDR2 modules, or have soldered 2 GB memory with no upgrade path. The revival playbook is different for those machines because tuning has to compensate for hardware you cannot change.

    Before planning a lightweight Linux install, confirm the real RAM ceiling for the exact model. If the memory is soldered or the platform is stuck on expensive DDR2, spend effort on compression, remote workloads, or a different machine.

      Attribution:
    • AnthonyMouse #1 #2
    • forinti #1
    • windowsrookie #1
    • johnvaluk #1
  4. 04

    The browser is the real minimum spec

    What makes ancient desktops feel unusable is usually not the Linux desktop itself. It is Chromium-class browsing, Electron apps, video-heavy pages, Google Docs, and modern JavaScript payloads. Several people said command-line tools and native desktop apps still feel fast on old CPUs, while a handful of tabs or one heavy web app can crush a machine with 2 GB or even 8 GB RAM. That reframes the whole revival problem from operating system choice to workload choice.

    Set expectations around browsing first. If the target use case depends on heavy web apps, no lightweight distro will save truly old hardware.

      Attribution:
    • haunter #1
    • IgorPartola #1
    • giantrobot #1
    • NoboruWataya #1
  5. 05

    GPU support can decide the whole project

    The guide barely touched graphics, but old GPUs often determine whether a machine is worth reviving at all. NVIDIA was the sore spot because unsupported legacy cards can leave you stuck on old drivers or Nouveau compromises. Older AMD Radeon paths and Intel integrated graphics were described as much easier to keep useful under current Mesa and Linux kernels. Several people called out revived laptops that were fine on CPU and RAM but blocked by graphics support or suspend quirks.

    Check GPU generation and driver path before you commit time to an install. If the machine has old NVIDIA hardware, verify legacy driver support or be ready to turn it into a headless box.

      Attribution:
    • pmontra #1
    • type0 #1
    • anthk #1
    • WCSTombs #1
    • nbernard #1
  6. 06

    Old business desktops are the sweet spot

    The most practical reuse target was not the 2 GB netbook but the flood of retired office machines. Tiny Lenovo, Dell, and HP desktops from the late 2010s often arrive with 8 GB RAM, SSDs, and decent Intel CPUs, which makes them good Debian or Ubuntu desktops, TV boxes, self-hosting nodes, NAS or VPN appliances, and even small Talos or Kubernetes clusters. This is where Linux revival stops being a hobby stunt and becomes an economical default.

    If you need cheap Linux capacity, start with decommissioned micro desktops instead of trying to save the weakest laptop in the closet. They are easier to support and useful for both desktop and homelab roles.

      Attribution:
    • alaudet #1
    • theandrewbailey #1
    • drnick1 #1
    • jftuga #1
    • initramfs #1
  7. 07

    Intel Macs age better on Linux than on patched macOS

    Several reports on older Intel Macs made the same point. Machines that stutter or lose features under newer macOS, especially through OpenCore Legacy Patcher, can feel better again under current Linux with solid support for Wi-Fi, Bluetooth, trackpads, and everyday desktop use. One person even turned a 15-year-old Mac Pro into a GPU-heavy Ubuntu box that outperformed newer Apple Silicon systems for a specific local model workload because the expansion path was still available.

    Old Intel Macs are unusually good Linux candidates if the hardware is intact. If your macOS path now depends on patching and still performs badly, Linux is often the cleaner second life.

      Attribution:
    • littlecranky67 #1
    • rmnclmnt #1
    • ProllyInfamous #1

Against the grain

  1. 01

    No swap can be the right answer

    The usual advice says to add some form of swap and compression, but there was a credible pushback from people who hate the latency cliff. For interactive systems, they would rather let earlyoom or the kernel kill a process than keep the desktop technically alive while it stalls under heavy paging and cache reclaim. That is a different definition of usable, but on very weak hardware it is often the more honest one.

    If a revived machine feels awful under memory pressure, test a no-swap or early-kill setup instead of endlessly tuning swap. A hard failure can be better than a machine that freezes for minutes.

      Attribution:
    • mrob #1
    • yjftsjthsd-h #1
  2. 02

    BSD is not a universal better fallback

    A few people pushed NetBSD, Haiku, or Alpine-style minimalism for truly old hardware, but the strongest rebuttal was that this is nostalgia more than practical guidance for the machines under discussion. Linux already has broad support for the late-2000s and 2010s hardware most people actually own, including odd laptops, routers, and office desktops. Switching operating systems entirely does not solve the real blockers, which are browser load, GPU support, and RAM limits.

    Reach for BSD or niche systems when you want the experience, not because you expect a free performance miracle on 2010-era PCs. For mainstream revival work, Linux support breadth is still the safer bet.

      Attribution:
    • 2b3a51 #1
    • nasretdinov #1
    • 1vuio0pswjnm7 #1
    • jmclnx #1
    • ajross #1
  3. 03

    Software moved on for reasons, not just bloat

    The dominant tone blamed modern software for wasting resources, but one commenter pushed back that newer apps do more and supporting old hardware is expensive. The uncomfortable point is that some pain comes from real capability changes like modern codecs, richer web applications, and larger security and compatibility surfaces, not just careless engineering. That does not excuse absurd JavaScript payloads, but it does make simple nostalgia misleading.

    Do not plan around a fantasy that every modern workflow should fit on ancient hardware. Separate unnecessary inefficiency from genuinely heavier requirements before deciding whether to optimize, downgrade the workload, or replace the machine.

      Attribution:
    • Random09 #1
    • tocariimaa #1

In plain english

earlyoom ↩
A userspace Linux tool that watches memory pressure and kills processes early to keep the system responsive before the kernel reaches a full out-of-memory state.
GPU ↩
Graphics processing unit, the chip that handles graphics rendering and can also accelerate some compute workloads.
HDD ↩
Hard disk drive, a traditional spinning storage device that is much slower than an SSD, especially for random reads and writes.
Mesa ↩
An open source graphics software stack for Linux that provides drivers and APIs for many AMD, Intel, and some other GPUs.
MGLRU ↩
Multi-Gen LRU, short for Multi-Generation Least Recently Used, a newer Linux memory management system that tracks pages by age to reduce thrashing under memory pressure.
min_ttl_ms ↩
A Linux MGLRU tuning parameter, measured in milliseconds, that tries to keep file cache in memory for at least a minimum time before reclaiming it.
NAS ↩
Network-attached storage, a device or server that provides shared file storage over a network.
OpenCore Legacy Patcher ↩
A tool used to install newer unsupported versions of macOS on older Apple hardware.
SSD ↩
Solid-state drive, a flash-based storage device that is much faster than a hard disk drive for most desktop workloads.
Talos ↩
A Linux distribution designed specifically for running Kubernetes with minimal operating system management.
VPN ↩
Virtual private network, a secure tunnel used to connect devices or networks over the internet.
zram ↩
A Linux feature that creates a compressed block device in RAM, often used as swap so the system can store more memory pages without writing them to disk immediately.
zswap ↩
A Linux feature that compresses swapped pages in RAM before they are written to a real swap device like an SSD or HDD.

Reference links

Memory management and kernel tuning

Distro and project references

  • Bodhi Linux
    Suggested as a better under-2 GB option than antiX for some hardware.
  • Tiny Core Linux
    Mentioned as an ultra-light option for extremely constrained systems.
  • SliTaz
    Referenced as a very small distro with working Wi-Fi on very old netbook-class hardware.
  • Damn Small Linux 2024 download
    Suggested as another retro-focused lightweight distro to test on old machines.
  • BunsenLabs downloads
    Shared by someone recommending an older BunsenLabs release as a smooth Debian GUI option.
  • MrChromebox supported devices
    Recommended for anyone buying a Chromebook specifically to run non-ChromeOS Linux.

Hardware compatibility and upgrade references

Setup guides and personal build logs