自己点一个，不寒碜。
我甚至还从我 timeline 中学到一个方法：隔一段时间取消 star ，再重新 star ，这样项目就会出现在所有 followers 的 timeline 上...
以前也觉得好像有点不对劲，但是想想也合理吧，真做的好的项目，这么推广下感觉没啥毛病。

@kristpan 毕竟圈子就这么大哈哈

额误发了条空信息，楼上见谅😂

@cdswyda

@cdswyda 世界就还挺小的~

@DiamondY 嗯，折腾让世界更美好 emmm

@qq565425677 是的，折腾这些东西，其实无关效率。

看完了，新知识 GET

@shijingshijing 不用情何以堪，形式化验证验证显然是小众中的小众。

@darksword21 just for fun 好建议，我更新了下文章😂

@acerphoenix 这真的算小众。我想其实你也很清楚，大众用的是啥。

接上文，要说有啥区别的，就是折腾 Neovim/Linux 这些，获得的知识更值钱一些吧。
比如我，遇到 astronvim 的 bug ，会提 PR 给上游仓库。发现 NixOS 的文档很糟糕，我直接自己写文档并分享出来。
发现 NixOS 缺少对我手头某块开发板的支持，我直接自己尝试移植。
啥时候发现社区缺少自己想要的插件，我也可能直接自己写一个。

这些折腾过程中获得的经验、创建的开源项目、在上游仓库中留下的 PR 、在社区中收获的感谢，感觉都是有价值的。

@makelove 是这样，打游戏不也是浪费时间？不也很快乐？我感觉实质是差不多的东西。

ESPHome 便宜大碗，不过想做得好用且漂亮，自己要付出很多的精力了。

@WOSHILIDAYE 是这个：

https://github.com/flarum/flarum

juicefs 的性能会好很多，它多了一层抽象，可以帮你做很多读写合并操作。

不分区 +1

on-premise 这词一听就很商业化、很正式，在商业场合才用得到吧。
个人自建些设施，一般都叫 self-host ，没见过谁用 on-premise.

@ZedRover 那是你用法有问题，你 brews 声明了要这个依赖，它自然不会被清理掉。

我的做法是只往 brews 里加我需要的包，依赖应该由 homebrew 自动处理，不要写进来。

额不小心发出去了，我继续补充下。

1. 或者用户会需要依赖私有密钥解密一些由 sops/age 加密的信息，你没有这个密钥，就得先从代码中剔除掉对应的内容。
2. 用户在长期使用过程中，可能未严格确保环境的可复现能力，比如偶然地依赖了自己现有环境中的某些数据，这会导致在新机器上复现环境时报错，需要手动解决。
3. 每台机器都会具有不同的硬件信息，比如自动生成的 hardware-configuration.nix 通常就是跟硬件相关的。此外有的用户还开了 Nvidia 显卡，如果你没有这个显卡那直接部署也会失败。

总之确实会存在一些这样不够理想的情况，因此一般还是不建议直接部署别人的公开配置，最好还是只摘抄自己需要的部分。