Linux images
A Linux ISO torrent is the standard way distributions hand out an installation image, and on release day it is usually the fastest one: the image is a single file of a few gigabytes, it is identical for everybody, and the people who want it all arrive within hours of the announcement. That combination is the exact problem the protocol solves, so projects such as Ubuntu, Debian, Linux Mint, Arch Linux and Fedora publish a torrent beside the direct download rather than trying to serve every request from their own mirrors. A distribution is also, in most cases, given away without charge by a project living on donations, which makes shifting delivery cost onto the swarm a practical decision.
Why a distribution reaches for a swarm on release day
On release day a distribution faces a demand curve no fixed set of mirrors handles gracefully. Announcements land, news of the release spreads, and a large fraction of the year's downloads happen in the first day or two. A mirror network absorbs some of that, but each mirror is still a server dividing fixed outbound capacity among everybody pulling from it. In a swarm the opposite happens: a peer that has verified a piece can pass it on, so the arriving crowd is also the delivery capacity. That is why a major release page almost always offers both, and why the torrent is often quicker in the first forty eight hours and slower in the quiet months afterward.
Which images are published this way, and which are not
Most community distributions publish an image torrent, and the ones that do not are usually not free to take in the first place.
- Ubuntu publishes torrents for its desktop and server images alongside the direct downloads.
- Linux Mint publishes a torrent for each edition, so the Cinnamon, MATE and Xfce builds are separate images with separate torrents, all 64 bit.
- Debian publishes torrents for its installer images and for its full multi disc sets, where the file sizes make the case obvious.
- Arch Linux publishes a single rolling install image on a monthly schedule with a torrent and a magnet link for it.
- Fedora publishes torrents for its editions and spins next to its own mirror system.
- Red Hat Enterprise Linux is not distributed this way, because it goes to subscribers through Red Hat's own customer portal rather than to the public.
Size decides the rest. An Alpine Linux install medium measured in tens of megabytes is cheap enough to serve directly, and a swarm adds coordination without much value. A full Debian disc set running to many gigabytes is the opposite case.
Getting a client before getting the image
To open an ISO torrent, install a client first, and take that client from the project that makes it rather than from a search result. qBittorrent, Transmission and Deluge are three open source clients, each publishes its own builds, and each project is where a build should come from. On a Linux desktop the question answers itself: the distribution's own repositories carry all three, so the client arrives through the package manager signed by the distribution, which is one of several ways clients on Linux differ from clients elsewhere. On Windows and on a Mac the installer comes from the project, and a build offered by anybody else is a build nobody has any reason to trust.
The checksum step, and what it proves
Verify the published checksum after the transfer finishes, because it answers a question the protocol cannot. The protocol already hashes: every piece that arrives is checked against the 20 byte SHA-1 hash recorded for it in the torrent's info dictionary, and a piece that fails is discarded and requested again. That is genuine verification, and it is why a completed torrent is a byte exact copy of what the torrent describes. What it cannot tell you is whether the torrent described the right image in the first place, because a torrent is self consistent by construction: every torrent matches itself.
The checksum closes that gap. Projects publish a sums file, almost always SHA-256 now, and usually a detached signature over that sums file made with the project's own signing key. Compare the hash of the finished ISO against the published value with the tool the platform already has: sha256sum on Linux, shasum with the 256 option on macOS, or Get-FileHash in Windows PowerShell.
| Check | What it proves | What it does not prove |
|---|---|---|
| Per piece SHA-1 hashes, done automatically by the client | Every piece on disk matches the torrent that was opened | That the torrent describes the image the project released |
| Info hash, the 40 hexadecimal character identifier of the torrent itself | The client joined the swarm it was pointed at | That the person who pointed at it was the project |
| Published SHA-256 checksum of the ISO | The finished file is the exact image the project published | That the checksum itself came from the project |
| Signature over the sums file | The checksum list was signed by the project's key | Anything, if the key was never checked against another source |
Each check covers the blind spot of the one above it, and the chain stops being useful wherever the reader stops looking. The terms in it, piece, info hash and info dictionary, are set out in the Glossary.
What goes wrong on release day and afterward
Release day problems are almost always congestion, and quiet month problems are almost always the opposite. In the first hours, trackers are answering slowly and every peer is still assembling its first pieces, so a transfer that starts at nothing and climbs over a few minutes is behaving normally. Months later the same torrent may sit waiting because the release has been superseded and hardly anybody is still seeding, in which case the direct download from a mirror is the working route. A client that accepts no incoming connections will still download, but it reaches fewer peers and starts more slowly, which is felt most sharply on the day the swarm is largest.
A released image is a fixed set of bytes that will never change again, which is why a torrent describes it so neatly. Keeping a folder that does keep changing in step across machines is a different problem, and Syncthing is the tool built for that one. It is also a long way from the Napster era, where a single company's index stood between every request and every answer, whereas a distribution now publishes its own torrent beside its own image and signs its own checksums.