我在实际开发中使用 neovim ，插件只有一个 telescope ，配置只有 100 多行（主要是 LSP 相关的），已经好几年几乎没修改过了。临时编辑文件的话就用默认配置的 vim 。

要说原因，和 OP 主帖说的差不多：已经「习惯了」。我这人不怎么喜欢折腾，如果一个工具足够方便高效而且稳定的话，那就没必要去追求所谓「更好的」方案（除非我对相关技术感兴趣，想要研究探索一下）。似乎大部分 vim 用户都是类似的心态，这和 Emacs 社区的风气有所不同，后者似乎永远都在折腾配置，在「打造完美的编辑体验」的路上一去不复返。

几年前倒是跟风用过一段时间的 VSCode ，甚至还开发上架过插件。但还是习惯问题，用着总是感觉不趁手。虽然能装插件模拟 vim 键位，但限制很多而且经常出 bug 。另外它内置的那些类似 IDE 的各种功能，比如终端、git 集成之类的，我根本用不到（有需要的话直接用系统终端进行操作不就好了）。所以后来就把这个臃肿的玩意彻底抛弃掉了（但出于负责的态度，当年上架的插件现在还在做最基本的维护）。

这种设计属于典型的 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

Super+Return -> foot
Super+Shift+Return -> librewolf
Super+d -> fuzzel
Super+Escape -> swaylock
Print -> grim -g "$(slurp)"

无所谓了。

我在「分享创造」节点发帖，只是在随手分享自己的作品，就像和朋友分享自己的游戏通关截图一样随意。并没有指望着能有人来关注、试用、讨论技术（事实上也的确几乎没有，大概是因为这个节点帖子质量这两年有明显下降，导致潜在的目标用户都流失了），更不用提打赏了。

就算有人打赏也不可能指望着靠这个赚钱。要知道很多知名开源项目一年收到的捐赠可能都不够买一杯星巴克（

更多时候不是笨的问题，而是疏忽导致的犯错。
尤其是当程序架构设计得比较糟糕，屎山代码一堆起来，这种疏忽就更容易发生。

所以我现在写的新应用默认当我开始处理不信任的用户输入时，攻击者立即取得 ACE 。
但由于有 seccomp+landlock / capsicum 沙箱兜底，即便如此攻击者也无法造成实质性的损害（如果沙箱自身没有漏洞的话）

To Err Is Human; To Sandbox, Divine.

我自认为是一个视野短浅的人，只能看到眼下的事物而非长远的发展，从小到大没什么能称为「理想」的东西。

最开始学习计算机技术只是觉得好奇、有趣，想搞明白为什么。
刚毕业时选择一份程序员工作也只是想凭自己的技术养活自己，在社会中取得立足之地。
那时程序员就业还算容易，薪酬待遇不错，而我恰好会一点点代码，何乐而不为呢？

但由于自身能力平庸，内心也不够强大，多年来心理状态一直不太好，有时甚至到了精神崩溃的边缘。
直到我深入接触了自由软件文化，这才久违地感受到了内心的平静。

如今推动自由软件事业发展就是我的人生目标，为此我可以微笑接受一切质疑、嘲讽和谩骂，哪怕得不到任何物质报酬也在所不辞。大概这就是「理想」的魔力吧。

GrapheneOS 用户（也包括各种其他第三方 ROM 用户）内心毫无波澜：
不管你谷歌加上什么反人类的限制，我直接给它去掉不就行了。

除非有一天 AOSP 暴死，Android 变成彻头彻尾的专有软件。（其实最近已经有这样的苗头了，未雨绸缪一下也好）

@newtype0092 #43

等这个 RFC 实现了就没问题了： https://wiki.php.net/rfc/partial_function_application_v2

@passive 我在自己的 PC 上用 Proton 可以完美游玩，你也可以试试

我心目中的国产 ARPG 最佳，没有之一。没想到制作人竟然是 V 站的元老用户。V 站可真是卧虎藏龙

---

除了游玩方面的体验外，个人觉得 AI LIMIT 最大的加分项是新颖的背景设定：
不同于传统的「 AI 造反」设定，这游戏里的人类是因为过度依赖 AI 带来的便利，以至于失去了自主创造的能力。
当 AI 失控，不再为人类所用，人类这才惊恐地发现，发达的现代科技在自己手里如同破铜烂铁。
最终社会秩序难以为继，生产力重新回到了旧时代。AI 没有造反，是人类把自己作死了。

在 LLM 迅速发展，vibe coding 盛行的当下，这个故事可谓是很有前瞻性了
（记得早在 2019 年 AI LIMIT 就有 demo 了，不知道中途有没有改过剧本）

我觉得保持技术热情的关键在于摒弃功利主义和虚荣心。

当开始一个项目的时候，先问自己：人生苦短，为什么要花费宝贵的生命去做这么一个东西？

如果答案是「能给自己的生活带来方便」，或者是「有趣，能够放松身心，陶冶情操」，甚至更进一步，「能帮助他人，给社会带来价值」，那恭喜你，你做这件事的技术热情很难消散。哪怕是遇到难题，或者得不到他人的关注和支持，也不会因此而轻易放弃。

但如果反过来，如果你做个人项目是为了「挣外快」，「丰富自己的简历」，或者「向他人展示自己的技术，证明自己不是个废柴程序员」，那当你无法从中得到及时的正反馈时，热情必将大打折扣。