Linux基金会2025年度报告近日曝光，其中一个数据引发了开源社区的广泛讨论：在基金会的总预算中，仅有2.95%被直接用于Linux项目本身。其余97%以上的资金流向了哪里？这个数字背后反映了开源治理的什么问题？

2.95%的数据来源

Linux基金会是全球最大的非营利开源组织之一，托管了Linux内核、Kubernetes、Node.js等数百个重要开源项目。其年度报告披露了详细的资金分配情况。

报告显示，Linux基金会的预算主要分配在以下领域：

• 项目支持和基础设施：包括CI/CD、代码托管、安全审计等
• 活动和会议：如Linux Foundation开源峰会、KubeCon等大型技术会议
• 培训和认证：LFS系列认证课程的开发和运营
• 法律和合规：开源许可证合规、专利保护等法律服务
• 行政和运营：基金会自身的人员和办公成本
• 直接Linux内核支持：仅占2.95%

为什么只有2.95%

这个数字看似惊人，但有几个背景需要了解：

1. Linux基金会≠Linux内核基金会

Linux基金会的名称容易让人误解。实际上，它已经从最初的”Linux内核支持组织”演变为一个综合性的开源基金会，托管了数百个项目。大部分预算用于支持这些托管项目的整体生态。

2. 内核开发主要由企业资助

Linux内核的开发工作主要由各大科技公司的全职开发者完成。据Linux基金会的Kernel Development Report，超过85%的内核代码贡献来自公司雇佣的开发者。基金会的直接资金支持并不是内核开发的主要资金来源。

3. 间接支持

虽然直接用于Linux的预算只有2.95%，但基金会在基础设施、法律保护、活动组织等方面的支出，间接惠及了Linux内核项目。

开源社区的反应

这个数据在开源社区引发了不同观点：

批评声音：

• 认为基金会偏离了初心，更像一个商业活动组织机构
• 质疑高昂的会议和行政开支的必要性
• 担心核心基础设施项目得不到足够资金支持

支持声音：

• 认为基金会的多元化运营有助于整个开源生态的健康发展
• 指出活动和培训收入反过来资助了项目开发
• 强调企业合作模式是当前开源治理的最可行方案

对站长和开发者的启示

1. 了解开源治理现实

开源不等于免费，维护开源项目需要持续的资金和人力投入。作为开源软件的使用者，了解这些背后的运作方式，有助于做出更负责任的使用决策。

2. 考虑直接贡献

如果你的业务重度依赖某个开源项目，除了Star和口头支持外，考虑通过赞助、贡献代码、参与社区治理等方式给予实际支持。

3. 关注项目健康度

在选择技术栈时，不仅要看项目的功能和性能，还要关注项目的治理模式、资金状况和社区活跃度。一个资金充裕、治理健康的项目，长期维护的可靠性更高。

4. 理解基金会的角色

开源基金会的主要价值不在于直接资助代码开发，而在于提供法律保护、品牌信任、企业合作桥梁和社区治理框架。这些”软性”支持对开源项目的长期生存同样重要。

其他有趣的数字

Linux基金会2025年报告中还有几个值得关注的数据：

• 基金会托管项目的总代码价值估计超过200亿美元
• 成员企业数量持续增长，覆盖全球主要科技公司
• 新孵化项目集中在AI/ML、安全、边缘计算等领域

JavaScript运行时Bun的实验性Rust重写版本近日达到了一个重要里程碑：在Linux x64 glibc平台上，测试兼容性达到了99.8%。这意味着Bun用Rust重写后，几乎完全兼容原有的JavaScript运行时行为。对于前端和全栈开发者来说，Bun正在从”有趣的实验”变成”可以考虑生产使用”的选项。

Bun是什么

Bun是一个新兴的JavaScript运行时和工具链，由Jarred Sumner创建。它的目标是成为Node.js的更快替代品，集成了打包器（bundler）、包管理器（类似npm）和测试运行器。Bun最初用Zig语言编写，以其极快的启动速度和执行效率著称。

为什么要用Rust重写

虽然Zig语言性能出色，但其生态系统和社区规模相比Rust要小很多。Bun团队决定用Rust重写核心模块，主要出于以下考虑：

• 更好的内存安全保证：Rust的所有权系统在编译期捕获内存错误，减少运行时崩溃。
• 更活跃的生态系统：Rust有更丰富的库和工具支持。
• 更容易吸引贡献者：Rust开发者群体远大于Zig，降低社区贡献门槛。
• 长期可维护性：Rust的类型系统和模块化特性有利于大型项目的长期维护。

99.8%兼容性意味着什么

Jarred Sumner在社交媒体上宣布，Rust重写版本在Linux x64 glibc平台上的测试套件通过率达到了99.8%。这是一个非常高的数字，意味着：

• 绝大多数现有的Node.js和Bun代码可以在Rust版本上无缝运行
• npm包的兼容性基本没有问题
• 文件系统、网络、子进程等核心API行为一致

不过需要注意，99.8%是在Linux x64 glibc上的数据，其他平台（macOS、Windows、musl libc）的兼容性可能还有差距。

对开发者的影响

当前阶段：观望为主

Bun的Rust重写目前仍处于实验阶段，不建议在生产环境中使用。但如果你对JavaScript运行时的性能有极致追求，可以开始关注和测试。

中期：评估迁移

当Rust版本的兼容性在所有主流平台上都达到99%+，并且性能指标稳定后，可以考虑将部分Node.js项目迁移到Bun。

长期：生态竞争

Bun、Deno和Node.js三个JavaScript运行时的竞争会推动整个生态的发展。无论你最终选择哪个，这种竞争都是好事。

快速体验Bun

如果想试试当前版本的Bun（Zig版本），安装很简单：

# Linux/macOS
curl -fsSL https://bun.sh/install | bash

# 验证安装
bun --version

运行一个简单的HTTP服务器：

// server.ts
export default {
  port: 3000,
  fetch(request: Request) {
    return new Response("Hello from Bun!");
  },
};

bun run server.ts

OpenAI在推出实时语音和视频功能时，遇到了一个不大不小的基础设施难题：WebRTC。这个为浏览器实时通信设计的技术栈，在面对OpenAI的规模和需求时，暴露出了不少问题。本文分析OpenAI遇到的WebRTC困境，以及这对整个实时AI通信领域意味着什么。

什么是WebRTC

WebRTC（Web Real-Time Communication）是一套支持浏览器和移动应用进行实时音视频通信的开放标准。它被广泛用于视频会议、直播、在线教育等场景。Zoom、Google Meet、Discord等产品的底层通信都依赖WebRTC或其变体。

当OpenAI推出GPT-4o的实时语音功能时，选择了WebRTC作为客户端与服务端之间的实时音频传输方案。这个选择看起来很自然——WebRTC是浏览器原生支持的、成熟的实时通信方案。但在实际落地过程中，问题逐渐暴露。

OpenAI遇到的WebRTC问题

1. 延迟和抖动

AI实时语音对话对延迟的要求比普通视频会议更高。用户说完一句话后，期望AI能在几百毫秒内开始响应。但WebRTC的网络自适应机制（如抖动缓冲区、丢包重传）在某些场景下反而增加了延迟。

2. NAT穿透问题

WebRTC需要通过ICE（Interactive Connectivity Establishment）框架来处理NAT穿透。在复杂的网络环境（如企业防火墙、运营商级NAT）下，连接建立的成功率和速度都不够理想。

3. 服务端扩展

传统的WebRTC架构中，SFU（Selective Forwarding Unit）或MCU（Multipoint Control Unit）负责媒体流的转发和混合。当需要处理海量并发的AI语音会话时，服务端的扩展成本和复杂度急剧上升。

4. 浏览器差异

虽然WebRTC是W3C标准，但不同浏览器的实现细节存在差异。Chrome、Firefox、Safari在编解码器支持、API行为等方面的不同，给跨平台兼容性带来了额外工作。

替代方案探讨

有开发者提出了几种可能的替代方案：

• WebSocket + 自定义音频流：绕过WebRTC的复杂性，直接通过WebSocket传输PCM或Opus编码的音频数据。实现简单，但需要自行处理网络自适应。
• Media over QUIC (MoQ)：IETF正在标准化的新一代媒体传输协议，基于QUIC协议，目标是替代WebRTC用于大规模实时媒体分发。这也是那篇HN文章的讨论重点。
• gRPC Streaming：Google的gRPC框架支持双向流式传输，可以用于音频数据的实时传输，但浏览器端支持有限。
• 专有协议：像Discord那样，开发针对特定场景优化的专有协议。

对站长和开发者的启示

如果你在开发涉及实时AI语音交互的应用，以下几点建议：

1. 评估实际需求：如果你的应用不需要浏览器端实时音频，WebSocket方案可能更简单可靠。
2. 关注MoQ进展：Media over QUIC是未来方向，但目前标准化和实现都还不成熟。
3. 做好降级方案：即使使用WebRTC，也要准备WebSocket降级方案，确保在WebRTC连接失败时用户仍有基本体验。
4. 测试真实网络环境：在开发环境中的低延迟网络下测试没问题，不代表在用户的4G/WiFi环境下表现良好。

实时AI通信的未来

随着AI语音交互、AI视频通话等功能的普及，实时AI通信基础设施的需求会越来越大。WebRTC虽然是目前最成熟的选择，但确实需要演进才能满足AI场景的特殊需求。

OpenAI遇到的这些问题，其实也是整个行业需要解决的。未来可能会出现专门为AI实时交互优化的通信框架，或者WebRTC本身会针对AI场景进行扩展。

cPanel，全球最流行的服务器管理面板之一，近日遭遇了一波严重的勒索软件攻击。据安全研究人员披露，超过44000台运行cPanel的服务器在这次攻击中受到影响，官方随后紧急发布了三个高危漏洞的补丁。对于使用cPanel管理服务器的站长来说，这是一个需要立即关注的安全事件。

事件经过

安全研究人员发现，攻击者利用cPanel中未修补的安全漏洞，对大量服务器部署了勒索软件。这次攻击的规模令人震惊——受影响的服务器数量达到44000台，涉及全球多个地区的托管服务商。

攻击被发现后，cPanel安全团队在短时间内连续发布了三个安全补丁，分别修复了三个高危CVE漏洞。业内将这一周称为cPanel的”黑色一周”。

三个高危漏洞详情

cPanel在此次事件中修复的三个漏洞均被评为高危级别，涉及认证绕过和权限提升等攻击向量。攻击者可以利用这些漏洞：

• 绕过正常的身份认证流程，直接获取管理员权限
• 在服务器上执行任意代码
• 部署勒索软件，加密服务器上的网站文件和数据库

受影响的cPanel版本范围较广，建议所有用户立即检查自己的版本并升级到最新版。

站长如何检查和应对

第一步：检查cPanel版本

登录WHM后台，在”Server Configuration” → “Update Preferences”中查看当前版本号。也可以通过SSH执行：

/usr/local/cpanel/cpanel -V

第二步：立即更新

在WHM后台执行更新操作，或通过SSH运行：

/usr/local/cpanel/scripts/upcp --force

更新完成后重启cPanel服务。

第三步：检查服务器是否已被入侵

如果你的服务器在更新前已经暴露在公网，建议检查以下指标：

• 检查是否有异常的cron任务：crontab -l
• 检查是否有未知进程在运行：ps aux | grep -v grep
• 检查网站文件是否被加密或篡改
• 检查是否有异常的SSH登录记录：last -20
• 检查磁盘空间是否异常减少

第四步：备份验证

确认你的自动备份是否正常运行。如果服务器已被入侵，可能需要从干净的备份恢复数据。

预防措施

1. 开启自动更新：在WHM中启用cPanel的自动安全更新功能。
2. 限制WHM访问IP：在防火墙中限制WHM管理端口（2087）的访问IP。
3. 使用强密码和双因素认证：确保所有管理账户使用强密码，并启用2FA。
4. 定期备份并异地存储：不要只依赖服务器本地备份，至少保留一份异地备份。
5. 监控安全公告：订阅cPanel安全邮件列表，第一时间获取漏洞信息。

站长经验教训

这次事件再次说明，服务器管理面板是黑客的重点攻击目标。cPanel虽然功能强大、使用方便，但其庞大的代码面也意味着更多的潜在漏洞。站长应该：

• 不要把管理面板暴露在公网，使用VPN或IP白名单访问
• 及时应用安全更新，不要拖延
• 做好数据备份，这是最后的防线
• 考虑使用更轻量的替代方案，如1Panel（开源）等