Linux release archive and catalog workspace

OpenFactory Research

Linux Release Archive Study: 904 Catalog Targets

A public inventory of Linux release labels, plus the source-level audit behind our historical browser VM coverage. The files below show what we found, what we rejected, and why.

By the OpenFactory Team · August 8, 2026

A release label and a bootable artifact are different facts. A catalog can say “Distribution X, version Y, desktop Z” even after the publisher removes the image, replaces a rolling build in place, or never shipped that exact combination. We ran this study because a browser launch button should not hide that distinction.

The first dataset inventories 904 target labels across 84 projects. The second records 249 manual checks against official project channels. We found acceptable source media for 159 candidates and declined 90. Those denominators measure different layers, so this report never calls the 904-label inventory a 904-image boot test.

Scope of the Linux release archive studyThe study separates a catalog inventory of 904 labels from a manual audit of 249 fixed-version media candidates. The manual audit accepted 159 candidates and rejected 90.Two different denominatorsCatalog breadth is not the same claim as exact-media verification.CATALOG INVENTORY904 labels84 distribution projectsEXACT-MEDIA WORK SURFACE351 cells81 maintained release matrices249 fixed-version candidateschecked against official project sources159 accepted90 not accepted
The inventory records what labels existed. The source audit asks a narrower question: can a fixed release be tied to appropriate official media and integrity evidence?

Prefer structured data? Download the JSON audit export. File hashes are in the SHA-256 manifest. URLs and upstream retention are accurate to the capture date and can change later.

Results

The numbers and what each one means

LayerCountInterpretation
Catalog inventory84 distributions904 target labels
Recorded maintained-release work surface81 matrices351 release and desktop cells
Manual official-source checks249 candidates159 accepted, 90 rejected
New exact mappings140 mappings19 candidates were already exact
Recorded media-fill run95 downloads0 checksum failures
Recorded resolver regression233 routesExact release media after the fill

Why 90 candidates were not accepted

Removed or replaced upstream45 (50%)
No acceptable publisher checksum20 (22%)
Catalog label was not an upstream release16 (18%)
Delivery class or edition mismatch6 (7%)
Other3 (3%)

Method

How a candidate passed

  1. 1

    Separate labels from artifacts

    We recorded distribution, version, desktop, edition, and architecture as catalog facts. No description from the comparison site was copied into the dataset.

  2. 2

    Search official channels first

    A candidate needed media on a project-controlled host, a project-listed mirror, or an official project archive. Unofficial reuploads did not qualify.

  3. 3

    Match identity and delivery class

    The version and usable form had to match the label. An installer DVD did not replace a promised live desktop, and a current rolling image did not become an old point release by renaming it.

  4. 4

    Require publisher integrity evidence

    Of the 159 accepted records, 127 use SHA-256, 19 use SHA-512, and 13 explicitly record publisher-authored MD5. A checksum generated by the same generic file host was not enough on its own.

  5. 5

    Verify the bytes and the resolver

    The fill fetched 95 new files with zero checksum failures. We then checked that no previously available route disappeared and sampled the public-page to console handoff on an exact Linux Mint target.

What the audit changed

Exact release is now a separate claim

A launchable route can use exact media, a rolling image, or a current compatible fallback. The public catalog discloses that distinction instead of turning availability into an exactness claim.

One file can cover several labels

Some publishers ship one image per release and choose the desktop inside the installer. That can make several release-desktop routes exact at the release level without creating several ISO files.

Archive retention affects product truth

Half of the rejected candidates were gone or replaced upstream. Historical browser VM coverage depends on publisher archives, stable filenames, and retained integrity records.

Fallbacks need their own regression tests

A route can remain “available” while silently changing to the wrong sibling image. We now test resolution behavior, not only availability counts.

Limits of this dataset

  • The 904 rows describe a catalog snapshot captured on July 26, 2026. They are not 904 independent boot results.
  • The 249-row source audit focuses on fixed-version gaps in the maintained release matrices. It does not score distro usability, security, speed, or popularity.
  • The 233-route figure is the resolver measurement after the media fill on August 6, 2026. Unified artifacts and inherited snapshot routes explain why route counts and file counts differ.
  • The 81-matrix, 351-cell, 95-download, and 233-route operational totals come from the versioned run summary in the JSON export. The 249 row-level decisions and their reason counts can be recomputed from either export; the operational totals cannot be reconstructed from those rows alone.
  • Upstream projects can remove or replace files after publication. Use the checksum manifest and treat every URL as an as-of observation.

Questions about the study

Were all 904 Linux targets boot-tested?
No. The 904 figure is the catalog inventory. The manual source audit covered 249 fixed-version candidates from OpenFactory's maintained release matrices. After accepted media was downloaded and verified, the resolver check counted 233 routes serving exact release media.
What counts as exact release media?
The artifact must match the requested release identity and come from an official project channel or listed mirror. It also needs publisher-backed integrity evidence. A unified upstream image can count for several desktop labels when the upstream installer chooses the desktop after boot.
Why reject a Linux ISO that still exists online?
Existence is not enough. We rejected community archive substitutions, mismatched installer media, rolling images presented as historical versions, and files without acceptable publisher integrity evidence. Those targets retain an explicitly disclosed current or compatible fallback instead.
Can I reuse the data?
The CSV and JSON files are published for inspection and analysis. They contain factual catalog identifiers and OpenFactory's recorded source decisions. Project names and trademarks remain the property of their owners, and upstream URLs can change after the capture date.

Use the catalog with the right expectation

Browse by distribution, release, and desktop. Check availability on the target page, then confirm the reported version inside the guest when historical identity matters.

Try Linux online