@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 这些现代化运维工具，应该会比较能理解这一点。

@huangmingyou NixOS 只负责维护系统状态，数据状态还是需要 lvm snapshot 来维护。

@lucifer9 理解，你自己写脚本安装软件、恢复配置文件，恢复整个环境，当然也完全可行，毕竟很多运维都是这么干的。

接前文 #22 ，NixOS 有这么一份可解释的、声明式的「知识」的好处在于：

1. 对系统做任何修改都很方便、安全、干净
2. 可以很方便地分享给别人，其他人也能通过简单的配置内容审查，确定你的配置是无害的

@lucifer9 #19 哦漏了一点，你用系统自动快照来管理系统状态。

这里的区别在于，系统快照的内容是不可复现的，快照内容不包含如何从零构建这个快照的「知识」，是不可解释的。

而 NixOS 的配置是一份从零构建出一个一模一样的 OS 的「知识」，是可解释的，而且可以通过简单几行命令就自动完成这个构建。NixOS 配置本身既是一份记录你的 OS 都做过哪些变更的文档，也是用于自动构建出这个 OS 的配置。

@lucifer9 #19 单纯从 dotfiles 管理的角度看，我也觉得没啥区别。
但是 NixOS 作为一个 OS ，它的配置显然不仅仅只能管 dotfiles ，它的配置文件可以管理整个操作系统的大部分状态。

我贴下我写过的云原生相关内容：

https://thiscute.world/series/%E4%BA%91%E5%8E%9F%E7%94%9F%E7%9B%B8%E5%85%B3/

看来得考虑迁移数据了

@vcn8yjOogEL 想了下还真是，Android 包老早就是不可变了，还带签名校验，灯下黑了我。