…CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal. …
… Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement.
后续红帽又发文解释(同一个人,自称做开源十几年),但是这个解释更加令人失望。他似乎并没有意识到自己问题,反而认为是 Linux 社群的人不懂 GPL。让我们来看看他的惊人言论:
We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL. …
I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous. …
第二点,这个人直接将下游利用 RHEL 代码的行为定性为自私自利。但是不要忘了,你红帽做出 RHEL 不也是靠利用上游代码?如果 Linux 和 GNU 都不提供给你源码,你不也一样赚不了钱?甚至红帽 2021 年退出了自由软件基金会,变成了利用 GNU 赚钱却不回馈 GNU。对于红帽的这种双重标准,我只能说是虚伪之极,无耻之极。
职业经理人正在毁掉一切
提到红帽,就不得不提 IBM。
2019 年,IBM 收购红帽。
2020 年,CentOS 卒,走得并不安详。
2023 年,RHEL 背叛开源。
如今的 IBM 已经是一家唯利是图的公司了,近些年几乎毫无创新。职业经理人掌控科技公司就会带来这种问题。而如今他们似乎也想给红帽杀鸡取卵。职业经理人们根本不懂开源,也不懂社区,甚至也不太懂企业客户。任何东西对他们来说都是工具,而他们只为股价和股东负责,为此他们很乐意牺牲任何工具,包括客户。
在国外,有 Google 赶鸭子上架的 Bard(上架当天股价暴跌 8%),有 Facebook 被迫开源的 LLaMA(不知道被谁给泄漏了源码)。在国内,百度的文心一言已经开过发布会,阿里的通义千问刚刚开始邀请测试。各家互联网公司都在烧钱搞大语言模型,盈利前景尚不明朗,唯有 NVIDIA 老黄赚的盆满钵满。
在坊间,AI 已经被过度神化,主流媒体甚至也在鼓噪“你的工作会被 AI 取代”这种论调。但是对于科技从业者而言,我们需要冷静看待,AI 大语言模型仍然有很大的局限性。它还远不能取代人,甚至不能取代同为程序的搜索引擎。但是不可否认,就像现在每个人都要使用计算机和手机一样,未来每个人都要使用 AI 做一些事情。了解和接触大语言模型还是很有必要的。
Vite 基于 esbuild (用 Go 语言编写) 和 Rollup。它采用了 Unbundled Dev Server 模式,通过浏览器原生 ESM 特性,省去了 Bundle 步骤,以达到比 Webpack Dev Server 更快的 HMR 和启动速度。Vite 4 提供了一个新的基于 SWC 的 React 插件 @vitejs/plugin-react-swc ,用于替换旧的基于 Babel 的插件。这让 React Fast Refresh 的速度快了 20 倍。目前,Vite 仍然是速度最快的前端构建解决方案之一。
Vite 易于使用。即使不进行任何配置,也能开始使用。如果需要定制,它的文档也非常详细好用。Vite 兼容 Rollup 插件和配置接口,甚至可以借用 Rollup 的文档。用户更容易找到需要的插件,遇到问题也更容易找到解决方案。编写 Vite 插件也相对容易。所以 Vite 的社群和生态系统成长很快。Vite 的 JS API 设计简单清晰,功能丰富。基于 Vite 开发你自己的构建工具很容易。
用 JS 写的 Webpack Dev Server 采用 Bundled 模式启动。即先由 Webpack 将多个源码文件打包成一个,再传输给浏览器。在浏览器的网络记录中,你只会看到几个网络请求。因为 Webpack 打包的效率低,启动速度很慢,热加载也很慢。
后来出来了 Snowpack (已废弃),可能是第一个 Unbundled 模式的 Dev Server。采用 Unbundled 模式启动 Dev Server,通过原生 ESM 加载,省去了 Bundle 的过程,提高了启动速度。当 Dev Server 启动时,不会进行编译,而是在接到浏览器请求时,动态编译每个文件,每次传输一个源文件对应的代码。过程大致是:
请求 → 编译 → 响应 → 请求 → 编译 → 响应 → … → 请求 → 编译 → 响应
这导致 Snowpack 的启动速度极其缓慢,对比 Webpack Dev Server 并没有显著优势。
后来 Vite 继承并改进了 Snowpack 的思路。它将 node_modules 中大量的依赖用 esbuild 先 Bundle 成单个文件,而项目源码依旧采用 Unbundled 模式。得益于 esbuild 的强大性能,不管是依赖的 Bundle,还是单个源码文件的转译,都非常快。因此 Vite 对比 Webpack Dev Server 取得了巨大的性能优势。
因此 Parcel 2,Turbopack 和 Rspack 选择了回到 Webpack Dev Server 的 Bundled 模式,通过用 Rust 重写关键部件,改进打包和编译性能来提高性能。
但是根据 Turbopack 的 Benchmark,只有在 src 中有 1000 个以上的 React 组件时,Turbopack 对比 Vite 才会有比较明显的优势。但实际应用中,1000 个组件(约100K到1M行代码)已经是相当大规模的应用了。而 Vite 的冷启动速度仍然可以接受:4.2s。另外,我觉得这个 Benchmark 用 Turobopack 的 Server Side Rendering 对比 Vite 的 Client Side Rendering,并不公平,因为 Vite 也是支持 Server Side Rendering 的。
总结一下,我觉得 Vite 的 Unbundled 策略和 Parcel 等的 Bundled 策略各有所长,在实际应用中并不能拉开明显的性能差距,未来很长一段时间仍然会共存,而不是此消彼长。