从 Linux 与 Ubuntu 到 Chromium 与 Chrome：理解平台与发行版的边界
俊宁 · 日期未详文章目录
以 Linux/Ubuntu 和 Chromium/Chrome 为参照，区分共享底座、产品身份、默认策略与最终交付责任。
本文讨论通用机制和设计判断；示意不对应任何具体产品的已交付状态。源码阅读坐标沿用原稿，本次整理不构成新的运行时验收。
（此版本省略该配图。）
类比能说明什么
- Linux/Ubuntu 提供最清晰的层次参照：kernel 只是完整系统中的一个组件；发行版还要承担软件包、默认环境、升级、安全维护和支持责任。
- Chromium/Chrome 提供最贴近浏览器的参照：Chromium 默认使用开源资源与品牌，Chrome branded build 则引入专有品牌与内部资源；产品发布不能由开源源码 checkout 自动推出。
一、为什么会自然联想到 Linux 与 Ubuntu
Linux 官方明确提醒：kernel 只是一个可工作的 Linux 系统里的组件；普通用户真正要安装的是一个完整的 Linux distribution。Linux Kernel 官方说明
这一区分很重要。kernel 解决的是硬件、进程、内存、文件系统、网络等底层抽象；一个发行版还要把 kernel 与用户空间、软件包、默认配置、安装媒介、安全更新和支持周期组织成可使用的系统。Ubuntu 自己也将其描述为基于 Debian 架构与基础设施、同时拥有不同界面、社区和发布流程的系统。Ubuntu 项目文档
因此，发行版需要对以下问题作出具体承诺，换一套图标远远不够：
| 问题 | Linux kernel | Ubuntu 这类发行版 |
|---|---|---|
| 提供什么 | 通用内核能力与硬件/系统接口 | 一套可安装、可升级、可运维的完整系统 |
| 谁定义默认选择 | 不替用户选择桌面、软件源或支持策略 | 选择默认包、桌面体验、版本节奏与安全维护 |
| 谁向最终用户交付 | 不直接等于用户安装体验 | 负责镜像、包仓库、升级和支持承诺 |
| 怎样复用 | 多个系统可以采用同一内核版本或补丁线 | 可以选择、集成、验证并维护自己的组合 |
这个模型的价值不在“谁抄谁”，而在于它迫使团队把共享能力和产品责任分开。共享底座可以持续演进，发行版不必一起改名、一起发版；但发行版也不能把最终交付责任推回底座。
二、Chromium 与 Chrome：更接近浏览器的参照
对浏览器工程而言，Chromium/Chrome 的关系更有参考价值。Chromium 的官方构建文档说明：默认 Chromium build 使用开源的 Chromium assets 和 branding；Google Chrome branded build 使用额外的品牌条件，且某些商标资源位于内部仓库。Google Chrome branded builds
这至少说明三个事实：
- 同一上游代码不等于同一产品。品牌、资源、默认实验配置与发布输入会改变最终交付物。
- 构建参数不是产品所有权的替代品。
is_chrome_branded这类开关只能选择已经定义好的输入；它不自动提供商标、签名、渠道、合规或用户支持。 - 浏览器产品的分界比“fork 了多少代码”更重要。谁控制 bundle identity、内置资源、更新 feed 和验收，谁才对该浏览器产品负责。
但 Chromium/Chrome 也不能被简单等同为 Linux/Ubuntu：Chrome 与 Chromium 的组织、商标和内部资源关系，并不是独立团队各自维护一个 Linux distribution 的复制品。这个案例真正可借鉴的是：开源基线、品牌化输入和最终发布产品应在工程上可区分。
四、这个类比指导怎样划分改动
类比最有价值的地方，是让改动路由变得可执行。
| 改动 | 主要 owner | 是否通常需要重构 Browser | 原因 |
|---|---|---|---|
| 内置扩展 UI、Prompt、业务规则 | Extension owner | 通常否 | 可走独立 Extension release；新增 capability 时再联动 Browser |
| Runtime Tool/MCP 或实现版本 | Runtime implementation + Distribution | 通常否 | 独立 artifact 和 channel，但需验证与当前 Extension/Browser 的兼容 |
五、平台要克制，发行版也要承担责任
- 哪些 contract、manifest、package 版本与 hash 必须被锁定；
- 哪些 Browser Native capability、权限和兼容规则由平台保证；
- Kernel Build Kit 如何在目标 Chromium 基线上重放并校验平台输入；
- 哪些状态必须分开记录：Built、Packaged、Signed、Uploaded、Activated、Client-updated、Live-verified。
而 Distribution 不能把“平台已经提供能力”误读为“产品已经发布”。它必须自行决定并证明：采用哪个版本、用什么品牌和签名、向哪个 channel 激活、哪些旧客户端能升级、升级后业务是否仍正常。
六、不要从这个类比推出的三件事
- 不要认为共享底座就应该统一版本和统一发版。兼容性由精确依赖、manifest compatibility、Profile 与 lock 表达；相同版本号本身不能证明兼容或完成交付。
用这个类比做架构判断
Linux/Ubuntu 与 Chromium/Chrome 的类比最终要落到一条架构门禁：共享机制进入 Browser Kernel，品牌、能力组合、签名、渠道和用户验收留在 Browser Distribution。新增 Distribution 不应要求平台重写业务判断；某个 Distribution 的发布也不能替其他产品背书。
参考资料
- The Linux Kernel: About Linux：kernel 与完整 Linux distribution 的基本区分。
- Ubuntu Project: Debian：Ubuntu 与 Debian 的基础、界面、社区和发布流程边界。
- Chromium: Google Chrome branded builds：Chromium 默认 branding 与 Chrome branded build 的资源边界。
- Chromium GN build configuration：official Chrome build 与 branded build 的构建条件。