Rust实战案例：用自研数据库HorizonDB替换Elasticsearch/MongoDB，性能成本双优化

Redox 自首次提交代码以来已经十周年，2025 年在 Wayland 支持方面取得了重大进展，在硬件加速图形方面也迈出了初步步伐，并且首次尝试在智能手机上运行 Redox！

这意味着 Redox 正从“实验性系统”向“实用性系统”快速演进。其中，原生显卡驱动 和 ARM64 动态链接 的实现，标志着该系统在直接掌控硬件和支持现代计算架构方面取得了实质性突破。

硬件支持的里程碑

• Intel 图形驱动：Redox 实现了其首个原生 Intel GPU 模式设置（modesetting）驱动。
  • 开发者：由项目创始人 Jeremy Soller 开发，旨在替代传统的、非加速的 BIOS VESA 或 UEFI GOP 显示方式。
  • 支持范围：目前主要针对 Intel Kaby Lake 和 Tiger Lake 代的集成显卡。
  • 现状：虽然目前仅支持模式设置（即控制屏幕分辨率等），尚未实现硬件 GPU 加速，但这为 Redox 摆脱对通用显示标准的依赖迈出了关键一步。
• Linux DRM 兼容层：开始实现基本的 Linux DRM (Direct Rendering Manager) 只读 API。这将简化未来从 Linux 移植图形驱动程序的过程。

架构与链接改进

• ARM64 动态链接：ARM64 架构现在支持动态链接。这不仅能减小可执行文件的体积，也是实现二进制兼容性和系统稳定性的重要基石。
• POSIX 兼容性提升：持续改进了对 POSIX 标准的支持，使得更多现有的开源软件能够更容易地在 Redox 上编译和运行。

构建系统与基础设施

• 自主构建服务器（Autonomous Build Server）：上线了全新的自动化构建基础设施，用于更高效地处理包的编译和分发，提升了开发迭代的速度。
• Cookbook 改进：Redox 的包管理工具 Cookbook 现在支持更好地处理 Linux 二进制文件 的编译与集成。
• 可选包特性（Optional Package Features）：引入了对包特性的可选支持，使用户可以更灵活地配置安装的组件。

系统稳定性与其它更新

• 内核与 Relibc 优化：对微内核核心和标准 C 库（Relibc）进行了多项修复和性能微调。
• 应用移植：继续推进各类应用向 Redox 的移植工作，系统生态进一步扩大。

阅读完整报告：https://www.redox-os.org/news/this-month-251231/

---

Rust 生产实践：Radar 用单 Rust 服务取代 Elasticsearch/MongoDB

Radar 是一家地理位置基础架构公司，其开发了一个名为 HorizonDB 的自研地理空间数据库，完全使用 Rust 编写。该数据库的核心目标是整合并取代之前分散在多个系统中的地理位置服务。

那么，他们为什么要用 Rust 来替换掉原有的 MongoDB 和 Elasticsearch 组合呢？

在切换到 Rust 之前，Radar 的架构依赖于 Elasticsearch（处理正向地理编码）和 MongoDB（处理反向地理编码）。这种架构在实际运行中暴露出不少挑战：

• 成本高昂：Elasticsearch 频繁地将查询扇出（fan out）到所有分片，且需要复杂的服务编排来进行批量更新。
• 性能瓶颈：MongoDB 缺乏真正的批量摄取（batch ingestion）能力，且在数据出现错误时难以进行可靠的批量回滚。
• 架构复杂：Node.js API 层在扩展时，每个核心都需要独立的进程，内存占用较高。

技术实现与优势

为了解决上述问题，Radar 团队进行了全面的技术重构：

• 高性能后端：充分利用 Rust 的内存安全和强类型系统，并借助 Rayon 和 Tokio 来处理高并发场景。
• 单进程模型：相比 Node.js 的多进程，Rust 的多线程模型能更高效地利用单机的内存地址空间。
• 底层优化：基于 RocksDB 构建，成功将多种位置服务整合进单一的高性能二进制文件中。

取得的显著成果

这次技术迁移带来了立竿见影的效果：

• 成本节省：由于关闭了多个 MongoDB 集群和大型 Elasticsearch 集群，每月节省了 五位数（数万美元） 的云服务开支。
• 极低延迟：反向地理编码的中位延迟降低到了 < 1ms，正向地理编码中位延迟为 50ms。
• 高吞吐量：单核可处理 1,000 QPS。
• 运维简化：实现了线性的横向扩展能力，且开发者可以在本地轻松运行整个服务。

Radar 的这个案例是典型的 “用 Rust 重写” 的成功故事。他们通过自研 Rust 数据库 HorizonDB，精准地解决了传统数据库在特定地理空间任务下的性能和成本痛点，最终实现了性能飞跃与成本削减的双赢。

收听完整访谈：https://corrode.dev/podcast/s05e08-radar/

---

文章分享：将屏幕共享UI从 Tauri/WebKit 移植到 iced

这篇文章由远程结对编程平台 Hopp 的开发者 Costa Alexoglou 撰写。文章详细说明了他们为什么决定在关键业务中“抛弃”基于 WebKit 的 UI（如 Tauri 默认的 webview），转而使用 Rust 原生渲染库 iced。

究竟是什么原因让他们如此“讨厌” WebKit 呢？作者列举了在开发高性能、低延迟远程桌面协作工具过程中遇到的几个重大坑点：

• 视觉渲染缺陷：WebKit 在处理 SVG 阴影和滤镜时经常出现模糊或失效，导致团队不得不为了适配 Safari 而牺牲 UI 设计。
• iOS 上的“无头”崩溃：在 iOS 上，WebKit 可能会因为几个 GIF 动图就导致页面反复崩溃且不提供任何错误日志，调试极其困难。
• 过时的 User Agent：WebKit 的版本号长期保持不变，导致无法通过版本检测来启用某些现代特性，迫使开发者使用丑陋的 Monkey-patch。
• 音频处理问题：列出麦克风列表时会出现音频闪烁，且 WebKit 会在开启麦克风时强制调低其他应用的音量。
• 编解码器限制：WebKit 对 AV1 编码的支持仅限于有硬件解码的新设备，不像 Chrome 那样有软件退避方案，这在复杂的屏幕共享场景中非常受限。
• Linux 兼容性差：Linux 上的 WebKitGTK 默认不支持 WebRTC，这直接阻塞了 Hopp 在 Linux 平台上的核心功能。

未来的解决方案：拥抱 Rust 原生渲染

由于上述问题积重难返，Hopp 团队决定不再等待 Tauri 对 Chrome (CEF) 的支持，也不想切换到沉重的 Electron，而是采取了更激进的方案：使用 Rust (iced 库) 编写核心窗口。

这样做的好处显而易见：

• 简化逻辑：不再需要同步 Rust 后端和多个 WebKit 前端窗口，所有流媒体逻辑可以集中在后端处理。
• 性能提升：通过直接调用 libwebrtc 和 Rust 音频视频库，可以使用任何编解码器，彻底摆脱浏览器内核的限制。
• 利用原生特性：可以直接利用 Apple M 芯片的神经网络引擎进行图像超分辨率缩放，提供比浏览器内核更清晰的视频流。

阅读原文：https://gethopp.app/blog/hate-webkit