## SideX：一个轻量级的 VSCode 移植 SideX 是一个早期发布、开源项目，旨在以更小的体积重现 Visual Studio Code 的功能。它通过用 Tauri（一个基于 Rust 的后端和原生 webview）取代 Electron 来实现这一点，从而获得更快的性能和更低的资源占用（目标是 200MB 内存）。 该项目是对 VSCode 的 1:1 架构的精简移植，使用了超过 5600 个 TypeScript 文件，并使其能够在原生 shell 上运行。目前，Monaco 编辑器、文件资源管理器、集成终端、基本的 Git 集成和主题支持等核心功能已经可用，并且支持从 Open VSX 加载扩展。 然而，SideX 仍在积极开发中。许多工作台功能尚不完整，扩展兼容性有限，调试/设置界面不稳定。 开发者正在积极寻求社区贡献，以解决错误、实现功能（尤其是终端、扩展和调试），并改进平台支持。如果您熟悉 VSCode 的架构，鼓励您参与贡献！您可以在 GitHub 上找到该项目和贡献指南：[https://github.com/Sidenai/sidex](https://github.com/Sidenai/sidex)。
每日HackerNews RSS
## SideX：一个注重轻量级性能的 VS Code 移植版
SideX 是一个基于 Tauri 的 Visual Studio Code 移植版，旨在显著降低 RAM 占用量，目标为 200MB。该项目在 Hacker News 上引发了争论，讨论的中心在于 Tauri 是否真正能兑现其性能承诺，以及该项目是否更多的是“炒作代码”而非实质内容。
许多评论者质疑 Tauri 的原生性能声明，指出潜在的 RAM 使用问题以及该项目对 Web 视图中 TypeScript 的大量依赖。人们对 README 的清晰度表示担忧，并质疑该项目是否真正可用，还是仅仅停留在设想阶段。
虽然有些人赞赏创建轻量级编辑器并利用 AI 进行开发的努力，但另一些人持怀疑态度，指出 VS Code 已经进行了性能改进，并且复制其庞大的扩展生态系统面临挑战。创建者通过更新 README 以提高清晰度，并承认为完全支持扩展仍需付出努力。最终，该项目的成功取决于提供一个稳定、可用的编辑器，并实现其性能目标。
## Parlor：实时、本地多模态人工智能 Parlor 是一个研究预览版，展示了使用语音和视觉进行实时人工智能对话，所有处理都在您的设备*本地*进行。它利用 Google 的 Gemma 4 E2B 来理解音频和视觉输入，并使用 Kokoro 进行文本到语音的输出。 Parlor 的驱动力是创造一个可持续、免费的英语学习工具，它通过完全在设备上运行来消除服务器成本——这得益于像 Gemma 这样更小、更强大的 AI 模型领域的最新进展。虽然它无法执行复杂的代理任务，但这代表着向人人可及的人工智能迈出的重要一步。 目前 Parlor 适用于 macOS (Apple Silicon) 和 Linux，并配备支持的 GPU，允许进行免提、可中断的对话。它可以通过 GitHub 克隆轻松运行，并需要大约 3GB 的内存。该项目旨在未来移植到手机，设想一个用户可以通过简单地展示和谈论他们周围的物体来与人工智能交互的世界，甚至利用多语言支持。
## M3 Pro 上使用 Gemma E2B 的实时人工智能
一位开发者展示了一个在 M3 Pro 芯片上本地运行的实时人工智能系统，使用了 Gemma E2B 模型（可在 GitHub 上获取）。该项目的目标是创建一个免提、语音激活的助手——实现手机助手最初的承诺，而无需解锁设备或持续的网络连接。
讨论强调了对当前“科技”公司充当技术进步的守门人的不满，以及对自托管解决方案的渴望。用户对实际应用充满期待，例如车间辅助、家庭自动化和个人任务管理。
讨论中的挑战包括语言切换、初始互联网连接要求（一位用户通过本地保存必要文件解决了这个问题），以及实现真正实时的视频理解。多位用户正在尝试类似的项目，利用 Kokoro 等工具进行文本转语音，并探索微调选项以自定义人工智能的行为。该项目展示了令人印象深刻的速度和响应能力，引发了构建原生应用程序以方便访问的兴趣。
UsenetArchives.com 是一个历史悠久的 Usenet 帖子档案，包含数十年内容。**用户被警告，该内容未经审核，可能包含成人、冒犯或令人反感的内容。** 通过访问该网站，您**确认您已年满 18 岁**（或您所在地区的法定年龄），并理解该档案的性质。您对您的浏览选择承担全部责任，并同意不非法分发内容。 该网站包含来自公共论坛的用户生成内容，无法保证其适当性。用户可以提交内容删除请求，访问受网站的隐私政策管辖。总之，请谨慎行事，并理解可能存在的敏感材料。
## 信号：深入了解响应式编程 信号是一种现代的响应式编程方法，在Solid、Vue等前端框架中越来越受欢迎，但往往缺乏清晰的内部理解。 它们的核心是管理状态，并在状态改变时自动更新依赖值——就像一个电子表格，单元格会根据公式自动更新。 这种响应性由一种“推拉”算法驱动。**基于推的信号**在值改变时通知订阅者（不共享新的状态本身）。**基于拉的“计算值”**是惰性的；它们只有在被读取*并且*依赖项发生变化时才会重新计算。 重要的是，计算值会自动跟踪这些依赖项，无需手动指定——这是优于传统方法的关键优势。 这种依赖跟踪利用一个全局堆栈将计算与它们访问的信号关联起来。 带有“脏”标志的缓存系统确保仅在必要时才重新评估，从而优化性能。 推用于失效和拉用于重新评估的结合，创造了一种细粒度、高效的响应式系统。 标准化工作正在进行中，旨在将信号原生集成到JavaScript中（TC39 proposal-signals），可能为未来的框架提供一个共同的基础。 这种方法侧重于*如何*传播变化，为现有的状态管理解决方案提供了一种强大的替代方案。
对不起。
## 功敬设计奖：源于体验的设计
近25年来，功敬设计奖一直致力于推动创新文具，将概念变为现实。今年的主题是“共鸣：引发共鸣的设计”，鼓励设计师从个人经验中汲取灵感，创造出有影响力的产品。
大奖得主是神成宏树的**“Before Note”**，它重新构想了笔记本，将其设计成可定制的页面组合，使用户能够超越批量生产，个性化他们的体验。
优胜奖作品突出了微妙而有影响力的设计：高东田的**“Gram”**探索了重量对书写的影响，塚本雄二的**“边缘识别笔记本”**以可持续的方式提供优雅的组织，而五十嵐&泷泽的**“渐变日记”**则打破了刻板的计划表结构，采用了流畅的渐变布局。
其他值得关注的入围作品包括创新的包装、鼓励反思的笔以及增强阅读和捕捉灵感的工具，所有这些都体现了对用心互动和个人联系的关注。
对不起。
## HarfBuzz GPU 与 Slug 渲染彩色字体
Eric Lengyel 的 Slug 算法现已开源，并集成到 HarfBuzz 中作为 GPU 库，超越了文本塑形，进入了字形渲染领域。传统上，文本渲染依赖于在特定尺寸下栅格化位图，这对于缩放或 3D 环境来说是个问题。像符号距离场 (SDF) 这样的替代方案也有局限性，但 Slug 直接在片段着色器中计算字形覆盖率，从而实现完美的缩放和变换。
核心思想是将字形曲线预处理成数据缓冲区并上传到 GPU。虽然最初是用于单色字形，但可以通过 COLRv0 和 COLRv1 等格式扩展到矢量彩色字体（如表情符号）。COLRv0 将表情符号渲染为堆叠的彩色字形，可以通过调整现有的单色渲染来轻松支持。COLRv1 更加复杂，利用带有变换、裁剪和混合的渲染树 – 由 HarfBuzz 的 `hb-paint` 组件处理。
这涉及将绘图命令（裁剪蒙版、填充、变换、组）编码到纹理缓冲区中，并在片段着色器中执行它们，可能需要基于图层的混合方法。最终，这使得在任何应用程序中都能实现清晰、可缩放的表情符号渲染，并且即使对于单色文本也优于传统方法。作者希望该概述能够激发进一步的开发并集成到现有的渲染库中。
对不起。
我们检测到您的浏览器已禁用 JavaScript。请启用 JavaScript 或切换到受支持的浏览器以继续使用 x.com。您可以在我们的帮助中心查看受支持的浏览器列表。帮助中心 服务条款 隐私政策 Cookie 政策 版权信息 广告信息 © 2026 X Corp.
本文详细描述了在一次意外断电后，成功恢复一个严重损坏的12TB Btrfs文件系统，该文件系统跨越3个设备池（数据单副本，元数据DUP，DM-SMR磁盘）的过程。标准的`btrfs check --repair`命令失败，由于extent树和空闲空间树的问题陷入无限循环。 恢复是通过14个基于btrfs-progs API构建的定制C工具实现的，数据损失极小——大约4.59TB中的7.2MB（0.00016%）。作者分享此案例作为研究，*而非*错误报告，并为btrfs-progs的潜在改进提供建设性反馈。 提出了九个具体的改进领域，重点是增强的修复工具功能（进度检测、extent树重建、孤立inode清理）、更清晰的文档以及对已识别边缘情况的修复。定制工具的参考实现以及一个补丁已在GitHub上公开提供，作为进一步调查和讨论的资源，而非直接提交补丁。
## Btrfs 数据恢复案例研究与讨论
最近的案例研究详细描述了在提交操作期间断电后，如何恢复一个损坏的 12TB Btrfs 多设备池。作者利用自定义 C 脚本，并借助 LLM (Claude) 的帮助，在原生 Btrfs 工具失效后恢复了 99.9% 的数据。
该事件引发了关于 Btrfs 可靠性的争论。人们对文件系统在意外关机期间数据丢失的脆弱性表示担忧，并质疑这种风险是否已得到充分记录。许多评论员指出，特定配置——例如在没有 RAID 的情况下使用元数据 DUP——尤其容易出现问题。其他人分享了他们 Btrfs 损坏的个人经历，并将其与 ZFS 的感知稳定性进行了对比。
虽然有些人为 Btrfs 辩护，承认可能存在用户错误或硬件问题，但普遍的看法是，它的恢复过程通常很脆弱，导致整个文件系统无法访问，而不是孤立的数据损坏。 建议使用 ZFS，甚至 LVM、dm-integrity 和 mdraid 的组合，尽管每种方案在性能和复杂性方面都有其自身的权衡。 这次讨论凸显了围绕 Btrfs 成熟度和是否适合生产环境的持续争论。
利用月球反射信号——被称为地月地（EME）通信——长期以来一直是无线电爱好者的终极挑战。它需要大型天线、昂贵设备以及精确的手动指向和跟踪。我们试图将这项技术带到地面，提供体验太空通信的乐趣所需的所有工具，通过开源软件定义的相控阵来实现。
## Bun vs. Node.js：Trigger.dev 的 5 倍性能提升
Trigger.dev 在其对延迟敏感的“Firestarter”服务（一个处理数千个长轮询 HTTP 连接的预热连接代理）中用 Bun 替换了 Node.js，从而实现了 **5 倍的吞吐量提升**。初步分析显示 Node.js 实现存在瓶颈：缓慢的 SQLite 查询、过多的 Zod 解析以及低效的头部转换。
第一阶段消除了 SQLite 数据库，用复合键 Map 替换它，实现 O(1) 查找，吞吐量翻倍，延迟减半。第二阶段切换到 Bun 的原生 `bun.serve()` API，进一步将性能翻倍。随后的分析（第三阶段）识别并修复了与 Zod 验证、头部处理和调试日志记录相关的热点，将 CPU 使用率提高了 40%。最后，编译成单个二进制文件（第四阶段）又将吞吐量提高了 14%，并将镜像大小从 180MB 减少到 68MB。
一个关键发现是 Bun 的 HTTP 模型中存在内存泄漏：来自断开连接的客户端的未解决的 Promise。修复此问题稳定了内存使用并进一步提高了性能。该团队强调分析的重要性，在每个步骤进行基准测试，并理解 Bun 独特的 HTTP 生命周期。他们还为常见的 Bun 问题创建了一个调试技能。
对不起。