每日HackerNews RSS

OpenBSD 7.8 带来了显著的网络性能和安全改进。主要更新包括对网络堆栈的大幅增强,采用了软中断线程和并行 TCP 处理,需要多核系统和多队列网络接口才能充分利用。新的高通骁龙图形驱动程序扩展了硬件支持。 安全性得到了加强,重新设计的剖析子系统与 OpenBSD 的安全特性(如 `pledge()` 和 `unveil()`)兼容,并且 OpenSSH 10.0 现在默认使用后量子密钥交换算法。新的工具,如 `lldpd(8)`,实现了基于标准的网络发现功能。 核心守护进程(如 `bgpd(8)` 和 `LibreSSL`)的开发仍在继续,而 `got` 则增加了活跃的功能。然而,`httpd(8)` 和 `relayd(8)` 的开发速度放缓,表明需要新的维护者。初步的 Raspberry Pi 5 支持也已包含,但仍存在一些限制。最后,由于 libpng 更新,基础系统现在支持 emoji 渲染。

## OpenBSD 7.8:关注稳定性和核心基础设施 OpenBSD 7.8 的最新发布带来了一些改进,最值得注意的是原生 libpng 支持——这使得终端能够渲染表情符号。虽然有些用户可能更喜欢通过安装字体来禁用表情符号支持,但此更新凸显了 OpenBSD 持续的开发。 讨论的重点是 OpenBSD 的核心优势:它适用于可靠、安全且易于管理的 инфраструктура,例如名称服务器、路由器以及 Web/邮件服务器。用户称赞其可预测的升级和高质量的软件打包。它也是一个可行的、安全的桌面选择,特别是对于那些喜欢极简设置的用户。 虽然通常功能强大,但 OpenBSD 在较新的硬件(如蓝牙设备和 Nvidia GPU)方面存在局限性,需要使用 USB 适配器等解决方法,或者由于驱动程序可用性而接受有限的支持。尽管存在这些妥协,用户报告了成功的日常使用体验,他们更看重它的简单性和稳定性,而不是最先进的功能。有关此版本的更多详细信息,请参见 Mastodon ([https://bsd.network/@brynet/115403567146395679](https://bsd.network/@brynet/115403567146395679))。

## 算法在现实世界的应用:Git Bisect 与二分查找 尽管人们对面试中偏重算法的问题感到沮丧,但它们在最近的一次调试工作中展现出了实际价值。一个团队面临着大型单仓库中频繁提交导致测试失败的问题,使得传统的调试方法变得困难。问题源于一个引用了错误账户的配置更改,绕过了最初的集成测试。 手动定位问题提交是不切实际的。幸运的是,一位同事使用了 `git bisect` 命令,该命令利用 **二分查找** 算法有效地识别引入错误的提交。通过定义一个已知的良好提交和一个不良提交,`git bisect` 系统地检查中间提交,并运行测试以缩小范围。 虽然每次测试运行都需要时间,但该过程迅速隔离了有问题的提交。回滚该提交解决了问题。这表明像二分查找这样看似学术的算法,是日常软件开发中一种强大的工具,尤其是在像 Git 这样的版本控制系统中,可以节省大量的调试时间和精力。

作者意识到他们的自建实验室,曾经是一种放松的爱好,却因为自己设定的过于复杂的标准而成为了压力的来源。他们受到基础设施即代码、不可变性、自动化(Kubernetes、GitOps、CI/CD)等理念的驱动,创建了一个系统,甚至简单的任务——比如共享文件或安装软件——也变得非常复杂。 这甚至延伸到了他们的日常使用系统(Fedora Silverblue),进一步限制了快速实验。作者意识到这种“纯粹性”并没有带来乐趣,反而阻碍了享受。他们现在正在积极简化配置,除非有益,否则拒绝不可变系统,优先考虑易用性而非严格遵守最佳实践,并放弃复杂的流水线,转而使用更简单的解决方案,如shell脚本。核心要点是:对于个人项目,优先考虑个人享受和实用性,而不是僵化、理论上“更好”的方法。

## 家庭实验室中的“自我制造的牢笼” 一则 Hacker News 的讨论集中在个人项目和家庭实验室过度工程化的倾向,这反映了大型企业 IT 的复杂性。许多评论者对原作者的观点表示认同,他们发现自己陷入了不必要的工具和配置的循环。 核心问题是将为大规模设计的解决方案(“像牲畜一样管理服务器,而非宠物”)应用于小型个人项目。用户通过简化找到了自由——拥抱手动配置,减少自动化,并接受“足够好”而不是完美。 几位用户强调了当专注于*构建*而不是*工具*时,乐趣回归。 提到的解决方案包括使用轻量级系统如 Alpine Linux,将 Bundlewrap 作为 Ansible 的替代方案的简洁性,甚至像 Silverblue 这样的系统所施加的约束,防止对系统级别的调整。 最终,讨论强调爱好应该是有趣的,过度的复杂性会导致拖延症和对实际项目目标的注意力丧失。

韩国正在颁布一项新法律,要求所有拥有80个以上停车位的停车场(包括新建和现有停车场)安装太阳能遮阳棚和车库。这项倡议由贸易、工业和能源部推动,旨在扩大可再生能源生产,并在太阳能和建筑行业创造就业机会。 除了能源效益外,这些太阳能结构还能为驾驶员提供实际优势,遮挡车辆免受天气影响,降低车内温度,从而可能通过减少空调使用来延长电动汽车的续航里程。官员强调,最大限度地利用土地和为公众提供舒适是关键目标。 此举与美国的方法形成对比,因为韩国的法律具有追溯力。然而,类似的工程在美国也正在获得进展,亚利桑那州和纽约州的例子表明,太阳能车库有可能产生清洁能源并扩大电动汽车充电基础设施。韩国的成功可能会激励全球更广泛地采用这种实用的可再生能源解决方案。

启用 JavaScript 和 Cookie 以继续。

## X.Org 安全公告 - 2025年10月28日 关于 X.Org X 服务器(21.1.18 版本之前)和 Xwayland(24.1.8 版本之前)漏洞的安全公告已发布。更新 xorg-server-21.1.19 和 xwayland-24.1.9 解决了 Jan-Niklas Sohn (Trend Micro Zero Day Initiative) 发现的三个严重问题。 这些漏洞包括多个 **使用后释放** 问题:一个在 X11 Present 扩展(CVE-2025-62229)的通知处理过程中,另一个在 Xkb 客户端资源移除(CVE-2025-62230)中。第三个漏洞(CVE-2025-62231)涉及 Xkb 扩展的 `XkbSetCompatMap()` 函数中的 **值溢出**。 这些缺陷可能被利用,导致安全漏洞。强烈建议用户更新到最新版本的 X 服务器和 Xwayland,以减轻这些风险。完整的公告中提供了详细的修复和提交链接。

## X.Org 安全问题与 Wayland 讨论 最近的安全公告强调了 X.Org 的 X 服务器和 Xwayland 中存在多个漏洞。Hacker News 上的讨论集中在这些问题的影响,特别是 X11Libre 分支如何快速应用补丁来解决这些问题。 一个关键的争论点是 X11 设计中固有的安全限制,允许潜在的不受信任的客户端拥有广泛的访问权限。一些人认为这些漏洞通常是理论上的,因为利用率很低,而另一些人则强调需要像 Wayland 这样更安全的架构。 对话还涉及了维护 X11 的挑战、X11Libre 分支背后的动机(最初源于被拒绝的补丁),以及 Wayland 的功能完整性和可用性与 X11 相比的持续争论。 许多评论者对 Wayland 的碎片化以及跨桌面环境缺乏一致的实现表示沮丧。 最后,还讨论了像 Fil-C 这样的工具在减轻 X.Org 等现有 C 代码库中的漏洞方面的潜力。

请启用 JavaScript 并禁用任何广告拦截器。

## Palantir 与招聘的未来:摘要 一篇近期文章讨论了 Palantir 启动一项招聘高中毕业生的计划,这在 Hacker News 上引发了关于传统大学教育对于软件工程职位价值的争论。许多评论者认为,需要一所严格的、为期四年的职业学校,专注于实践技能,并指出学术课程与行业需求之间的差距。 一些用户提到了奥地利和瑞士等国家成功的学徒制模式,在那里,职业培训与学术研究相结合。人们对潜在的剥削表示担忧,一些人认为 Palantir 旨在招聘容易塑造、工资较低的员工。另一些人强调了更广泛的教育的重要性——包括人文科学——以用于伦理考量和批判性思维,而这些技能可能在纯粹的技术型招聘人员中缺乏。 讨论还涉及实习的好处以及纯粹智力之外的经验价值。一些人分享了直接从高中招聘的积极经验,而另一些人则告诫不要认为 18 岁的人已经准备好迎接企业生活的挑战。最终,这场对话的中心是替代途径是否能够有效地培养个人进入科技行业,以及其中可能涉及的权衡。

感谢在Patreon上支持我的各位,包括Jason Pittman, Alexander Shendi, Gustavo Pezzi, Scott Bollinger, Ryan Harris, Rafael Campos, K MI, Nikola Markovic BGD, Wade Brainerd, Mike Garcia, Philip Espi, Vlastimil Holer, Dan Mons, Stephen Smoogen, Bill Marshall, Patater, Brett Owen, Ronald Eichler, Tom Dison, Joe Walker, Magnus Wild, Kwang Lee, Mitchel Valentino, TheGreatCodeholio, Bérenger Doneux, Daniel Monteiro, Mark Eichin, Sparheld International GmbH, Hallmentum LLC, Eric LeBlanc, Luke Abbott, John Paul Wohlscheid, Sean Dobes, Tom Dearden, Eric Smith, SuperIlu, 和 Dwayne。Jim的Patreon。

## FreeDOS C 语言编程:Hacker News 摘要 一场 Hacker News 讨论围绕着使用 C 语言为 FreeDOS 编写程序展开,起因是 freedos.org 的链接。用户分享了各种编译器,重点关注轻量级、MIT 许可的选项,例如 DOS 4.0 源代码中的微软 C 编译器(一个令人惊讶的完整工具链,仅需 1-2MB)。 虽然此微软工具链的源代码不易获得,但 MIT 许可允许二进制分发。有人担心没有源代码进行调试,但另一些人认为该编译器的年龄和彻底测试使其出错的可能性降低。对话还涉及 `curses` 等库的可用性(最近有 PDCurses 移植),以及 DOS 和 FreeDOS 环境之间的差异。 讨论了实际用例,包括维护遗留工业控制系统和业余爱好者的复古游戏/编码。人们注意到在现代 UEFI 系统上启动 FreeDOS 的 BIOS 支持方面的挑战,以及 mUEFIrcate 等解决方案。一些人提倡 Turbo Pascal 作为 DOS 开发的更优语言。最终,讨论强调了 FreeDOS 的价值,包括怀旧、在虚拟机环境中的稳定性以及在老化硬件上保存软件。

## 大本钟的守护者:安德鲁·斯特兰奇威 安德鲁·斯特兰奇威,38岁,是一位负责维护威斯敏斯特大钟的敬业机械师,这座标志性的钟被称为大本钟。自2023年起,他负责在大本钟运行期间处理重要的国家活动,承受着确保精准计时的压力——尤其是在诸如纪念日和除夕夜等场合。 他的日常工作包括在黎明前骑自行车穿过威斯敏斯特桥,然后爬上334级台阶,不仅要维护大本钟,还要维护威斯敏斯特宫内的300座古董钟,以及另外3000个石英钟。调整时间变化,例如10月26日即将到来的时钟调整,是一项特别艰巨的任务。 安德鲁曾是一位数学家和教师,后来改行成为钟表匠,被这项工作的实用性和动手性所吸引。他从钟的机械结构中找到了一种独特的宁静,甚至在165岁的钟中发现了一种“个性”——包括由历史裂缝引起的独特音调。他利用传统方法,例如用维多利亚时代的便士调整钟摆,以及现代技术来保持其准确性。尽管他非常注重细节,但他承认他的团队经常毫不介意地将塔称为“大本钟”。

## 大本钟与一位尽职的守护者 最近的 Hacker News 讨论突出了一篇关于安德鲁·斯特兰格威的文章,他是负责维护大本钟的人——具体来说,是伊丽莎白塔内的时钟和钟声。用户推荐参加上午 11 点的导览,以便在中午听到 12 下钟声,称赞导览揭示了这座标志性地标背后的巧妙工程和“流程黑客”。 对话很快转变为一场关于正确术语的有趣争论: “大本钟”指的是钟声、时钟还是塔本身? 许多人指出,尽管在技术上不准确,但人们在历史上和口语中一直用“大本钟”来指代整个结构。 除了命名讨论之外,该帖子还分享了展示时钟面和塔的历史性大胆维护的视频链接,包括工人在安全措施非常简陋的情况下进行维修的镜头。 一位用户甚至幽默地将其与一部英国情景喜剧联系起来,该喜剧讲述了“大本钟上的互联网”的管理员。

## 证明助手的发展:从依赖类型到高阶逻辑 本文详细描述了作者数十年开发Isabelle证明助手的心路历程,以及他们对数学形式系统的不断演变观点。最初,作者探索了依赖类型理论,始于1977年接触N.G. de Bruijn的AUTOMATH系统。虽然印象深刻,但他们发现AUTOMATH缺乏更强类型理论中直接的Curry-Howard对应关系。 后来,马丁-洛夫类型理论吸引了作者,甚至构成了Isabelle的第一个版本(Isabelle/CTT)的基础。然而,教义上的分歧和内涵相等性问题促使他们改变了关注点。他们观察到构造演算(用于Lean)也引发了对基础稳定性的类似担忧。 最终,作者倡导了一种通用方法,使Isabelle能够适应各种逻辑。这导致Isabelle/HOL占据主导地位,它建立在Church的简单类型理论和公理化类型类之上。通过ALEXANDRIA项目的资助,最近证明了高阶逻辑形式化极其复杂的数学的能力——甚至超出了预期并消除了批评。尽管像Lean这样的依赖类型理论取得了成功,作者仍然致力于高阶逻辑,理由是那些系统中的性能问题和复杂性。他们总结说,选择一种形式主义并将其推向极限是一种有效的研究途径,而Isabelle/HOL继续证明其力量。

## 依赖类型:务实讨论 这次Hacker News讨论围绕一篇质疑依赖类型在形式化验证和编程中广泛应用的文章展开。文章承认依赖类型的强大之处——例如精确地类型化矩阵等数据结构——但核心论点是它们并非构建健壮系统所*必需*的。 许多评论者强调了权衡:依赖类型会引入复杂性和调试挑战,可能减慢开发速度。当处理复杂的不变量时,优势才最明显,但对于许多任务,像Isabelle/HOL(一个证明助手)中采用的更简单的方法——利用自动化、广泛的库和易读的证明——更实用。 一个关键点是开发者体验的重要性。学习曲线和潜在的复杂类型错误可能超过收益。一些人讨论了替代方法,例如在Python中使用`torchtyping`等库进行类型注解,或者利用C++和Rust等语言的编译时元编程来实现类似的安全性保证。最终,共识倾向于选择合适的工具来完成工作,认识到依赖类型并非通用解决方案。

更多

联系我们 contact @ memedata.com