Ubuntu默认用systemd因其面向桌面与云服务器，需热插拔、依赖自动解析等；Alpine用OpenRC因定位轻量容器，追求启动快、攻击面小，且musl与apk决定其本质轻量。
为什么 Ubuntu 默认用 systemd 而 Alpine 用 OpenRC
本质不是“谁更好”，而是初始化系统与发行版目标强绑定。Ubuntu 面向桌面和云服务器，需要热插拔、服务依赖自动解析、日志统一归集——systemd 原生支持这些；Alpine 定位轻量容器镜像，追求启动快、二进制少、攻击面小，OpenRC 无 daemon 进程、纯 shell 实现、不强制替换 init，更易审计和裁剪。
常见误判：以为换 init 就能“变轻”。实际 Alpine 即便换成 systemd，其 libc（musl）和包管理（apk）仍决定它无法直接运行多数 glibc 二进制，init 只是表层差异。
Debian stable 的软件版本为何总比 Arch old
这不是更新慢，而是冻结策略导致的确定性优先。Debian stable 在发布前会冻结整个软件源数月，只接受关键安全补丁（通过 stable-updates）和严重 bug 修复（需经过 proposed-updates 测试），所有包版本锁定在冻结时刻的 ABI 和 API 兼容状态。
Arch 则采用滚动发布，pacman 每次升级都拉取最新 master 构建产物，连 glibc 升级都可能触发全系统重编译。两者不是“新旧”之分，而是“可预测性”与“前沿性”的权衡：
- Debian：
/etc/apt/sources.list里写的是bookworm，意味着所有包行为受该 release 的 Policy Manual 约束 - Arch：
pacman -Syu后，linux内核、mesa驱动、systemd可能在同一次更新中跨大版本，依赖链由PKGBUILD显式声明，但无全局兼容性验证
CentOS Stream 和 RHEL 的 ABI 兼容到底保到哪一级
CentOS Stream 是 RHEL 的上游开发分支，不是“免费 RHEL”。它的 ABI 兼容仅承诺对 RHEL 下一版本“目标 ABI”对齐，而非对当前 RHEL 稳定版完全二进制兼容。
典型陷阱：
- 在 CentOS Stream 上编译的内核模块（
.ko文件）可能因CONFIG_*变更或符号导出变化，在 RHEL 9.3 上加载失败，报错类似Invalid module format -
libcurl在 Stream 中已升级到 8.x，但 RHEL 9.2 仍为 7.76.x，直接搬运动态链接的二进制会提示undefined symbol: curl_url_get - RHEL 的
security errata补丁（如openssl-1.1.1k-5.el9_0）不会反向合入 Stream，Stream 用的是上游社区补丁，修复节奏和范围不同
为什么 NixOS 的包路径全是哈希，而 Fedora 不需要
NixOS 把每个包构建结果存进 /nix/store，路径含内容哈希（如 /nix/store/9v6m...-firefox-120.0.1），是因为它放弃“全局 /usr”范式，改用纯函数式构建：相同输入（源码 + 编译参数 + 依赖哈希）必须产出相同输出，且不同版本共存不冲突。
Fedora 用 dnf 管理 /usr，靠 RPM 的文件冲突检测和 %posttrans 脚本维护一致性，但这也意味着：
- 不能同时装
python3.11和python3.12的完整 runtime（除非用alternatives或手动 prefix） -
rpm -Uvh升级时若中断，/usr/bin可能残留混合版本文件，需rpm --rebuilddb修复 - NixOS 的
nix-shell -p python312是瞬时环境，退出即销毁，Fedora 的dnf install python312是永久变更系统状态
哈希路径不是为了炫技，是支撑原子升级、回滚、多版本并行的基础设施代价。省掉它，就得接受状态管理复杂度转移到管理员身上。
