WorseIsBetter

这种设计属于典型的 dark pattern 之一：confirmshaming

https://deceptive.design/types/confirmshaming/

不过这里面举的例子应该都不是最早的。印象里 Windows XP 时代不少流行的桌面应用都是这种德行，能卸载干净就已经算良心了

这类问题的通用答案：不要分发预构建二进制。有篇文章讲得很好： https://drewdevault.com/blog/Developers-shouldnt-distribute/

对于开源/自由软件来说，「源码分发」是唯一合理的分发形式。如果有人想用，他可以自己下载源码构建；用户多起来之后，自然会有发行版的维护者愿意站出来帮你打包（开发者可以主动推进，但不要在软件足够流行之前这么做，不然很讨人嫌）。如果你经常关注主流 Linux 发行版的邮件列表和代码提交记录，你会发现大部分软件包的维护者并不是开发者自己。

macOS 也是同理。作为开源软件的开发者不想给苹果的专有平台交保护费，那是理所应当的。如果用户的需求强烈，自然会有人掏钱帮你上架（或者不掏钱，比如 Homebrew ）。

在自由软件的世界，从来不缺技术人才。因为这几十年来，社区积累了不计其数来自大佬们的高质量代码和技术思想可供使用和学习。人人都可以站在他们的肩膀上。而 LLM 虽然可以让平庸者更容易地营造出自己是“技术人才”的假象，但这种行为的盛行目前来看给社区带来的更多的是负担，而不是生产力。

至于所谓“产品人才”，对我们来说则是 malware/adware/bloatware 的罪魁祸首之一，白送都不要（

我很早以前偶尔写写博客，然后 2020 年的时候彻底弃坑了。
正好前几天打算重拾起来，还写了篇碎碎念： https://cismon.net/blog/hello-world/

其实各大代码托管平台，包括 GitLab/Codeberg/SourceHut 等，都有自己的 Pages 服务。
常见的需求比如自动化部署、自定义域名之类的，它们也都支持。
虽然只能部署静态页面，但个人主页和博客这种站，一般也不需要什么后端。
选择 Cloudflare Pages 更多还是因为稳定。

本来以为这又是一篇贩卖焦虑的营销号垃圾（标题确实很像），捏着鼻子点进去看的。
但读下来发现，这其实是一篇客观中肯，有思想的优质文章。如今已经很少能看到这种发自内心的深刻讨论了。

---

不过作为一个常年混迹于自由软件社区的编程爱好者，我对于所谓的 agentic coding 持杜绝态度。
除了私下进行的用于试探 LLM 能力边界的实验性工作，我无意将其用于任何实际的软件开发。

这一点不同于 OP 。或许过段时间我也会写篇博客来讨论一下自己的感受。

我的个人项目（参考我发的第一个主题帖）也有处理 32-bit/64-bit 的 off_t/time_t 。我觉得这块其实是很 trivial 的，没你说的那么复杂。

原则只有一条：管好自己的项目就行。

你的代码里需要意识到这些类型有 32-bit 和 64-bit 两种可能，并且分别对其做支持（或者不对某些情况做支持并让构建过程失败），就足够了。至于和其他程序的 ABI 兼容，是由发行版的包维护者或者用户自己（如果他们选择自行构建）来保证的。

除此之外，你唯一能做的，大概只有把构建脚本写得更灵活、优雅，再配上清晰明确的构建文档，让包维护者和用户少走或不走弯路。

另外：不建议依靠 autoscan ，那玩意只起到一个基本的示例作用，对实际项目的帮助不大。还是得想清楚自己具体需要在 autoconf.ac 中检查什么、配置什么，然后根据需求来写

我上次安装 Linux 失败，是因为那块主板的 BIOS 不支持 legacy boot 也不支持 MBR ，导致一众发行版的官方安装镜像除了 Fedora 的一个都不认。最后手动重做安装镜像为 UEFI+GPT 就好了。

不过看 OP“卡在进度条”的描述，大概不是同一个问题。OP 的问题似乎是网络环境问题导致下载软件包更新的时候卡住了，但由于没有把问题描述清楚，别人也只能猜，无法给出有用的解决方案。

@amorphobia #3

很久没碰 windows 了，所以没有特意去适配。刚弄了台虚拟机看了下，问题原因是 cygwin 环境下构建需要额外参数，加上以后就可以正常构建。

cygwin 上 arif 的核心功能包括 readline 都可以正常使用。但是 arify 用不了，大概是 LD_PRELOAD 在 cygwin 上的行为和 *nix 有所不同导致，没有细看。

Rime 能不能用不清楚，因为 cygwin （包括 msys ）上没有 librime 的包（而且它的依赖也有缺失）。如果你有兴趣可以试试。

另外，项目相关的技术讨论建议发到邮件列表（具体地址见项目主页）。这样不仅能更快得到响应（我不经常登录 V 站），还能帮助到其他用户。

@TimePPT #8

还有一点就是 "~" 和 "/" 都是可以用于 local-part 的合法字符（ RFC 5322 ），但是很多 MTA 不支持（包括我常用的某老牌企业邮箱），导致一些基于电子邮件的服务（比如邮件列表）无法正常使用。

我在使用 lists.sr.ht 的时候就遇到过这个问题，好在他们提供了另外一套地址规则作为 fallback