Hacker News Reader

Comment by _sinelaw_ | Hacker News Reader

Hi, I'm the author of this post (and of Fresh). I've spent a lot of time getting it distributed cleanly to Linux users of all distros, and it's an uphill battle. I'm curious how other solo maintainers are dealing with this problem. Is a self updating static binary a reasonable solution?

View on HN

I am a solo developer of a niche CLI application. The use-case is backing up your computer data to S3 Glacier (cold storage) and later restoring from it.

I took two actions to distribute my app.

First, I automatically build static binaries for Windows, macOS, and Linux: https://gitlab.com/philipmw/warmup-s3-archives/-/releases/v1... . This part is fully within my control, and I believe these binaries fully cover the potential audience. This works well because my app is just one binary, so I am not worrying about distributing assets or other complications. If you like this, adopt my `.gitlab-ci.yml`.

Second, I am already a Nixpkgs contributor, and I added my package to Nixpkgs. Nixpkgs is niche in its own way (as you point out too), but it makes it trivial to adopt my app if you're already using Nixpkgs. Given that my app's intended audience is very tech-savvy, Nixpkgs is probably a good fit here.

The answer is to not do it. Provide the source and help distro maintainers to package it for you. You can help by being responsive to maintainers' questions, making sure the source is clean (no binary blobs, weird licenses, strange build systems, generally builds like similar packages), and integrating patches from maintainers upstream.

If I don't make my program easy to install, many people won't even try it.

Being responsive to maintainers doesn't help if maintainers never reach out or even actively refuse to package your software.

In the early stages you can help by making your source code easy to build. No weird build system, make dependencies optional as much as possible, document how to build, reduce the number of steps required and make them as similar as possible to comparable software. Linux users will put up with this. That also helps distro packagers so it's a win-win.

The existence of a build step at all, even a nice and simple one, is enough to deter lots of users who would find a lot of software useful. Remember that nontechnical users exist (e.g. folks who only know how to install software via a GUI).

Sure. They'll get it when it's packaged by the distro. Following the steps I outline will make that happen faster.

In order to be packaged, it first needs to become popular, so this is a chicken-and-egg problem.

This is not true, at all. Debian has like 50K packages, many of them extremely niche. Packaging is all about how difficult something is to build/package, not how popular it is. I've been a Linux distro packager for decades.

His program is a CLI only text editor. The people who both would specifically seek out a CLI text editor, and have needs that aren't being met by the numerous other CLI text editors available on Linux, are a much more technical userbase than the typical desktop computer user.

Usually thats the job of the Distro maintainers, your job is to provide a .tar.gz site on your website, the distro maintainers are responsible for publishing your app on their distro's.

This doesn't really scale, and it doesn't really solve the problem for your (potential) users to wash your hands of software delivery like this.

I mean thats the whole philosophy of Linux distros, anyone can create a Linux distro but the job they then take on is maintaining their own distribution of packages. I'm not saying your wrong; I'm just saying that is the what a Linux distribution _is_.

I personally think that a self-updating static binary is the pragmatic choice. I give out my software in the form of a single static binary which my users can update using a simple "update" command when a new released is published - they also receive access to the Git repo if they for any reason choose to build it themselves. I've had users on many different Linux distributions and no one has complained yet.

Linus Torvalds has talked about this very issue. He didn’t even release his own app for Linux as a result and relied on others to pick up the slack and package the app for Linux, while telling them they were wasting their life.

https://m.youtube.com/watch?v=Pzl1B7nB9Kc

At work we maintain embedded-linux computers with a custom distro but the actual graphical interface is a separate artifact developed by another team. Moreover they have to use an SDK that only works on a specific distro (semi-closed source).

Our solution is shipping it with its own glibc and running the executable with the LD inside this separate glibc. Basically the entire userspace. It is almost like a container but the containerization is provided by systemd and there is scoped access to limited system services via mount and network namespaces.

We cannot use static programs. Our systems have limited memory so the GUI load relevant parts of the program as shared library plugins.

This is the only reliable way to distribute closed source / independently packaged Linux software. You ship it with an entire userspace. Docker and Flatpak are just that; an admittance that distributing independent software reliably on Linux is practically impossible.

Have you considered running Docker on the embedded device?

That sounds like a heavier-weight wrapper over the same system services they're using through systemd today.

It could be useful if updating is a pain point.

In this case, they may also consider Podman, as it has excellent systemd integration[1] including rudimentary container orchestration and the ability to auto-update containers and Kubernetes-style pods installed as systemd units. I've run Pihole under Fedora CoreOS this way for several years without touching a single thing to update the OS or Pihole.

[1] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

See https://news.ycombinator.com/item?id=49275165

TL; DR you're right. We are aware options like Podman and systemd-nspawn (check it out if you don't know). They are just overkill.

No we don't need / shouldn't use Docker. As jasomill guessed the disk size and memory usage that Docker needs is just unnecessary overhead. These devices have only 8 GiB disk space. systemd provides every single thing that we need; one can obtain equivalent isolation just with a systemd unit file.

If you don't need the layers of Docker and server pull-push, it is just overhead. We just fetch a single cryptographically signed squashfs file and execute the program in it with limited FS and separate namespaces.

I feel like Zed, rustup, and a lot of other applications (with CLIs) moved in that direction. (Hope someone corrects me if that’s wrong, unsure those projects are fully static, but they do self update.)

As a user that surprised me at first, but I’ve grown to really like it!

> Is a self updating static binary a reasonable solution?

It's a reasonable antidote against DLL hell, so I would say yes, that's as close to an ideal solution as we can get.

Considering you are already using Rust and looking at a static binary: why not package that inside the various distro-specific formats?

Sure, you won't get into the official repos that way, but do your users really care? Fedora users are pretty used to enabling Copr and RPMFusion, Ubuntu has its PPAs. It's not ideal, but it's good enough. Even an RPM/DEB via Github release would already be a good start.

Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update

Not sure about debian/ubuntu.

You can easily setup a copr repo for this to solve the auto update qualms for almost all the RPM repos. Needs a spec file and that's about it.

AUR should do.

Debian. Eeshk.

Rust binaries are not static by default, they _statically link other crates_ by default. Subtle but important distinction.

I think the only downside with the musl binary is that there can be a performance hit compared to libc, which may or may not be an issue for a terminal text editor.

I also echo some of the comments here saying it's entirely reasonable for a single maintainer not to support absolutely every single distro unless it's straightforward or enjoyable.

Just use Steam. Works on all the Linux distros. lmao Ironically this might not even be as stupid a suggestion as it sounds.

Costs money and is centralized with a for-profit entity, probably best to stay far away when it comes to day-to-day software.

Don't get me wrong, I love Steam, but for video games. You can't stop auto-updating for example, and still be able to launch the "game" (program in this case) if it's out of date, which obviously breaks pretty much every professional computer user's workflow.

It doesn't have to cost money. You can write a normal Windows app and run it under Proton. For end users, provided that they have Steam installed (it's free), they can just add "Non-Steam game" to the library - it's ~4 clicks.

It works. It works great. It's actually the only sensible solution if you want something compiled today to work without changes on both Windows and Linux in 10 years.

I did an experiment, implementing a GUI calculator, and Rust + Slint + cross-compiling to Windows (I develop on Linux) + Proton runtime was the clear winner:

    - compiled bundle: 20 MB (F#/dotNet + Avalonia: 207 MB)
    - loc: ~1000 (dotNet: ~700)
    - dlls: none other than what Wine provides (dotNet: 67 .dll files)

You have an option to build for Linux for dev/testing, then you cross-compile to Windows and provide a short (4 points) instruction for adding the Windows build to Steam on Linux. It works, and it will most likely continue to work in the future, unless Valve folds and both Wine and Proton die. The only thing worth looking out for is crates that depend on external shared libraries: you need to bundle them manually. Other than that, it works.

Another option I considered was Zig with the Win32 API, but the LOC count was unacceptably high.

I'm working on a write-up for the experiment. The premise was: "I'm working on Linux and want to create a GUI app that will, with the build done today, continue working on Windows and Linux for the next 10 years". Steam/Proton + mostly static compilation + bundled libraries is the only solution that makes this mostly painless.

> It doesn't have to cost money. You can write a normal Windows app and run it under Proton. For end users, provided that they have Steam installed (it's free), they can just add "Non-Steam game" to the library - it's ~4 clicks.

Publishing on Steam costs money: https://partner.steamgames.com/doc/gettingstarted/appfee

I'm saying you don't need to publish on Steam to make your app run on Steam. You really don't. A user can add any executable to the Steam Library via the "Add a Game -> Add Non-Steam Game" button in the bottom-left corner of the GUI. It works 100% locally and with any kind of executable (not just games). It also bypasses any auto-updates. Finally, you can launch an app like that from the CLI or a desktop shortcut without opening Steam (well, it'll still run and update itself when needed, but you bypass the GUI).

The full discussion about this I had with ChatGPT is here: https://klibert.pl/statics/Steam-Linux-Runtime-Stack-2026-08...

> A user can add any executable to the Steam Library via the "Add a Game -> Add Non-Steam Game" button in the bottom-left corner of the GUI.

Yeah, but that's also not exactly a better user-experience for the end-user than "Download .exe, double-click to launch" or "Download .msi, finish install, run program".

Distribute your software however you want, I tend to try to make the download and install as familiar as possible to the users of the specific platforms.

Btw, even your starting prompt is guiding the model to just agree with your opening statement. You can't just roll with whatever the model says and assume the conclusion of "definitely can run in 10 years unchanged" is true.

Yeah, that's why the second prompt starts with "You misunderstood" and a correction. This is a long conversation, with multiple experiments performed and a lot of inspection of all the intermediate results on my end between prompts. You assuming otherwise without reading is a bit offensive.

To your point on installation: sure, but if you value it that much, just pay Valve to add you to the Steam store? And that would be the only possible solution given my constraints, all explicitly mentioned at least once in the linked conversation:

   - binary produced today works
   - without changes
   - on both Linux and Windows
   - is a GUI app
   - has some dependencies
   - is developed on Linux (no Windows needed)

For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)

For other constraints, it's a solution. Worth considering. That's all.

> You assuming otherwise without reading is a bit offensive.

Yeah sorry, hurling huge LLM conversations at me tends to make me skim them, hope you don't mind I didn't study the conversation you had with ChatGPT in detail.

That you considered someone skimming a chat log offensive yet the act of sharing those chat logs and expecting others to dredge through them, is almost offensive to me. So I guess we can call it even now.

> For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)

Cross-compiling the good old way, with a Linux VM, Windows VM and a macOS host (maybe Mac Mini?). I basically have the very same requirements (+ macOS), except zero third party dependencies, and end up doing it this way, all managed with Nix so basically all the installation-bloatyness is something I deal with so users get the exact same experience they expect on their OS.

> I'm saying you don't need to publish on Steam to make your app run on Steam.

The context was how to distribute software to Linux users. Not how Linux users could run Windows software.

And you can use Wine or Crossover to run your app on the Mac.

Better yet, build it for Windows 95, and it'll not only run under Windows, Linux, and macOS, but you can even package it to run in a browser[1].

For command-line programs, you might try something like Cosmopoliton[2] instead.

[1] https://www.pcjs.org/software/pcx86/sys/windows/win95/4.00.9...

[2] https://github.com/jart/cosmopolitan

Steam works because it packages certain distros that everyone can rely on. It's the same approach as Docker or Flatpak.

Steam provides a stable Linux runtime, but it's not containerized or isolated Docker/Flatpak-style. It's closer to a chrooted env with some specific distro, but without chroot and the need to maintain said distro. They want to provide runtime stability and compatibility comparable to that on Windows - it's a great initiative, and I really hope they'll succeed. The snowflake-like userlands on Linux are a pain, but the current solutions (Docker, Flatpak, things like conda) are all bad solutions to this particular problem (though they are good solutions to other problems, so it's not a criticism, just a difference in goals).

However, Steam Runtime for Linux was still in beta, last I checked. Plus, it doesn't solve the cross-platform part. But for Linux-native development, Steam Runtime might be what's needed to have long-term compatibility for apps (finally).

It's xkcd927 of a container.

Probably not, you'll receive flak for that in some circles.

I made a different post, but fits here as well: https://news.ycombinator.com/item?id=49271276

TLDR is basically that you don't have to package it for others, the expectation is that people using the distributions will package it for themselves and others if the software ends up useful enough and they want it in the distribution. Until then, just ship a zipped up binary or whatever and call it a day.

Reply on news.ycombinator.com