(Empty input provided. There is nothing to translate.)
每日HackerNews RSS
## 间歇性 Pod 创建失败，CPU 限制为 4096m 使用 systemd cgroup 驱动的 Kubernetes 中，CPU 限制为 4096m 的 Pod 间歇性地创建失败。根本原因在于 containerd 在将毫核转换为微秒时，CPU 配额计算结果不确定（4096m 有时变为 409600µs，有时变为 410000µs）。Runc 一致地计算为 410000µs。 这种不匹配违反了 cgroup v1 约束（子配额不能超过父配额），导致内核错误和 Pod 失败。问题似乎与节点相关，因为失败的 Pod 会导致父 cgroup 停留在 409600µs，从而导致该节点上后续的 Pod 创建也失败。 该问题在将 CPU 限制从 8192m 降低到 4096m 后出现，影响了分数核心值。它与过时的 cgroup 无关，而是 containerd 在 Pod 沙箱创建期间进行的不一致的初始计算。该问题影响 containerd 1.7.27、runc 1.3.2 和 Kubernetes 1.30.14-eks。修复需要 containerd 中确定性和一致的毫核到微秒转换逻辑，与 runc 对齐。
最近的 Hacker News 讨论围绕着针对容器运行时 `runc` 提交的一份错误报告，内容涉及 CPU 请求处理。核心问题是：如果 CPU 请求不是 10 的倍数，`runc` 会导致 Pod 崩溃。然而，报告本身引发了争论，因为它完全由 LLM 生成，导致对其冗长和不简洁的风格的批评——具有讽刺意味的是，尽管 LLM 具有总结能力。
许多评论者对人工智能生成的内容在开源项目中的日益增长的趋势表示沮丧，认为浪费了维护者的时间，并且难以解析“人工智能垃圾”。 发现该问题已通过拉取请求修复。
进一步调查显示，该报告可能暴露了敏感的客户信息（一家使用 AWS 的保险公司），该信息与 Accenture 的人工智能基础设施项目相关联，引发了对粗心数据处理的担忧。 这次讨论凸显了人们对开源贡献方向以及 LLM 对项目质量和安全性的影响的担忧。
## eForth：一种现代Forth实现 eForth 是一种精简的、跨平台的 Forth 实现，旨在使这种语言更容易被 C/C++ 程序员接受。项目认识到 Forth 尽管具有优势却在衰落，因此专注于易于理解和现代工具。 主要特性包括一个动态的、基于向量的字典，取代了传统的链表方法，简化了单词的定义和执行。该实现优先考虑核心概念，省略了词汇表和元编译等复杂特性。最近的版本 (v5.0+) 引入了多线程，利用线程池和消息传递来实现并行执行。 核心代码使用 C/C++ 编写，注重性能。基准测试显示，与经典的 Forth 实现相比有所改进，但优化仍在进行中。该项目提供适用于 Linux、macOS、Windows、WASM 和 ESP32 微控制器的构建版本。 eForth 为学习 Forth 甚至构建自定义实现提供了基础，GitHub 上提供了一个包含大量注释的 800 行核心代码。它代表了 Forth 的一种现代方法，旨在弥合其强大功能与当代开发实践之间的差距。
## 认知能力下降与社交媒体：日益严重的危机 最近发表在《神经病学》杂志上的研究显示，美国人口的认知困难——注意力不集中、记忆力下降或难以做决定——正在令人担忧地激增。该研究分析了十年内来自450万份调查问卷的数据，发现“认知障碍”的比例从5.3%上升到7.4%，但在18-39岁成年人中*翻倍*，并且在所有人口群体中都在上升。 这种增长始于2016年左右，早于疫情爆发，表明与技术和社交媒体的普遍影响有关。作者推测社会隔离和对技术依赖增加等因素，但数据表明了一种更根本的转变——一种文明正在通过持续的刺激和外包思维来积极“重塑其神经系统”。 其影响是重大的，不仅限于个人挣扎，还可能破坏民主功能，因为分散的注意力会阻碍知情的公民参与。虽然需要进一步调查，但这项研究表明，在数字饱和的环境中，认知能力正在崩溃，年轻一代尤其脆弱。
最近的 Google Project Zero 报告详细描述了一种漏洞，该漏洞允许在 Pixel 设备上绕过内核地址空间布局随机化 (KASLR)——本质上，绕过一项关键的安全措施。核心问题在于 Linux 内核在 arm64 上的线性映射未随机化，并且内核加载到静态物理地址。
有趣的是，最初向 Google 和 Linux 内核团队报告这些问题的研究人员发现，双方都认为这是“预期行为”，并且没有立即计划修复。
Hacker News 评论区的讨论强调了一个更广泛的观点：定制的 Android 构建，即使只是简单的编译器调整，也可能比已修补的 iOS 或原版 Android 具有更好的安全性，因为针对独特配置制作漏洞利用的难度更高。缺乏随机化部分归因于热插拔内存的复杂性，这是一种主要用于虚拟化环境的利基功能。最终，争论的中心在于平衡安全性和功能性，以及设备设计中做出的权衡。
## SGI IRIX 操作系统：简要历史
SGI 的 IRIX 操作系统与它的硬件一同发展，最初使用摩托罗拉 CPU 的系统，随后过渡到基于 MIPS 的工作站。早期版本如 4D1 (1988) 基于 UNIX System V Release 3，并带有 BSD 增强功能和 4Sight 窗口系统。后来，SGI 采用了 X Window System (X11) 并进行了自定义。
IRIX 5.0 (1993) 引入了 UNIX System V Release 4 的特性，包括 ELF 可执行文件，并随后整合了 XFS 日志文件系统。完整的 64 位支持随 IRIX 6.0 (1994) 发布。
最终版本 IRIX 6.5.30 (2006) 标志着积极开发的结束，尽管支持一直持续到 2013 年。选择合适的 IRIX 版本很大程度上取决于具体的 SGI 系统——它的系列、处理器和图形硬件。
主要版本包括 5.3 (适用于较旧的 R3000 系统)、6.2 (适用于低端 Indigo/Indy 配置) 以及 6.5.22/6.5.30 (适用于较新的系统，如 O2 和 Octane)。硬件限制，例如 RAM 大小，也会决定合适的版本。
## IRIX：一段怀旧的回顾
最近在Hacker News上的一场讨论引发了人们对SGI的IRIX操作系统及其对图形和计算的影响的回忆。IRIX以其视觉上吸引人的GUI（在macOS X之前被认为是最好的）而闻名，它驱动着在图形密集型领域流行的强大工作站。
对话强调了IRIX对XForms（Xfce的基础）和FLTK工具包等技术的贡献，后者最近收到了13年来的首次更新。尽管具有创新性，SGI在商业模式上遇到了困难，专注于利基市场且缺乏消费级应用程序。
用户分享了个人经验，从使用IRIX作为大学服务器和早期Unix学习，到遇到SGI不愿向某些客户销售的情况。讨论还涉及MIPS架构、XFS的起源（现在是Red Hat的重要组成部分）以及3D文件管理器fsn。尽管最终衰落，IRIX仍然留下了深刻的印象，许多人希望其功能能够得到现代复兴。
展示HN：PingStalker – 一款面向网络工程师的macOS工具
Show HN: PingStalker – A macOS tool for network engineers
19 天前
PingStalker 是一款全面的 Mac 网络监控工具，提供连接健康和性能的实时洞察。它为关键主机提供**实时 Ping 监控**，由 Cloudflare 提供支持的详细**速度测试**，以及清晰的**接口详情**显示，如 IP 地址和 Wi-Fi 强度。
除了基本监控外，PingStalker 还提供**无线网络分析**，显示信号强度和信道使用情况，一个方便的**子网计算器**，以及带有供应商识别的**MAC 地址查找**。高级用户可以利用**Wi-Fi 嗅探/监控模式**，并轻松集成到 Wireshark 中。
重要的是，PingStalker 具有强大的**网络日志记录**功能，被动地观察和记录重要的网络事件——从意外的 Ping 到 VLAN 暴露——为主动故障排除提供详细的网络活动记录。
## PingStalker：macOS网络工具简介
PingStalker是一款为网络工程师和专业人士开发的macOS工具，提供了一个基于GUI的网络诊断替代方案，取代了命令行界面。这款工具的创建者是一位对CLI局限性感到沮丧的Wi-Fi工程师，旨在提供对局域网/无线局域网网络活动的全面、实时视图。
该工具执行ARP、ICMP、mDNS和DNS扫描，以识别设备、监控延迟、检测VLAN以及捕获关键网络流量，例如DHCP事件和身份验证数据。一个独特的功能是自定义厂商logo数据库，可在扫描结果中直观地识别设备。PingStalker使用Swift构建，并同时利用BSD sockets和Apple的网络框架，优先考虑速度和可靠性。
开发者正在积极寻求关于潜在改进的反馈，包括移植到Linux/BSD、扫描速度优化和可视化增强。未来的计划包括iOS、Android和Windows版本，以及视觉traceroute和扩展的Wi-Fi分析功能。目前，它可直接从开发者的网站下载，并提供为期一天的试用期。
## 通过反向工程访问 GPT-5-Codex-Mini
一个部分发布的 OpenAI 模型，GPT-5-Codex-Mini，通过巧妙的变通方法被直接访问。最初仅限于 Codex CLI 工具，一位开发者通过修改开源 CLI 本身，而非直接分析 API，来反向工程了该工具的 API。
使用基于 Rust 的 Codex CLI，该开发者添加了一个“codex prompt”子命令，允许直接提示新的模型。这涉及到指示 AI 构建和修改其自身代码库，所需的 Rust 手动编码最少。最初的尝试面临模型试图执行工具的问题，但通过强制进行无工具请求得以解决。
该过程揭示了 API 端点 (`https://chatgpt.com/backend-api/codex/responses`) 以及在请求中包含特定指令的必要性。虽然生成的 SVG 结果不尽如人意，但该实验成功地展示了对 GPT-5-Codex-Mini 的直接访问，并突出了 AI 辅助代码修改的力量。修改后的代码，包括用于检查请求的调试选项，是公开可用的。
## 赫菲斯托斯：自适应人工智能工作流
赫菲斯托斯是一个新框架，旨在利用人工智能代理处理复杂的软件项目，克服传统代理系统的局限性。 与需要为*每个*可能场景预定义指令的系统不同，赫菲斯托斯采用“半结构化”方法。 它定义了广泛的**阶段类型**（计划、实施、测试），并允许代理根据其发现动态地在这些阶段内创建任务。
这产生了一个自我构建的分支工作流——如果测试代理发现了一个优化点，它会自动生成一个调查任务，而不是因为缺乏预编程指令而受阻。 演示展示了赫菲斯托斯根据PRD构建一个Web应用程序，展示了代理如何并行工作、发现优化并处理错误修复，所有这些都通过动态生成的看板协调。
赫菲斯托斯在结构（阶段定义、明确的完成标准）与灵活性（动态任务创建）之间取得平衡，从而实现能够实时适应意外发现的工作流。 它需要Python 3.10+、tmux、Git、Docker、Node.js，以及兼容LLM（如OpenAI或Anthropic）的API密钥。 快速入门指南和全面的文档可在项目的GitHub页面上找到。
## 赫菲斯托斯：自主代理编排
赫菲斯托斯是一个新的开源框架，用于编排多个AI代理，最近在Hacker News上分享。它的目标是通过分解成逻辑阶段来构建复杂的任务，从而允许代理并行工作。创建者idolevi设想了软件开发之外的应用，包括研究和投资工作流程。
早期的反馈强调了在快速发展的LLM领域中增加复杂性的问题，以及对强大调试能力的需求。idolevi承认了这一点，表示赫菲斯托斯是第一个版本，并且正在积极开发工具来学习和适应现有的代码库，最终目标是加快开发周期。
用户指出它与现有工具如vibe-kanban和superpowers相似，而另一些人则对生产环境中潜在的代码库失控增长表示担忧。初步设置被报告为复杂，开发者打算解决这个问题。该项目正在积极寻求贡献，并计划保持开源。
因滥用流量模式而被阻止。