(Empty input provided. There is nothing to translate.)
每日HackerNews RSS
## CodeMic：分享与探索编码过程
CodeMic (codemic.io) 是一款新的开源工具，用于录制和分享包含音频、视频和图像的完整编码过程，类似于 Asciinema，但更具互动性。与传统的视频教程不同，CodeMic 允许观众暂停、在自己的编辑器中探索代码、修改代码，甚至在播放过程中运行代码。
开发者 SeanSh 已经开发 CodeMic 超过两年，并正在寻求反馈。用户 JaumeGreen 赞扬了该概念，但指出在 SteamOS 上 VSCode 的兼容性问题，并建议添加双视频流（演讲者和演示）。SeanSh 回复说，愿意解决兼容性问题，并承认双视频流的想法是一个潜在的改进。
本质上，CodeMic 旨在使从代码库中学习和理解变得更实用和更具吸引力。
## SHDL：逻辑门电路仿真
SHDL是一种轻量级的硬件描述语言和Python驱动（PySHDL），专为仿真完全由逻辑门构建的数字电路而设计。它提供了一种直观的语法来定义电路，以及一个无缝的Python API来进行交互，从而实现轻松的测试和分析。
主要特性包括：用于快速和可移植仿真的C后端、命令行编译工具，以及对可重用电路组件和常量的支持。用户在`.shdl`文件中定义电路，将其编译为C，然后通过Python使用诸如`poke`（设置输入）、`peek`（读取输出）和`step`（推进仿真）等方法与其交互。
SHDL仍在开发中，欢迎用户通过GitHub issues、讨论、pull requests或直接邮件提供反馈。它需要Python 3.10+和一个GCC或兼容的C编译器。该项目旨在易于使用，并为实验、教育和个人项目提供价值。
## SHDL：一种极简硬件描述语言
Rafael Rayes 创建了 SHDL（简单硬件描述语言）作为一个实验，旨在探索硬件描述最基本的形式——直接由逻辑门和导线构建。与 Verilog 或 VHDL 等语言不同，SHDL 故意缺乏算术运算符、隐式位宽和高级结构，迫使用户从基本组件分层构建所有内容。
目标不是实际的综合或性能，而是*理解* 在去除抽象后数字系统如何工作。SHDL 利用 Python 接口 (PySHDL) 进行仿真，将电路编译为 C 以实现快速执行。
Rayes 寻求对语言设计选择、限制与教育价值之间的平衡以及这种“反抽象”方法对学习和实验的整体实用性的反馈。该项目旨在帮助学习数字逻辑、HDL 设计探索以及可视化硬件复杂性。例如，全加器、16 位寄存器和进位加法器等示例在项目的 GitHub 仓库中提供：[https://github.com/rafa-rrayes/SHDL](https://github.com/rafa-rrayes/SHDL)。
## 自旋锁：痛苦的根源
本文详细描述了作者反复遇到糟糕的自旋锁实现——循环重复检查资源是否可用——以及为什么应该尽量避免使用它们。尽管已经有大量资源涵盖了自旋锁的陷阱，但问题仍然存在。
核心问题是什么？ 简单的自旋锁在等待时浪费 CPU 周期，影响性能和能源效率。 即使是看似正确的原子操作实现，也可能遭受竞态条件、优先级反转（高优先级线程被低优先级线程阻塞）和缓存争用的影响。
解决方案包括使用 `PAUSE` 指令和指数退避等技术来减少浪费的周期。 然而，即使这些也需要根据 CPU 架构进行仔细调整。 作者强烈建议利用操作系统原语，如 futexes（Linux）或 `WaitOnAddress`（Windows），这些原语允许操作系统有效地管理等待线程。
最终，信息很明确：自旋锁复杂且容易出错。 除非你*真的*知道自己在做什么，并且有一个特定的、低竞争的使用场景，否则完全避免它们，并依赖于成熟的、操作系统提供的同步机制。 许多项目（RPMalloc、OpenBSD libc，甚至 .NET 的一部分）已经证明了正确实现自旋锁的困难。
## 解决远程设备管理挑战 在众多客户站点管理设备时，家庭路由器普遍使用默认且重叠的子网（如192.168.1.0/24）使得情况复杂化。这会产生路由冲突，使可靠的远程访问变得困难——特别是对于固件固定且缺乏VPN功能的设备。传统的解决方案，如端口转发不可靠（ISP调制解调器重置会破坏配置，难以处理RTSP等多端口协议），而子网路由在地址重叠时会失败。重新配置客户网络是不切实际的。 解决方案在于**使用1:1 NAT的覆盖寻址**。这为每个远程设备分配一个唯一的、全球可路由的IP地址，该地址位于保留范围内（100.64.0.0/10），独立于其本地IP。客户局域网上的网关设备通过WireGuard隧道在“覆盖”地址和本地地址之间进行转换。 这种方法消除了冲突，增强了安全性（没有暴露的端口），并简化了管理。像Netrinos这样的系统可以自动执行密钥生成、NAT规则部署和DNS分配，跨数百个站点实现安全可靠的远程访问，而无需更改客户网络或设备固件。这已在生产环境中成功管理数千个设备。
## Netrinos 与 192.168.1.x 问题
这次 Hacker News 讨论围绕一篇博客文章展开，文章详细介绍了一种解决连接大量客户网络时常见问题的方法：私有 IP 地址范围重叠（特别是 192.168.1.x）。 核心问题在于需要访问这些网络后 NAT 设备。
提出的解决方案利用基于 Linux 的堆栈（WireGuard、nftables、Go）创建一个带有 NAT 的 VPN 叠加层，从而有效地隔离每个客户的网络。 虽然存在更复杂的解决方案，如 VRF/EVPN，但这种方法优先考虑自动化和易用性，避免了对专业网络知识的需求。
许多评论者强调 IPv6 是理想的长期解决方案，可以消除地址冲突。 然而，实际限制——特别是旧设备或低成本设备缺乏 IPv6 支持以及 ISP 实现不一致——需要变通方法。 讨论中还包括服务器端使用 IPv6 的 NAT64 等替代方案。
对话强调了网络的“人为因素”——与各种 ISP 和客户设置协调的困难。 最终，讨论指出需要在优雅的解决方案（IPv6）和解决当前现实约束的实用方法之间进行权衡。
## OpenCHM启动，数字化计算机历史 计算机历史博物馆（CHM）已启动OpenCHM，一个新的数字门户，向全球开放其广泛而独特的计算文物收藏。该倡议由戈登和贝蒂·摩尔基金会和其他捐助者资助，标志着CHM持续数字化工作的重要一步。 OpenCHM旨在激发好奇心，并使技术历史对所有人开放，从研究人员到普通大众。该平台具有高级搜索工具、CHM历史学家的精选故事以及标志性文物的亮点。用户还可以创建个性化收藏，对于开发者而言，还可以访问API以进行进一步探索。 摩尔基金会赞扬了OpenCHM周到的设计和对开放获取的承诺，希望它能鼓励类似的倡议。通过保护和分享计算机历史，OpenCHM 推进了CHM的任务，即培养知情的数字公民并塑造更美好的未来。新的材料将不断添加到该平台。
计算机历史博物馆（CHM）最近推出了其庞大馆藏的数字入口，在Hacker News上引起了热烈讨论。用户分享了特定领域的链接，例如复古营销材料、讲座和口述历史。虽然该入口因其丰富的资料而受到赞扬，但讨论也指出了需要改进的地方。
一些评论员提到，除了静态图像外，还希望有模拟器和互动体验，并以Smalltalk Zoo为例。另一些人指出历史叙述中存在空白，建议纳入硅谷之前的早期计算工作，例如范内瓦尔·布什和美国国家安全局的OP-20-G项目。
许多人分享了参观CHM以及已关闭的Living Computers Museum + Labs的个人经历，强调了亲眼目睹历史技术的重要性。一些用户还指出了小问题，例如图像分辨率低和搜索限制（特别是关于TRS-80的搜索）。总的来说，反应是压倒性积极的，用户认为CHM是保存和分享计算机历史的宝贵资源。
## LM Studio 0.4.0：重大更新 LM Studio 0.4.0 引入了重大改进，专注于部署灵活性和性能。一个关键功能是 **llmster**，一个允许无头部署的守护进程——在服务器、云实例甚至通过命令行*无需* GUI 即可运行 LM Studio。 此版本支持**并行请求**和持续批处理，以实现更快的处理速度，以及一个新的**状态化 REST API** (/v1/chat)，用于将本地模型集成到应用程序中。用户界面已完全刷新，具有聊天导出（PDF、Markdown）、**分屏视图**用于多个聊天、**开发者模式**用于高级选项以及应用内文档等功能。 底层的 **llama.cpp 引擎已更新至 v2.0.0**，支持并发推理。新的 CLI 体验，通过 `lms chat` 提供基于终端的交互。现在可以使用**权限密钥**来控制服务器访问。 此更新优先考虑强大的后端功能和简化的用户体验，为本地 LLM 使用提供更大的控制力和效率。
## LM Studio 0.4 讨论 - 摘要
Hacker News 的讨论围绕 LM Studio 0.4，这是一款在本地运行大型语言模型的工具。一个关键更新是引入了功能齐全的命令行界面（“llmsterm”），允许无头操作——这是用户一直要求的功能。这解决了之前 CLI 需要桌面应用程序运行的限制。
用户将 LM Studio 与 Ollama 和 llama.cpp 等替代方案进行比较。一些人认为 Ollama 偏离了其最初的原则，并且缺乏及时的模型支持。LM Studio 被认为是一个有希望的替代方案，特别是有了新的 CLI。
对话强调了对本地 LLM 兴趣日益浓厚，原因不仅仅是隐私（尽管这也是一个因素）。这些原因包括控制、稳定性、认知安全以及运行专用模型或离线处理敏感数据的能力。虽然承认基于云的模型目前提供卓越的性能，但许多人认为本地运行的模型“足够好”用于各种任务，尤其是在模型效率不断提高的情况下。
讨论还涉及开源格局，Jan.ai 被建议作为替代方案，以及对更多面向专业用户的 LLM 前端，并具有高级控制选项的需求。
汇丰银行发了一封令人担忧的信，声称邮件“无法送达”，促使作者检查了自己的账户——结果邮箱地址已经正确。与客服沟通一小时后，得到的令人沮丧的回应是，即使地址有效，也*必须*更新。
深入调查后，作者发现汇丰银行在其邮件中使用跟踪像素来监控邮件打开情况。这些像素通过未加密的连接不安全地实施，揭示了他们依赖这种有缺陷的跟踪方法来验证邮件送达。由于作者为了保护隐私而屏蔽了这些像素，汇丰银行错误地将他们的邮件标记为未送达。
这凸显了一个令人不安的趋势：假定跟踪是万无一失的，并在跟踪失败时做出不准确的声明。作者批评了汇丰银行具有侵入性的监控行为、糟糕的安全措施以及具有误导性的沟通方式，并建议简单的邮件确认将是一种更安全、更透明的解决方案。最终，这起事件揭示了普遍存在的监控资本主义如何扭曲基本功能并侵蚀信任。
## 汇丰银行邮件追踪缺陷及更广泛的银行业问题
最近在Hacker News上分享的一则经历揭示了汇丰银行邮件实践中的一个奇怪问题：如果追踪像素未加载，银行会发送信件声称邮件无法送达。即使邮件*已*被接收，也会发生这种情况，因为像Gmail这样的服务会预加载图片，从而有效地掩盖了用户是否实际打开了邮件。
几位评论员报告说，其他银行如澳大利亚国民银行（NAB）和Capital One也出现了类似问题，这表明这不是个别事件。讨论的重点在于依赖不可靠追踪像素的站不住脚的逻辑，以及大型金融机构内部的官僚流程，这些流程允许这种有缺陷的“功能”得以实施。
除了技术问题外，该帖子还涉及对银行业务更广泛的担忧，包括客户账户的价值、对数据追踪的依赖（“监控资本主义”）以及许多银行提供的在线服务的普遍质量较差。一些人建议更换银行作为解决方案，而另一些人则认为系统性问题使得避免这些问题变得困难。追踪像素使用不安全的HTTP链接也引发了安全问题。
该项目详细介绍了使用软件工具和少量编程创建3D打印灯罩的过程。受类似设计的病毒式视频启发，制作者旨在基于Desmos中生成的复杂波动2D轮廓（公式为`r = cos(5θ) + 0.2cos(9θ) + 0.05cos(200θ) + 4`）构建灯罩。
最初，由于轮廓过于复杂（1047个点）导致OnShape中的“loft”操作难以实现，并导致崩溃。随后，制作者利用ChatGPT生成了一个Python脚本，将2D轮廓缩放到一个点，从而创建了所需的形状。
目前，生成的巨大STL文件正在进行3D打印。该项目还包括转换为Marimo笔记本，允许在网页浏览器中直接可视化灯罩的横截面和轮廓，而无需安装Python。
## 3D打印数学灯罩 - Hacker News 总结
一位 Hacker News 用户分享了一个项目，该项目基于数学函数创建灯罩，使用 Python 生成并进行 3D 打印。讨论迅速扩展到各种 CAD 软件选项的比较。
许多评论者赞扬了这个项目，并分享了他们使用 **OnShape、Blender、OpenSCAD、FreeCAD 和 CadQuery** 等工具的经验。特别是 OpenSCAD，被频繁提及，并建议使用 **Belfry** 库以简化建模。一些人强调了使用 **Manifold 引擎** 的 OpenSCAD 夜间版本在速度上的提升。另一些人正在探索 **build123** 等替代方案。
对话还涉及实际考虑因素，例如材料选择——由于 LED 灯条产生的热量，建议使用 **PETG 或 ASA，而不是 PLA**。一个关键的收获是可以跳过 STL 格式，直接从数学定义生成 **G 代码**，从而可能获得更好的结果。最后，人们也注意到像 **Claude** 这样的人工智能工具可以根据图像生成 OpenSCAD 代码。
## Mousefood：嵌入式系统的Ratatui后端
Mousefood是一个no-std嵌入式图形后端，旨在将Ratatui终端框架带到资源受限的环境中。它允许您在ESP32、STM32和RP2040等设备上构建终端UI。
默认情况下，Mousefood使用`embedded-graphics-unicodefonts`以获得更广泛的字符支持，克服了嵌入式系统中常见的基本位图字体限制。字体使用可以自定义——包括粗体和斜体样式——或禁用以优化性能。颜色主题也可配置，提供ANSI和Tokyo Night预设等选项，或自定义RGB调色板。
Mousefood支持各种显示类型，包括标准LCD和WeAct Studio和Waveshare的E-ink显示器（EPD），需要特定的驱动程序配置。可以使用`embedded-graphics-simulator` crate进行测试。
建议使用编译器级别3进行优化，以提高性能，并认识到由于字体数据而可能导致二进制文件大小增加。Mousefood正在积极开发中，欢迎贡献，并采用Apache 2.0和MIT双重许可。 多个项目已经利用Mousefood，包括Tuitar和Mnyaoo32。
## Mousefood：Rust 中的嵌入式终端 UI
一个新的 Rust crate，**Mousefood**，可以使用流行的 Ratatui 库为微控制器构建基于终端的用户界面。这允许开发者在 ESP32、Raspberry Pi Pico 和 STM32 等设备上创建基于文本的 UI，甚至包括电子墨水显示屏。
讨论的重点在于嵌入式系统中基于文本的图形与直接像素操作的效率。虽然较早的字符硬件依赖于专用的字符生成器，但现代位图显示屏提供了灵活性。然而，利用基于文本的方法仍然可以高效，因为存储和渲染固定大小的矩形很简单。
该项目利用 `embedded-graphics` 库，并与现有的嵌入式 Rust 应用程序和框架（如 Embassy）兼容。它似乎也支持 CYD（廉价黄色显示屏）等显示屏，触摸屏集成方面可能存在挑战。 许多用户对将复古终端美学带到嵌入式设备表示兴奋，让人想起 *The Last Ninja* 等游戏和 ComputerCraft 等工具。
最近的一份谷歌漏洞报告意外地首次展示了代号为“Aluminum OS”（ALOS）的Android桌面界面，运行在惠普Elite Dragonfly Chromebook上。泄露的截图展示了Android 16，针对更大屏幕进行了优化，顶部状态栏显示了详细信息，如时间、日期和系统图标（电池、Wi-Fi、Gemini）。
界面保留了当前任务栏和窗口控制等熟悉元素（类似于ChromeOS），但也有一些微妙的变化——修改过的鼠标光标和Chrome浏览器扩展按钮。泄露还演示了分屏多任务处理功能。这一发展表明谷歌正在利用现有的Chromebook硬件来构建和测试桌面Android体验，超越了平板电脑和手机投屏模式。识别出的构建编号是ZL1A.260119.001.A1。