我想要的只是让Fresh在每个人、每个地方都能轻松安装——这有多难？Windows和macOS还不错，因为它们相对统一。对于Windows，我使用winget——虽然丑，但能用（在克服了最初的麻烦后）。目前我正在使用homebrew来处理macOS，这并不是理想选择，但设置也不难。一旦我花时间正确打包它，我可能会转向更本地化的已签名mac应用。对于现代Windows和macOS用户，这两种解决方案都能正常工作。但Linux就不一样了。我开始将Fresh作为npm包发布。这感觉很丑，令一些hn的用户烦恼，但也有真实的问题：安全性——npmjs经历过多次漏洞，我想晚上能睡得更好。不普遍——许多用户没有安装npm，他们为什么要仅仅为了安装Fresh而安装npm呢？奇怪的安装程序——npm安装流程实际上是一个脚本，你从npmjs下载，然后去github下载适合你机器的正确二进制文件。每次你想要更新都需要这样做。因此，我听取了那些烦恼用户的反馈，(在几位热心贡献者的帮助下) 我们继续创建了“所有”包：rust的cargo在crates.io（还有cargo-binstall），无发行版的包如AppImage和Flatpak，deb，rpm，AUR（Arch Linux），两种变体——源代码构建和预构建的二进制包——bin包，nix，mise，Linux的homebrew（这是什么鬼？），npm / npx，Terra，Gentoo，GURU。此外，我还以tarball的形式发布了预构建的二进制文件。你可以想象所有这些是多么脆弱。每次发布后，我都在想我会否遇到某种问题，一种或另一种渠道都有可能出错。每种解决方案对某些用户有效，但没有一个能对所有用户都有效。而且它们都有缺点。"为什么不使用nix？！"因为很多人没有安装nix，并不想单为了使用我的应用而安装它。我支持nix作为一种方法，但它并不适合所有人。"只需使用Flatpak！"我确实发布了一个Flatpak，但实际上我正在与之作斗争。它是为自包含的沙箱桌面GUI应用设计的，而我发布的是基于终端的TUI，允许你在机器和网络中翱翔。我传递了一些可怕的“坏实践”标记以让它正常工作。Flatpak的沙箱并不适用。"只需使用AppImage！"我确实发布了一个AppImage，但由于按需加载的squashfs FUSE挂载，它的运行速度极其缓慢，这使得启动时间不可接受。我希望我的程序能够瞬间启动，尽可能快速。为了使启动时间合理，我的安装脚本采用了一个非常糟糕的黑客手段，将squashfs内容提取到某个地方并丢弃AppImage。如果你喜欢，仍然可以直接运行AppImage，但启动将会非常慢。在这两种情况下，它都需要安装FUSE。为什么我的应用需要FUSE？此外，由于我的二进制文件需要某个最低的libc版本，因此它实际上并不是普遍可移植的（对于2-3年前的发行版，它可能无法运行），因此我不妨使用静态链接，直接丢弃AppImage。出于某种原因，我以为仅使用AppImage能解决这个可移植性问题。最后，出于各种原因，许多人对AppImage和Flatpak（以及Snap）都有不好的看法，他们会拒绝使用它。我损失了。Debian家族的痛苦如同在另一个hn讨论中所解释的那样，我还没有抽出时间将我的.deb推送为Debian（和Ubuntu）的官方包，因为这需要所有（许多）rust依赖也成为Debian包。有很多好的理由支持这一政策——对任何包均可完全重现和自包含的构建，减少供应链地狱，等等——但这需要大量工作。我怎么能跟得上呢？我所有的直接依赖都需要在每个安全问题上在Debian上重新更新等等。我没有时间这样做。我不能仅仅将所有依赖作为源代码纳入我的deb源包，那违反政策。另一个有趣的轶事是，我确实希望支持运行例如旧版Ubuntu（和我想任何旧的发行版）的老机器——但这些机器有旧版的libc，这意味着我为新版ubuntu构建的包无法安装在旧版上，因为在二进制加载时会因为链接错误而失败。因此我必须在旧版Ubuntu容器镜像中构建并将其未修补的包继承到我的构建中——或者完全放弃那些用户。这两种选择都不行。没有.deb /.rpm的自动更新因为这实在是个麻烦，我没有让我的.deb（或.rpm）包被官方源接受。因此，安装这些包的用户在运行系统的本地包更新机制（如apt-get upgrade或相应命令）时无法获得自动更新。如果有一个快速的无服务器解决方案，能够仅通过一个URL来查找单个包的新版本，apt和dnf都能记住并更新包，那就太好了。我很清楚这里“正确”的做法是将我的包纳入官方渠道。