@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 显卡，如果你没有这个显卡那直接部署也会失败。

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

@ZedRover 不知道你搞定没，最近意识到 nix-config 配置根据用户的使用情况，复用流程可能没我前面描述的这么简单。

可能存在的问题会有：

1. 用户有依赖一些私有数据
比如我的 nix-config 仓库现在就依赖了一个我自己的私有仓库，用于存放一些敏感信息。
2.

@ZedRover 可以举个例子么？我之前测试记得是所有依赖也被清理掉了的。
zap 的逻辑应该是删除所有不在 Brewfile 里的包，而这个生成的 Brewfile 应该只包含声明的软件以及必要的依赖项。

如果你想找到在改变世界的人，不妨去 GitHub 上看看各种为爱发电的开源项目、层出不穷的 AI 创意项目，关注下 RISC-V 芯片、龙芯的 Linux 系统适配进度，了解下新兴的前后端框架、DevOps 技术等等。

没人会跑出来宣称自己的项目目标是改变世界，可实际上这些工作都可能会对世界产生影响，其中佼佼者甚至可能改变一个行业（比如说曾经默默无闻差点破产的 Docker 项目）。

靠口头讨论「技术改变世界」改变不了世界，真正改变了世界的人、项目、团队，做的都是实事，不是口头讨论。

我得说大部分人本来就没这样的理想主义，主要还是为了钱。

有想法并且真正做出了行动的永远是少部分人，而这少部分人的声量，跟大众是没法比的。

已 star

@ZedRover 大多数人的 nix-config 仓库 README 都写得挺清楚的，最简单直观的方法是：

1. 首先用官方 ISO 镜像安装好一台 NixOS 主机，图形化操作跟 Ubuntu 之类的其他发行版没啥区别。你要是熟悉命令行也可以用命令行。
2. 安装完进入新系统后，先修改 /etc/nixos/configuration.nix 安装 git
3. 用 git clone 一个 nix-config 仓库到这台新主机上，然后执行 `sudo nixos-rebuild switch --flake .#hostname`. 部署命令中的 hostname 是用于选择配置的，比如我的 nix-config 目前包含了 5 台机器的配置，通过该参数就选择其中之一进行部署。

完毕，就这三步。

@tywtyw2002 确实，官方没有文档明确说清楚了 Nix, NixOS, Nixpkgs, 以及新旧 CLI 之间的关系。

@lucifer9 @huangmingyou 如果单纯说 NixOS 跟自己写脚本以及用 Ansible 、Dockerfile 的区别，我暂时想到的是，NixOS 把环境的「可复现性」提升了一个级别，另外它的「声明式配置」也是前面几种方法所没有的。

先说下「可复现性」，Ansible 、Dockerfile 、自己写脚本，实质上都存在不可复现的安全隐患。
比如说你会用 `apt install curl` 来安装一个 curl 包，用 `pip isntall xxx` 安装一个 python 包，一个月前在 ubuntu 20.04 上跑它，跟现在跑它，下载到的包版本是可能会更新的。这通常不会导致啥问题，但是一旦出现不兼容变更的更新，那麻烦就大了。
而 NixOS 的 Flakes 功能，跟 go.sum/package-json.lock/cargo.lock/poetry.lock 一样，不需要手动做任何配置，它默认就会通过 hash 值、git commit 等手段完全锁定所有依赖包的版本号与 hash id ，这就极大地提升了环境的可复现性。

再说「声明式配置」，声明式配置工具将底层的复杂操作全部封装在了它内部，只给用户提供了简洁且必要的声明式参数。我想用过 terraform/kubernetes 的人都应该能体会到它的好处，通过改几行配置，就可以简单地更换系统的各种组件，或者直接创建并配置好一整套包含 k8s/mysql/redis 在内的云上微服务系统。如果自己写脚本或者用 ansible 去做，那这会是个大工程，要达到众多贡献者维护的 terraform 等工具的稳定性，更不知道要花多少精力。

@lucifer9 @huangmingyou #24 #28 我一起回复下吧，用传统 Linux 发行版、脚本或者 ansible 等工具，当然都能实现同样的功能，毕竟这么多年业界都是这么用的。

而 NixOS / Fedora SilverBlue / Android 以及其他类似的发行版，它们或多或少拥有的，比这些传统方法更有优势的特性就在于本文的标题：

不可变文件系统、无状态、声明式配置

如果各位有用过帖子前面提过的 Docker/Kubernetes/Terraform/Pulumi 这些现代化运维工具，应该会比较能理解这一点。