## RCade：Recurse Center 的社区街机
RCade 是 Recurse Center 打造的一款定制街机柜，用于展示其社区成员创作的游戏。该项目灵感来自 Greg Sadetsky 的交互式 Rapid Riter 显示屏，旨在创造一种具有复古吸引力的独特、易于访问的游戏体验。
该街机柜配备了以 320x240 分辨率运行的真 CRT 显示器、定制显卡以及独特的输入控制器，包括滚轮。其关键特性是简化的部署系统：Recurse Center 的成员只需推送到 GitHub 即可发布游戏。为了支持远程参与，还提供了一个网页播放器和一个本地模拟器。目前，已有超过 44 款游戏可供游玩。
RCade 的构建涉及克服与老式 CRT 接口和开发用于社区代码的安全沙箱环境等挑战。Stephen D 构建的定制显示适配器可提供 60fps 的 24 位色彩。身份验证利用 GitHub OIDC 实现安全、无密码部署。
RCade 促进了协作和创造力，游戏内容从 Etch A Sketch 的重现到独特的多人游戏体验不等。它体现了 Recurse Center 的探索精神和社区驱动的项目理念，为成员提供了一种切实的贡献和联系方式。该项目的源代码可在 GitHub 上找到，鼓励进一步贡献。
每日HackerNews RSS
## RCade：社区街机柜
由Recurse Center打造的全新社区街机柜RCade正在网络上引起关注。该项目专注于重现街机体验，采用定制机柜，配备独特的CRT显示器，支持18位色彩和通用USB接口。
讨论中强调了建造者Frank高超的技术水平，以及该项目对街机保护（保留原始CRT）和创新（定制显示适配器和软件）的投入。虽然有人建议使用树莓派进行模拟，但RCade团队优先考虑超越标准街机限制。
RCade并非广泛开放，但会不定期举办公开活动（录像可在Recurse Center的YouTube频道上找到）。与RCade相关的是Wondercab，一种开源街机柜设计，但目前尚未提供易于获得的建造计划。软件方面包括CLI、SDK、桌面模拟器和部署基础设施，最初被一位评论员贬为“网络垃圾”，但随后被辩护为大量开发工作。 还有人提出了通过Microsoft Edge与SteamOS集成的可能性。
## 构建更快的语音代理：深入研究
在为一家大型消费品公司使用语音代理超过六个月后，作者发现，虽然Vapi和ElevenLabs等现成平台简化了开发，但它们掩盖了显著的复杂性。受到GPT-5.3和Claude 4.6等模型的最新进展的推动，他挑战自己从头开始构建一个可比的编排层。
令人惊讶的是，他成功了——在一天内创建了一个功能性的语音代理，API成本约为100美元。这种定制构建在**延迟方面比Vapi快2倍**，实现了约400毫秒的端到端响应时间。
关键在于理解语音代理本质上是一个**编排问题**，需要精确的 timing 和对语音到文本 (STT)、大型语言模型 (LLM) 和文本到语音 (TTS) 的持续管理。至关重要的是，**地理位置很重要**——将服务 collocating 可以大大降低延迟。利用Groq的llama-3.3-70b模型进一步优化了速度。
作者强调了**管道化**每个阶段以最小化延迟的重要性，**取消飞行中的请求**以实现无缝中断，并优先考虑来自LLM的**首次标记时间 (TTFT)**。虽然平台提供便利，但理解底层循环可以使开发人员优化性能并构建真正响应迅速的语音体验。该项目的代码可在GitHub上获取。
## 低于500毫秒延迟语音代理：摘要
Nick Tikhonov 从头开始构建了一个语音代理，实现了约400毫秒的端到端延迟——从语音输入到第一次语音响应。实现这一速度的关键在于将语音交互视为“轮流发言问题”，而不仅仅是转录。
该系统以连续的听和说循环运行，优先考虑即时响应和插话取消。所有组件（STT、LLM、TTS）的流式处理至关重要，因为顺序处理会引入不可接受的延迟。最大的性能提升来自于使用Groq的低延迟TTS（约80毫秒）。所有组件的地理位置接近也很重要。
作者强调，最小化延迟需要一种整体方法，专注于编排和管道优化。该项目的代码可在GitHub上找到 ([https://github.com/NickTikhonov/shuo](https://github.com/NickTikhonov/shuo))。评论中的讨论强调了实现类似人类的对话流程的挑战，以及生产系统中延迟和功能复杂性之间的权衡。
## Meta 的 AI 眼镜：隐私的代价？ Meta 新推出的 AI 驱动眼镜，广告中使用了彼得·福斯贝里，被宣传为智能手机的替代品——提供实时翻译、协助以及无缝捕捉生活瞬间的功能。然而，《瑞典日报》和《哥德堡邮报》的调查揭示了一个隐藏的代价：大量的数据收集和处理，主要外包给肯尼亚等低收入国家的工人。 这些“数据标注员”通过标记眼镜捕捉到的图像和视频来手动训练 AI，这些内容通常包含高度私密的信息——包括用户家中亲密时刻。工人们报告称，他们观看过人们换衣服、在浴室以及进行性活动的录像，引发了严重的隐私担忧。 尽管 Meta 声称用户拥有控制权并对数据进行匿名化处理，但调查发现存在不一致之处。销售人员通常缺乏关于数据处理的知识，并且匿名化并不总是有效的。此外，眼镜需要持续的数据传输才能运行，并且 Meta 的条款允许人工审查用户互动。 专家质疑用户对数据收集范围和潜在风险的认知程度。尽管有 GDPR 法规，但调查强调了缺乏透明度，并对 Meta AI 革命中的数据安全和伦理外包实践提出了质疑。
## Roughtime 服务器性能提升：类型提示的故事
最近一个 Roughtime 协议的开源实现，该协议旨在实现安全的时间同步，通过一个看似微不足道的代码更改，获得了令人惊讶的 13 倍吞吐量提升。该服务器处理涉及排队、16 个版本之间的协议兼容性、Merkle 树构建和 Ed25519 签名等请求——所有这些都是计算密集型任务。
然而，初步分析显示，90% 的请求时间都花在一个简单的计算字节数组长度的函数中。尽管通过了测试且没有反射警告，但 `mapv` 函数的动态分派和运行时类型检查引入了显著的开销。
修复方法？添加一个类型提示 (`fn [^bytes v] (alength v)`)，告知编译器字节数组的类型。这使得编译器能够发出单个高效的字节码指令，而不是复杂的函数调用链。
虽然隔离测试显示性能提升了 8 倍，但端到端基准测试表明性能提升了 13 倍，这可能是由于减少了反射调用路径中的竞争，并改进了 JIT 优化。这表明在 Clojure 中，没有反射警告并不能保证最佳性能，并且分析对于识别意外的瓶颈至关重要——即使是在“简单的”代码中。
## Clojure 类型提示带来的 185 微秒性能提升
sturdystatistics.com 上的一篇最新博文详细介绍了一种通过添加类型提示在 Clojure 代码中实现的令人惊讶的性能改进。作者观察到显著的加速——将执行时间减少到 185 微秒——通过指定字节数组的类型来实现。
最初的解释认为编译器将代码优化为单个 CPU 指令。然而，Hacker News 评论区的讨论表明这可能过于简单化。专家指出，字节码可能仍然包含带有潜在异常处理的类型转换，而加速很可能归功于 JIT（即时编译）编译器优化。
具体来说，添加类型提示允许 JIT 编译器假设类型，从而实现类型保护以及在没有提示的情况下不可能进行的内联或循环展开等优化。作者承认需要检查发出的字节码以获得明确的解释，并表达了对像 Clojure 这样高级语言通过 JIT 优化实现令人印象深刻的性能的潜力感到兴奋。该帖子还提到了“Roughtime”协议，这是一种用于密码学可验证时间的系统，用于加固许可证服务器。
``` 0xPARC ``` (This remains the same as it's a technical identifier.)
## 可编程密码学：摘要
一篇近期在Hacker News上的文章讨论了“可编程密码学”——即创建足够灵活的密码系统，以组合和扩展现有协议，用于新的应用。尽管承认密码学原语方面的进步，评论员们对“通用协议”方法表示怀疑，并将其与JSON对通用互操作性的有限影响相提并论。
核心概念在于构建能够表达复杂逻辑的API，例如“如果X发生，则允许Y”，从而实现不同系统之间的无缝集成。然而，人们对设计快速且被广泛采用的密码学栈的实用性表示担忧。
讨论的重点是年龄验证等用例，零知识证明（ZKPs）可以在此提供隐私优势，但目前受到计算成本和潜在滥用（凭证共享）的阻碍。一些人认为，使用政府颁发的证书的更简单的非对称加密解决方案可以实现类似的结果。另一些人指出，许多提议的解决方案仍然依赖于可信设置或速度太慢而无法通用。
最终，这场辩论凸显了可编程密码学的理论潜力与实施和采用的实际挑战之间的紧张关系，许多人认为当前成熟的方法足以满足大多数需求。
十多年来，作者一直持续遇到macOS中挥之不去、无法解决的bug，需要完全重置系统才能修复。这些问题涵盖核心功能：Time Machine备份反复失败，Spotlight搜索变得不可靠（经常需要重启Finder），Finder难以显示更新的文件夹内容，AirPods Pro和Quick Look出现音频故障，以及全屏空间中窗口焦点不一致。 这些并非孤立事件；解决方案通常可以在苹果自己的论坛上找到，而且这些问题在多个操作系统版本和Mac上仍然存在。作者对苹果优先考虑表面设计而非解决这些根本、长期存在的问题感到沮丧。 尽管拥有强大的苹果硬件，作者由于报道的不稳定性而犹豫是否升级到最新macOS版本（Tahoe）。他们质疑苹果优先考虑用户体验和稳定性的能力，特别是像逐步淘汰Rosetta 2这样的决定。最终，作者希望苹果内部的核心团队仍然重视平台的历史，并倡导回归优先考虑质量和用户需求，而不是短暂的设计趋势。
## Boss-CSS：一种多态的样式方案 Boss-CSS是一个灵活的“CSS-in-JS”库，源于22年的Web开发经验以及克服现有样式方案局限性的愿望。作者对原生CSS、预处理器、BEM等方法论、CSS Modules甚至Tailwind的权衡感到沮丧，寻求一个能提供所有优势的系统。 Boss-CSS的独特之处在于其**多态性**——支持多种CSS应用方式，无论有无运行时环境，都能根据项目需求进行定制。它允许开发者以熟悉的方式编写CSS（基于属性、类名、对象、原生CSS），并提供各种提取策略，从内联样式到类似Tailwind的类名生成。 主要特性包括强大的插件系统、TypeScript支持、AI准备就绪以及框架无关性，这得益于利用PostCSS而不是依赖特定的编译器集成。一个独特的“Bosswind”插件提供了类似Tailwind的简写。重要的是，Boss-CSS可以配置为零运行时依赖，编译为原生元素和样式。 虽然目前仍处于早期Alpha阶段，作者希望该项目能激励他人，并可能获得社区支持以进行进一步开发。该库旨在赋予开发者控制权和灵活性，让他们“掌控自己的CSS”。
一位开发者最近在Hacker News上发布了“Boss-CSS”，这是一个新的“CSS-in-JS”库，最初几年前开始开发，最近在AI的帮助下完成了润色。该库的独特之处在于其灵活性，支持各种应用CSS的方法，有或没有运行时处理。
作者不打算积极维护，除非有社区兴趣，希望分享这项工作，而不是让它被闲置。这次讨论引发了关于CSS工具的对话，评论者们指出对Tailwind CSS配置（特别是`line-height`）的 frustations，并分享了像“preact-css-extract”这样的替代项目，旨在实现原子CSS，而无需大型CSS文件。
一位评论员认为，对CSS-in-JS性能的担忧被夸大了，应该优先考虑开发者体验（DX）。
从你的钢琴Linux CLI工具运行shell命令，将shell命令分配到USB MIDI键盘上的按键。注意：假定使用ALSA作为声卡驱动。使用acconnect -i查找所需的midi端口。 $HOME/.config/pianoterm/config # 这是一条注释 # 触发可以是on_release或on_press on_press # 语法：端口 = 命令 # 使用aseqdump -p <端口>查找特定的键码 21 = playerctl previous # 88键键盘上的第一个键 22 = playerctl play-pause 23 = playerctl next # ... 108 = /home/me/my_script.sh git clone https://github.com/vustagc/pianoterm.git cd pianoterm && make C编译器 alsactl (1.2.15.2) make (可选)
## Pianoterm：通过钢琴执行 Shell 命令
一个名为“Pianoterm”的新项目（github.com/vustagc）允许用户直接从钢琴或 MIDI 键盘执行 shell 命令。该工具将 MIDI 键按下映射到 shell 命令，有效地将钢琴变成一个可定制的宏键盘。
最初的目的是用于暂停/播放/倒带音乐学习，但用户很快指出了更广泛的应用。类似 BOME Midi Translator 和 `smhkd` 的工具已经存在，但 Pianoterm 提供了一种更简化的方法。想法包括控制 DAW 软件和视频编辑，以及管理音量、亮度甚至相机控制等系统设置。
该项目使用一个简单的配置文件进行按键映射，避免了为了定制而修改代码的需要。讨论强调了其在创意开发工具方面的潜力，甚至包括通过音乐序列输入密码等趣味应用——参考了电影《夺宝奇兵》。这是一个有趣的周末项目，激发了人们对 MIDI 控制器超出其音乐用途的重新利用的想法。
## LFortran 编译 fpm，向 Beta 版本迈进 LFortran 成功编译了 Fortran 包管理器 fpm——迄今为止最复杂的项目，标志着其向 Beta 版本发布迈出了重要一步。这项成就历时从 2025 年 4 月到 2026 年 2 月，暴露并解决了 LFortran 中的数十个错误和缺失的功能，将其内部 Beta 就绪度提升至 9/10。 编译 fpm 突显了改进的需求，尤其是在类处理、虚函数和继承方面，促使 LFortran 进行了一次受 Clang 的 C++ 实现启发的重构。LFortran 现在也支持 fpm 的关键依赖项（M_CLI2、toml-f、fortran-regex、fortran-shlex 和 Jonquil）。 目前，LFortran 可以可靠地编译最多约 1000 行的代码，目标是大型项目达到 90% 的成功率。性能分析表明，将 LLVM IR 编译为二进制代码是主要的瓶颈，计划开发自定义后端以实现潜在的 10 倍加速。剩余的任务包括实现协数组和参数化派生类型，目标是在 Beta 版本发布后几个月内完成。LFortran 仍处于 Alpha 阶段，积极寻求贡献者以进一步完善和扩展其功能。