4 ms·

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

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?

jdc-pub 2mo ago
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!
bluedays 2mo ago
Just use Steam. Works on all the Linux distros. lmao Ironically this might not even be as stupid a suggestion as it sounds.
- embedding-shape 2mo ago
  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.
  - klibertp 2mo ago
    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.
    - embedding-shape 2mo ago
      > 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 https://partner.steamgames.com/doc/gettingstarted/appfee
      - klibertp 2mo ago
        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-10.html https://klibert.pl/statics/Steam-Linux-Runtime-Stack-2026-08...
        embedding-shape 2mo ago
        > 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.
        klibertp 2mo ago
        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.
- inigyou 2mo ago
  Steam works because it packages certain distros that everyone can rely on. It's the same approach as Docker or Flatpak.
  - klibertp 2mo ago
    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).
    - inigyou 2mo ago
      It's xkcd927 of a container.
okanat 2mo ago
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.
- inigyou 2mo ago
  Have you considered running Docker on the embedded device?
  - jasomill 2mo ago
    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.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    - okanat 2mo ago
      See https://news.ycombinator.com/item?id=49275165 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.
embedding-shape 2mo ago
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 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.
theknarf 2mo ago
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.
- uhoh-itsmaciek 2mo ago
  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.
  - theknarf 2mo ago
    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_.
flurie 2mo ago
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.
crote 2mo ago
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.
- _sinelaw_ 2mo ago
  Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update
  - aki237 2mo ago
    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.
- duped 2mo ago
  Rust binaries are not static by default, they _statically link other crates_ by default. Subtle but important distinction.
al_borland 2mo ago
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 https://m.youtube.com/watch?v=Pzl1B7nB9Kc
rwmj 2mo ago
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.
- _sinelaw_ 2mo ago
  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.
  - rwmj 2mo ago
    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.
    - zbentley 2mo ago
      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).
      - rwmj 2mo ago
        Sure. They'll get it when it's packaged by the distro. Following the steps I outline will make that happen faster.
        xigoi 2mo ago
        In order to be packaged, it first needs to become popular, so this is a chicken-and-egg problem.
Shorel 2mo ago
> 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.
GOATS- 2mo ago
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.
pmw 2mo ago
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.2.3 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.

jdc-pub 2mo ago

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!

bluedays 2mo ago

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

embedding-shape 2mo ago
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.
- klibertp 2mo ago
  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.
  - embedding-shape 2mo ago
    > 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 https://partner.steamgames.com/doc/gettingstarted/appfee
    - klibertp 2mo ago
      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-10.html https://klibert.pl/statics/Steam-Linux-Runtime-Stack-2026-08...
      - embedding-shape 2mo ago
        > 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.
        klibertp 2mo ago
        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.
inigyou 2mo ago
Steam works because it packages certain distros that everyone can rely on. It's the same approach as Docker or Flatpak.
- klibertp 2mo ago
  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).
  - inigyou 2mo ago
    It's xkcd927 of a container.

okanat 2mo ago

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.

inigyou 2mo ago
Have you considered running Docker on the embedded device?
- jasomill 2mo ago
  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.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
  - okanat 2mo ago
    See https://news.ycombinator.com/item?id=49275165 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.

embedding-shape 2mo ago

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 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.

theknarf 2mo ago

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.

uhoh-itsmaciek 2mo ago
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.
- theknarf 2mo ago
  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_.

flurie 2mo ago

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.

crote 2mo ago

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.

_sinelaw_ 2mo ago
Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update
- aki237 2mo ago
  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.
duped 2mo ago
Rust binaries are not static by default, they _statically link other crates_ by default. Subtle but important distinction.

al_borland 2mo ago

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 https://m.youtube.com/watch?v=Pzl1B7nB9Kc

rwmj 2mo ago

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.

_sinelaw_ 2mo ago
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.
- rwmj 2mo ago
  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.
  - zbentley 2mo ago
    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).
    - rwmj 2mo ago
      Sure. They'll get it when it's packaged by the distro. Following the steps I outline will make that happen faster.
      - xigoi 2mo ago
        In order to be packaged, it first needs to become popular, so this is a chicken-and-egg problem.

Shorel 2mo ago

> 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.

GOATS- 2mo ago

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.

pmw 2mo ago

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.2.3 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.