在历经三年打造一台实体 80x 系列列车模拟器后，创作者针对几项复杂的升级进度进行了更新。 主要进展包括： * **前照灯面板：** 创作者定制了一块带有 LED 扩散器的电路板（PCB），并成功组装了一个罕见的六档位选择开关，以还原原型车的前照灯及危险警示控制功能。 * **仪表盘面板：** 将材质从易碎的硬纸板改为激光切割并进行粉末喷涂的钢板，大幅提升了耐用度与真实感。目前面板已安装到位，创作者正在优化标签制作工艺，以避免涂料渗入哑光涂层的问题。 * **AWS 系统：** 该项目正在集成原装的微型 AWS“向日葵”信号指示器。为了支持这些模块所需的高侧切换（high-side switching），创作者正在对其 CAN 总线子板进行修改，以实现灵活的开关配置。 虽然这些项目仍在进行中，但它们标志着该模拟器正向着高保真真实感迈进。后续博文将详细介绍 PCB 设计、面板精加工技术以及微型机械 AWS 向日葵装置的集成过程。
每日HackerNews RSS
这篇 Hacker News 的讨论聚焦于 *z80.me* 上展示的一款自制火车模拟器控制器。用户称赞了该硬件简洁的设计与真实感，并由此引申出关于火车模拟周边设备小众市场的广泛讨论。
要点包括：
* **市场潜力：** 评论者认为，尽管在采购锁存按钮等特定的复古机电零件方面存在挑战，但与制造商合作仍具有巨大的挖掘潜力。
* **替代方案：** 用户分享了诸如“火车控制器数据库（Train Controller Database）”等资源，并提到了针对日本风格模拟器、价格实惠且紧凑的 Zuiki Mascon 等选择。
* **创意应用：** 除了模拟游戏外，参与者还对将工业级控制器作为生产力工具、编程或大语言模型（LLM）交互的触觉界面表现出兴趣。建议包括使用 MIDI 接口将物理硬件映射到软件功能上。
* **怀旧情怀：** 讨论在对经典的“Blinkenlights”工程迷因的轻松致意中结束，反映了社区对复古工业控制面板和具有触感的“咔哒”类硬件接口的共同赞赏。
本文反驳了“正则表达式无法解析 HTML，因为 HTML 不是‘正则语言’”这一常见观点。作者指出，现代编程语言的正则引擎（如 PCRE）远比形式语言理论中定义的“正则语言”强大得多。 核心要点包括： * **超越正则语言：** 现代正则引擎通过递归和命名子模式等功能，可以处理上下文无关语法（如格式良好的 HTML 和大多数编程语言）。 * **复杂能力：** 它们甚至能匹配某些上下文敏感语言，并通过反向引用支持 NP 完全问题。 * **实用性与能力：** 正则表达式“能”解析复杂结构并不意味着“应该”这样做。虽然正则表达式在提取特定数据点方面表现出色，但作者强调，通用的 HTML 处理仍应依赖 DOM 库，因为后者能更好地处理格式不规范的代码。 * **最佳实践：** 如果正则表达式是处理特定、封闭任务的正确工具，作者建议使用 `x` 修饰符来提高可读性，并利用 `DEFINE` 断言和命名子模式来管理复杂性。 总之，正则表达式是一种功能强大且具备图灵完备性的工具，但开发者在处理具体问题时，应优先考虑可读性和可维护性最强的方案。
作者拒绝在个人项目中使用现代“AI生成、人工审核”的工作流程，认为将整个编码过程外包会造成巨大的认知负债，并剥夺开发的乐趣。与其允许 AI 直接修改文件，作者采用了一种“手动录入”的工作流：在聊天中请求代码片段，并手动将其键入编辑器。 尽管这种方法不如全自动化高效，但作者认为它更具价值。手动转录代码会强制放慢节奏，这有助于理解代码、构建代码库的空间心智模型，并更容易发现幻觉内容或糟糕的设计选择。通过将大语言模型视为交互式文档而非自主代理，作者保持了自己的主导权，并确保对工作有深刻的个人理解。归根结底，作者更看重长期的代码掌握能力和构建过程，而非 AI 驱动的原始生产速度，并警告称，行业目前对自动化“垃圾内容”的依赖，可能会导致未来开发者不再理解自己的基础设施。
所提供的文本记录了 Hacker News 上关于大语言模型（LLM）对软件开发影响的一场激烈辩论，核心议题是“认知债务”——即开发者过度依赖 AI 生成代码而导致理解能力丧失的现象。
该文章作者建议，手动重写 LLM 生成的代码有助于开发者“掌握”逻辑、内化实现方式并保持技能水平。评论区的反应呈现两极分化：
* **支持者**认为编程是一项易退化的技能。他们将手动输入视为一种“练习曲”——一种强迫专注、建立肌肉记忆并捕捉错误的方式，类似于学生通过抄写讲义或课本来学习。
* **批评者**认为重写代码是“痛苦的”、“按部就班”的苦差事，忽视了行业的发展。他们认为，AI 带来的效率提升应被转向更高层面的任务（如架构、设计和需求收集），而不是沦为“肉体代理”来敲击代码。
* **“中间派”**主张将 LLM 用于研究、构建框架，或作为“小黄鸭”来激发灵感，同时保持对代码库的积极掌控。许多人认为，真正的理解源于自行设计系统并利用 AI 填补空白或提供反馈，而非盲目接受其输出。
在中世纪，食物被视为医学的基石。在盖伦理论的指导下，人们认为饮食是一个在体内“烹饪”食物的过程，以此产生血液、热量和生命精气。健康取决于对食物“热、冷、湿、干”属性的平衡，从而维持体液的和谐。
中世纪的烹饪本质上就是应用饮食疗法。厨师与医师相互配合，确保餐食易于消化，并常通过烘烤、水煮或调味来中和食材的有害属性。例如，人们认为寒湿的鱼类具有危险性，除非通过香料调味或油炸来增加其热性和干燥度。
饮食选择具有高度的个性化，取决于一个人的年龄、职业、社会地位，甚至出生地。虽然节制被奉为美德，但财富使精英阶层能够定制饮食；医师常根据健康需求开具特定的食谱，或给予宗教斋戒的豁免权。归根结底，中世纪的饮食观反映了一种虽与现代不同、却十分复杂的生物学认识，在当时，营养与医疗之间的界限被刻意模糊了。
这篇 Hacker News 帖子讨论了一篇关于中世纪饮食观点的《Literary Hub》文章。讨论很快从文章内容转向了该网站的用户体验。多位评论者对网站侵入性的广告和全屏弹窗表示不满，并指出由于阅读体验不佳，他们经常会跳过此类链接文章。其他参与者则反驳称，可以通过使用 uBlock Origin 等内容拦截器或禁用 JavaScript 来规避现代网页的干扰。
关于文章内容，一位评论者指出，中世纪关于“热性”和“冷性”食物的概念与南亚的阿育吠陀传统惊人地相似。但他们同时也提醒道，文章的分析可能过于宽泛。由于原始作者引用的资料跨越了数个世纪和不同的地理区域，可能忽略了随时间推移在农业、生活方式和食物种类方面所发生的重大演变。
UniFi 网关（包括高端型号）在处理 PPPoE 连接时存在严重的性能瓶颈。这是因为大多数 UniFi 的 SoC 缺乏对 PPPoE 的硬件加速，而 PPPoE 本质上是一个单线程进程，会极大地消耗单个 CPU 核心。因此，用户体验到的速度往往远低于其光纤额定带宽。
为了规避这一限制，ArcBox Labs 提出了一种“PPPoE 半桥”（或称 Zero IP Bridge）解决方案。通过将 PPPoE 认证卸载到辅助设备（例如运行 OpenWrt 的路由器）上，PPPoE 的开销由外部设备处理。随后，该设备通过 DHCP 将公网 IP 地址直接传递给 UniFi 网关。
ArcBox Labs 的解决方案利用 OpenWrt 的 `hotplug.d` 机制实现了该过程的自动化：OpenWrt 设备进行拨号连接、剥离 IP，并管理向后端 UniFi 网关的移交。这有效地使 UniFi 网关能够专注于路由和安全功能，而无需承受 PPPoE 处理带来的繁重 CPU 负担。使用此方法，用户可以成功实现超过 5 Gbps 的线路速度，从而克服 UniFi 当前产品系列固有的硬件限制。
本网站正在使用安全服务来抵御在线攻击。您刚才的操作触发了安全防御机制。触发此拦截的原因可能有多种，包括提交了特定的词汇或短语、SQL 命令或格式错误的数据。
本次讨论围绕《计算机周刊》（Computer Weekly）的一篇报道展开，该报道指出英国议员们质疑为何富士通（Fujitsu）在邮局丑闻之后仍能获得英国政府的高额合同。
Hacker News 的评论者探讨了大型政府 IT 项目背后的系统性失败，核心观点包括：
* **机构无能：** 评论者认为，政府的大型“预付式”合同往往从设计之初就注定失败。这些项目缺乏内部技术监管，导致政府过度依赖大型咨询公司，而这些公司为了利益倾向于追求复杂性而非效率。
* **“供应商锁定”陷阱：** 英国政府在富士通、Capita 或 Atos 等巨头之外几乎没有其他选择。由于这些公司掌握了核心的机构知识和基础设施，很难被取代，从而形成了一种即便供应商表现不佳也会被无限期续聘的恶性循环。
* **治理成本：** 一些人认为，问题的根源不仅在于供应商，还在于那些在管理公共资金时缺乏问责机制的官僚机构。
* **道德义愤：** 用户强调，这起丑闻远不止是“软件漏洞”问题；它涉及系统性的舆论操纵（gaslighting）、对无辜邮局代理商的冤狱，以及相关负责人未能受到真正的惩罚。
舆论普遍认为，这种采购模式已经失效，它过度优先考虑大规模外包，而非建立可持续的内部技术能力。
**PISIGuard** 是一款专注于隐私保护的浏览器扩展程序，旨在保护您在使用 ChatGPT、Claude 和 DeepSeek 等 AI 平台时的数据安全。
许多用户在不知不觉中会将姓名、电话号码、密码和 API 密钥等个人信息共享给 AI 模型。PISIGuard 通过在数据离开浏览器之前在本地自动识别并遮盖这些敏感信息来解决这一问题。它会将敏感信息替换为安全占位符，确保 AI 无法获取您的隐私细节。当 AI 回复后，该扩展会自动还原原始值，从而为您提供自然且无缝的使用体验。
主要功能包括：
* **本地处理：** 所有识别、遮盖和还原操作均完全在您的设备上完成；不会有任何数据被发送到第三方服务器。
* **隐私至上：** 不包含任何遥测、分析或后台进程。
* **兼容性：** 适用于各大主流浏览器（Chrome/Edge/Brave 和 Firefox）。
* **可配置性：** 高级用户可以自定义检测规则，以满足特定需求。
PISIGuard 在确保您的个人信息始终保密的同时，还能让您顺畅使用心仪的 AI 工具，为您带来安心的体验。
*免责声明：本软件按“原样”提供，不提供任何保证。*
PISIGuard（个人身份与敏感信息保护工具）是一款基于浏览器的工具，旨在保护用户与 AI 聊天机器人交互时的隐私。它能自动检测姓名、电子邮件、API 密钥和信用卡号等敏感数据，在将提示词发送给大语言模型（LLM）之前用安全占位符进行替换，并在 AI 的回复中还原原始信息。
该项目近期在 Hacker News 上受到讨论，旨在为非技术用户提供一种简便的解决方案，方便他们无需手动清理隐私细节，即可将文本复制并粘贴到 AI 工具中。虽然一些评论者质疑该工具的必要性，或建议使用微软的 Presidio 等企业级替代方案，但其他人则强调了它在快速、安全地调试及总结敏感文档方面的实用性。
开发者 Mohamed Abdel-Maksoud 解释说，该工具的目标用户是那些通常未意识到数据泄露程度的普通用户。来自社区的反馈推动了文档和品牌形象的改进，相关讨论也探索了未来的可能性，例如扩展该工具以支持代码混淆，或通过本地运行来实现更注重隐私的工作流。
在多年依靠每天四到五杯咖啡来对抗慢性疲劳后，作者决定尝试将摄入量限制在每天早晨仅喝一杯。 在经历第一天强烈的戒断反应（这揭示了作者疲劳的真实程度）之后，效果发生了彻底的改变。通过清除体内残留的咖啡因，作者打破了“因为喝咖啡而疲惫，又因为疲惫而喝咖啡”的恶性循环。 如今，作者表示睡眠质量显著提高，全天情绪稳定且头脑清晰。通过顺应自然的能量水平，而非用过量的咖啡因来掩盖疲劳，作者现在晚上能快速入睡，醒来时也感到真正恢复了活力。这一实验证实，大幅减少咖啡因摄入可以显著改善日常能量水平和睡眠质量。
这份来自 Hacker News 的讨论探讨了改善睡眠质量的策略，并强调个人的需求差异巨大。主要建议包括：
* **规律性**：保持固定的起床时间比严格的就寝时间更重要。
* **咖啡因管理**：许多参与者建议将咖啡因摄入限制在上午，或者完全戒除，以改善深度睡眠和梦境清晰度。
* **睡前习惯**：在睡前 60 到 90 分钟建立一段“放松时间”至关重要。这包括调暗灯光、避免使用屏幕（或使用蓝光过滤器），以及进行阅读小说或听有声书等低刺激性的活动。
* **心态**：对于那些饱受辗转反侧之苦的人，用户建议接受偶尔失眠是不可避免的这一事实。比起在床上干躺着，不如起身做些安静的事情，直到有睡意为止。
* **身体因素**：经常锻炼被广泛认为是有益的，但也有人发现睡前进行高强度运动会影响入睡。补充镁元素以及营造一个舒适、凉爽的睡眠环境也常被提及。
总之，用户强调睡眠是一场“马拉松，而非短跑”，通常需要采取个性化的方法，在饮食、光照和习惯之间找到恰当的平衡。
DMARC 常被误解为一种全面的安全过滤机制，但其实际用途非常有限：它仅用于确认电子邮件中“可见发件人”地址的域名是否已通过 SPF 或 DKIM 对齐验证。 SPF 用于验证隐藏的“信封”发件人，而 DKIM 提供加密签名。DMARC 则是确保这些验证方法与用户实际看到的地址相匹配的桥梁。它在防御精确域名仿冒方面非常有效，但并非万能的解决方案。 DMARC 不会分析邮件内容，这意味着它无法拦截伪装域名、显示名称冒充、遭入侵账户或已通过认证的恶意邮件。此外，DMARC 并非垃圾邮件过滤器，它仅负责验证来源。由于电子邮件转发等合法操作可能导致验证失败，因此在推行严格的 `p=reject` 策略时，必须经过仔细监控，以避免拦截正常的通信。 归根结底，DMARC 是一种身份验证工具，而非信任信号。它能保护您的域名身份并提供有关谁代表您发送邮件的可见性，但无法判断邮件是否安全或真实。真正的安全性要求将 DMARC 作为多层防御策略的一部分，而非将其视为单一的修复方案。
这篇 Hacker News 帖子讨论了一篇关于 DMARC 的博文，但参与者大多认为该文章质量低下，是由 AI 生成的。
技术讨论聚焦于电子邮件验证的机制，强调 DMARC 旨在验证“发件人”地址与 SPF 或 DKIM 协议之间的一致性。用户强调，理解 SMTP 与电子邮件标准（RFC 821 与 822）之间的区别，对于掌握这些安全层如何相互作用至关重要。
讨论中很大一部分内容涉及 `opendmarc` 的“废弃软件”状态，许多技术用户推荐使用 `rspamd` 作为现代、稳健的入站 DMARC 验证标准。其他评论者感叹自建邮箱的难度日益增加，指出 Gmail 等大型服务商强制执行严格的“信任”要求，这使得独立邮件发送变得复杂。归根结底，该帖既是对当前电子邮件安全实践的批评（一些人认为这些做法在应对复杂的欺诈时很大程度上只是流于形式），也是交流可靠开源邮件基础设施工具的资源平台。
```dependencies✖ 单个 Octane 运行时：安装了 2 个 Octane 副本 ✔ Vite 对等范围：vite 8.1.5 符合 ^8.0.16 typescript✖ JSX 导入源：未设置 jsxImportSource ⚠ 类型检查脚本：typecheck 运行的是原始 tsc ✖ 无通配符 .tsrx 声明：在 1 个文件中找到 declare module '*.tsrx' 3 个失败 · 1 个警告 · 11 个通过 `octane doctor --fix` 可以修复 2 个问题。```
前 React 核心团队成员 Dominic Gannaway 发布了全新的 React 风格前端框架 **Octane**，在 Hacker News 上引发了广泛讨论。
Octane 旨在通过摒弃 React 合成事件系统等历史包袱，并提供包括非响应式状态访问在内的编译器优化编程模型，来实现 Web 开发的现代化。开发者指出，该项目有意引入破坏性变更，旨在为当前的生态系统提升性能和开发体验。
然而，社区对此褒贬不一。批评者对该项目的网站内容提出了严厉质疑，称其文案为“AI 垃圾内容”，即那种与 Claude 或 OpenAI 等大模型相关、缺乏灵魂的通用语调。这进而引发了关于技术项目使用 AI 生成营销材料这一趋势的广泛讨论，用户认为此类内容掩盖了幕后开发者的专业水准。
在技术层面，用户对引入 `tsrx` 语法表示怀疑，并质疑 Octane 如何将其自身与 SolidJS 或 React Compiler 等现有解决方案区分开来。尽管一些开发者看好其更小的运行时和改进的状态管理，但也有人对 JavaScript 框架的快速激增感到疲惫。