Among Unix-like systems an old saying goes around, that everything is a file, and the standard way of gathering those files into one thing that can be carried elsewhere is tar. GNU tar comes out of the GNU project, and its name abbreviates Tape Archive: in the years when data lived on magnetic tape, this was the tool that wrote a pile of files onto a reel in sequence. The tape itself has long since retreated to a niche, yet the format it produced is still how source code is released, how software is packaged and how systems are backed up.

Packing is all it does

A great many people assume that a .tar.gz was compressed by tar. It was not. tar only merges files and directories into a single archive, and along the way it preserves the data that describes them: the directory structure, the permission bits, the owner, the timestamps. Those details are the reason an archive can be unpacked somewhere else and behave exactly as it did at home, and they are the part most easily lost when files are moved by hand. Making the result smaller is somebody else job, handed to a dedicated compressor such as gzip, xz or zstd and joined to the output through a pipe. Hence the familiar pairs, .tar.gz, .tar.xz, .tar.zst, where the first half names the container and the second names the compressor. Keeping the two apart let each side mature at its own pace, and it explains why unpacking takes a single command no matter what the inside of the archive looks like. A different compressor swapped in later changes nothing else, and that is why an archive written years ago still opens on a freshly built machine: the container and the codec are two decisions, not one.

Three letters, one toolbox

Daily use condenses into three letters: c to create an archive, t to list what one contains, x to extract it, with f naming the file and v letting the work scroll past as it happens. The grammar is small enough that people who learn it once rarely lose it, which is unusual for a tool this old. Around those three letters sit the abilities that make real work possible: incremental archives that carry only what changed since the last snapshot, exclusions that hold a directory out of the result, and splitting across several volumes when something has to travel on limited media. Wrapped in a script, the same grammar turns into a backup routine that runs without anyone watching. Nothing is hidden along the way: no project file, no index, no state kept between two runs, only an archive and the commands that read it.

The layer under releases and backups

GNU tar is published under GPLv3 or later as free software, and every Linux distribution ships it. A GNU build can be held alongside the system own version on macOS, and ports exist for Windows as well. Source packages from open projects arrive as tarballs almost without exception, and the full backups and the incremental ones that administrators run every day lean on the same tool. The short version is that anyone who touches a Unix-like system meets it, whether or not they go looking for it, and usually before they have understood what it is doing. The same tool therefore stands at both ends of a release: whoever builds the tarball and whoever unpacks it type the identical command, and a symmetry that complete is rare.

Maintained, and still moving

As of 2026-09 the latest stable release is 1.35, while the development line is bringing in reproducible packaging: the same source tree packed on any machine should yield a tarball identical byte for byte. That weighs more than it sounds, because a release that can be rebuilt and compared is a release whose supply chain can actually be checked, and a difference of one byte becomes a signal worth chasing. The tool is free to use, with source and documentation published openly. For anyone who lives in a command line, it belongs near the middle of the toolbox rather than at the edge of it. Age is not the argument here; the argument is that the format still improves without breaking what already exists.