Gentoo Linux 2025年回顾与2026年新年快乐！
由于github持续强迫使用 Copilot 处理我们的仓库，Gentoo 目前正考虑并将计划将仓库镜像和拉取请求贡献迁移至 Codeberg。
2026新年快乐！过去数月间，Gentoo社区再度迎来诸多新进展。新开发者加入、二进制包数量增长、GnuPG替代方案支持、WSL版Gentoo、改进的Rust引导程序、更完善的NGINX打包方案……一如既往，我们将在此回顾所有激动人心的动态，来自我们最喜爱的Linux发行版。
数字看Gentoo
当前Gentoo包含 31663个ebuild ，对应 19174个不同软件包 。针对 amd64(x86-64)架构，镜像站点提供 89 GB 二进制软件包 。每周 Gentoo 会为不同处理器架构和系统配置构建 154 个独立的安装阶段 ，其中绝大部分均保持最新状态。
2025年主::gentoo仓库的提交总量 保持高位运行，仅从123942次微降至112927次。外部贡献者的提交量为9396次，涉及377位独立外部作者。
作为潜在开发者入门通道的用户可信模型仓库GURU 活跃度有所下降。2025年提交量为5813次，较2024年的7517次有所下降。GURU贡献者数量从2024年的241人增至2025年的264人。欢迎加入我们，共同打包最新最优秀的软件——这正是成为Gentoo开发者的理想准备！
Gentoo 错误追踪器 bugs.gentoo.org 的活动也略有放缓，2025年共创建20763份错误报告，而2024年为26123份。已解决漏洞数量呈现相同趋势：2025年为22395个，2024年为25946个。当前数据更接近2023年水平——但显然今年修复的漏洞远多于新增！
新晋开发者
2025年我们迎来了 四位新Gentoo开发者 ，按时间顺序排列如下：
- Jay Faulkner (jayf) : Jay 于三月从美国华盛顿加入我们。在Gentoo及开源领域，他深度参与OpenStack项目；同时身为狂热体育爱好者，尤其痴迷冰球与纳斯卡赛车，且是Gentoo的长期拥趸。
- Michael Mair-Keimberger (mm1ke) : Michael 终于在六月加入我们 来自奥地利，此前已累计贡献超过9000次提交。Michael在奥地利一家大型系统集成商担任网络安全工程师，平日喜欢慢跑，周末常去登山。在Gentoo项目中，他主要参与质量控制和代码清理工作。
- 亚历山大·帕克·诺伊维特 (apn-pucky) : 亚历山大，一位物理学博士后，于七月加入我们。身处计算机科学、Linux与高能物理的交叉领域，他已将Gentoo用于代码管理，并视其为卓越的开发环境。除科学物理外，他还热衷于持续集成与RISC-V架构。
- 雅科·克伦 (jkroon) : 雅科于10月注册成为开发者 来自南非。他是一名系统管理员，供职于运营并托管多个Gentoo安装环境的公司，自2003年起便活跃于Gentoo社区！在我们的软件包中，Asterisk正是他关注的领域之一。
重点变更与动态
现在让我们聚焦Gentoo在2025年的重大改进与动态。
全范围计划
告别Github，欢迎Codeberg ： 主要由于持续强迫使用 Copilot 处理我们的仓库，Gentoo 目前正考虑并将计划将仓库镜像和拉取请求贡献迁移至 Codeberg。Codeberg 是一个基于 Forgejo 的平台，由非营利组织维护，位于德国柏林。Gentoo将继续自主托管核心Git仓库、缺陷追踪等基础设施，暂无变更计划。- EAPI 9 ：作为ebuild规范新版的EAPI 9(详见https://projects.gentoo.org/pms/latest/pms.pdf)措辞已最终确定并获批准，Portage支持工作已全部完成。EAPI 9 的新特性包括：用于改进错误处理的 pipestatus、用于打印并执行命令的 edo 函数、更洁净的构建环境，以及为配置目录树声明默认 EAPI 的可能性。
活动参与 ： 在布鲁塞尔举办的FOSDEM 2025大会上，Gentoo再次设立展位，今年与基于Gentoo的Flatcar Container Linux联合参展。现场自然少不了马克杯、贴纸、T恤，还有著名的自编译按钮…… 此外，我们还参加了在圣奥古斯丁举办的FrOSCon 2025大会，并开设了Gentoo安装与配置 以及 编写专属ebuild 工作坊。最后但同样重要的是，工具链团队代表Gentoo参加了在波尔图举办的GNU工具大锅饭2025。
SPI迁移 ：财务架构向Software in the Public Interest (SPI)的迁移正稳步推进，费用支付流程已随迁移进展同步调整。若您正向Gentoo捐款(尤其是定期捐赠者)，请将付款渠道切换至SPI；详情参见我们的捐赠网页。- 在线研讨会 ：我们的德国支持机构 Gentoo e.V.，衷心感谢2025年四场线上研讨会(https://gentoo-ev.org/news/online-workshops-2025/)的演讲者与参与者。这些以德语和英语举办的研讨会涵盖EAPI 9、GnuPG与LibrePGP等多元主题。我们期待2026年举办更多精彩活动。
架构支持
RISC-V可启动QCOW2镜像 ： 与amd64和arm64架构相同，我们现已为RISC-V提供现成的QCOW2格式可启动磁盘映像可从我们的镜像站点下载，包含控制台版和cloud-init启动版。这些磁盘映像采用rv64gc指令集和lp64d ABI规范，可通过标准RISC-V UEFI支持启动。
WSL版Gentoo ： 我们现已基于amd64阶段环境，每周发布适用于Windows子系统Linux环境(WSL)的Gentoo镜像，详情请参阅镜像站点。虽然这些镜像尚未登陆微软应用商店，但我们计划尽快解决此问题。- hppa与sparc架构转为不稳定状态 ：由于相关硬件已难以获取，且这两种架构主要服务于复古计算领域，hppa(PA-RISC)和sparc均已取消稳定版本支持。该架构将继续通过测试版本提供支持。
musl 支持区域设置 ： 基于轻量级musl C库的Gentoo阶段环境现默认集成sys-apps/musl-locales包提供的本地化支持。
软件包
GPG 替代方案 ：鉴于 GnuPG / OpenPGP / LibrePGP 生态系统因标准竞争而不幸分裂，我们现提供替代方案机制以选择系统 GPG 提供者并简化兼容性测试。目前支持： 原始未修改版GnuPG FreePG分支/补丁集(亦被Fedora、Arch等众多Linux发行版采用) Debian、Arch等)使用的FreePG分支/补丁集，以及基于Chameleon的重构版本Sequoia-PGP。实际应用中，不同提供商的实现细节存在差异。虽然 GnuPG 和 FreePG 获得完整支持，但选择 Sequoia-PGP/Chameleon 时仍可能遇到困难。- zlib-ng支持： 我们已初步支持在兼容模式下使用zlib-ng和minizip-ng替代标准zlib库。
全局作业服务器 ： 我们创建了steve，这是全局令牌计数任务管理器的实现方案，并在Portage中引入了实验性的全局任务管理器支持。由此可实现全局控制并发构建任务数量，准确统计并行emerge任务、make任务、ninja任务及其他支持任务管理器协议的客户端。- NGINX重构 ：Gentoo中的NGINX网页服务器及反向代理打包方案已大幅优化，包括将多个第三方模块拆分为独立包。
基于C++的Rust引导程序 ： 我们通过Mutabah的Rust编译器mrustc实现了从C++构建Rust的引导路径，此举既免除了预编译二进制文件的需求，又显著简化了多配置环境的支持。- Ada与D语言引导环境 ： 同样地，gcc 中的 Ada 和 D 支持现已具备简洁的引导路径，只需切换 gcc 的 useflags 并运行 emerge 命令，即可轻松在编译器中启用这些语言。
FlexiBLAS ： Gentoo 已采用新型 FlexiBLAS封装库 作为运行时切换BLAS数值算法库实现的主要方式。该方案同时自动提供程序链接的ABI稳定性，并将不同BLAS变体的特殊处理集中管理。- Python ：Gentoo 默认 Python 版本现已升级至 Python 3.13。此外还提供稳定的 Python 3.14 版本——完全与上游保持同步。
- KDE升级 ：截至2025年底，Gentoo稳定版包含KDE Gear 25.08.3、KDE Frameworks 6.20.0及KDE Plasma 6.5.4。测试版始终追踪上游最新版本(通过KDE覆盖层甚至可直接从Git源安装)。
硬件与软件基础设施
- 新增构建服务器 ：已在德国Hetzner托管第二台专用构建服务器，用于加速生成安装阶段文件、iso与qcow2镜像及二进制包。
- 文档建设 ：wiki.gentoo.org 的文档工作持续推进。《Gentoo 手册》进行了若干实用更新，众多活跃志愿者为文档体系贡献了大量改进与新增内容。当前维基包含9,647个页面，项目启动以来累计编辑次数达766,731次。欢迎通过贡献文档助力Gentoo！
Gentoo基金会财务状况
收入 ：Gentoo基金会在2025财年(截至2025年6月30日)共计收入12,066美元； 其中主要部分(超过80%)来自社区个人的现金捐赠。在SPI方面，我们于2025财年同期收到8,471美元；同样全部来自个人小额现金捐赠。- 支出 ：2025年度支出明细如下：项目服务(如托管费用)8,332美元，管理及行政(会计)1,724美元，筹款活动905美元，非运营支出(折旧费用)10,075美元。
- 余额 ：截至2025年7月1日(即2026财年会计起始日)，银行账户余额为104,831美元。Gentoo基金会2025财年财务报表已发布于Gentoo维基。
- 向SPI过渡 ：基金会敦促捐赠者确保其持续捐款流向SPI——截至年底仍有40余位捐赠者未响应转移定期捐款的请求。随着持续收入的增加，相关支出将逐步转移至SPI架构。
衷心感谢！
值此岁末，我们谨向所有Gentoo开发者及贡献者致以诚挚谢意，感谢你们为Gentoo付出的不懈努力。 若您有意参与，欢迎加入我们共同完善Gentoo！作为志愿者项目，Gentoo的存在离不开社区的支持。
本文由 TecHug 分享，英文原文及文中图片来自 2025 in retrospect & happy new year 2026!。
共有{185}条精彩评论
Gentoo 才是最棒的！一旦你掌握了创建可启动系统的诀窍，并习惯突破常规的操作方式，它就像 Linux from Scratch 那样自由，却无需手动构建所有组件。我仅用podman(构建根文件系统)和qemu(测试启动/写入根文件系统及异构架构模拟)就实现了系统镜像自动化构建，每周通过CI为所有硬件生成新镜像并用rsync同步更新。这大概是我建过最酷的东西——现在我实际上是在从源代码构建自己的Linux发行版，所有配置都定义在Containerfiles里！我对Gentoo团队怀有深厚敬意，正是他们让这个项目成为可能。得知他们运作资源如此有限时震惊不已，我已决定设置定期捐款。
Gentoo如同LFS，但为你清晰映射了软件包间的依赖关系( USE标志万岁！)。或者说，它更像是拥有更多可调参数的Arch系统。
过去十五年间，我身边至少有一台物理机或虚拟机始终运行着Gentoo。每次与它互动都充满乐趣。
我认为这是绝佳的学习机会，但使用Gentoo十余年后，如今我更倾向于Arch。若想深入了解Linux及其生态系统，不妨尝试几个月或几年。
不过我尚未尝试过官方仓库的二进制包版本。或许这样能更省时地保持系统更新。
我一直愉快且成功地使用官方二进制包，运行效果极佳。偶尔源代码包的二进制版本会稍晚出现在仓库中，但仅此而已。这就像在运行Arch系统，但搭配Portage管理器<3！当然偶尔仍需编译——毕竟你的使用标志可能与二进制包不完全匹配
你是否在某处记录过这个方案？我很想了解更多
没有，这是我首次公开提及。欢迎提问，若反响热烈，或许这能成为我撰写首篇博客的契机。
我也鼓励你写写这个方案。听起来既有趣又别出心裁。
我过去常折腾系统，但随着年龄增长和时间有限，已放弃许多折腾行为，现在更注重“高效完成任务”。虽然我仍会调整系统并优化工作流程，但已不再像从前那样进行内核重新编译之类的深度优化了，不知你是否明白我的意思。如今我靠“折腾”客户系统谋生，但若可能，我尽量避免采用非常规方案。
我确实意识到系统描述至少在文档化层面颇具价值。我一直在关注NixOS却迟迟未下定决心尝试。容器文件似乎是更简便的方案，但它们(至少Docker如此)的设计理念更侧重描述应用环境而非完整系统环境。因此你的方法颇具吸引力。
> 容器文件看似更简便，但它们(至少Docker如此)的设计理念更侧重描述应用环境而非完整系统环境。
确实如此！我最初只是想在主机上运行服务时拥有一个基础容器镜像，要求：a) 能生成完整的源代码列表，b) 对物料清单(BoM)拥有完全可视性。后来发现直接使用FROM scratch并拉取Gentoo的stage3即可实现。这恰好也是新建Gentoo chroot环境时的第一步操作。我意识到后续所有安装步骤(软件安装、内核编译、用户配置等)同样能在容器中执行——说到底，容器不就是“可移植的可执行chroot环境”吗？我最初的构建系统版本，就是将容器中的/目录直接复制到手动格式化的挂载磁盘。向磁盘写入其实是整个方案中最违背直觉的部分——毕竟没人能提供不依赖内核的完美解决方案。我曾尝试在特权容器中直接格式化挂载设备，但现在改为在非特权容器中启动qemu虚拟机，通过initramfs完成操作(反正这些我也都是手动构建的)。在迭代过程中我发现，Containerfiles带来的所有优势(可移植性、可重复性、缓存机制、最小化主机运行时等)自然延伸到了操作系统构建项目中。由于我本就倾向于以容器形式部署服务，这种方案相较于到处使用独立工具和范式，实现了高度的复用性。
我一定会整理成文发布到Hacker News，但要把整个项目浓缩成那段简介实在令人头疼。
感谢分享！非常期待进一步了解这个项目。
我也非常想读那篇博客文章！
我也是！很有意思 🙂
虽然和楼主提的不一样，但我正在开发一个基于容器镜像根文件系统的嵌入式Linux构建系统：https://makrocosm.github.io/makrocosm/
示例项目采用Alpine基础容器镜像，但我正在开发的另一个项目使用Debian基础容器。
老实说，对资深Gentoo用户来说这不过是寻常操作？Gentoo维基上有大量相关文档。找不到的话去IRC或论坛问问。“Catalyst”是内部构建系统生成镜像的方法，例如https://wiki.gentoo.org/wiki/Catalyst。
2004年使用Gentoo一段时间后，我意识到实在不想为每个软件都等待编译过程。
对于不想等待编译的用户——https://www.calculate-linux.org/
这仍是100%纯正的Gentoo(实际上如今连原生Gentoo都提供预编译二进制文件)，因此在极少数情况下，若二进制文件尚未按您所需的use/config配置编译，您仍可自行编译。
这正是我在CI中构建系统镜像的主要原因；最耗时的构建(例如树莓派板卡的aarch64架构qemu用户模式仿真)可能需要数天，因此我设定每周更新窗口期，通过rsync同步变更。测试流程中甚至会用qemu引导镜像进行验证。未来或许会尝试像Gentoo那样构建预编译二进制文件并托管，不过目前我刻意避免使用这类资源，坚持从源代码构建所有组件。
对我而言，这里最被低估的收获是RISC-V架构的支持现状。
当其他发行版还在为新指令集架构搭建软件仓库而苦苦挣扎，等待构建集群跟进时，Gentoo基于源代码的特性使其天生具备架构无关性。我赞赏RISC-V团队已实现与amd64架构的@system集兼容性。这证明元发行版模型是应对2025年后硬件多样性爆炸式增长的唯一可扩展方案。若您正在构建嵌入式平台或定制芯片，Gentoo无疑是顶级选择——只需交叉编译stage1，Portage将自动处理后续工作。
虽然我向来偏好基于源代码的个性化发行版，但这也正是我2004年初转向Gentoo的重要原因(当时是为amd64平台，而非你举例的Risc-V/其他嵌入式系统)。虽然奔腾IV的超长流水线和编译器参数敏感性(以及“最快企鹅”的称号本身)强化了“专为本系统编译”的提速认知，但这种模式更契合所有追求定制化配置的黑客思维。
这真是绝妙的史诗级对照。amd64初期的确堪称Gentoo的杀手级应用时刻。当二进制发行版还在为仓库拆分和/lib64/lib标准的物流噩梦挣扎时，Gentoo用户只需修改CHOST环境变量，完成引导即可运行原生64位系统。你对这种心理机制的洞察也精准到位。所谓“速度营销”始终是种转移视线的噱头。真正酷炫的是当你说“我的邮件客户端不需要LDAP支持”时，包管理器能真正尊重这个选择——它尊重用户智慧而非将其抽象化。
既然你从2004年就参与其中，我很想听听你的看法。相比GCC 3.x时代，如今的维护负担有何不同？借助现代binhost回退机制和portage的改进，感觉现在解决重建循环的问题比从前省时了？但不知老用户是否同感。
> 能明确声明“我的邮件客户端不需要LDAP支持”，而包管理器真的会遵守这个要求，这很酷。
我接触Gentoo的时间点恰与楼主开始使用它相近，也特别欣赏这个特性。多数包管理器在这方面表现欠佳，配置时默认往往是“全功能启用”模式。比如在Debian安装ffmpeg时，会牵扯进超过250个(！！)依赖包。即便你只想用它转换一次.mp4容器到.mkv格式。
十五年前用Gentoo时我也欣赏这个理念，但很快意识到它其实不太合理。
你正在权衡取舍：要么拥有一个能应对所有挑战的系统，要么与所有人使用相同的二进制文件——而这种选择几乎毫无意义。虽然理论上可被利用的攻击面更小，但你必须信任Gentoo的补丁在移除漏洞的同时不会引入新隐患，也不会意外关闭强化功能。虽然软件包体积略小，但我实在难以想象2026年还有什么场景会因此产生实质影响。
对我而言，最糟糕的是其极差的调试体验和无法与源项目正常交互的缺陷，这根本不是明智之选。相比之下，Arch坚持只发布纯净原生软件的承诺才更具合理性。
> 既然你从2004年就参与其中，我很想听听你的看法。相比GCC 3.x时代，你觉得现在的维护负担如何？有了现代binhost回退机制和Portage的改进，感觉我们现在花在解决重建循环上的时间比那时少了？但不知老用户是否也有同感。
我也是从那个时代就参与的成员 🙂
总体而言，稳定版已变得_真正_稳定，而不稳定版也基本可正常使用，很少出现重大故障。如今我的维护负担比十年前轻得多——基本只需每月执行一次emerge -uDN @world --quiet --keep-going，遇到问题再修复。虽然偶尔会遇到包安装失败，但我的系统基于llvm+libcxx架构且会测试包，因此遇到的问题可能比普通GCC用户更多。
对我而言，如今重点已不再是速度，而是丰富的定制选项和本地构建几乎所有所需软件的能力。尤其欣赏ebuild本质上是bash脚本的特性——当需要进一步定制或复现某个功能时，我能直接将包管理器中的命令复制粘贴到本地文件夹。
该项目已成功实现大量默认优化和最佳实践，总体而言系统软件包的代码库已臻成熟，如今再遇到内部编译器错误、奇怪的依赖问题或全局重建等情况反而显得异常。从我的角度看，编译器逐步强制执行更现代严格的C/C++标准，同时Github、CI工作流、更完善的测试工具等技术的出现也起到了巨大推动作用。
如今我每年仅执行一次emerge -e1 @world来排查潜伏问题(例如clang 19与clang 21编译差异)，但通常已无需如此操作。除非安装新软件包需要启用新USE选项，否则配置基本保持不变。
> 因此我在 GCC 环境下遇到的问题可能比普通用户多。
多年未遇构建失败，甚至在 ~amd64 架构上也接受过几次(使用 gcc)。
我在这里回复只是因为这里是“更合适的附件位置”。
总之，回答祖辈的问题：19年来我基本没遇到过重建循环… 只需每日或每周执行一次emerge -uU world。我的基础系统运行至今从未更换——让我查查：
qlop -tvm|h1
2007-01-18T19:50:33 >>> x11-base/xorg-server-1.1.1-r4: 9m23s
这19年间我从未从零重建过整个系统。(升级硬件时我只是将根文件系统rsync到新机器，再逐步重建——正如这里许多人提到的，对我而言重点不在于“全面性能优化”或可复现系统，而是“更多定制化+特定功能优化”。) 不过从单体X11升级到分层X11倒是“很有趣”。/s
我确实广泛使用各种包屏蔽策略/单包屏蔽/全局屏蔽。对于与上游意见相左的组件，我拥有自定义的Portage/本地覆盖层。甚至还有自动化系统来“修补”这些分歧。例如我自主掌控LLVM组件的升级节奏，主要使用gcc并同样掌控其更新。基本上所有耗时的独立构建项目都如此。
若数十年间出现可能引发海量重编译的情况，我通常会等待数日或数周再想办法解决。若新依赖引入大量垃圾，我通常会设法阻断它。
从 gcc 3.3 到 3.4 的升级是个大工程，若未遵循升级流程可能引发问题，且许多 C++ 代码库需要微调。此后这类问题已大幅减少。
此外，Gentoo 对使用标志依赖关系的管控已大幅严格化，系统还会检测二进制文件是否依赖旧版库文件，并在更新包时保留旧版库，从而彻底杜绝“应用依赖旧版 libstdc++”的情况。待所有依赖关系解除后，系统会自动移除旧版库。
我从04年前就开始持续使用Gentoo系统，一切基本都能正常运行。我敢打赌，比起使用OSX、Windows、Debian等系统的用户，我花在“管理操作系统”上的时间少得多。当然，我的CPU需要编译大量代码，但也就仅此而已。
没错，“–omg-optimize”从来不是真正卖点，真正核心在于useflags提供的完全控制权。几乎没有任何系统能与之匹敌，这正是Gentoo如此出色的原因。
说得对。
我认为“最快”只是“允许用户将系统调校至极致”的附带效果——启用march=native指令、舍弃冗余组件、将模块整合进内核、用更高效(但功能受限)的组件替换旧件等等。
公平地说，创建纯64位二进制发行版并非难事，当时也存在若干此类版本。真正的难题在于如何实现32/64位混合环境，这正是围绕/lib目录展开争论的根源。在纯64位发行版中，运行32位二进制文件的唯一方法是创建包含完整32位安装环境的chroot。直到后来才达成更优解决方案。那是个Flash和Acrobat Reader的时代——这些专有软件均仅支持32位，因此人们格外重视32位支持。
嵌入式系统通常采用Yocto、Buildroot之类的工具链，从未见过有人使用Gentoo。
我可以证实Yocto完全基于源代码构建，并拥有海量BSP(通常由厂商提供)。
所有发行版都基于源代码并通过源代码引导启动。它们默认提供二进制包(同时提供源代码包)，而Gentoo默认提供源代码包(但仍有二进制包)。这方面Gentoo毫无优势可言。你的说法甚至不合逻辑。
其他发行版不支持Risc-V，是因为几乎没人愿意为此投入精力——毕竟相关硬件基础几乎不存在。
Fedora和Debian早已在稳定版本中提供RISC-V架构版本。我认为这并非技术难题。
Arch确实存在此问题，但该发行版连amd64_v3/v4构建都困难重重，更不用说arm64了。
> Gentoo基金会2025财年(截至2025/06/30)收入为12,066美元，其中80%以上来自社区个人现金捐赠。SPI方面同期收入8,471美元，同样全部来自小额个人现金捐赠。
如此庞大且有影响力的项目竟能以如此微薄资金运转，实在令人惊叹。当然，许多人正为项目贡献着宝贵的人力，但相较于商业软件的开发成本，Gentoo的投资回报率堪称惊人。
某种程度上，这正是我们需要红帽、SUSE等公司存在的原因。即便你因各种原因不喜欢它们的特定发行版，这些公司至少找到了盈利方式，并将所得反哺开源生态——多数企业都做不到这点。
反哺何处？从这里微薄的数字来看，肯定不是给Gentoo。
红帽为广泛的Linux软件包、驱动程序乃至内核本身[1]都做出了贡献。
虚拟化领域便是例证：virtio堆栈由红帽维护(据我所知)。这正是推动虚拟化“民主化”的核心驱动力，让普通用户和小型企业无需向VMware“卖肾”就能获得高性能虚拟化服务。
此外，红帽参与贡献或维护了OpenShift和OpenStack的所有组件(其中就包括virtio！)。
[1] https://lwn.net/Articles/915435/
为何要期待红帽为Gentoo贡献代码？发行版本应由其用户资助。除非存在衍生关系，否则哪个发行版会直接为另一个发行版贡献代码？
红帽主要向内核及各类开源项目贡献代码，资金来源于企业客户的合同。付费客户提出需求，红帽便予以实现。随后我们其他人得以免费获取代码，这正是其精妙之处。
观察顶级贡献者名单，红帽(与其他企业巨头)始终位居前列。
或许应从软件包维护等非金钱形式，为整个生态系统作出贡献。
正如其他评论所言，红帽(及SUSE)对整个Linux社区贡献卓著。它们回馈的远超GPL许可要求——几乎所有付费“企业版”产品都提供完全免费的开源版本。
例如：
- Red Hat Identity Management -> FreeIPA (i.e. Active Directory for Linux)
- Red Hat Satellite -> The Foreman + Katello
- Ansible ... Ansible.
- Red Hat OpenShift -> OKD
- And more I'm not going to list.
多年前尝试使用Okd时简直一团糟。尽管安装流程存在显著差异，其文档却只是对OpenShift文档的逐字复制粘贴。它极力推荐使用OLM，但目录中的上游操作工具(如基于Istio的Red Hat服务网格上游项目Maestra)往往严重滞后，甚至与当前Okd版本完全不兼容。我在GitHub上提交了问题，红帽员工回复称他们当时对现状也不满意，但建议持续反馈以保持关注度。后来我转用Talos实现更纯粹的K8s部署，这才成功安装了服务网格。
这与运行Keycloak时的体验截然不同——其上游文档完善，或如FreeIPA那样与IDM完全兼容，直接使用红帽文档即可。这两款卓越软件实属我们的幸运。
红帽为开源生态做出了巨大贡献，是Linux内核最大的贡献者之一(或许首屈一指)。
https://insights.linuxfoundation.org/project/korg/contributo…
至少根据Linux基金会(LF)的统计标准，AMD的贡献量仅次于英特尔。不过驱动程序代码相较于其他领域往往占据更大篇幅。看看这里堆积如山的AMD模板垃圾：https://github.com/torvalds/linux/tree/master/drivers/gpu/dr…
英特尔长期是重要贡献者——据我所知主要贡献驱动程序相关代码。(英特尔的软件工作量远超大众认知。)三星也曾位居贡献榜前列。我研究生时期的室友(现已基本退休但仍参与开发)曾跻身个人贡献榜前十——主要贡献网络相关代码。
他们为GNOME、libvirt、firewalld等Linux系统贡献良多，即便作为Gentoo用户，我也在受益于这些成果。
红帽雇佣了大量GCC核心开发者。
确实如此，但以他们的Grub源RPM为例，某些看似原创的补丁实则源自Debian。
当年实体商店陈列着实体机箱时，SuSE曾是入门Linux的绝佳选择。
我桌面电脑上安装的OpenSUSE Tumbleweed已运行近两年仍持续更新。这是款优秀却略显低调的发行版。
SuSE/openSuSE 创新了许多其他发行版争相效仿的功能，例如 CachyOS 和 omarchy 这些 Arch 衍生版就认为 openSuSE 风格的 btrfs 快照机制相当出色。
这是个坚如磐石的发行版，若我需要企业级支持，SLES绝对会成为我的重点考虑对象。
其技术布局之广阔堪称无出其右：既有滚动更新的Tumbleweed，也有独树一帜的延迟滚动更新Slowroll，还有点发布版本Leap， Tumbleweed和Leap还提供不可变版本(分别是MicroOS和Leap Micro)。所有版本均支持多种桌面环境，或可构建为专注服务器的极简环境——其占用空间之小令人惊叹，且未做任何不合理的取舍。若将所有选项组合起来，其组合可能性堪称庞杂的组合数学难题，但他们确实很好地支撑了这一切。
在图形化系统管理工具领域，YaST堪称最强大的存在之一。鉴于其二十年的历史使其界面显得过时，官方正着力开发合适的替代方案。今日我试用了全新的Agama安装程序，对其发展方向深感满意。
……所以不太明白你所谓“当年”的具体指涉。我也记得当年去实体店购买Linux盒装版的岁月，当时选择只有红帽和SuSE。此后它们的市场关注度确实因众多新选项的涌现而下降，但我认为它们始终默默保持着相当出色的表现，至今仍深受关注者的喜爱。
如今SUSE高层聚集了大量前红帽员工。其CEO曾长期执掌亚太区业务，并短暂负责过北美商业销售部门。
SUSE在欧洲一直相当强势，但在北美从未占据显著地位——除了IBM大型机领域，而红帽公司正逐步蚕食该市场份额。(有一段时间，SUSE支持了红帽未提供的某些大型机功能，这可能部分源于红帽工程团队领导层至少私下里对在大型机上运行Linux的理念持否定态度。)
我发现openSUSE MicroOS是绝佳的家庭实验室服务器操作系统。
苏塞的缓慢转型对我来说是新消息，感谢分享。
红帽力推灾难性的Wayland技术，让Linux桌面发展倒退数十年。
它堪称Linux世界的微软。
为何Wayland是灾难？绝大多数Linux社区成员都强烈支持它。
恕我直言，这完全脱离现实。Wayland每天都在成功运行。你个人不喜欢某事物，并不代表它本质上就是糟糕的。
[已删除]
没关系！谁在乎呢！继续用吧！
红帽确实为那些可怕的家伙烧了不少钱。虽然我们因此获得了优质软件，但这种融资模式不值得歌颂。当然，美国企业不生产开源软件才是地球上最恶劣的力量。
实在难以推测这里究竟在搞什么名堂。
既然要实现生产社会化，就该做彻底点。
> 红帽确实为服务那些令人发指的恶棍烧了不少钱。
红帽还有个恶习：强行将决策强加给其他发行版，例如：
– systemd
– pulseaudio(记得这主要是Fedora的决策)
– Wayland
– Pipewire(公平地说，我试用时它倒不算太糟)
强行决策？这简直滑稽。
我猜Debian、SUSE、Canonical之类收到红帽的邮件就乖乖照办。我们最好赶紧换系统，可不想被::查看笔记::竞争对手指责。
systemd及其同类项目总爱通过拙劣实现替代方案来吞并其他项目，再诱使官方项目放弃。
Pipewire太棒了。Wayland半成品，在老系统上简直灾难。SystemD嘛…openrc就够用了，关机时从不崩溃。
不知道他们从哪冒出来的，我尽量避开名单里所有东西。说实话音频系统本来就是个烂摊子。
呃，pulseaudio已大幅改进，而pipewire现在“开箱即用”(至少对我如此)。连蓝牙音频多数时候都能直接工作。
或许吧。我的评论背景是：90年代末我在一家Windows专业音频公司工作。当时我们用多张声卡，支持多种输入输出接口、不同采样率、声道数和位深度…API设计极其简单，我一小时就搞懂了。
快进到去年，我在Linux系统开发OpenGL项目时想“加个音频功能吧”——结果被层层嵌套的API、混乱的子系统和糟糕的文档搞得晕头转向。对我而言本该比视频简单得多的音频，突然变得复杂得离谱。从用户视角看，去年我还想用树莓派做蓝牙音箱，结果也是糟糕透顶的体验。
所以，我不知道…或许该试试Pipewire？当年折腾完ALSA和PulseAudio后我就放弃了，遇到第一个问题就直接放弃了。
我不确定红帽是否算得上积极力量。他们似乎正致力于让Linux桌面变得让普通用户难以理解——考虑到他们的核心收入依赖于用户付费修复问题而非自行解决，这种做法倒也合乎逻辑。
你竟不认为他们是积极力量？
尽管Rocky、Alma、Oracle企业版Linux等发行版的存在，正是源于红帽的投入与付出。
那些公司又做了什么来解决你所谓的红帽问题？毫无作为。因为他们只贪图利润——尤其当他们只需重新打包他人成果贴上自家标签时。
究竟哪里难以理解？他们对Linux桌面做了什么导致用户无法自行解决问题？Rocky和Alma最核心的卖点不正是“无需红帽支持即可轻松部署”吗？
补充说明：Rocky和Alma源自CentOS
当然——但CentOS的上游不是RHEL吗？
可以说红帽根本不在乎桌面系统——至少在内部系统之外。虽然Fedora团队多少有些关注，但这绝非优先事项，从商业角度看完全无关紧要。
你能说出哪家公司真正关心Linux桌面吗？这些年来，我确信红帽为各种桌面项目做出了巨大贡献，实在想不出还有谁的贡献能超过它。
红帽确实曾尝试推出过企业级桌面发行版，并提供支持。正如我所写，Fedora——红帽以多种方式为其提供支持以满足不同需求——几乎就是我的默认Linux发行版。
所以这并非批评。没错，红帽员工确实会参与与桌面相关的项目，即使这通常并非他们日常工作的核心。而且，其他公司几乎肯定没有做得更多。
我脑海中立刻浮现System76及其硬件和Pop!_OS。
Canonical。至少他们曾经如此，尽管我不太欣赏近十年的Canonical。
毋庸置疑，Ubuntu曾因多重因素对潜在Linux桌面用户更友好。(虽可探讨其争议性决策/方向但在此不展开。)尽管Canonical如今存在感减弱，相信仍有大量用户在使用Ubuntu。我认为Canonical本质是马克·沙特尔沃思的激情项目，如今只是低调了许多。
> 你能举出真正重视Linux桌面的公司吗？
某种程度上Valve算一个。他们必须重视，毕竟Steam Deck的桌面体验完全依赖于“Linux桌面”的流畅性。
Fedora可能是开箱即用的最佳桌面体验。红帽公司成就斐然，即便被IBM收购后有些变味。
我认为systemd在调度和运行服务方面表现良好，但它以我看来次优的方式全面接管其他功能的做法令人恼火。
问题不仅在于systemd。必须审视全局——比如GNOME的设计理念，或是GTK如今基本沦为GNOME专属工具包的现状(若在reddit指出这点，ebassi怕是要暴跳如雷)。他们正逐步掌控整个生态系统，将其单一化以强化自身控制。这也解释了为何我认为“Wayland才是未来”的论调，部分意图在于进一步扩张控制权；当前形势已截然不同——xorg-server确实主要由Alanc等英雄人物进行维护，但Wayland在我看来本质上是IBM与红帽主导的项目。果不其然，GNOME率先强制采用Wayland并抛弃Xorg，正如它当年率先将systemd强行塞进生态系统那样。
老一套的半阴谋论废话。GNOME对那些习惯Windows 95界面模式的鼠标党确实难以适应。至于Wayland？当真？还在对着那片云大喊大叫吗？
等Wayland能像X那样稳定运行时，人们才会停止抱怨——这恐怕还得十年。等着看你那套“在我这儿运行正常！”的回应。
你说“X在我这儿运行正常”很合理，但所有持异议者都是错的。
我不明白你的意思。人们经常抱怨Wayland存在诸多问题，却总有人用“它在我这儿完美运行！”这种无聊的回复搪塞，仿佛它对某些人完美运行就意味着对所有人完美运行。
我的观点是同样的情况也适用于X。它缺少Wayland具备的功能，所以X也只适合部分人。
如今即使搭配Nvidia显卡，Wayland也比X11流畅得多。用X11时我偶尔会遇到撕裂问题或其他怪异行为，而Wayland在我的游戏电脑上彻底解决了这些问题。
若使用原生支持systemd并提供轻量抽象层的发行版，体验会更佳。NixOS便是典型代表。
NixOS绝非轻量抽象(身为用户我必须指出)。
坦白说，NixOS的便利性很大程度上依赖于systemd及其他必须整合的组件——这些才是构建可用(即兼容)Linux桌面的基础。与其如此，不如采用功能强大的编程语言、运行时环境及软件包集合，通过单一声明式接口实现统一管理。
这类问题的根源在于系统设计中“整合现成工具包”的做法，当然这种方式也有其优点。不过红帽似乎正通过资金支持，将几个平庸工具吹捧得异常庞大，从而加剧了这种弊端。
这怎么不是轻量级抽象？如果你熟悉systemd，即使对Nix一无所知，也能轻松理解下面代码片段的作用。
systemd.services.rclone-photos-sync = {
serviceConfig.Type = "oneshot";
path = [ pkgs.rclone ];
script = ''
rclone
--config ${config.sops.secrets."rclone.conf".path}
--bwlimit 20M --transfers 16
sync /mnt/photos/originals/ photos:
'';
unitConfig = {
RequiresMountsFor = "/mnt/photos";
};
};
systemd.timers.rclone-photos-sync = {
timerConfig = {
# Every 2 hours.
OnCalendar = "00/2:00:00";
# 5 minute jitter.
RandomizedDelaySec = "5m";
# Last run is persisted across reboots.
Persistent = true;
Unit = "rclone-photos-sync.service";
};
partOf = [ "rclone-photos-sync.service" ];
wantedBy = [ "timers.target" ];
};
在我看来，用Nix定义systemd服务比到处复制文件和创建符号链接要好得多 🙂
NixOS的价值体现在第6行：
--config ${config.sops.secrets.“rclone.conf”.path}
NixOS让你构建所需的抽象层，并能与他人提供的抽象层混合使用。这一行代码完美诠释了这个理念——因为sops目前尚未成为NixOS的组成部分。
密钥管理功能未来可能会集成到NixOS中，但在此之前，你可以通过使用https://github.com/Mic92/sops-nix或https://github.com/ryantm/agenix来实现管理功能。(https://github.com/Mic92/sops-nix) 或 https://github.com/ryantm/agenix 实现对敏感文件内容的管理。
其他包管理器同样提供对软件包的抽象处理，其系统d配置文件在安装后脚本中也可能采用类似抽象方式。但加密的rclone.conf文件仍会以静态路径形式存在于/etc目录下。
虽然NixOS将安装后脚本逻辑移至安装前执行，但这个细微差别赋予了额外能力：既能混合使用安装后脚本，又能在系统变更前确保配置一致性。
哈，我今天刚写了类似方案，用于定期将NAS备份推送到另一台服务器。
我同意 systemd 接口相当简单(只需将 Nix 表达式转换为配置文件)。但 NixOS 是个庞然大物：它彻底改变了每个软件包的构建方式，引入函数式编程语言和文件系统标准来整合所有组件，随后用这种新语言重新定义几乎所有软件包，还添加了海量额外工具和基础设施。
我指的是在NixOS上具体操作systemd。没错，Nix生态确实不易上手，但一旦领悟精髓就再也回不去了。
“不易学习”这个说法有点转移视线。更关键的是，当你真正掌握它后，需要在脑中处理的信息量实在不成比例地庞大。
操作系统本质上是一套实现其他功能的底层工具集。经典Unix“更差即更好”的设计精髓，正是提供恰到好处的工具让你专注完成任务：编写C程序采集模拟数据，通过管道输出至awk或gnuplot进行切片处理，再用脚本自动化部分流程。
现代工具虽能实现更多功能，有时也更优雅严谨，但你将失去工具群通过统一规范和接口协作时那种野蛮的简单性。取而代之的是各自为政的大型系统，各自采用专有规范且互操作性差。比如Systemd和红帽系的其他产物，带着它们自定义的格式和糟糕的命令行界面。每种编程语言都配有专属的n个包管理器。这些工具固然实用，却被包裹在层层重复发明的基础设施与规范之中。
反观资金匮乏也有其优势，比如无需支付高薪给CEO、经理、营销人员，也避免了分散精力的副业项目。
这虽是两千万美元级别的难题，但若能拨出几十万资金支付人员和基础设施成本，许多项目本可做得更好。
然而现阶段社会结构不容许如此——毕竟股票回购和高管加薪被视为更重要的任务。
没错，尤其当某个CSS库年收入达百万美元时。看来他们根本没有动力改善资金状况。
这正是我想评论的。为何不增加投入？虽然不清楚具体用途，但毕竟是Gentoo啊！我以为核心开发者至少能获得些报酬？
什么资金？听起来他们根本没有多余预算？
10.4万美元余额
若能更精确估算Gentoo的实际维护成本会很有意思。假设100名核心开发者每周投入10小时，380名外部贡献者每周投入2小时；这相当于40多个全职员工，按每人15万美元年薪计算，年成本达600万美元。
问题在于Gentoo在业界并不热门。若能获得几家资金雄厚的科技公司青睐，每家在会议赞助中投入1万美元左右便不成问题。
ChromeOS以Gentoo为基础系统。但这似乎并未为其争取到谷歌的资金支持。
…如今Gentoo是否仍具规模与影响力？据我所知，它当前的文化地位已沦为笑柄，但欢迎指正。
Gentoo的Portage构建系统(至少曾经？)是谷歌ChromeOS的核心组件
Gentoo还支撑着索尼PlayStation云游戏服务的后端基础设施
据传闻它曾运行过纳斯达克交易所系统
没错。Gaikai。
PSN运行Gentoo的可能性极低。他们使用的是AWS。
不清楚索尼是否使用Gentoo，但AWS上绝对能运行Gentoo
不是PSN。是索尼的云游戏服务。他们会将整台PlayStation主机流式传输给你
楼主的说法符合我的认知；部分组件曾基于Gentoo开发。
Gentoo常在识别并解决不同软件项目间的集成问题方面处于前沿地位，尤其在编译器技术领域(例如修复软件包使其能正确使用LTO、LLVM或GCC构建)，以及其他后台细节优化方面——这些改进虽不总被终端用户察觉，却能显著提升系统整体性能。
ChromeOS 基于 Gentoo 构建。
没错，Gentoo 类似 NixOS，属于元发行版。
作为 ChromeOS 的基础系统，其影响力极为深远。
ChromeOS 在多国市场份额超过 5%，部分地区甚至达到两位数。
同样好奇2026年Gentoo的影响力会如何发展。
若不浪费在DEI项目上，少量资金也能发挥巨大作用。
感谢分享！作为Gentoo开发者的第一年非常愉快。在摸索过程中，大家都对我友善且乐于助人。
我想特别强调：Gentoo的开发者入职体系堪称卓越。从普通社区活跃成员起步，你需要说服现有开发者担任导师，并完成开卷测试(https://projects.gentoo.org/comrel/recruiters/quizzes/ebuild…)，该试卷将在后续会议中评分/批改，相当于“工作面试”环节。我希望更多开源项目(包括我自己的项目)能建立如此完善、直观的提交权限获取流程。我非常欣赏这种测验机制，它有效弥补了我的知识短板。
考虑到Gentoo Portage是ChromeOS的核心支撑架构，这个数字实在微不足道。
以及纳斯达克[0]
[0] https://www.pcworld.com/article/481872/how_linux_mastered_wa…
典型的企业开源吸血行为
2025年我转用NixOS并可能长期使用。此前用了近20年Gentoo，它是我心中的发行版。
部分笔记本(其中不少已显老态)更新时资源消耗过高。仅以GHC为例，在某些老旧笔记本上编译常需12小时以上。
我曾尝试在NixOS上列出可用软件包，结果nix-env就占用了6GB以上内存。所有人都劝我别用nix-env——除了NixOS官方手册。试图理解NixOS环境简直是掉进深不见底的兔子洞。
当年尝试Nix时，正是其文档体系让我望而却步。最终我转向了GNU Guix，至今已使用五年。我发现该系统的文档体验更佳(信息页设计出色！)，而数十年积累的Scheme文档也让语言学习更轻松。
赞同！我曾非常喜欢Nix，但觉得语言和部分工具难以捉摸。通过(非)Guix我获得了Nix的所有优点，却以更易理解的形式呈现。若非Guix如此出色，我早该转投Gentoo或Arch了。
确实，它处于一种奇怪的状态：官方仍固守旧式通道/配置文件，非官方却已转向片段化。nix-env过高的内存占用(理论上可改进但需深度设计变更)正是促使我转向片段化的主因。
使用官方二进制包难道不够吗？
官方二进制包直到2023年末才添加。
真心希望尽快回归Gentoo。它是我用过最稳定且最友好的黑客发行版，向所有贡献者致敬！
我使用Gentoo十年(2005-2015)，体验非常愉快！虽然频繁更新常导致系统崩溃需要手动修复，因此“稳定”并非我对它的评价。但它的灵活性无可比拟！系统各方面的配置选项触手可及，这种体验在我后来尝试的任何系统中都未曾再现。若有更多调试时间，我仍会继续使用它。如今我转用NixOS，主要是为了在所有设备上保持统一配置。
Gentoo真正需要的，是类似Fedora Silverblue采用的ostree或ZFS/btrfs根分区快照这类官方不可变机制。如此既能保留发行版的实验精神，又能通过简易机制回滚至已知稳定版本。
哈，我也是！NixOS对我来说简直完美，我超爱它的声明式特性。但Portage绝对是我用过最棒的传统包管理器，简直惊艳。
我觉得Gentoo非常稳定，但必须善用revdep-rebuild且清楚自己在做什么(意思是：很容易自掘坟墓)。
我的游戏主机用Gentoo系统已有两三年，从未因更新导致系统崩溃。
不过得说我的valgrind因march native功能失效了。:)
若有人能协助添加AVX512(及其他CPU特性)支持将不胜感激。不过这确实是个大工程。
自2004年起所有设备都用Gentoo。最初是通过玩他们的《虚幻竞技场》演示ISO版让我彻底折服。
真正改变游戏规则的是将NAS作为所有机器的构建主机。它拥有足够的内存和核心支持32线程编译。但若在老旧的Thinkpad X13或单板机上直接从stage3进行完整安装，这些可怜的机器会直接烧毁，根本无法长期维护。
我为不同微架构配置了systemd-nspawn容器，通过NFS将/var/cache/binpkgs和/etc/portage目录挂载到目标机器。如今Thinkpad仅需约一小时就能完成空树emerge，且跳过依赖包可减少约150个软件包。
尽管专注于OpenRC，但在所有尝试过的发行版中，Gentoo搭配systemd的体验最为顺畅。
我对此深感兴趣。您是否仍在Thinkpad上执行所有emerge命令？通过NFS挂载/etc/portage有何优势？
我一直梦想将所有Ubuntu服务器迁移到Gentoo，但尚未明确如何集中管理一整套Gentoo机器
是的——我仍在Thinkpad上像在主机上那样使用emerge命令，例如执行emerge -avuDN @world等操作。这是我用于配置Portage相关设置的维基文档[1]，其中也涵盖了NFS方案。
我通过NFS将容器的/etc/portage挂载到/mnt/portage，并创建符号链接指向Thinkpad的/etc/portage目录，这样就能精确选择需要与构建容器保持同步的内容。无需修改repos.conf，因为Portage默认会搜索/var/cache/binpkgs目录。
make.conf在两台机器上都是目录形式，包含01-common-flags.conf和02-binhost-flags.conf等配置文件。Thinkpad上配置了01-common-flags.conf和03-target-flags.conf，其中设置了EMERGE_DEFAULT_OPTS=“–with-bdeps=n –usepkgonly”参数，因此在Thinkpad上执行emerge -avuDN时，仅会从挂载的/var/cache/binpkgs目录更新二进制文件。我通过/etc/portage/sets而非world文件保持软件同步，此时所有package.*目录均为符号链接。
Thinkpad宾主机采用znver3架构，因此构建容器设置了CFLAGS=“–march=x86-64-v3 –mtune=alderlake”。由于两者存在部分SIMD扩展差异，必须构建兼容两台机器的代码，否则可直接通过–march指定目标架构。在我的场景中，使用–mtune选项会将生成的代码L2缓存大小设置为与英特尔芯片一致。
Systemd-nspawn容器的创建极其简便，本质上是通过stage3安装Gentoo系统，其运行机制类似chroot环境但具备完整的初始化系统。我采用不定期更新策略，维护仍需部分手动操作，但主要流程仅需启动emerge命令并在tmux会话中完成构建。
[1] https://wiki.gentoo.org/wiki/Binary_package_guide
现在能在笔记本上安装Gentoo了，我真心爱上了二进制包。
感谢！这里有太多值得我学习的内容
Gentoo聚集了众多才智之士。但不得不说，自从Arch崛起后，Gentoo似乎失去了不少优势。这或许并非Arch的主因，但确实让我产生了这种感受。我认为Gentoo开发者应当认真审视Void或Arch这类主要竞争对手。在我看来，这些系统更像是现代版的Gentoo——尽管它们存在差异且侧重点不同。
Void和Arch都不是“现代版Gentoo”。Gentoo自成一派。若真要说，Gentoo在操作系统定制化方面最接近的“竞争者”应是NixOS或Guix，而非Void或Arch。但Gentoo正开辟自己的道路，无需追随任何发行版。
Arch正是我最新系统未选择Gentoo的原因。它便捷且“足够好”，满足我所有使用场景。Gentoo能让你感受到与计算机深度连接的独特体验——那种令人怀念的感觉——但这也需要投入大量时间。
“所有Arch用户都使用同一个分支”
https://blogs.gentoo.org/mgorny/2024/08/20/gentoo-profiles-and-keywords-rather-than-releases/
我听说有传言称Gentoo曾一度失去其论坛——这简直是灾难性的打击，就像Arch Linux维基被删除那样
并非论坛，而是2008年因托管商问题消失的非官方维基。如今已有官方维基。
我从2006年起使用Gentoo长达十余年，深爱这个系统。后来转向嵌入式系统和低功耗硬件领域，尝试过其他发行版。服务器至今仍在运行Gentoo，但台式机和笔记本已转用更主流的发行版。
此刻正在个人工作站执行emerge @world，同时为IT基础设施(约600+虚拟机、400+裸机服务器)准备年度Portage更新——这些设备均运行Gentoo。
所有虚拟机都运行Gentoo？这很特别，它们具体承担什么任务？
我大约14年前用过Gentoo！它至今仍是运行特定硬件(高核心数的4插槽AMD Opteron服务器)时我见过的最快发行版之一，我认为这主要归功于它在安装时会为特定CPU编译所有组件(甚至包括基础操作系统！)。emerge命令会进行构建/编译，只要正确设置USE标志，就能生成高度定制化的优化二进制文件。我觉得采用分阶段/渐进式安装(先下载/运行预编译程序，同时后台运行标志优化编译)能有效规避部分缺点(比如用emerge/pacman安装火狐要45分钟，而且编译失败的概率比包安装失败更高)。
看到它依然活跃真令人欣喜——记得当年大规模管理机器颇具挑战，尤其要及时修补漏洞。
45分钟哈哈，我们当年编译kde得花三天呢 😉
任务服务器取名“steve”真有意思
谢了，steve！
期待在WSL中更便捷地使用Gentoo。目前虽用Ubuntu写脚本，但既然桌面端也用Gentoo，我随时准备切换。看到Rust工具链和BLAS打包改进也很欣慰。
从初代Opteron时代(20多年前)起，Gentoo始终吸引我的核心价值在于：安装过程本身就是学习修复所安装组件的实践，这种能力日后大有裨益。我经常进行全系统重建，这相当于对源代码型操作系统进行备份测试呢。:)
我早在2003年就用过Gentoo。看到它至今仍蓬勃发展令人欣慰。如今闲暇时间不多，它已不适合我，但或许退休后我会重拾旧爱。
精彩的回顾！RISC-V镜像、WSL版Gentoo和EAPI 9的开发成果，充分展现了Gentoo的适应性。我很好奇提交量和错误报告减少的趋势——你认为这是自然稳定化的结果，还是贡献者参与度下降？此外，从GitHub迁移到Codeberg的决策很果断，社区对此转变的反应如何？很想了解新贡献者如何适应这些更新带来的过渡和入职流程。
运行超过20年：
https://blog.nawaz.org/posts/2023/May/20-years-of-gentoo/
历史讨论链接：https://news.ycombinator.com/item?id=35989311
编辑：好奇，为何被点踩？
更让我惊叹的是你用了同一台机器20年。我也是用了20多年的用户，但换笔记本时重装过5-6次系统。
不，我换过机器，但每次都重新安装Gentoo。我只是保留了每台机器的emerge.log日志。
> 为什么要扣分？
我看不出任何理由。
虽然多年没用了，但初学Linux时我长期使用Gentoo。从零构建Gentoo让我学到很多，可能比之前双系统启动的方式更高效。我对Gentoo始终怀有特殊情愫。
巧了，我正考虑重拾Gentoo。或许该当作某种征兆。
试试https://www.calculate-linux.org/——纯正Gentoo系统，附带预编译二进制文件 😉
现在Gentoo本身不提供二进制安装了吗？
我以前用过Gentoo，它帮我学习了Linux，我非常喜欢它。虽然等待编译需要花些时间，但我因此了解了distcc，还专门配置了另一台机器来协助编译！现在不再使用Gentoo了，毕竟实在抽不出时间处理那些编译问题——但能拥有专为自己定制调优的系统，那种感觉真的很酷。
(顺便说一句，我现在用Fedora)
管理Gentoo服务器有多容易？和Nix/Arch相比是同等难度还是更难？
我已有多年未直接使用Gentoo。当初选择它是为了学习系统优化、追求性能极限，以及在其他发行版支持新CPU规格前获得完善的AMD64支持。那几年Gentoo的文档也最为完善。
Id Software在《毁灭战士3》首发时提供了Linux客户端。我发现自建的Gentoo系统运行该游戏比Windows XP更流畅。
你是否考虑过通过自定义编译参数和内核配置来最大化性能，而非使用预编译二进制文件和加载模块的通用内核？
定制版Gentoo会因软件升级等待时间增加而耗费更多精力。这如同所有Arch软件包都仅通过AUR提供。编译失败的风险也存在，可能需要调整参数。多数情况下，只要确定好编译参数，一切都能顺利编译。出现问题的情况实属罕见。
技术上讲，仅需针对CPU优化内核、应用实时补丁、启用NTSync并定制MESA编译(设置-O2优化选项和-march指令匹配CPU架构)，就能获得显著性能提升，无需尝试重新编译所有组件。
日常管理与Arch等常规发行版类似。软件包更新因需重新编译而耗时较长，但这仅涉及CPU时间。若需节省时间，可选用预编译的大型流行二进制文件(如OpenOffice、Firefox等)。
真正耗时的是利用Gentoo提供的多重参数优化系统与软件包。若你是强迫症般的调试狂人，Gentoo既能带来极致满足感，也可能成为巨大的时间黑洞。
我不理解所谓的时间黑洞。深入了解系统细节难道不是好事？若你已钻研至此，必然比多数人更了解系统。
学习确实有益，但很容易陷入过度深究的陷阱——把时间浪费在无意义的优化和定制上，反而耽误了实际工作。
以我的经验(注意这是五年前的事了)，它的复杂度不比Arch安装更高，但社区规模更小，文档也更少。
简而言之：安装过程痛苦，初始配置痛苦，总有无穷无尽的调试事项，更新虽稍好些但依然痛苦。不过乐在其中，堪称BDSM式体验…
安装流程是：启动LiveCD，手动分区存储设备，解压Gentoo STAGE3存档，进入chroot环境，完成网络、时区、Portage(包管理器)基础配置、服务器设置等基础配置，编译安装内核，最后重启进入新系统。
接着你就能玩转/etc/portage/make.conf——这是包管理器的根配置文件。你可以设置CPU指令集(CPU_FLAGS)、gcc编译器参数(CFLAGS)、MAKE编译器参数、显卡目标、可接受的软件包许可证、全局USE标志(这些是简化的./configure参数，通常适用于多个软件包)、要构建的Apache模块、要构建的qemu目标等等。这些都是Portage(包管理器)用于为系统构建软件包的环境变量。
使用Gentoo越久，你就会发现make.conf中越多的功能。乐趣永无止境。
接着开始安装软件包和更新(流程相同)：
- 启动更新时需逐个审查新增/更新软件包的USE标志——这需要浏览数屏密集的文本。
例如PHP的USE标志如下：https://packages.gentoo.org/packages/dev-lang/php – 鼠标悬停可查看功能说明。你可以在/etc/portage/package.use文件中自由调整这些标志，其调试空间无穷无尽。
若有任何强迫症倾向，请远离Gentoo，否则这将成你永世难解的毒！
- 随后进入编译阶段，耗时长短取决于安装内容，可能持续数小时至数日。此过程将占用大量CPU资源，并消耗存储I/O或内存(若内存充足，可在tmpfs中编译以显著提升速度)。
我不确定在运行中的服务器上编译更新是否妥当，尤其是在高峰时段。不过Gentoo提供了替代方案：包括二进制包(近期新增，但需确保您的USE标志与它们匹配)、在另一台系统上远程构建包(distcc)，甚至可在不同架构上操作(crossdev)。您可以在x86工作站上运行ARM服务器并为其构建包。我尚未使用过“steve”工具，因此无法说明它能实现哪些出色功能。
- 受架构限制，部分使用率较低的软件包可能编译失败。此时需手动调试并提交错误报告。您也可在/etc/portage/patches/<软件包名>目录添加补丁，这些补丁将在构建软件包时自动应用，内核编译同样适用。
建议使用 –keep-going 参数运行 emerge，使包管理器在错误后继续处理剩余软件包。
- 每个软件包编译完成后会自动安装。系统不会自动重启，所有文件(包括可执行文件和库文件)都会实时替换。运行中的服务会继续使用内存中的旧文件，直到手动重启服务或系统——在此之前，这些服务在 htop 中会显示为红色/黄色。
极少数情况下，成功编译的新软件包可能导致系统崩溃。此现象仅出现在已基本废弃的armv7架构平台。遇到此类情况可回退旧版本，并屏蔽存在缺陷的版本以防止下次更新。
- 最后一步是审查配置变更。dispatch-conf会为所有更新包的.ini和.cfg文件显示拟定变更的差异对比。您可以审查、接受、拒绝变更，或手动编辑文件。
就这样。很简单。:)
这段描述非常清晰地勾勒出预期流程。这项任务已在待办清单上搁置太久，我很快就要尝试了。感谢分享 🙂
我常对人说：
红帽系统用Anaconda安装程序，Ubuntu用ubiquity。
等等…
在Gentoo里——你就是安装程序。这意味着你必须准备好——或多或少手动完成——其他发行版自动化处理的许多任务。我把它看作是电子游戏里的教程关卡：你学会如何阅读并遵循wiki指南，这本质上是Gentoo成功的关键。
不，我不同意。那应该是Slackware。你大概没用过吧…它甚至不做依赖管理。
Portage/emerge高度自动化，配置完成后只需确认即可自动更新，除非你需要调整某些设置。
Slackware 没有包管理器或安装程序，只是省去了一步操作而已。
我从未说Gentoo没有包管理器(它确实有，而且很出色！)
从https://www.calculate-linux.org/下载镜像，写入USB闪存盘。
安装过程简直就是“是，是，下一步，下一步”——默认配置相当完善。
- Calculate Linux是100%的Gentoo系统，但增加了更多配置文件(如服务器版、KDE桌面版、GNOME桌面版等)。从原生Gentoo切换到Calculate后，我无需调整任何软件包的使用标志。
配置文件设计得如此出色，所有组件都能完美协同工作
-
提供针对配置文件与使用标志组合的预编译二进制包——记不清上次等待编译是什么时候了
-
由于所有组件都提供二进制包，出错概率大幅降低——而额外的cl-xxx工具集让操作更轻松
-
我认为这并非缺点。当然，自动重启服务的选项确实会更理想。
-
没错——还能存档配置，基本实现git-log级别的配置变更追踪。
> Calculate Linux是100%的Gentoo系统，只是增加了更多配置文件(如服务器版、KDE桌面版、GNOME桌面版等)。从原生Gentoo切换到Calculate后，我无需调整任何软件包的use标志。
若你偏好如此，自然没问题。但对我而言，连Gentoo都过于自动化了。我采用最基础的配置文件，所有包的use标志都手动调整。已弃用openrc，转而直接使用sysvinit/inittab。
不过话说回来，既然需要二进制包之类的东西，为何还要使用Gentoo或其分支？
“主要由于持续强推Copilot使用于我们的仓库，Gentoo目前正考虑并将计划将仓库镜像及拉取请求贡献迁移至Codeberg。”
我在“从Windows转投Linux”的讨论中看到评论暗示Windows比Linux更具配置潜力。真想知道那位评论者看到Gentoo会作何感想。
真希望我有更多时间维护系统，如今因时间不足只能困在Arch上，实在遗憾。
二十五年前还是个孩子时，调整使用标志、用Intel cc编译器编译、钻研蓝色内核配置界面里的每个菜单都充满乐趣。记得当时系统重新编译要花上四小时。那段经历让我学到很多，至今仍派得上用场——要不是当年纯粹好玩地折腾glibc的使用标志，我可能连glibc是什么都不知道。
如今我在Arch Linux上愉快地玩游戏，日常开发用Mac，偶尔需要跳进Docker里的Debian环境。但真心希望现在的年轻人能尝试Gentoo——它培养的黑客技能无可替代。无意冒犯仍在使用它的成年人！只是希望别再出现太多“我的系统无法编译了”的窘境，毕竟我记忆中这种情况实在太多了。
某些语言的维护者竟不把“始终提供干净的黄金启动路径”作为头等要务，这实在令人费解。
关于Github迁移(离开)还有更多消息吗？虽然Github的AI功能很烦人，但目前我还能完全忽略它们。
我仍在向Gentoo的GitHub镜像提交PR，若他们关闭此通道我会很惊讶。
所以谷歌对Gentoo说再见了？ChromOS变异成了AluminumOS？？
项目本身很棒，背后团队也很出色，但实在太耗时间。
从公告看，更多是多余的哲学性调整而非创新举措。我喜欢创新的Linux，不过这只是个人观点。
发表回复