前段时间我把自己的 ThinkPad 主力系统从 Windows 11 完整迁移到了 Ubuntu。关于为什么放弃 Windows、转向 Linux我之前已经写过一篇文章《为什么我把 ThinkPad 主力系统从 Windows 11 换成 Ubuntu》那篇文章讲的是为什么从 Windows 换到 Linux。但最近我突然又想到另一个问题Linux 有这么多发行版我为什么偏偏选择了 Ubuntu仔细想想这其实和我过去十几年使用 Linux 的经历有很大关系。我工作中长期使用过 Red Hat、Fedora、CentOS后来又越来越多地使用 Ubuntu Server这些年 Arch Linux 也越来越火我最近还专门研究了一下它。最后我发现自己选择 Ubuntu并不是因为它某一项技术最先进而是因为经历了这么多发行版之后我越来越清楚我需要的不是一个最酷、最新、最能折腾的 Linux而是一个稳定、主流、生态完整又尽量不打扰我工作的 Linux。目前来看Ubuntu 正好处在这个位置。一、最早接触 Linux基本就是 Red Hat 和 Debian/Ubuntu我大概在十五到二十年前开始真正接触 Linux。当然那时候 Linux 发行版已经很多了Arch Linux 也早就存在。但至少在我当时接触到的资料和企业环境中最常见的基本就是两大体系Red Hat ├─ Fedora ├─ RHEL └─ CentOS Debian └─ Ubuntu特别是在企业环境里Red Hat 系非常常见。而我工作中使用 Linux绝大多数时候也不是为了桌面而是Server ↓ SSH ↓ Shell ↓ 编译 / 调试 / 部署所以 Linux 对我来说从一开始首先就是一个服务器、开发和基础设施平台。二、Fedora新技术很好但开发基线未必喜欢“太新”我对 Fedora 的印象其实一直很好。Fedora 更新很快Kernel、GCC、glibc、systemd 等底层组件通常都比较新。如果你的工作就是研究 Linux OS、Kernel 或新硬件特性这当然很有价值。据说 Linus Torvalds 本人也长期使用 Fedora。但我当年遇到的问题恰恰就是Kernel 和整个系统升级得太快了。Fedora 一个版本的生命周期大约只有 13 个月。这里可能需要解释一下EOLEnd of Life。EOL 并不是说日期一到电脑突然不能开机了。而是意味着这个版本正式结束维护之后不再正常获得安全更新、Bug 修复等支持。个人电脑当然可以继续用。但在企业环境里事情完全不同。服务器可能面对安全漏洞扫描公司 Security Policy客户认证第三方软件支持矩阵合规要求厂商技术支持因此一个系统到了 EOL企业通常不能简单说“还能启动那就继续用吧。”一般要么升级要么购买延长支持要么采取其他明确的风险控制措施。而在我们当时公司的 Policy 下OS EOL 基本就意味着必须安排升级。问题在于OS 升级从来不是免费的如果只是普通桌面用户升级 Kernel 可能感觉不到什么。但如果你正在开发一个和操作系统关系很深的软件事情可能变成Kernel 升级 ↓ Driver 变化 ↓ GCC / glibc 变化 ↓ 第三方组件升级 ↓ API / ABI 变化 ↓ 自己的软件重新适配甚至某个依赖不能简单升级小版本而是必须1.x ↓ 2.x ↓ 接口变化 ↓ 重新开发于是本来正在开发 Feature AFeature A ↓ 突然暂停 ↓ 升级 OS ↓ 升级依赖 ↓ 解决兼容问题 ↓ 重新测试 ↓ 终于继续 Feature A而这些工作本来根本不在项目计划里。所以后来我们越来越倾向使用长期稳定版本。这也让我很早就认识到研究 OS 和“把 OS 当作开发平台”其实是两种不同需求。研究 Linux Kernel新一点很好。把 Linux 当作几年不动的开发基线稳一点可能更重要。三、RHEL稳定是真的稳定但 Subscription 曾经让我很痛苦后来因为商业软件支持、客户环境等原因我也使用过不少Red Hat Enterprise LinuxRHEL 本身并不难用。真正让我印象深刻的是它的Subscription。商业 Linux 收费当然很合理。企业购买的不只是软件还有长期维护安全更新厂商支持认证SLA但到了开发环境里有时候体验就比较痛苦了。想安装一个软件yum install xxx结果先发现Subscription 不可用于是subscription-manager ...然后注册、关联、启用 Repository……问题是我们当时服务器访问 Red Hat 的网络经常不太顺畅。于是连接 ↓ 卡住 ↓ 失败 ↓ 再试 ↓ 继续卡最后明明只是想装一个工具却在那里折腾账号、网络和 Subscription。四、到了 Container 时代问题甚至进入了 Docker Build后来 Container 开始大量使用。如果 Base Image 使用 RHEL并且构建过程中需要安装受订阅控制的软件包那么构建流程同样可能碰到 Subscription / entitlement。于是docker build ↓ 安装软件包 ↓ 访问 Repository ↓ 网络 / Subscription 出问题 ↓ Build 失败原来只是 Host 装软件不方便。现在连自动化 Build 都可能受到影响。更麻烦的是订阅到期以后还得重新走公司流程处理。那时候我真的经常有一种感觉我到底是在开发软件还是在维护 Red Hat Subscription哈哈哈。UBI 已经改善了很多但不是所有 RHEL 软件都免费了这里也需要替今天的 Red Hat 说句话。后来 Red Hat 推出了UBIUniversal Base ImageUBI 本身以及 UBI Repository 中提供的软件可以在不绑定传统 RHEL Subscription 的情况下使用因此现在做很多普通 Container 已经方便得多。但需要注意UBI Repository 只是完整 RHEL 软件仓库的一部分。如果某个 Container 需要的软件不在 UBI Repository而来自完整 RHEL BaseOS、AppStream 等受 entitlement 管理的内容那么仍然可能需要有效的 Red Hat Subscription。所以更准确地说UBI 大幅缓解了我当年遇到的 Container 问题但并不意味着所有 RHEL 软件从此都可以完全脱离 Subscription。五、CentOS曾经是我非常喜欢的 Server Linux相比之下CentOS 曾经让我非常舒服。特别是 CentOS 7RHEL 生态 没有传统 Subscription 困扰 Kernel 比较稳定 生命周期长Kernel 老没关系。软件版本旧很多时候也没关系。对于开发平台来说我有时真正希望的是你千万别动。今天编译成功。半年以后最好还是一样。两年以后也不要突然因为系统升级让我重新适配一轮。所以 CentOS 我用了很多年。六、然后 CentOS 8 改变了这条路线后来 CentOS Linux 8 提前结束生命周期CentOS 项目的重心转向了CentOS Stream这并不是简单CentOS 8 ↓ CentOS 9而是整个定位发生了变化。过去很多人把 CentOS Linux 理解成RHEL ↓ CentOS Linux一个偏向下游、稳定、免费使用的 RHEL 兼容系统。而 CentOS Stream 更接近Fedora ↓ CentOS Stream ↓ RHEL也就是运行在 RHEL 正式版本前面的持续开发平台。当然后来出现了Rocky Linux AlmaLinux继续走 RHEL Compatible 的路线。它们当然值得考虑。但当时既然 CentOS 已经需要迁移我突然想到既然反正都要换一次 OS为什么不重新看看 Debian / Ubuntu七、结果我惊讶地发现需要的软件几乎都支持 Ubuntu于是我把需要使用的软件一个个重新检查。包括开发工具编译环境第三方 Library中间件ContainerCloud Native 工具各种开源软件自己的软件结果发现绝大多数都已经支持 Ubuntu。甚至不少项目的 Ubuntu 安装文档非常完整。这让我当时有点意外。因为十几年前我脑子里的印象一直是RHEL / CentOS Server Ubuntu Desktop结果突然发现这个认知早就过时了。八、第一次认真使用 Ubuntu Server我当然没有直接迁移。先在 VM 中装了 Ubuntu Server把过去的软件完整跑了一遍。我的目标非常简单CentOS 上能跑的东西 ↓ 尽量全部在 Ubuntu 上重新跑结果顺利程度远远超过我的预期。大多数开源软件apt install ...就过去了。源码编译gcc cmake make也基本没有什么特别大的障碍。Container 更不用说。后来很多项目我直接使用FROM ubuntu:...大量软件一次 Build 就能通过。当然不可能 100% 没问题。一些古老代码、写死 RPM 路径的软件还是需要修改。但整体体验让我第一次认真认识到Ubuntu Server 已经完全不是我十几年前想象中的那个“Ubuntu 桌面的服务器版”了。它已经是一个非常成熟的 Server Linux。九、所以这次主力桌面迁移我自然选择了 Ubuntu Desktop几年下来我越来越习惯 Ubuntu Server。于是这次 ThinkPad 从 Windows 11 迁移到 Linux 时我并没有花太多时间纠结发行版。因为Ubuntu Server这套底层我已经足够熟悉。桌面自然就选择Ubuntu Desktop这样还有一个很大的好处Desktop Server VM Container Cloud很多环境都可以共享同一套知识APT systemd 目录结构 Library 网络 Shell 工具链对我来说这比桌面主题漂亮一点重要得多。十、为什么不用更小、更轻的发行版Ubuntu 还有很多衍生版本Xubuntu Kubuntu Lubuntu Ubuntu MATE ...甚至完全可以从 Minimal 系统开始自己一点一点装桌面。这些当然都很好玩。但主力生产力电脑我反而更愿意选择 Ubuntu Desktop。原因很简单我并不想把太多时间花在解决发行版自身的问题上。我真正想研究的是Kernel Container Kubernetes Cloud Network Performance Infrastructure AI Infra我愿意折腾 Linux。但我希望折腾的是我感兴趣的 Linux 底层技术而不是每天修桌面环境。因此对主力系统我反而更喜欢用户多 资料多 第三方支持多 硬件支持全面 出了问题容易搜索Ubuntu 在这些方面的综合表现正好很适合我。十一、那 Arch Linux 为什么这些年突然这么火然后就是最近让我很好奇的Arch Linux我十几年前几乎没关注过它。但这些年 Arch 的影响力越来越大。于是我专门研究了一下Red Hat、Debian、Ubuntu 已经拥有这么庞大的生态Arch 为什么还能杀出这么一匹黑马常见答案有KISSRolling Release高度定制软件新Arch WikiAUR但研究之后我发现有些特点并不是 Arch 独有。KISS很好但不是只有 Arch 才能极简Arch 很强调Keep It Simple从一个很小的基础系统开始需要什么就装什么。这当然很好。但 Linux 本身就是高度模块化的。如果使用Debian Minimal Ubuntu Server Fedora Minimal同样可以最小系统 ↓ 安装图形栈 ↓ 安装桌面 ↓ 安装应用对于真正熟悉 Linux 的用户来说并不困难。所以极简是 Arch 的核心理念但“Linux 可以从最小系统自己搭”并不是 Arch 独有的能力。Rolling ReleaseArch 的特色在于把它作为正式使用模式Arch 最大特点之一当然是Rolling Release一直滚动升级没有传统Version 1 ↓ Version 2 ↓ Version 3这样的跨版本迁移。但如果只是想获得新软件其实其他发行版也有办法。例如Fedora Debian testing / unstable Ubuntu Development Release都可以获得比较新的软件。Arch 真正特别的地方在于Rolling Release 本身就是它面向普通 Arch 用户的正式发行模式而不是单独提供一个开发分支。这确实很有特色。同时也意味着系统一直在变化。高度定制也不是其他 Linux 做不到Arch 默认替用户做的决定比较少。你可以自己决定Desktop Window Manager Display Server Shell Network Service Application但 Ubuntu、Debian、Fedora 其实同样可以换桌面、窗口管理器甚至大量底层组件。所以 Arch 的不同更准确地说是它从一开始就鼓励用户自己决定系统应该长什么样。而不是只有 Arch 才能定制。十二、真正让我眼前一亮的其实是 AUR最后真正让我产生“Arch 这个东西一定要装一台玩玩。”这种想法的是AUR也就是Arch User RepositoryAUR 里最核心的东西其实不是传统意义上的二进制软件包而是PKGBUILD可以简单理解成告诉 Arch 怎么下载、构建和安装这个软件的一份脚本。十三、AUR 厉害在哪里如果一个软件有源码比较容易理解下载源码 ↓ 安装依赖 ↓ 编译 ↓ 打包 ↓ pacman 管理但有些闭源软件根本不提供 Arch Package。厂商可能只有.deb或者.rpmAUR 社区完全可以写一个 PKGBUILD下载官方 DEB / RPM ↓ 解包 ↓ 调整目录 ↓ 处理依赖 ↓ 重新打成 Arch Package ↓ 交给 pacman 管理于是本来官方不支持 Arch。最后变成官方没提供 Arch 包但社区已经替你包装好了。这个设计我觉得非常聪明。十四、甚至 Windows 软件也可以被包装进去更进一步。如果一个软件根本没有 Linux 版本但是 Wine 可以运行那么 AUR 脚本甚至可以下载 Windows Installer ↓ 准备 Wine 环境 ↓ 安装程序 ↓ 生成启动脚本 ↓ 创建 Desktop Entry最终用户可能只是点击一个 Linux 桌面图标。背后其实是Arch ↓ Wine ↓ Windows Application当然这并不意味着所有 Windows 软件都能运行更不意味着一定稳定。但这个思路确实很有意思。十五、不过 AUR 并不是“万能兼容层”我一开始甚至有点想把 AUR 理解成Linux 软件世界的万能兼容层。后来仔细想想这其实不准确。真正负责兼容运行的软件可能是Linux Library Wine Proton AppImage Flatpak 各种 RuntimeAUR 做的事情更像把下载、转换、编译、依赖配置、Wine 环境等复杂步骤统一包装成可复用的 PKGBUILD。因此它真正厉害的是源码 DEB RPM Binary Git Wine ↓ PKGBUILD ↓ Arch Package ↓ pacman这种强大的社区 Packaging 能力。十六、但这套模式天然也会降低“可预测性”AUR 是社区维护的。于是可能出现上游软件更新 ↓ 下载地址变化 ↓ 目录结构变化 ↓ 依赖变化 ↓ PKGBUILD 暂时失效再加上 Arch 本身是 Rolling ReleaseKernel 更新 Library 更新 Driver 更新 Desktop 更新 AUR 软件更新系统变化速度自然比长期稳定发行版更快。这不代表 Arch 不稳定。真正熟悉 Arch 的用户完全可以把它维护得很好。但它要求用户关注升级 阅读公告 理解依赖 知道系统发生了什么而这正好又回到了我当年使用 Fedora 时学到的那个问题变化本身就是维护成本。十七、所以我会不会把 Arch 作为主力系统大概率暂时不会。假设某天晚上我已经调试程序八个小时。碰到一个问题我怀疑可能和某个 Library 有关。于是顺手sudo pacman -Syu结果Kernel 更新 Driver 更新 Library 更新 几个 AUR Package 也更新然后重启。原来的 Bug 还在。结果又多出来几个新问题。……那时候估计真的会欲哭无泪。哈哈哈。所以对我来说Arch 非常值得玩。但是“好玩”和“适合主力生产力系统”是两套不同的评价标准。十八、用了这么多年 Linux我现在反而希望 OS 少一点存在感年轻一点的时候很容易觉得Kernel 越新越好 软件越新越好 能定制越多越好 能折腾越多越厉害但工作很多年之后我越来越看重稳定 可预测 兼容 生态 长期维护 文档因为人的时间和注意力是有限的。如果一天只有八小时我宁愿花六小时研究Kubernetes Kernel Cloud Network Infrastructure而不是修 Desktop 修 Package 修 Driver 修完终于开始工作所以现在我对主力操作系统很高的评价反而是我几乎感觉不到它的存在。开机。Terminal。IDE。VM。Container。SSH。Kubernetes。开始干活。这就够了。十九、所以为什么最终是 Ubuntu现在回头看答案其实已经非常清楚。我选择 Ubuntu并不是因为技术最先进 性能最好 最漂亮 最能定制而是它在我最在意的几个方面取得了一个很好的平衡稳定 生态 软件支持 Server Desktop Container 长期维护 较低的维护成本可能每一项单独拿出来都有其他发行版做得更极致。但对我来说Ubuntu 的综合平衡最好。写在最后如果让我非常简单地概括这些发行版Fedora 适合体验新技术、研究新的 Linux 软件栈。 RHEL 适合真正需要商业支持和企业认证的场景。 Rocky / AlmaLinux 适合希望延续 RHEL Compatible 路线的用户。 Debian 稳定、社区化也是一条非常优秀的路线。 Ubuntu 在 Server、Desktop、生态和长期维护之间取得了很好的平衡。 Arch 非常适合希望深入理解、定制和折腾 Linux 本身的人。它们其实并没有谁战胜谁。只是解决的问题不同。而我用了这么多年 Linux 后越来越清楚自己需要什么一个足够稳定、足够主流、生态足够完整又尽量不要打扰我的 Linux。目前来说Ubuntu 正好处在这个位置。至于 Arch Linux当然也得玩。只不过我准备先放在虚拟机里。而且下一次我真正想研究的也不是Arch 到底有多难安装而是AUR 到底能有多野看看 DEB、RPM、闭源 Linux 软件甚至一些 Windows 软件到底能被 Arch 社区折腾到什么程度。说不定有一天Windows、Linux、macOS、Android、iOS 之间的软件边界真的会越来越模糊。当然那就是另一个故事了。哈哈哈。