Skip to content
Dev Tools Article

Linux Packaging Didn't Get Fixed. It Got Bypassed

A Rust editor shipped through ten channels, and the lone survivor says everything about where distribution is heading.

Lenn Voss
Lenn Voss
Cloud & Infrastructure Writer · Aug 12, 2026 · 5 min read
Linux Packaging Didn't Get Fixed. It Got Bypassed

The author of Fresh, a Rust terminal editor, spent months shipping it through more than ten Linux channels — deb, rpm, AppImage, Flatpak, AUR, Nix, Homebrew, npm, cargo, mise, Gentoo's GURU — and just published a frustrated post-mortem that hit the Hacker News front page. His conclusion: abandon nearly all of it and ship a statically linked musl binary with a built-in self-updater.

That ending is the interesting part, because it's not one developer's tantrum. It's where the entire developer-tools ecosystem has quietly converged, and it amounts to a repudiation of the Linux distribution model that traditionalists are still defending in the comments.

The social contract nobody renegotiated

The classic Linux deal goes like this: you write software and publish source; distro maintainers package it, review it, and ship it through their repos. The top-voted pushback on HN was exactly this — "you provide sources and instructions on how to build them, and then your job is done."

That contract was written for C software that released once or twice a year. It fits a 2026 Rust or Go project badly. Debian's policy requires every dependency in a package to itself be a Debian package — no vendored crates in main — which for a typical Rust tool means dozens of crates individually packaged and version-pinned against whatever Debian froze two years ago. Even if you do the work, your users get the version from the last freeze, not the one you shipped Tuesday. For a fast-moving tool, "get into Debian main" is less a distribution channel than a time capsule.

Meanwhile, building your own deb outside the repos buys you a different trap: glibc symbol versioning. Link on a modern machine and your binary demands GLIBC_2.3x symbols that older Ubuntu LTS boxes don't have, failing at load time. The standard workaround — build on the oldest distro you support, the same trick Python's manylinux wheels institutionalized — means maintaining a crusty build environment forever, or reaching for cross-compilation hacks like Zig's ability to target arbitrary glibc versions.

The modern formats didn't save him either

The universal formats were invented to fix precisely this, and each failed Fresh in a characteristic way.

AppImage promises "one file, runs anywhere," but it mounts a squashfs image through FUSE at launch — slow startup for a terminal editor where startup is the whole first impression, and a hard dependency on libfuse that recent Ubuntu releases don't ship by default. The portability format has its own portability problem.

Flatpak is genuinely good at what it was designed for: sandboxed desktop GUI apps. A terminal editor is the opposite of that. A TUI's job is to roam your filesystem, spawn your shell, talk to your network — so packaging one for Flatpak means punching holes in the sandbox until the sandbox is decorative. The Fresh author admits to shipping it with "horrible bad practice flags." That's not a packaging bug; it's a category error, and it applies to most of the CLI tools developers actually install.

Even the community channels are wobbling. The AUR — long the answer to "just let users package it" — spent 2025 fighting repeated malware waves, including packages carrying the CHAOS RAT and a campaign that pushed Arch to temporarily freeze package adoptions entirely. npm's supply-chain year was worse. The Fresh author's releases stalled during the AUR lockdowns through no fault of his own. When your distribution channel's security incidents become your release blockers, "someone else's job" stops being a comfort.

Everyone already voted, with curl | sh

Here's the judgment call: the static self-updating binary isn't a workaround anymore. It won. rustup bootstrapped the entire Rust toolchain this way. uv and ruff — arguably the most successful new developer tools of the past few years — ship as static binaries with uv self update, installed by a shell one-liner that HN ritually complains about and millions of developers ritually run. Deno, Bun, and most of the modern CLI generation do the same. Astral even maintains its own fork of cargo-dist, the tool that automates exactly this pipeline, because release engineering for this model matters more to them than any distro relationship.

The HN objection — "software that overwrites itself is bad design" — isn't wrong in the abstract. A self-updater is a vendor-controlled code-execution channel, and you're trading the distro's review-and-curation layer for raw trust in one upstream. But look at what that curation layer actually delivered this year: malware in the AUR, a compromised npm ecosystem, and official repos whose review capacity hasn't scaled since the 2000s. The security argument for distro packaging is real, but it assumes a level of review that mostly no longer happens for the long tail. Firefox has self-updated on Linux for years; the sky has stayed up.

If you're the one shipping

Practical translation for anyone distributing a Linux CLI tool in 2026:

  • Make a static musl build your primary artifact. One caveat the HN thread rightly flagged: musl's default allocator is slow under multithreaded load, so link jemalloc or mimalloc if performance matters — most serious Rust tools already do.
  • If you need glibc builds (glibc-only features, dlopen), build against the oldest glibc you support, or use cargo zigbuild to target one explicitly.
  • Automate the boring parts with cargo-dist or an equivalent: tarballs, checksums, installer script, GitHub Releases.
  • Pick two or three channels you'll genuinely maintain — Homebrew and an AUR -bin package cover a lot of ground — and say no to the rest. Ten channels is how you end up writing an "I hate packaging" post.
  • Ship Flatpak only if you're a GUI app. There it's the right answer, and Flathub is the closest thing Linux has to a working app store.

The losers here are the distros' claim to be the sole distribution layer, and users on niche setups who benefited when upstreams felt obligated to care. The winner is a model that looks suspiciously like Windows and macOS: the vendor ships a binary, the binary updates itself, and the OS stays out of it. Linux packaging didn't get fixed. It got bypassed — and the developers doing the bypassing are the ones shipping the tools everyone actually uses.

Sources & further reading

  1. I hate packaging my software for Linux — getfresh.dev
  2. I hate packaging my software for Linux (discussion) — news.ycombinator.com
  3. Arch Linux disables AUR package adoption to stop malware flood — bleepingcomputer.com
Lenn Voss
Written by
Lenn Voss · Cloud & Infrastructure Writer

Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading.

Discussion 0

Join the discussion

Sign in or create an account to comment and vote.

No comments yet

Be the first to weigh in.

Related Reading