ZhuLink ZhuLink
登录

【HN中文日报】科技圈炸了！Rust横扫GPU、CSS干翻SPA、AI代写要凉？还有开源神器复活老古董！

意外富翁 · 5个月前 · News · 17 · 0

今天 Hacker News 社区聊了啥？ NO.20250726

这期日报信息量爆炸！Rust 强势崛起，一套代码通吃所有GPU，简直逆天！现代CSS要革SPA的命，网页性能起飞！AI代写被大佬怒怼，真诚写作才是王道！还有创客大神用开源软件复活老旧导航仪，DIY精神燃爆！想知道更多？赶紧戳进来，带你一网打尽科技圈最新鲜、最劲爆的资讯！

Hacker News 中文精选

Rust 代码在所有 GPU 上的运行

本文介绍了如何使用 Rust 编写一套通用的代码，使其能够在包括 NVIDIA 的 CUDA、AMD/Intel/NVIDIA 的 Vulkan (SPIR-V)、Apple 的 Metal、Windows 的 DirectX 12、浏览器 WebGPU 以及 CPU 在内的所有主流 GPU 平台上运行。核心在于使用标准 Rust 代码直接编译到 GPU 目标，无需使用专门的着色器或内核语言。

文章详细阐述了实现跨平台 GPU 计算的三个关键项目：Rust GPU（将 Rust 代码编译为 SPIR-V）、Rust CUDA（将 Rust 代码编译为 NVVM IR）和 Naga（一个 GPU 语言翻译层，支持 WGSL、SPIR-V、GLSL、MSL 和 HLSL 之间的转换）。作者作为 Rust GPU 和 Rust CUDA 的维护者，以及 naga 的贡献者，致力于将这些项目整合在一起。

该演示程序实现了一个简单的 bitonic sort 算法，其计算逻辑是完全通用的，并在 CPU 和 GPU 上运行相同的代码。文章还解释了后端选择的机制，通过 Rust 的 feature flags 和编译目标来选择不同的后端和驱动 API，例如 wgpu、ash 和 cuda。此外，文章还介绍了内核编译的过程，内核被编译为适用于特定 Rust features、目标操作系统和驱动 API 的设备格式，并在构建时嵌入到二进制文件中。

文章还深入探讨了幕后发生的事情，例如使用 rustc_codegen_spirv 将 GPU 内核编译为 SPIR-V，然后使用 naga 将其翻译为平台所需的着色语言。

由于没有评论内容，这里跳过评论分析。

CSS 中的 font-size-adjust 属性的妙用

本文探讨了 CSS 中 font-size-adjust 属性的用途，并提出了与主流观点不同的使用建议。作者认为，该属性的价值不仅在于处理字体回退问题，更在于统一网页中不同字体的显示效果，即使在没有字体回退的情况下也能发挥作用。

文章首先解释了 font-size 的工作原理，指出它实际上定义的是字体周围的盒子大小，而不是字形本身的大小。因此，不同字体的相同 font-size 值可能导致字形大小差异很大。font-size-adjust 允许开发者指定字形（例如 "x" 字母的高度）与字体大小的比例，从而使不同字体在视觉上更加一致。

目前，font-size-adjust 主要被认为是在字体回退时保持页面外观一致性的工具。作者对此提出了不同看法，他认为更重要的是利用 font-size-adjust 来统一网页中使用的各种字体的显示效果，并建议将其添加到 CSS reset 中，就像 box-sizing: border-box 一样。作者建议使用 0.53 作为 ex-height 的比例，因为这是 Helvetica 字体的比例，但其他相近的数值也可以。

评论区也出现了一些有趣的讨论。

有人询问 font-size-adjust 与 text-box-trim 的区别。也有人反对为了避免 FOUC（Flash of Unstyled Content）而将整个字体内联的做法，认为这会降低每个页面的加载速度。另有评论者质疑，为了避免 FOUC 导致的页面重绘，而让用户长时间面对空白页面是否值得。还有人表示 font-size-adjust 在需要使用字体和 emoji 作为图标的游戏开发中非常有用，因为它能保证视觉上的一致性。

使用开源软件复活老旧自行车导航仪

本文介绍了如何利用开源软件，特别是 NaVeGIS 和 OpenStreetMap，让一台 2015 年的 Navman Bike 1000 自行车导航仪焕发新生，摆脱官方地图停止更新的困境。 这篇文章的核心在于作者通过逆向工程发现该设备运行 Windows CE 6.0，并利用 Total Commander 和 NaVeGIS 结合 OpenStreetMap 项目的最新地图，成功实现了导航功能。

作者首先提到这款设备虽然硬件完好，但官方停止地图更新，面临“计划报废”的窘境。 他强调了使用开源方案的优势，即使当前地图提供商停止服务，用户仍然可以自行制作地图。 文章还展示了在这台设备上运行 DOOM 的有趣尝试。 作者还批评了厂商不愿为旧设备提供地图更新的行为，以及缺乏要求厂商开源停售设备软硬件的法律。 通过使用 mitmproxy 抓包分析，作者发现了设备连接更新服务器的地址，虽然找到了更新包的地址，但已经无法下载。

总而言之，这篇文章展示了如何通过开源技术克服硬件过时的问题，赋予旧设备新的生命力，同时也引发了关于厂商支持和电子垃圾问题的思考。

突破 WASM/JS 通信性能瓶颈：Sledgehammer Bindgen

这篇文章主要介绍了 sledgehammer_bindgen，一个旨在突破 WebAssembly (WASM) 和 JavaScript (JS) 之间通信性能瓶颈的工具。该工具通过优化数据在 WASM 和 JS 之间的传递方式，显著提升了性能。

sledgehammer_bindgen 的核心思想是减少不必要的数据拷贝和序列化/反序列化过程。它允许 WASM 和 JS 之间直接共享内存，从而避免了传统方法中昂贵的跨界数据传输。通过这种方式，可以大幅降低通信延迟，提高 Web 应用的整体性能。

该项目在 GitHub 上开源，提供了详细的文档和示例，方便开发者上手使用。它支持多种数据类型，并提供了灵活的配置选项，以满足不同应用场景的需求。sledgehammer_bindgen 的出现，为构建高性能的 Web 应用提供了新的可能性，尤其是在需要频繁进行 WASM 和 JS 交互的场景下，例如游戏、图像处理和科学计算等。

目前没有评论内容。

Open Sauce：一场汇聚创客与科技爱好者的盛会

Open Sauce 是一个由 William Osman 策划的，类似于 Bay Area maker faire 的活动，吸引了众多创客和科技爱好者。活动涵盖了从疯狂科学到复古电子产品，再到游戏和速解魔方等各种各样的主题。

文章作者连续两年带他的父亲参加 Open Sauce，并分享了他在活动中的所见所闻。活动现场聚集了各个年龄段的人，他们都在建造各种奇特的装置，既有实用的，也有非常不切实际的。与其它创客大会不同的是，Open Sauce 吸引了许多来自 YouTube 的创客和爱好者。作者有幸见到了正在修复旧 HP 铯原子钟的 CuriousMarc，以及 TubeTime 和 Ken Sheriff 等正在摆弄阿波罗时代硬件的爱好者。

作者还录制了三个视频博客，记录了 Open Sauce 的各种展位和人物。其中，Day 0 的亮点是一个可以平稳行走的咖啡桌，并且里面还藏有一个冷却器。在 Day 1，作者与许多只在网上互动过的人见了面，并与 Meshtastic、ADSBee 和 Framework 的工作人员进行了交流。作者还参加了一个关于逆向工程的 YouTube 内容创作者小组讨论。最令人意外的是，作者遇到了 NASA 宇航员 Matthew Dominick，他表示自己一直在观看关于 Proxmox 和 TrueNAS 的视频，目标是构建一个家庭实验室来处理他在国际空间站上用尼康相机拍摄的约 20 TB 的 RAW 照片。

作者对 2026 年的 Open Sauce 充满期待，并希望活动能够保持其最初的精神。

评论区里，有人觉得 Open Sauce 只是“还行”，像是一个有 YouTuber 在旁边搭台的创客集市。他们认为， William Osman 作为主持人在提问环节做得不够好，导致很少有人能真正提问。还有人觉得，孩子们似乎只是为了排队向 YouTuber 提问，而不是关注那些非名人的展位。

另一位评论者则表达了对整个创客运动的怀疑。他们认为，虽然创客运动让很多事情成为可能，但孩子们似乎并不想成为工程师，而是更想成为内容创作者或爱好者。即使是一些有潜力的学生，也只是把工程视为一种媒体职业或有趣的爱好。他们认为，这可能是导致工程师短缺的原因之一。

使用现代 CSS 终结 SPA 的时代

本文探讨了使用现代 CSS 技术（如 View Transitions API 和 Speculation Rules）构建高性能网站的可能性，挑战了长期以来 SPA（单页应用）在提供流畅用户体验方面的统治地位。作者认为，现代 CSS 已经能够实现原生、声明式的页面过渡效果，从而消除了 SPA 在这方面的优势。

文章指出，SPA 的流行很大程度上源于其在页面切换时提供的流畅感，避免了传统网站的白屏和滚动位置跳动等问题。然而，大多数 SPA 实际上并没有实现其承诺的平滑体验，反而带来了诸如过渡效果只是在两个加载状态之间切换、滚动条位置错乱、焦点行为不一致以及脚本重新渲染组件导致的延迟等问题。更糟糕的是，为了模拟原生导航，SPA 通常需要加载大量的 JavaScript 代码，导致性能下降。

现代浏览器，特别是基于 Chromium 的浏览器，通过 View Transitions API 提供了原生的页面过渡方案。开发者可以使用 CSS 来实现页面间的淡入淡出、共享元素动画以及保持头部或导航栏等持久元素，而无需编写任何 JavaScript 代码。此外，Speculation Rules 允许浏览器根据用户行为预加载或预渲染页面，从而实现即时导航。

文章还强调了浏览器对简单和弹性的偏爱，例如 Back/Forward Cache (bfcache) 可以瞬间恢复整个页面，但 SPA 的设计模式（如劫持路由、客户端渲染和复杂的状态管理）往往会破坏 bfcache 的工作。因此，作者呼吁开发者拥抱现代 CSS 技术，构建快速、稳定、易于维护且对 SEO 友好的网站。

汉萨同盟的兴衰：中世纪贸易联盟如何影响欧洲

本文探讨了中世纪德国商人组成的汉萨同盟，分析了其如何通过集体谈判、行动和安全措施，建立起北欧第一个长途贸易网络，并持续了近500年。

文章首先指出，汉萨同盟在没有公司结构的情况下，建立了连接北欧主要港口的供应链，其法律甚至管辖了从伦敦到西俄的贸易中心。即使由数百个成员城市组成，且没有国家元首，汉萨同盟仍然能够与外国统治者签订条约，甚至发动并赢得战争。

文章进一步分析了汉萨同盟兴起的大背景，包括欧洲在黑暗时代之后的复苏。大约从公元800年开始，北欧的商品和人口流动开始加速。中世纪暖期改善了农业产量，农民改进了农业技术，例如采用重犁和三田轮作制。这些进步使得欧洲的粮食产量首次超过了自给自足的水平，人口也从600年代的1800万增长到1300年代的7000多万。剩余的营养支持了欧洲自罗马帝国以来第一个重要的工匠阶级，促进了城镇的形成和专业化贸易的发展。

文章还提到了航运的进步，气候变暖延长了北海和波罗的海的通航时间，船只的吨位也显著增加。维京风格的 Knarr 船只的出现，使得货物运输能力大大提高。然而，早期的长途贸易商人也面临着海盗、沉船和内陆河流的阻碍等诸多挑战。

总而言之，汉萨同盟的兴起与欧洲经济的复苏、农业技术的进步和航运的发展密切相关。它在促进北欧贸易和欧洲国家能力建设方面发挥了重要作用。

Simon Tatham's Portable Puzzle Collection：随时随地享受解谜乐趣

Simon Tatham's Portable Puzzle Collection 是一系列小型的单人益智游戏合集，可在 Unix (GTK) 和 Windows 上原生运行，也支持通过 Java 或 JavaScript 在网页上游玩。这个合集的目标是提供更多可以在小窗口中快速启动和游玩的小游戏，让大家在工作间隙放松身心。

该合集包含了多种经典益智游戏的重新实现，例如 Black Box (通过激光束反弹寻找隐藏的球)、Bridges (用桥梁连接所有岛屿)、Cube (滚动立方体拾取所有蓝色方块)、Dominosa (用多米诺骨牌铺满矩形) 等等。每个游戏都提供了在线的 JavaScript 和 Java 版本（Java 版本可能已过时），以及 Windows 可执行文件和详细的手册。对于其他平台，这些游戏打包在一个单独的捆绑包中。

由于作者的 Mac 电脑已经停止工作，因此不再提供 MacOS 版本的构建。不过，仍然可以通过网页版本进行游戏。作者欢迎其他开发者自愿维护 Mac 前端代码并提供可下载的应用程序。

总而言之，这个游戏合集的设计初衷是方便用户在各种平台上都能轻松地玩到这些经典的小游戏，无论是在工作休息期间还是在旅途中，都能随时随地享受解谜的乐趣。

《PF之书》第四版即将发布：OpenBSD 与 FreeBSD 防火墙配置指南迎来更新

《PF之书》第四版即将面世，本书针对 OpenBSD 和 FreeBSD 平台上的 PF 防火墙进行了全面更新，以适应现代互联网环境的需求。 新版本不仅涵盖了近年来 PF 的各项改进，还特别关注了 FreeBSD 上的 PF 应用，旨在为读者提供更实用、更贴近实际的配置指导。

作者在邮件和社交媒体上被频繁问及为何时隔这么久才推出新版本以及旧版本是否已经过时。 作者解释说，在第三版发布后很长一段时间内，OpenBSD PF 在用户可见的配置语法上没有重大变化，因此没有立即更新的必要。 尽管底层代码一直在改进，例如多核支持等性能优化，但用户可以直接感知到的变化并不多。

不过，作者在持续进行讲座和教程的过程中，与 Max Stucchi 和 Tom Smyth 合作，不断完善教学内容。 随着时间的推移，教程内容逐渐以 OpenBSD 为中心。 在 COVID-19 疫情导致线下会议暂停期间，关于第四版何时推出的问题越来越多。

在 2023 年 EuroBSDCon 大会之后，作者开始认真评估更新的可能性。 他发现 NetBSD 已经开发了自己的 NPF 数据包过滤子系统，并弃用了 PF 端口，而 DragonFly BSD 上的 PF 版本也严重过时。 因此，作者决定专注于 OpenBSD 和 FreeBSD 这两个他日常使用的系统。

新版本中，FreeBSD 上的 PF 应用受到了更多关注。 作者还邀请了 Henning Brauer 和 Kristof Provost 担任技术审阅，以确保内容的准确性和实用性。

总而言之，第四版《PF之书》是对 OpenBSD 和 FreeBSD 上 PF 防火墙配置的全面更新，旨在帮助读者更好地理解和应用 PF 技术，应对现代网络环境的挑战。

Karpathy 的 “追加与回顾” 笔记法：极简主义的效率之道

Andrej Karpathy 分享了一种名为 “追加与回顾” 的极简笔记方法，核心思想是将所有想法、待办事项等都追加到一个单一的文本文件中，并通过定期回顾来整理和提炼信息。这种方法旨在降低认知负担，方便快速记录和检索。

Karpathy 强调只使用一个名为 "notes" 的文本文件，避免了管理多个笔记和复杂文件夹结构的麻烦。他通常使用 Apple Notes 应用，因为它支持离线编辑、设备同步和备份。记录时，他会将新的想法或信息添加到文件顶部，不做过多结构化处理，仅使用 "watch:", "listen:", "read:" 等标签方便日后查找特定内容。

定期回顾是该方法的关键。通过向下滚动浏览笔记，Karpathy 会将重要的信息复制粘贴到文件顶部，进行合并、处理或修改。不重要的内容则会逐渐沉淀到底部，但不会被删除，只是不再优先关注。他分享了多种使用场景，包括记录随机想法、电影推荐、读书笔记、TODO 列表、写作草稿、有趣引言、实验记录等等。这种方法让他能够快速记录想法，释放工作记忆，并在之后回顾时进行更深入的思考。随着时间的推移，笔记会变得庞大，回顾旧的笔记可以带来新的灵感和洞见。

评论区对这种方法褒贬不一。

  • 有人认为这种方法过于简单，难以满足复杂的知识管理需求，使用列表管理笔记的认知负担并不高，关键在于建立回顾和整理的习惯。
  • 也有人觉得这种方法很实用，并分享了自己类似的实践，例如使用单一文本文件并结合自定义的标记语言进行结构化管理，或者使用即时通讯工具给自己发送消息来记录想法，因为这些应用通常具有更好的时间戳和用户体验。
  • 还有人指出，这种笔记系统本质上类似于 GitHub issue，具有可编辑的描述和评论功能。
  • 另一些人则质疑这种分享笔记系统文章的价值，认为更应该关注笔记本身带来的实际成果。

总的来说，“追加与回顾” 笔记法是一种简单有效的个人知识管理方法，但其适用性因人而异。关键在于找到适合自己的方法，并坚持实践。

警惕AI代写：作者呼吁回归真诚的写作

这篇文章的作者分享了自己对AI代写内容的反感，他认为使用AI生成的内容缺乏个人思考和真情实感，并呼吁大家重视原创写作。作者凭借着对语言的敏锐度和长期与AI模型打交道的经验，能够轻易辨别出AI生成的内容。

作者认为，花费时间润色文字是个人思考和学习的过程，不应被AI取代。他强调，AI擅长产出内容，但无法代替人类的思考和经验。将未经个人思考的AI生成内容直接呈现给他人，实际上是将自己的工作转嫁给他人，迫使他人花费额外的时间去辨别和理解。作者也提到，如果英语不是母语，使用AI辅助润色是可以理解的，但最终仍需加入个人的理解和风格。作者鼓励大家拥抱AI技术，但同时也要保持自己的独立思考和原创精神，不要让AI成为偷懒的借口。他希望看到的是经过个人思考和沉淀的“精华汤”，而不是AI批量生产的“泔水”。

评论区也引发了一些有趣的讨论。有人调侃作者的语气像“海豹突击队”式的咆哮，但表示感同身受，认为很多人都应该对行业现状感到不满。也有人认为，对于那些读写能力较弱的人来说，写作助手可以帮助他们建立自信。还有人建议干脆模仿AI的写作风格，让其成为自己的独特风格。一位资深开发者表示，他非常理解作者的心情，认为在社会变革时期，总会有人坚持手工技艺的价值。他认同作者的观点，即AI不能取代人类的思考和经验，并分享了自己在使用AI工具时，会花费大量时间来构建上下文和提示词的经验。

别再下载 App 了，直接用网页版！

这篇文章指出，现在很多公司都在诱导用户下载 App，但实际上，很多时候网页版的功能已经足够强大，甚至更好。App 之所以被大力推广，主要是因为它们能获取用户更多的个人数据和设备权限，比如通讯录、位置信息、麦克风权限以及已安装应用列表。这些数据对于公司来说是宝贵的财富，但对于用户来说，却牺牲了隐私和控制权。文章建议大家在下载 App 之前，先考虑一下自己是否真的需要它，以及是否愿意为此付出隐私的代价。很多时候，网页版已经足够满足需求，而且还能避免成为一个“数字间谍”。

评论区里，大家的观点也各不相同。

  • 有人表示赞同，认为很多 App 确实不如网页版方便，比如在浏览器里可以轻松打开多个标签页和收藏结果。
  • 有人提到，很多 App 体积庞大，功能却很鸡肋，而且还会要求访问通讯录等敏感权限。
  • 也有人指出，现在很多网站会强制用户下载 App 才能使用，根本没有选择的余地。
  • 还有人认为，原生 App 的体验通常比移动网页版更好更流畅。

总的来说，是否选择使用 App，取决于个人的需求和偏好。但无论如何，都应该对 App 获取的权限保持警惕，并权衡便利性和隐私之间的利弊。

Discord 年龄验证被指可用游戏角色照片绕过

Discord 的年龄验证机制被曝存在漏洞，用户可以通过上传游戏角色照片来绕过验证，以访问“不适合工作 (NSFW)”的内容。

这篇文章指出，Discord 为了遵守英国的《在线安全法案》，推出了年龄验证工具，该法案旨在保护未成年人免受不适宜内容的侵害。Discord 的年龄验证要求用户提供面部照片或身份证件，才能访问包含成人内容的频道和服务器。然而，有用户发现，通过上传高品质游戏角色的照片，可以欺骗该验证系统。一位用户分享了他们如何使用游戏《死亡搁浅》中的角色 Sam Porter Bridges 的照片成功通过验证的经历。该用户还提到，游戏自带的拍照模式可以调整角色的面部表情，从而绕过需要张嘴闭嘴的二次验证。这意味着，Discord 的年龄验证机制可能并不像预期的那样严格，存在被滥用的风险。

(由于文章中没有评论内容，因此省略评论分析部分)

避免在领域层中使用 Pydantic

本文探讨了在软件开发中，如何避免在核心领域层过度使用 Pydantic，从而实现更好的关注点分离和代码可维护性。文章建议在应用程序的边缘（如表示层和基础设施层）使用 Pydantic 进行数据验证，而在领域层使用纯 Python 对象 (POPO)。

文章指出，虽然 Pydantic 在数据验证方面非常方便，但在应用程序的各个层都使用它会导致紧耦合，从而降低系统的可维护性和可测试性。为了解决这个问题，文章介绍了使用 Dacite 库将 Pydantic 模型转换为纯 Python 数据类的方法。Dacite 可以简化嵌套结构的初始化过程，从而减少手动转换所需的工作量。

文章通过一个简单的例子展示了如何使用 Dacite 将 Pydantic 模型转换为 Python 数据类。同时，文章也指出了手动转换的可能性，并建议在领域驱动设计 (DDD) 风格的架构中保持聚合和实体结构的简单性。此外，文章还提供了一个更结构化的方法，其中数据类作为领域层的实体，而 Pydantic 模型属于应用程序或基础设施层。这种方法引入了一组支持对象，充当应用程序和领域之间的桥梁。

文章还详细介绍了 Repository 模式，该模式负责存储和检索数据，并在存储格式（如 JSON、YAML 或纯字典）和领域实体之间进行转换。Repository 通过 Mapper 与领域层进行交互，确保领域层不依赖于 Pydantic。通过这种方式，应用程序层可以调用领域逻辑，并将实体传递回 Repository 进行保存。

总而言之，文章建议谨慎使用 Pydantic，并将其主要用于数据验证。在领域层，应优先使用纯 Python 对象，并通过适当的转换机制（如 Dacite 或手动转换）来实现数据在不同层之间的传递，从而提高代码的可维护性和可测试性。

Instapaper 与 Rakuten Kobo 整合：无缝阅读体验升级

Instapaper 宣布与 Rakuten Kobo 电子阅读器整合，为 Kobo 用户带来直接在设备上保存和阅读网页文章的无缝体验。这次合作旨在为 Kobo 阅读器用户提供更佳的稍后阅读服务。

Instapaper 团队正与 Kobo 紧密合作，目标是在今年夏季末推出此整合功能。此次整合将取代 Kobo 之前与 Pocket 的合作，Pocket 已于本月早些时候停止服务。对于之前的 Pocket 用户，迁移到 Instapaper 可以获得更简洁、无干扰的阅读体验，以及更强大的组织工具。

为了帮助 Pocket 用户顺利过渡，Instapaper 提供了便捷的导入工具。用户可以通过 instapaper.com/pocket 轻松两步导入文章，或者下载 Pocket 导出文件，然后在 Instapaper 设置中导入。

Instapaper 团队表示非常高兴能与 Rakuten Kobo 合作，为其 Kobo 电子阅读设备提供稍后阅读功能。他们也欢迎用户通过 support@instapaper.com 提出任何问题、疑虑或建议。

由于没有评论内容，这里就不做评论分析了。

为什么你一直叫它DB9？实际上它是DE9！

SparkFun发布了一篇博客，解释了为什么他们的新产品使用DE9这个名称，而不是更常见的DB9。文章指出，虽然大家都习惯称9针D-sub连接器为DB9，但从技术上讲，DE9才是正确的叫法。

D-sub连接器的命名规则中，"D"代表D型金属外壳，后面的字母代表外壳尺寸，而数字代表针脚数量。"B"代表25针外壳的尺寸，而"E"代表9针外壳的尺寸。因此，9针D-sub连接器应该被称为DE9，而不是DB9，DB9这个叫法是错误的，因为它将25针的"B"外壳与9个针脚的数量配对，这在物理上是不一致的。文章解释说，之所以出现这种错误，是因为早期的IBM PC使用DB25连接器作为串口和并口，当引入较小的9针串口时，人们自然地沿用了DB的叫法，并将其称为DB9。尽管如此，SparkFun 决定在其新产品中使用技术上正确的名称 DE9，希望借此纠正这个长期存在的错误。

评论区里，大家对这个话题也展开了热烈的讨论：

  • 有人指出，类似的命名错误在其他领域也很常见，比如“RJ45”实际上应该叫“8P8C”。
  • 有人赞叹D-sub连接器经久耐用，从50年代的军用标准沿用至今。
  • 有人调侃SparkFun应该再去纠正“传统电流”方向的错误。
  • 有人质疑DB外壳是否不能容纳9针连接器。
  • 有人分享了其他连接器命名混乱的例子，比如“复合视频”的各种别称。
  • 有人说，说“IEC电源线”别人听不懂，但说“水壶线”就明白了。
  • 有人认为，重要的是大家明白你在说什么，没必要过于纠结技术细节。
  • 有人表示，自己一直都叫它“串口”，懒得记DB9，以后可以用DE9来“炫耀”了。

总的来说，评论区既有对技术细节的探讨，也有对约定俗成用法的理解，展现了大家对技术命名规范的不同看法。

永远不要编写自己的日期解析库？Eleventy 的选择与权衡

本文讨论了 Eleventy 框架在日期解析库上的选择，以及作者 Zach Leatherman 为什么最终决定自己编写一个日期解析库 @11ty/parse-date-strings。起因是 Eleventy 为了支持更多 JavaScript 运行环境，需要减少对大型依赖库 Luxon 的依赖。

Eleventy 早期选择了 Luxon 作为日期解析库，但随着项目发展，Luxon 的体积逐渐成为一个问题，尤其是在客户端环境中。虽然 Luxon 功能强大，但 Eleventy 仅用到 ISO 8601 日期解析功能，无法通过 tree-shaking 减少体积。作者考察了其他替代方案，如 dayjs、moment 和 date-fns，但 dayjs 的准确性不足，其他库的体积也无法满足需求。因此，作者决定自己编写一个更轻量级的日期解析库。

新库 @11ty/parse-date-strings 专注于 RFC 9557 兼容的日期解析，体积小巧，并且与未来的 Temporal API 保持一致。尽管与 Luxon 相比存在一些 breaking changes，但从长远来看，这能更好地为 Eleventy 的未来发展铺平道路。新库的引入显著减小了 Eleventy 的客户端 bundle 体积和 node_modules 的安装大小。文章还列举了一些其他的日期库和 Temporal polyfill 方案，供读者参考。

评论区中，有人表示每当看到“永远不要自己实现...”的说法时，反而会激起自己尝试的欲望，因为只有挑战困难的事情才能真正提升能力。

Tailwind Plus 推出 Vanilla JavaScript 支持

Tailwind Plus 现在提供对 Vanilla JavaScript 的支持，这意味着开发者可以在不依赖 React 或 Vue 等框架的情况下，使用其 UI 组件。

文章介绍了 Tailwind Plus 推出的 @tailwindplus/elements 库，这是一个专为 Tailwind Plus 客户提供的 headless custom elements 集合。这些 custom elements 封装了构建交互式 UI 所需的复杂行为，开发者可以使用 HTML 和 CSS 轻松地进行样式定制。使用方法非常简单，只需在 HTML 文件中引入 @tailwindplus/elements 的 CDN 链接即可。文章还展示了如何使用 <el-dropdown>、<el-select> 和 <el-dialog> 等 custom elements 构建自定义下拉菜单、选择菜单和命令面板的示例代码，强调了这些元素自动处理 ARIA 属性、焦点管理和键盘支持等功能。总而言之，Tailwind Plus 旨在简化前端开发流程，让开发者能够更专注于 UI 设计，而无需编写大量的 JavaScript 代码。

MIT 放弃 Scheme 转用 Python 的原因

本文讨论了 MIT 将其入门编程课程从 Scheme 切换到 Python 的原因，重点在于编程环境和教学目标的变化。

Sussman 解释说，在 1980 年代，优秀的程序员花大量时间思考，然后编写精简且可靠的代码。当时的编程更接近底层，即使是 Scheme 这样的语言，也能让人理解其运作方式。课程 6.001 的初衷是教工程师如何将完全理解的小部件组合成更大的、符合需求的系统。

然而，如今的编程更多的是与不熟悉的、文档不完善的软件库打交道，需要通过实验来了解其工作原理。这种转变需要不同的课程设置。新的 6.001 课程以机器人为中心，学生需要编写程序来控制机器人的运动。由于机器人不像电阻器那样按照理想函数运行，因此需要以不同于 SICP（计算机程序的构造和解释）的方式来构建系统的鲁棒性。

至于选择 Python 的原因，Sussman 认为可能只是因为当时已经有现成的 Python 库可以用于机器人接口。总而言之，MIT 转向 Python 是为了更好地适应现代软件开发的现实，并提供更实用的编程技能。

评论区里，有人认为这是一个遗憾，因为 Scheme 能够培养更深入的理解和更优秀的程序员。他们觉得使用 C 或其他更底层的语言可以让你成为一个“真正的程序员”。 也有人认为，对于非软件工程师或计算机专业的入门课程来说，Python 更实用。 还有人认为 Python 在教学入门和更深入的知识方面都更好，它既实用又能吸引许多聪明的程序员，因为它能够快速原型设计并理解手头的问题，而不是像 Scheme 那样需要大量的准备工作。 甚至有人庆幸没有选择 Java。

Efficient Computer推出Electron E1 CPU：号称能效比ARM提升100倍？

Efficient Computer推出了一款名为Electron E1的全新CPU，这款芯片专为嵌入式市场设计，其核心理念是打破传统CPU的设计模式，通过静态调度和数据流控制来实现极高的能效。他们声称Electron E1的能效比ARM的最佳嵌入式核心高出100倍。

传统的CPU架构在数据传输上消耗了大量能量，而Electron E1采用了一种名为"Fabric"的空间数据流模型。在这种模型中，指令被固定在特定的计算节点（称为tiles）上，数据在这些节点之间流动。每个tile执行基本的数学、逻辑和内存访问操作，编译器静态地调度每个tile，并确定数据的路由。这种架构避免了传统CPU中的程序计数器和全局调度器，从而大大降低了数据传输的能量消耗。

Electron E1的编译器能够将C++或Rust代码转换为数据流图，这使得它能够作为通用CPU使用。为了应对程序图过大的情况，Efficient Computer采用了流水线重配置技术，将程序图分解成块，并动态加载新的配置。此外，tile之间的互连是静态路由和无缓冲的，这意味着编译器需要在编译时解决潜在的数据冲突。

Electron E1的首个候选版本支持32位浮点运算，这对于其架构的可扩展性至关重要。该芯片的编译器前端基于Clang，支持C++和Rust，并且声称支持PyTorch、TensorFlow和JAX等机器学习框架。

总的来说，Electron E1代表了一种与传统CPU设计截然不同的方法，它通过优化数据流来提高能效，但同时也对编译器提出了更高的要求。

由于目前没有评论内容，因此跳过评论分析部分。

自托管的未来：一场关于数据所有权的讨论

本文探讨了在亚马逊等公司日益收紧数字内容访问权限的背景下，个人自托管服务的兴起与局限性。文章作者分享了自己搭建家庭服务器的经验，并反思了自托管是否是应对科技巨头控制的理想方案。

作者首先提到亚马逊限制Kindle用户下载书籍的事件，指出用户购买的数字内容实际上只是“许可”，而非真正所有。这种现象延伸到个人数据领域，例如存储在云盘、相册中的文件，用户实际上是在“租用”空间，随时可能面临服务商更改条款、提价，甚至难以迁移数据。为了摆脱这种受制于人的局面，作者尝试自建服务器，运行开源的Google Drive、Google Photos、Audible、Kindle和Netflix替代品。

文章详细介绍了自托管的概念，即在自己家中搭建服务器，运行各种应用程序，存储和备份数据。作者坦承，这需要大量的技术知识和精力，并非适合所有人。随后，作者分享了自己搭建家庭服务器的硬件和软件配置过程，包括购买Lenovo P520工作站、安装Proxmox、配置存储池、安装Tailscale和Docker等。最终，他成功运行了Immich（Google Photos替代品）、Calibre-web（电子书管理工具）、Audiobookshelf（有声书服务器）和Jellyfin（流媒体服务器）等开源应用。

尽管自托管带来了对数据的高度控制权，但也存在一些局限性。其中之一是互联网的限制。例如，如果想要与朋友分享照片，自托管服务难以实现便捷的共享功能。作者认为，自托管虽然提供了一种反抗科技巨头控制的途径，但并非解决所有问题的终极方案。

Tattoy 终端支持动画光标

Tattoy 终端现在支持动画光标，它使用与 Ghostty 相同的格式，并使用自定义着色器渲染光标。开发者可以直接使用一些流行的 Ghostty 光标。

尽管 Tattoy 支持 Ghostty 光标，但其渲染方式却大不相同。Ghostty 使用实际像素渲染光标，而 Tattoy 使用基于 UTF8 文本的 "像素"，即 "▀" 和 "▄"。这意味着 Tattoy 光标有时会错过 Ghostty 光标的细微之处，但像素化效果可能也会让一些人感到愉悦。

由于 Tattoy 已经有一个基于着色器的框架，因此只花了几个小时就让第一个 Ghostty 着色器在 Tattoy 中工作。但至少又花了一个星期的时间来解决所有问题。最困难的问题之一是支持光标轨迹的抗锯齿边缘的透明度。Ghostty 着色器希望能够对实际终端的底层像素进行采样，正是这种采样实现了平滑的抗锯齿混合。然而，Tattoy 纯粹是基于文本的，因此无法执行诸如获取字体字形的单个像素之类的操作。但它确实知道文本的真实颜色值，因此可以创建终端的粗略 "像素化" 版本，并将其作为图像缓冲区上传到 GPU。然而，虽然这解决了抗锯齿问题，但也意味着终端的像素化版本包含在光标图像数据中。为了解决这个问题，我添加了一个简单的后处理步骤，将上传到 GPU 的终端像素与最终渲染的光标像素进行比较。这两个图像之间的差异最终会渲染到用户的终端。

目前看来效果很好，但在较大的终端上可能会有一些延迟。还有很多更通用的性能改进应该会有所帮助。但我也想知道这是否可以通过 Tattoy 接管主机终端模拟器的所有光标渲染来解决。目前，动画光标和主机光标一起渲染，因此延迟存在差异。

总的来说，这是一个良好的初步尝试。

评论区里，有用户觉得这个动画光标非常酷，特别是在 TUI 应用中使用时，有助于注意到光标的移动位置。也有人好奇是否有人会将其作为日常使用，并有人建议可以根据光标移动的距离来调整动画效果，比如模拟运动模糊。此外，还有人分享了 Emacs 上的类似功能 beacon，以及 Ghostty 中光标功能的演示视频。也有用户遇到了配置问题，希望能够顺利使用该功能。一些评论也提到，虽然看起来很酷，但可能会让人分心。

C 语言中的泛型容器：Vec 的实现

本文探讨了在 C 语言中实现类型安全和边界安全的泛型容器，重点介绍了一种名为 vec 的可变大小数组（动态数组）的实现方法。

文章首先展示了 vec 的基本用法，包括如何创建、添加元素以及释放内存。核心实现依赖于宏定义，利用 C 语言的预处理器来生成特定类型的向量结构。vec 结构体包含一个用于存储元素数量的 N 成员和一个柔性数组 data，用于存储实际数据。

文章详细解释了 vec_push 宏的实现，该宏使用 realloc 函数来动态调整向量的大小，从而实现元素的追加。作者还讨论了错误处理的问题，并提出了使用 ssize_t 和 C23 的 checked integers 来增强代码健壮性的建议。

文章还探讨了是否需要 capacity 字段的问题。作者认为，虽然 capacity 字段可以避免频繁的内存重新分配，但为了保持代码的简洁性，选择不包含该字段，因为 realloc 通常在内部已经做了优化。不过，作者也提供了一些其他的接口，例如使用外部整数来跟踪容量，以及使用自动容量调整策略，以满足对性能有较高要求的场景。

最后，文章强调了边界安全的重要性，并提供了一个 vec2array 宏，用于将 vec 类型转换为传统的 C 数组，以便与现有的代码进行交互，并利用之前讨论的边界检查技术来确保代码的安全性。

评论区对文章提出的 C 语言泛型容器实现方法展开了激烈的讨论。

  • 宏的争议: 一些开发者认为，虽然宏在 C 语言中可以实现泛型，但它们并非最佳方案，并期待 C 语言能引入更完善的泛型编程机制，例如 Zig 语言的 comptime。
  • 性能考量: 有评论指出，文章中省略 capacity 字段的决定可能不适用于所有场景，特别是在需要高性能的通用数组库中。
  • 替代方案: 一些评论推荐使用 C++ 来实现泛型容器，认为 C++ 编译器在过去几十年里已经足够成熟，可以方便地将 C 代码移植到 C++。也有人分享了自己实现的 C 语言向量库，并展示了其应用案例。
  • 类型安全: 有评论质疑基于 token pasting 的宏定义泛型方法对于非平凡类型的适用性，例如 vec(int *)。
  • 现有资源: 还有评论推荐了 David R. Hanson 的著作 "C - Interfaces and Implementations"，该书被认为是该主题的权威指南。
  • 代码生成: 另一种观点认为，对于 C 语言来说，代码生成是更好的泛型实现方法，可以提供更好的代码人体工程学、tab completion 和更少的错误。

程序员的初心：为何我热爱编程

这篇文章讲述了作者从童年时期对电子设备的好奇，到后来通过编程创造虚拟世界和解决现实问题的经历，最终认识到编程不仅仅是一项技能，更是一种探索世界和满足好奇心的方式。作者分享了自己与编程结缘的经历，以及编程带给他的乐趣和成就感。

文章提到作者小时候喜欢拆卸电器，后来接触了MS-DOS、Logo、PASCAL和BASIC等编程语言，通过编写小游戏和计算器程序感受到了编程的魔力。在互联网普及后，作者开始学习HTML、CSS和JavaScript，并尝试制作网站。他还沉迷于GTA的MOD制作，并发现了Second Life这个虚拟世界，通过LSL语言进行创作并赚取了收入。

作者提到自己一度想为现实世界创造有意义的东西，并因此开始尝试商业活动。HTML5的出现让他重新燃起了对Web开发的兴趣，同时Bret Victor的演讲《Inventing on Principle》也深刻影响了他对编程和创造力的看法。在大学期间，作者学习了工程和商业相关的课程，并在毕业后加入了一家创业公司，正式开始了职业生涯。

作者也坦诚自己经历过职业倦怠，但通过休息和旅行重新找回了对编程的热爱。他认为编程的魅力在于其无限的可能性，以及不断涌现的新技术和领域。虽然保持专注很重要，但探索新事物也是编程乐趣的一部分。

评论区也引发了热烈讨论，许多人分享了自己与编程的故事和感悟。有人认为编程是一种独特的创造性活动，可以无限次地重复实验且无需承担物理成本。有人表示自己对编程上瘾，并享受创造一切的可能性。还有人分享了自己小时候拆卸玩具的经历，认为编程满足了他们探索和创造的欲望。Bret Victor的演讲《Inventing on Principle》也被多次提及，可见其对程序员群体的影响之深远。大家普遍认为，编程不仅仅是一份工作，更是一种爱好和生活方式。

Recurse Center 探讨 AI 的发展定位

Recurse Center (RC) 针对 AI 技术的快速发展，探讨了其对编程学习、职业发展以及社区管理的影响，旨在为 Recursers 提供有价值的参考。

文章指出，AI 已经渗透到 RC 工作的各个方面，包括招生流程、项目开发以及招聘业务。RC 并没有试图涵盖所有与 AI 相关的问题，而是专注于 LLM 对 Recursers 的个人和职业影响，因为这是他们最了解且与业务核心相关的领域。RC 组建了一个由校友组成的非正式 AI 顾问小组，这些校友代表了 RC 最重要的教育价值观，例如好奇心、自主性、严谨性、友善、在实践中学习和成长型思维。

通过与校友的交流，RC 发现经验丰富的程序员对 LLM 的能力和实用性存在分歧。一些人认为 LLM 对日常软件工程没有太大帮助，而另一些人则认为 LLM 已经极大地改变了他们的工作流程。造成这种差异的原因包括使用 LLM 的时间、深度和新近程度，编程工作的类型，以及是在小型项目中工作还是在大型现有代码库中工作。

关于 AI 对学习的影响，大多数人认为既有机遇也有陷阱。一种观点是，当人们真正想掌握某些东西时，应该关闭 LLM。一些人将 LLM 比作电动自行车，认为它们可以帮助人们更快地探索和熟悉主题，但不利于成为更好的程序员。

总的来说，RC 认为 AI 是一把双刃剑，既可以提高效率，也可以阻碍学习。关键在于如何明智地使用 AI 工具，并根据具体情况选择合适的策略。

理解 X-Forwarded-For：用途与信任度分析

本文深入探讨了 X-Forwarded-For HTTP 头部，解释了它的作用、使用场景以及安全隐患，旨在帮助开发者更好地理解和使用这一技术。

X-Forwarded-For 头部用于记录 HTTP 请求在经过多个代理服务器或负载均衡器时，客户端的原始 IP 地址。 它的主要作用是让后端服务器能够获取到客户端的真实 IP，而不是最后一个代理服务器的 IP。 这在很多场景下都非常有用，例如用户身份验证、负载均衡、地理位置内容分发、访问控制、Web 应用防火墙、欺诈预防、API 速率限制、本地化广告以及日志记录和分析等。

然而，X-Forwarded-For 头部的内容可以被伪造，因此不能完全信任。 恶意用户可能会篡改该头部，冒充其他 IP 地址，从而进行恶意活动。 为了提高安全性，可以采用一些措施，例如使用可信的反向代理，并禁用直接访问后端服务器，只允许通过反向代理访问。 反向代理可以覆盖 X-Forwarded-For 头部，将其替换为客户端的真实 IP 地址，从而防止欺骗。

更进一步，文章建议在反向代理层面做出决策，例如使用 Nginx 可以完全覆盖 X-Forwarded-For 头部，丢弃客户端提供的任何信息，并将其替换为它所看到的 IP 地址。 这种方式在不确定调用链的其余部分是否安全可靠时，是最安全的方法。 如果其他代理和后端应用程序可能会盲目信任传入的信息，或者通常做出不安全的选择，那么完全替换 X-Forwarded-For 头部可能是最安全的。

总而言之，X-Forwarded-For 是一个强大的工具，但在使用时需要谨慎，务必采取必要的安全措施，防止被恶意利用。

评论 0 条

暂无评论，来种下第一颗种子。