Where To Get Older Linux Releases


1) Drivers

2) Size

3) Mis-Features

4) Methods

This article gives a good example of some small-hardware-friendly Linux releases and an idea of one reason “why”:


Note that it is from 2006, so add a decade to his idea of small old hardware…

Joe ‘Zonker’ Brockmeier
February 24, 2006

Linux distros for older hardware

For these tests, I dug out Igor, an old PC that had been collecting dust in my closet. Igor is a Pentium II 233MHz machine with 64MB of RAM, an 8x CD-ROM drive, a 3GB hard drive, and an integrated ATI 3D Rage Pro video card with 4MB of video RAM. You can run Linux on older and slower machines, but this is the most under-powered machine I had available.

Next, I selected a handful of lightweight Linux distributions that looked promising, and started downloading. The distributions ranged from popular “mainstream” distros such as Slackware and Debian to distros that are specifically developed for lightweight machines, such as Damn Small Linux (DSL). I apologize in advance if your favorite lightweight distro is not represented here.

Sadly, I suspect the Raspberry Pi is going to kill off much of that antique gear. Heck, I’m looking at my old White Box PCs and thinking of deep-sixing them… and I have an old TUBE radio the size of a small stove in my office…


Old equipment is made of old parts. Pretty obvious. Those old parts need “drivers” to work. Drivers are the software that sits between the basic operating system and the actual hardware. Things to make that old dot matrix printer run, or that old serial mouse and primitive screen function.

As time goes on, fewer of those machines run the newer operating system. Eventually, the maker of the OS decides to not bother putting that old driver into his operating system, making it bigger and more complex, for no real use. Then that OS no longer works on that old hardware.

If, like me, you have a bunch of old hardware, or sometimes inherit it for “free”, you want those drivers. The place to find them is in the old operating system.


Code bloats. There are many reasons for it, some more valid than others. The simple fact is, it happens. The original Linux ran in 16 MB of memory. 32 MB if you wanted a nice graphical X-window environment.

My last 16 MB machine just hit the trash can. An old Hitachi laptop that finally had too much hardware die to keep it running. It had been my “office router” for a few years, starting about 15? 18? ago. I’d plug it into the wall ethernet, then it would be my boundary router to the company and the rest of ‘my gear’ was on a switch or hub behind it. That, and ‘blinky lights’ on things, meant that IF our network were hacked (or someone in Engineering was ‘playing’…) my desktop had an extra level of security and inspection. (Hey, I was the Sys Admin, they were out to get me! ;-) Besides, I have the logs to show it…)

But over time, code gets bigger. Then you needed 64 MB or 128 for the fancy releases. Now it’s up nearer 512 MB / 1 Gig. Heck, even the Raspberry Pi Model 2 with a Gig of memory has people complaining the memory is too small.

Some of this is from compile time parameters (you can set how big buffers are) and some is from changes of languages used ( the Object Oriented languages are generally fat and pudgy bloat makers). Sometimes it is just that a fine intensely hand crafted bit of code needed a re-write for some valid purpose, and the new party was not going to sink 1000 hours of time into making it smaller when “memory is cheap now”. More is from the ever acuumulating long list of drivers for “New” hardware that isn’t in your “old” box. (Modular kernel design could help here). Then there are a growing list of new “protocols” to support… all taking more code.

In any case, IF you want a small OS or just to compare the small program with the fat current one to ask “why?”, having the old copy is essential. For old equipment, it is usually a small memory size that limits running the newer versions, not the instruction set or disk / video.


Far less frequently, something gets ‘fixed’ in the new versions that is just horrible for some other uses. Time to go digging in the old freezer for that now deprecated version so you can resurrect it and / or use it as a basis for new replacement version sans ick.

While the general bugaboo thrown at folks is that you just MUST get the newest version to have security, the old one being buggy and having had those security holes not-patched, an equal truth is that all the new “features” added often are the source of the “new” bugs of tomorrow. So your vendor shoves “systemd” down your throat and against your will. 2 years later when you want to swap from Ubuntu to, oh, CentOS, where do you find that last old release pre-systemd?


How things are done changes over time. Languages have fads. Compilers change. When memory is cheep folks use algorithms that are memory intensive. When memory was incredibly expensive, folks used very memory-careful code. The old code often has the old methods embodied in it.

So lets say you are working on a 6 GB Memory Octo-Core SuperDuper machine with a Linux that takes 2 GB before you load up your 4 GB of Applications and datasets… and you are swapping a little sometimes… Now your boss hands you a new project. An embedded system board with 128 MB of memory and about 1 GB of flash. Where do you go to look at “how to make it fit”? Where’s the textbook of “the old ways”?

It is often easier to just look over some old code to get a quick set of clues.

Odds & Ends

I’m sure there are other reasons too. That’s just the set I think of most often. Sometimes I’ve just wanted “that old favorite wallpaper” and sometimes I’ve wanted to open an old file that has a format no longer supported. Archivists often have need of old ways. Or a forensic investigation might hinge on “could someone have broken into the suspects machine?” (to frame them). Or a movie maker wants “period correct” graphics on the screen… or There’s a long list of other reasons.

But whatever the reason, sometimes you need versions that just are not the newest.

So I’m going to just link a few sites here. If you know of any others, or have any favorites, please add them below in comments.

Note that this isn’t a ‘retro computing’ thing. While I like retro-computing and pine for my own B6700, and welcome any links to them, too; this is specifically including software you can run and use on hardware today.

Some Linux sites I use:

Least Old: Void Linux

This is just their active download page. I have yet to test drive it yet. I did download a copy to the PC, but it had issues at boot. Likely my fault for that particular old hardware, but I may need to work out a driver issue (sound familiar?)


They also have ARM images for the Pi:


“someday” there will be a need for “Old Void images”, but for now, as a new port, there isn’t much old out there to find. Just as an example of one extreme.

For this kind of site, you would need to make a clone of the ‘repository’ (often, now, a ‘git repository’) to capture the past iterations.


Releases that have been around longer, often have a formal release cycle and formal “support” periods where serious security fixes get applied (as a ‘patch’) to older versions. Eventually, even older releases exit the “interesting to developers” land and are left to rot. Sometimes a ‘friend of the project’ takes on the job of being the project attic…


Ubuntu loves to come out with new releases and rapidly drop older software from their “current”. From live desktops (Unity) to their preferred applications, they love to do that Microsoft thing of “that’s old so it’s gone, this is new so it’s all you get”. Then the hollers from the masses cause them to sometimes recant. BUT, while that new one is shoved at everyone, you sometimes need to know where to get the old ones.


The following old releases of Ubuntu are available:

Ubuntu 4.10 (Warty Warthog)
Ubuntu 5.04 (Hoary Hedgehog)
Ubuntu 5.10 (Breezy Badger)
Ubuntu 6.06.2 LTS (Dapper Drake)
Ubuntu 6.10 (Edgy Eft)
Ubuntu 7.04 (Feisty Fawn)
Ubuntu 7.10 (Gutsy Gibbon)
Ubuntu 8.04.4 LTS (Hardy Heron)
Ubuntu 8.10 (Intrepid Ibex)
Ubuntu 9.04 (Jaunty Jackalope)
Ubuntu 9.10 (Karmic Koala)
Ubuntu 10.04.4 LTS (Lucid Lynx)
Ubuntu 10.10 (Maverick Meerkat)
Ubuntu 11.04 (Natty Narwhal)
Ubuntu 11.10 (Oneiric Ocelot)
Ubuntu 12.10 (Quantal Quetzal)
Ubuntu 13.04 (Raring Ringtail)
Ubuntu 13.10 (Saucy Salamander)
Ubuntu 14.10 (Utopic Unicorn)
Ubuntu 15.04 (Vivid Vervet)

The following releases are also available which have been superseded by later point releases (the current point release is available on releases.ubuntu.com as usual):

Ubuntu 12.04.4 LTS (Precise Pangolin)
Ubuntu 14.04.3 LTS (Trusty Tahr)

Some old releases of Kubuntu, Edubuntu, and Xubuntu are also available here.

For current releases, see releases.ubuntu.com.

Ubuntu is based on Debian. It takes a bit more to find where Debian has their attic.



Even here, early versions are not to be found. Nothing from the 1.x series, and 2.x is sparse. Historians will be frustrated…

The following releases are currently available here:

    Some user-provided 2.0, 2.1 and 2.2 images (Hamm, Slink, Potato)
    3.0_r0 to 3.0_r6 (Woody)
    3.1_r0 to 3.1_r8 (Sarge)
    4.0_r0 to 4.0_r9 (Etch)
    5.0.0 to 5.0.10 (Lenny)
    6.0.0 to 6.0.10 (Squeeze)
    7.0.0 to 7.11.0 (Wheezy)
    8.0.0 to ... (Jessie) 

Then there are the “oddball” formats to deal with and the obligatory nag to never ever even think of using anything but the latest bit of 2 GB memory needed and quad core Intel code on your old 386 box with 64 meg of memory… (bold mine)

Notes for older versions

Most importantly: the archive images are provided as a service for our users who may need them. We strongly recommend that you install the current stable release of Debian if at all possible, as that is where you will receive the best support. Older releases will no longer receive security updates – this is limited to 12 months after the release of the succeeding stable version (e.g. Squeeze was released on the 6th of February 2011, meaning that we stopped formal security support of Lenny in March 2012).

By default, for each release here we keep all the images in jigdo format to save on space and download times. We also often keep the ISO images for the last release of each series.

In the days of Woody (3.0), we started producing DVDs reliably for every release from r5 onwards. Later releases included both CDs and DVDs as a matter of course.

Starting with Etch (4.0), we started making multi-architecture CDs/DVDs which would boot and allow for installation on more than one type of computer.

Starting with Lenny (5.0), we added Blu-ray (BD) images, downloadable only in jigdo format for the sake of mirror space and bandwidth. We also regularly produced live images – bootable images that run completely from the CD/DVD/USB stick and do not need to be installed to your hard disk. (More details…)

Starting with Squeeze (6.0), we started building CDs and DVDs for kfreebsd-amd64 and kfreebsd-i386, marking the first released non-Linux port of Debian.

Not familiar with “jigdo”? Well, nobody else is either. Last I looked there were something like 2 places still using it. I would characterize it as a sort of strict Bittorrent with central control. Never has caught on. Eventually, it will only be found in old archives of other releases… but a bit longer in Debian.

Now a particular peculiar problem comes up with Net Based Releases like Debian, where you do most of your install from the internet. You need an online repository from which to get that “apt-get install”… It is unclear to me where you find that for an old “Woody” release, but it likely ought to be found, and mirrored to be saved along with those CD or DVD images. Either that, or figure out how to create such a system from the DVDs.

Oddly, there is also ANOTHER site that claims to be the Debian archive (and points to a third…):


but it looks to be more an archive of the source listings:


If you need to access one of the old distributions of Debian, you can find them at the Debian Archives, http://archive.debian.org/debian/.

You can search packages in the old distributions at http://archive.debian.net.

Releases are stored by their codenames under the dists/ directory.

squeeze is Debian 6.0
lenny is Debian 5.0
etch is Debian 4.0
sarge is Debian 3.1
woody is Debian 3.0
potato is Debian 2.2
slink is Debian 2.1
hamm is Debian 2.0
bo is Debian 1.3
rex is Debian 1.2
buzz is Debian 1.1

As time goes on we will expire the binary packages for old releases. Currently we have binaries for squeeze, lenny, etch, sarge, woody, potato, slink, hamm and bo available, and only source code for the other releases.


CentOS (as the Community ENTerprise Operating System) derivative of Enterprise Red Hat (i.e. RHEL without the price) is easy to find, and surprisingly complete. Then again, it tends to be used by folks who know they may be sued and know they may need to assemble “what the system was like then” or lose. Though even they are missing the 1.x series…


[DIR]	2.1/	19-Aug-2009 01:36 	- 	 
[DIR]	3.1/	31-Jul-2005 16:05 	- 	 
[DIR]	3.3/	17-Mar-2005 11:17 	- 	 
[DIR]	3.4/	01-Mar-2005 01:38 	- 	 
[DIR]	3.5/	28-Jul-2005 16:14 	- 	 
[DIR]	3.6/	04-Apr-2006 16:59 	- 	 
[DIR]	3.7/	06-May-2006 01:20 	- 	 
[DIR]	3.8/	20-Apr-2012 10:55 	- 	 
[DIR]	3.9/	20-Apr-2012 10:49 	- 	

and on down to 7.2 of May 2016… I’m not listing the RHEL or older Red Hat (the original) series. While I have an old Red Hat 7.2 CD set (from just before the RHEL conversion of numbers) and used to run it preferentially, that conversion and subsequent changes left me uninterested in them. CentOS is about as close as I come. In anyone else cares, they can put up links to that stuff.


For some things, you may need to go to “The Wayback Machine” at archive.org. Here’s an example using Slackware:


A bit sparse. Some sites ask to be left out. Others just got missed. Sometimes the same name of a link causes it to be hard to find as you must pick the right date and hope an archive sweep caught it. Still, it can be your friend.

Slackware has dozens of mirrors, and each may well have different ‘cut off’ for the oldest releases they have “up”. Good luck digging through all that…


At one time I’d just occasionally buy a CD set for various releases, and I’ve got a few very old Slackware… in a box… somewhere…

An Archive For All:

On my “someday” dream list is to set up a Linux / BSD archive site where I can collect at least one copy of every release… but that would take a lot of money I don’t have. Oh Well. Besides, someone else is already doing it, and for Mac & Windows too:


BSD and other Hardware Broad support OSs

There are literally hundreds of “distros” of Linux and a half dozen of the BSDs. Each with a dozen or more major releases. The problem space is exponential in growth. Then some OSs, like FreeBSD, run on a half dozen different chip sets and platforms. Note the naming in this link. FreeBSD-Archive/old-releases/i386/ That’s the old i386 CPU and the 8.1 release.


At that “old-releases” level they have:

Index of /pub/FreeBSD-Archive/old-releases/
Name	Last Modified	Size	Type
Parent Directory/	 	-  	Directory
alpha/	2009-Feb-09 11:40:11	-  	Directory
amd64/	2014-Jun-24 11:55:14	-  	Directory
i386/	2014-Jul-01 09:29:11	-  	Directory
ia64/	2014-Jul-01 10:06:00	-  	Directory
pc98/	2014-Jul-01 10:17:03	-  	Directory
powerpc/	2014-Jul-01 10:19:28	-  	Directory
sparc64/	2014-Jul-01 10:39:32	-  	Directory

Seven different major CPU chips. Other releases, too, can have “variety chip-sets”… So a “full collection” would be:

Chip-sets x OS_Distro x Version x Minor_Number x {Options – like Libraries or toolchains} x Size {CD / DVD / Full / Source} and maybe a few more things I’ve forgotten.

While hot impossible to “capture that history”, the odds that it will be done, and effectively, are slim.

So I just hope that “enough” is captured for “folks like me” to do “the things we do”… I have a bookcase of old software to upload to that “oldversion” website. “Someday”. Heck, I even have one machine with a floppy drive in it that can still read the media! I just need about 4 months to “get a round tuit” and do all the unpacking, booting, uploading, etc. etc. etc. before my kids just toss it out one day after the “service” and while “cleaning out the garage”…

Oh Well… I’d do it now, but I’d rather have a cold beverage and ‘sun time’ ;-) Priorities, don’t you know ;-)

Subscribe to feed


About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

7 Responses to Where To Get Older Linux Releases

  1. tom0mason says:

    Thanks E.M. for the info. I need to change distro as 32bit is getting supported less and less for my old IBM Thinkpad 600x. I’m still stuck on the recently dropped 32bit PCLinuxOS. Its rolling release and although the 32bit is no longer updated, the PCLinuxOS64 (http://www.pclinuxos.com/ ) is still going strong and is very good. During the last 5 years I used this 32 bit distribution as my main OS and found it to be very stable, with good repository spread of software, fast at updating security updates for all the software, not always the fastest with issuing ‘normal’ updates.

    I’ve trialed ‘Void’ for a week or so recently on my old IBM Thinkpad 600x. Its good, and also has a rolling release version. I was impressed.

    Also I trailed Sparky Linux (rolling release) — http://sparkylinux.org — a bit hit and miss at first as it runs from Debian unstable branch. However it has a good friendly (if a tad slow) forum at http://sparkylinux.org/forum/index.php Overall I liked it once I got it going, and it’s footprint is small. Also it probably has the widest selection of desktop window managers.

    Manjaro (https://manjaro.org/ )is an Arch derivative and also as the rolling release version.
    Good stable platform but I had difficulty with some hardware issues (mouse and wifi dongle driver). If I can get this to perform better I’ll give it a longer trial.

    Linux Lite (https://www.linuxliteos.com/index.html ) looked very impressive and has recently been updated. Linux Lite is based on the Ubuntu LTS series of releases. LTS stands for Long Term Support, this means each release has a support period of 5 years.
    I was very impressed with the speed, impressive repositories of just about and software you could want, and the good menu system. So far it’s my favorite…

    When all else fails there is always Knoppix (http://www.knoppix.org/). I have this distribution as my fail-safe boot on a USB plug-in 320G hard drive partition, and on a thumb-drive. Very stable OS. This is my goto distro for when things go wrong. Based on Debian it has a version for those with poor sight called ADRIANE. ADRIANE is an easy-to-use, talking desktop system with optional support for braille, which can be used entirely without vision oriented output devices. Especially access to standard internet services like email, surfing the web, scanning and reading of printed documents and using mobile phone extension services like SMS (over the users own mobile phone) are supported.

    Yes, I’ve try a few others and will have to try some more as my favorite PCLinux OS for 32 bit PC is not to be supported any more.
    Ho-humm… as I need a 32 bit version, and prefer rolling release with LXDE, the field is limited.

  2. joncr says:

    CentOS stands for “Community ENTerprise OS”. I doubt any CentOS users worry about being sued since the project is effectively sponsored by Red Hat.

  3. E.M.Smith says:


    I knew that, honest I did…

    I’ve mentioned before that I have many “inner words” that differ from the outside world. Things that make the place a bit more tidy and clear. That also extends to acronyms…. and sometimes they leak out as I bypass the translation table. Oh Well…

    I’ve fixed the posting.

    My oblique reference to being sued is not about Red Hat suing them, but rather that as a large Enterprise, you know you will have many suites for all sorts of liability and may need to recreate what was to defend yourself in court.

    So, say, you have a PII system (Personal Identifying Information) and it is running a rolling release. How do you demonstrate that you ‘locked it down’ appropriately? How do you demonstrate that a proposed “exploit” could not have worked against the system of 2 years ago? It is easier with a conservative update fixed release system like CentOS. It assures more faults are found in the general population before new features are rolled into your release.

    Then, when some consumer group sues you, you have a very “protective” story to tell. Slow adoption of “new features”, fixed, highly QAed releases, your own “patch log” with any security patches applied as they are made available and regression tested. Worst case, you can even recreate exactly that system state and show you had not vulnerability, or that it was vulnerable, but no patch was yet available.

    At one company, we had a “request” go out for any evidence that we had done a particular bit of development prior to a particular date. Seems we were being sued over a “new” patent and needed to prove our “prior art”… Don’t know the outcome of that particular event, but it shows how you can be sued out of the blue, as a deep pockets, and may need to dredge up things like your devo platform from 5 years ago… (Why I always marked annual dumps as “never delete”… and preferred to keep quarterlies for as long as I could convince management to let me…)

    So, were I running a major enterprise again, I’d NOT be running it on anything like Arch or other rolling release (even though sometimes you get security fixes faster – if not QA checked enough…) just because you can’t show what you were running on any given day without a lot of hand waving. I’d pick a stable release, run it through PenTesting, apply my “custom sauce”, pentest again, then maybe do a tiger team on it; after that, it goes to acceptance testing (do all the aps work as expected without errors in regression tests) and then to deployment. I’d then NOT change it other than adding security patches until I had a good reason to change it. “Surprise outage from automatic update” is not something you want to hear at 2 AM when responding to a call from your bosses bosses boss… You also don’t want to be testifying and have your customer’s lawyer asking you “And so, fully aware that updates can crash a system, YOU as MANAGER, set up a system that just tosses updates on any time something changes? Breaking a system that was working. Willfully putting my client at risk of loss of data and business!”. You instead want to be parroting to YOUR lawyer all the steps and QA testing and penetration testing and stability testing and… before you would EVER put a client at risk…

    That’s what I was thinking about. Not Red Hat suing… ( I know some of the folks there. Worked with them back “in the day”; when Red Hat was just being formed and they merged with it. So I’ve lived the FOSS culture from before there was a Red Hat.)

  4. tom0mason says:

    To be honest I’m not bothered too much with that old box or this one. They are my ‘play’ machines.
    WRT ‘locked it down’ I monitor the logs a fair bit and I do not stay online 24/7, only on for the time I need then off. I hear what you are saying it’s just I got nothing TLA companies would find worthwhile. Last time I looked I have about ~213,000 pdfs kind of sorted out, now if they wish to help me with that I’d be obliged.
    IMO it’s nice being on something this slow is I have lots of time to watch things happen, and if it looks a iffy I just pull the internet plug, examine the logs, check for root kits etc … The downside is the old thing overheats too easily (always did) and there is no simple way round it.

    Never had a problem with PCLinuxOS’s rolling release updates/upgrade/downgrades method. I can decide when, and what to upgrade/downgrade depending on the information from the update screen/ forum, etc. It’s all nice and polite. or at least it was till PCLinuxOS stopped supporting the 32bit version. I like the rolling release idea. IMO it makes your system more of a moving target for malware writers. I can appreciate that it might not be the right choice for business though.

    But just in case something goes wrong though, I’ve at least 10 other older distros on CDs and thumb-drives around about, and also some old backed-up system images. I have a number of storage devices and interface hardware to allow backing-up of all my data. I prefer to keep most of the data out of the ‘play’ box.
    Well I hope that explains it enough, and thanks again for the links — might play with some of the old Windows progs using ‘wine’, just to see what breaks.

  5. beng135 says:

    Precise Puppy 5.7.1 is the only recent Linux that worked on my oldest (late 1990s) machine. OK, Peanut Linux (yes, Peanut Linux) worked well on it originally (multi-booted w/Win95 & WinNT), but couldn’t recognize the used, $1 PCI ethernet card I put in it to work w/DSL.

  6. E.M.Smith says:


    The rolling release works pretty well for the typical home use. No worries about “what was the state of the OS 2 years ago?” under deposition. Better tracking of “zero day” and bug fixes issues. For home use, I’m running a rolling release OS, Arch. (On my DNS server, not so much ;-)

    In any case, the tool gets matched to the needs.

    Per cooling: You can help that with an added fan. Just pick a set of air entry or exit holes and point a fan at it / away from it as needed. Sometimes cleaning the fan inside helps. Also note that there are a lot of ‘enhanced cooling’ devices sold to gamers for overclocked systems. It’s a big market… From little ‘stick on heatsinks’ to CPU heat pipes to all sorts of added fan gizmos and even some liquid cooling systems. It’s really interesting. I just wish I had a use for any of it ;-) If nothing else, just leaving the lid off can let it convect faster.


    Peanut Linux? Oh Boy, a never-heard-of-it-before Linux release to explore ;-)

    Yeah, driver issues are the bane of Linux (any OS really). Oh for a modular kernel with loadable drivers and an online comprehensive archive…

  7. kneel63 says:

    “Yeah, driver issues are the bane of Linux (any OS really). Oh for a modular kernel with loadable drivers and an online comprehensive archive…”

    Got it working – grab the packages/sources THAT DAY. Make sure you can compile sources and they work. Archive that. Any working Linux should have gcc, make etc installed. You might collapse on having a working YACC/bison/(f)lex and other stuff, but that can mostly be gotten from sources too – which you archive, of course.

    I had (have) an old MP3 player front-end perl script from about 1997 or so that I made into headless standalone boxes with little 4×20 LCD and buttons on the parallel port – pre-iPod days, or at least pre-80GB iPod days ;-)

    Most are still working OK on the old hardware (old even in ’97!) & RH8. I have the distro on CD. I have everything I added as an RPM or as sources. Can still get one going on old enough hardware.
    Porting it to a PI for my friend, whose machine finally died and spending $250 on new hardware (Pi, touchscreen, cases, USB flash etc) was “good enough”. All but working except for a few issues that are hardware related. Same deal – most stuff is OK, some requires “glue” code, some requires compiling from sources, but mostly “just works”.

Comments are closed.