Fresh is a small terminal editor written in Rust. Its author wanted one ordinary thing: make it easy for people to install.

He ended up supporting npm, Cargo, Homebrew, winget, Nix, Flatpak, AppImage, AUR, .deb and .rpm packages, prebuilt tarballs, and now a plan for a self-updating musl binary.1

The post he published this week is not proof that “Linux is impossible.” It is more useful than that. It shows how distribution can become a second product for a small software project to maintain.

Every universal solution is universal for someone

Fresh began with npm. Publishing was straightforward, but asking people to install Node just to obtain a Rust binary was odd, and the install flow still fetched the matching artifact from GitHub.1

So the project accumulated channels: Cargo, Nix, Flatpak, AppImage, AUR, native packages, and archives.

Each solves a different slice of the problem.

Flatpak provides distribution-independent runtimes and runs applications inside sandboxes. By default, access to host files, networking, devices, and other processes is restricted and must be granted explicitly.2

That makes sense for a desktop application designed to be isolated. It is less natural for a terminal tool whose job is to roam through files, execute tools, and interact with the machine. Fresh’s author says he has to relax the sandbox heavily for the application to make sense.1

That is not a general failure of Flatpak. It is a mismatch between a security model and a particular kind of application.

AppImage moves the compromise again

A type-2 AppImage contains a SquashFS filesystem that its runtime normally mounts using FUSE before executing the bundled application.3

Fresh ships one, but its author considers startup too slow for the experience he wants. His installer therefore extracts the contents to avoid paying that mount path on each launch.1

AppImage’s own documentation describes extraction as a fallback when FUSE is unavailable.3

Nothing here is simply broken. The goals conflict: single-file delivery, host compatibility, minimal dependencies, startup speed, updates, and security do not all point toward the same format.

Native packages add human process

A .deb or .rpm feels like the obvious answer: use the distribution’s own package manager.

But being integrated into official repositories is not the same thing as placing a package file on a release page. Fresh’s author says he has not had the time to push its Rust dependency tree through the processes required for Debian/Ubuntu and Fedora.1

A package downloaded directly also does not magically get the same update path as software installed from a configured repository.

Fresh also hits a boring compatibility problem: a binary linked against a newer libc may not run on an older distribution.1

Building on an old base can improve backward compatibility, while static linking shifts the compromises somewhere else again.

Fresh is coming back to a binary that updates itself

After trying to serve many ecosystems, Fresh now plans to recommend a statically linked musl binary with its own update command.1

The author jokes that he is effectively implementing a tiny package manager.

That model is not universal either. Self-updating binaries bypass some of the governance and guarantees that system package managers deliberately provide. Many managed environments will not want them.

For a solo maintainer or small team, however, it can collapse a large maintenance matrix into one path.

Packaging is a product decision

Distribution is often treated as the final box after the build: produce a binary, then choose a couple of formats.

In practice, the choice determines who can install the software, how updates arrive, what the application may access on the host, and how much release work the maintainer promises forever.

For Fresh, a small cross-platform terminal editor, that matrix grew expensive enough to change the distribution architecture of the project.1

This case does not prove there is one correct way to ship Linux software. It proves almost the opposite.

The delivery format is part of the tool. And for a small team, every package format you promise to maintain is a feature too, just one users mostly notice when it breaks.