feat: complex merging algorithm - nixpkgs module system

docs/introduction/advantages-and-disadvantages.md

@@ -38,8 +38,8 @@
   - To ensure the ability to roll back the system at any time, Nix retains all historical environments by default, resulting in increased disk space usage.
   - While this additional space usage may not be a concern on desktop computers, it can become problematic on resource-constrained cloud servers.
 - **Obscure Error Messages**:
-  - In general, error messages are usually clear. However, in some cases, the error messages may not provide specific reasons, and using `--show-trace` can produce a lengthy internal stack trace, making it time-consuming to identify the root cause.
-  - Two potential reasons for this problem are: (1) Nix is a dynamically-typed language, and various parameters are determined at runtime, and (2) error handling logic in the used flake packages may be inadequate, resulting in unclear error messages. Some obscure errors may not even be traceable through error stacks.
+  - Due to the [complex merging algorithm](https://discourse.nixos.org/t/best-resources-for-learning-about-the-nixos-module-system/1177/4) of the [Nixpkgs module system](../other-usage-of-flakes/module-system.md), NixOS error messages are quite poor. In many cases, regardless of whether you add `--show-trace`, it will only tell you that there is an error in the code (the most common and confusing error message is [Infinite recursion encountered](https://discourse.nixos.org/t/infinite-recursion-encountered-by-making-module-configurable/23508/2)), but where exactly is the error? The type system says it doesn't know, so you have to find it yourself. In my experience, **the simplest and most effective way to deal with these meaningless error messages is to use a "binary search" to gradually restore the code**.
+  - This problem is probably the biggest pain point of NixOS at the moment.
 - **More Complex Underlying Implementation**:
   - Nix's declarative abstraction introduces additional complexity in the underlying code compared to similar code in traditional imperative tools.
   - This complexity increases implementation difficulty and makes it more challenging to make custom modifications at the lower level. However, this burden primarily falls on Nix package maintainers, as regular users have limited exposure to the underlying complexities, reducing their burden.

docs/zh/introduction/advantages-and-disadvantages.md

@@ -37,8 +37,8 @@
   - 为了保证系统可以随时回退，nix 默认总是保留所有历史环境，这会使用更多的硬盘空间。
   - 多使用的这这些空间，在桌面电脑上可能不是啥事，但是在资源受限的云服务器上可能会是个问题。
 - **报错信息比较隐晦**:
-  - 一般的报错提示还是比较清楚的，但是遇到好几次依赖版本有问题或者传参错误提示不出原因，`--show-trace` 直接输出一堆的内部堆栈，都花了很长时间才定位到，通过升级依赖版本或者修正参数后问题解决。
-  - 猜测导致这个问题的原因有两个，一是 Nix 是动态语言，各种参数都是运行时才确定类型。二是我用到的 flake 包的错误处理逻辑写得不太好，错误提示不清晰，一些隐晦的错误甚至通过错误堆栈也定位不到原因。
+  - 由于[Nixpkgs 中模块系统](../other-usage-of-flakes/module-system.md)的[复杂的 Mergeing 算法](https://discourse.nixos.org/t/best-resources-for-learning-about-the-nixos-module-system/1177/4)，导致 NixOS 的报错信息相当糟糕。在很多情况下，不管你加不加 `--show-trace`，它都只会告诉你代码有错误（最常见且最迷惑的报错信息是 [Infinite recursion encountered](https://discourse.nixos.org/t/infinite-recursion-encountered-by-making-module-configurable/23508/2)），但究竟是错在哪？类型系统说我也不知道，这得你自己慢慢找了。目前我的经验来说，**遇到这种报错信息没任何意义的 bug，最简单有效的解决方法是用「二分法」一点点还原代码**。
+  - 这个问题应该是 NixOS 目前最大的痛点之一。
 - **底层实现更复杂**：
   - Nix 多做了一层声明式的抽象带来了诸多好处，而其代价就是底层的代码实现会比传统的命令式工具中的同类代码更复杂。
   - 这导致实现难度更高，对底层做些修改也会更麻烦。不过这个问题带来的负担主要是在 Nix 软件包的维护者身上，普通用户接触底层比较少，负担也就小很多。