本网站正在使用安全服务来抵御网络攻击。您刚才的操作触发了安全防护机制。触发此拦截的原因可能有多种，包括提交了特定的词汇或短语、SQL 命令或格式错误的数据。
每日HackerNews RSS
一位 Hacker News 用户分享了其受 Turtle（海龟绘图）启发的交互式 Python 项目 *codembark.com*。在测试期间，有用户遇到了 `ModuleNotFoundError`，原因是该平台的入门教程引导用户导入了一个在项目后期阶段才可用的模块。
创作者 *camdenreslink* 承认了这一困扰，并指出当前的“欢迎”步骤设计可能存在缺陷。他们正在考虑修订新手引导流程，例如直接让用户进入项目代码，以防止此类错误再次发生。
在讨论中，评论者们回顾了各自与 Turtle 图形的渊源。一些人指出，虽然 Scratch 等工具往往更能吸引孩子，但人们依然渴望拥有那种将空间定位直接集成到编程交互中的开发环境。
本报告总结了全球 SSH 蜜罐项目头 30 天（2026 年 7 月）的运行情况，该项目涉及分布于 5 家 VPS 服务商的 15 台服务器。该网络通过 Ansible 进行管理，并使用 Podman 容器化的 Python/Paramiko 脚本运行，共记录了来自 6,790 个唯一 IP 地址的 1,531,053 次登录尝试。
**主要发现：**
* **地理趋势：** 虽然亚洲贡献了最多的攻击源唯一 IP（60.1%），但欧洲产生的登录尝试总量最高（60.2%），主要受罗马尼亚和荷兰的高强度活动驱动。
* **凭据：** 分析显示共有 131,922 对唯一凭据。攻击模式依然简单，其中“root”是主要用户名，“123456”是最常用的密码。
* **基础设施：** 大量流量源自不同的 ASN，其中 TechTies Inc. (AS197170) 的登录尝试量占比异常突出。
该项目目前处于进行中阶段，数据可通过采用 CC BY 4.0 许可的开源存储库获取。未来的目标包括扩展至其他服务（数据库、Web、FTP），与 AbuseIPDB 等威胁情报平台集成，并开发实时仪表板。欢迎提供反馈及进一步分析的建议。
抱歉。
2026年7月30日下午6:22，Robin Candau 写道： 大家好， 由于目前 AUR 中出现了大量恶意软件包接管及后续提交的情况，我们在处理该问题期间已暂时禁用软件包接管功能。待问题解决后，我们会另行通知。在此期间，请随时举报尚未处理的可疑接管事件或提交，并保持警惕！感谢您的理解。 祝好， Antiz（代表 Arch Linux DevOps 团队） 大家好， 在我们处理该情况的同时，我们目前已完全禁用了推送功能。对于造成的不便，我们深表歉意。 顺颂商祺， Robin Candau / Antiz
Hacker News 最近的一场讨论凸显了人们对 Arch 用户仓库 (AUR) 安全性的持续担忧，此前曾发生过软件包推送被暂停的事件。
用户们讨论了 AUR 固有的风险。该平台采用“自由放任”模式，任何人都可以上传软件包。尽管 Arch Linux 明确警告 AUR 并非经过审核的存储库，但许多用户仍对审核复杂的 `PKGBUILD` 脚本的难度表示担忧。一些人坚持认为，只要核实下载链接和校验和，审核工作就非常简单；而另一些人则反驳称，现代复杂的供应链攻击使得普通用户难以进行手动审查，尤其是在处理私有驱动程序或复杂的构建依赖时。
该话题触及了保障开源软件安全这一更广泛的挑战。评论者指出，虽然用户理应为自身安全负责，但 AUR 的便利性导致许多人对其产生了盲目的信任。一些贡献者建议，为了提高安全性，开发者应转向由正式且有资金支持的基金会来管理软件包的完整性；但也有人指出，在业余项目中，这种繁琐的“文书工作”缺乏经济激励。最终，各方共识是 AUR 用户必须保持高度警惕。
开发者工具的演变——从 Vim 和 Emacs 的高度可定制性到现代代理式 AI——凸显了在效率与信任之间寻求平衡的持续博弈。尽管 AI 代理能快速生成代码，但其非确定性及其带来的“信任鸿沟”在代码审查、验证和基础设施管理方面制造了新的瓶颈。 本文认为，仅靠工具无法解决这些问题；如果不更新组织文化和流程而过度依赖 AI，往往会导致工作流的崩溃。为了重获可靠性，开发团队必须转变观念，不再将工具视为单纯的生产力助推器，而是将其作为严谨的、以人为本的系统的一部分。 重建信任的关键策略包括： * **保持人为问责：** 确保开发人员对所提交的代码承担全部责任，无论 AI 参与程度如何。 * **建立明确的工作流：** 用清晰的规范和共享的上下文取代模糊性。 * **优先考虑可持续性：** 关注代码重用，并避免在传统确定性代码更可靠的场景下使用非确定性 AI。 归根结底，成功的工程组织将是那些将 AI 整合到能够保留人类判断力的反馈回路中，而非仅仅追求原始产出速度的组织。
本次讨论聚焦于开发者为何会对特定工具产生深厚的情感依赖，以及这种信任为何正受到现代软件趋势与人工智能的挑战。
**核心议题包括：**
* **信任与可预测性：** 开发者青睐 Vim 或 Emacs 等工具，是因为它们稳定、可预测，且尊重“肌肉记忆”。相比之下，现代软件趋势（如强制自动更新和界面频繁变更）通过不断改变开发环境，削弱了这种信任。
* **“速度谬误”：** 许多公司为了交付功能而牺牲稳定性，往往损害了用户体验。这导致软件陷入“流沙”陷阱，更新不仅引入漏洞还删减功能，最终迫使用户转向竞争对手。
* **人工智能的干扰：** 虽然 AI 编程助手提供了极高的速度，但也带来了明显的阻力。由于 AI 具有概率性、不透明且不断变化的特性，它将开发者的角色从“创作者”转变为“审查者与调试者”。许多参与者认为，AI 带来的所谓生产力提升，往往被修复缺陷代码和管理 AI 不可预测行为所花费的时间抵消了。
* **管理与工艺：** 人们对“只需提交提示词（Prompt）”的思维方式日益怀疑。许多观点认为，可持续的工程实践需要深厚的理解与严谨的测试，而非依赖不可靠的“黑盒”式智能代理工具。
访问受限 抱歉，您所在的地区无法访问此页面。感谢您的理解。
最近的报告显示 Linux 桌面在北美的市场份额已突破 10%，这在 Hacker News 上引发了广泛讨论。虽然许多用户持乐观态度，但也有人提醒要谨慎看待这些数据，指出 StatCounter 的统计方法可能将“未知”流量误分类，或者统计到了自动化机器人活动，而非真正的用户。
讨论的核心主题包括：
* **采用驱动力：** 爱好者指出，Steam 的游戏支持、Windows 11 对硬件的高要求，以及人工智能辅助故障排查提升了 Linux 的易用性，这些是主要促成因素。
* **实际应用场景：** 由于 Windows 的授权限制，回收商和二手店越来越多地预装 Linux 系统。与此同时，开发者发现 Windows 对于现代工作流程而言正变得越来越难用。
* **遗留障碍：** 尽管有所增长，用户仍指出存在一些“棘手问题”，例如驱动兼容性和配置问题，与主流操作系统相比，这些仍是挑战。
总的来说，尽管 10% 的数据仍有争议，但社区一致认为，得益于技术进步、硬件要求变更以及用户辅助工具的完善，Linux 正在成为一个更加可行且受支持的生态系统。
**Garden Eternal** 是由 Khalid Alshaikh 创建的一个数字保存项目，它通过基于浏览器的功能性 Windows 98 环境，重现了 20 世纪 90 年代的网络体验。 该网站不仅限于静态截图，还还原了早期互联网“失落”的交互性。它允许用户体验现代浏览器不再支持的旧技术，如 Flash、Java、MIDI 音频、VRML 3D 世界以及动态留言板等。该平台是一项数字历史的活体实验，记录了 Alshaikh 在归档沙特阿拉伯近代史及业余无线电（7Z1FP）方面的工作，同时也为“Gopher”协议提供了一个罕见的访问入口。 该项目的名称体现了其初衷：为那些在其他地方已被删除或废弃的数字遗迹提供“第三生命”，使其能够再次生长并发挥作用。通过将归档视为一个主动过程而非被动记录，Garden Eternal 确保了那个早期互联网的阅读空间能够像内容本身一样充满活力。
抱歉。
请启用 JavaScript 和 Cookie 以继续。
该 Hacker News 讨论帖围绕一篇关于 TP-Link TL-841N 路由器固件 root 与分析的技术文章展开。
讨论很快延伸至多个相关技术领域：
* **工具与发行版：** 参与者讨论了各种串口通信工具的优劣，`tio` 被推荐为 `picocom` 的有效替代品。这引发了关于 Arch Linux 软件包管理偏好以及 Snap 与 Flatpak 持续争论的旁议。
* **硬件黑客技术：** 用户指出，尽管 TL-841N 由于年代久远且资源受限，在现代网络环境中已显过时，但它仍是学习硬件黑客技术的廉价且热门的平台。
* **OpenWRT 与路由器硬件：** 讨论转向了寻找支持 OpenWRT 的现代平价硬件的难度。一些用户推荐了特定的高性价比型号（如 Cudy WR3000 或 Totolink X5000R），另一些用户则讨论了在专有固件上维护复杂网络配置（如 IPv6 隧道）所面临的挑战。
* **内存安全：** 对话最后简要探讨了使用内存安全语言编写的路由器固件，特别提到了由 Go 语言编写的项目“router7”。
本仓库提供了一系列工具，用于在 NVIDIA DGX Spark 和 Asus Ascent GX10 系统上运行 **Nix**。用户既可以直接在默认的 DGX OS（Ubuntu）上运行 Nix 配置，也可以进行 **NixOS** 的完整安装，以获得完全可复现的系统体验。
**核心功能：**
* **灵活部署：** 可作为原生 NixOS 系统运行，也可在现有的 DGX OS 安装中使用 Nix 开发 Shell。
* **硬件支持：** 包含一个专用的 NixOS 模块，提供优化的 NVIDIA 内核、通过 DGX Dashboard 进行系统遥测，以及通过 `fwupd` 进行固件更新支持。
* **简化配置：** 自定义 Flake 模板可实现轻松的项目初始化，智能化的内核配置管理则最大限度地降低了维护开销。
* **性能优化：** 集成二进制缓存（Flox 和 Cachix），显著加快了 CUDA 和 AI 工作负载的构建时间。
* **广泛的工作负载：** 仓库内置了针对主流 AI 任务（如 ComfyUI、FLUX.1 微调、vLLM 和 TensorRT-LLM）的预配置开发 Shell。
**入门指南：**
如需部署，请更新固件、构建自定义 USB 镜像，并遵循标准的 NixOS 安装步骤。对于现有的 DGX OS 系统，只需安装 Nix，并按照文档说明配置实验性功能和缓存即可。
Hacker News 上的这个讨论帖介绍了由用户 `graham33` 开发的项目 **NixOS-DGX-Spark**，该项目提供了一系列 NixOS 模块和配置脚本，用于支持 NVIDIA DGX Spark 系统（以及华硕 Ascent GX10 设备）。
讨论的一个核心主题是 **NixOS 与 AI 编程助手**（如 Claude、DeepSeek 等）之间的协同效应。用户们表示，尽管 Nix 的学习曲线向来陡峭，但大语言模型（LLM）从根本上改变了这一体验，它们能够高效地处理系统配置、故障排查和软件包管理。由于 NixOS 允许将整个系统状态定义为代码，它提供了一个“无副作用”的环境，特别适合 AI 智能体进行迭代、调试和维护复杂的架构。
贡献者们指出，尽管交叉编译和 Flakes 等“实验性”功能仍具挑战性，但能够维护一个可复现、版本可控的系统，相比传统的操作系统管理方式是一次巨大的升级。该项目因在管理无头设备和 AI 硬件方面的实用性而受到赞誉，用户强调它简化了家庭实验室及专业部署环境的工作流程。
**Kakehashi** 是一个以 CLI 为核心的翻译层，能够让 macOS (Darwin) aarch64 二进制文件直接在 Linux aarch64 主机（如 Docker、Colima 或裸机 UTM）上运行。 Kakehashi 不使用指令模拟（JIT），而是让访客代码在 CPU 上原生执行。它的工作原理是映射一个独立的 `libSystem.B.dylib` 并翻译 BSD 系统调用，从而允许 `7-Zip` 和 `curl` 等 Darwin 工具在 Linux 上运行。 **主要特性：** * **性能：** 虽然系统调用边界的开销使得它在处理高频交互任务时比原生 macOS 慢约 5 倍，但与昂贵的 macOS CI 运行器相比，其性价比显著更高。 * **CI 友好：** 专为将 Darwin CLI 工作负载分流至成本更低的 Linux aarch64 基础设施而设计，无需专用 SDK。 * **无缝集成：** 使用“容器（bottle）”系统来桥接文件系统，将 Linux 目录映射到 Darwin 环境（例如 `/Volumes/linux/`）。 * **零安装运行：** 必要系统库已嵌入二进制文件中，安装过程仅需执行 `cargo install kakehashi`。 Kakehashi 并非商业产品，而是一款用于在 Linux 环境中运行已验证 Darwin CLI 制品的专用工具，旨在 Apache 2.0 协议下平衡性能与基础设施成本。
**Kakehashi** 是一个实验性的开源项目，旨在让 macOS 命令行二进制文件在 Linux ARM 机器上原生运行。该工具由 Vlad Kalinkin 使用 Rust 开发，完全在用户空间运行，无需内核级修改或 root 权限。
目前，该项目已成功实现了 7-Zip、`curl` 以及 Xcode 套件中部分基础 Git 命令的原型。开发者的长期目标是实现对 Xcode 工具的全面支持，从而在 Linux 上进行 iOS 应用开发，并可能支持 macOS 版本的 Homebrew。
该项目在 Hacker News 上引发了关于其技术路线及成功潜力的热烈讨论。批评者强调，复制 macOS 庞大且不断演进的 ABI（应用程序二进制接口）难度极大，并将该项目与 Darling 等类似尝试进行了对比。开发者指出，尽管他们在开发中使用了人工智能辅助，但 Kakehashi 是使用 Rust 从零开始的净室实现，与 Darling 的 C/Objective-C 架构不同。尽管技术障碍依然巨大，但社区对项目的进展表现出了浓厚的兴趣，特别是在跨平台音乐制作和软件开发等细分领域。
在1930年代至1990年代之间，由密尔沃基电力铁路与照明公司（Milwaukee Electric Railway & Light Company）开创的密尔沃基公交系统，曾推出过一系列既美观又实用的周票。从1930年代起，公交管理部门超越了单纯的实用主义设计，开始制作色彩丰富、手工绘字的车票，票面上印有独特的插画、城市历史和当地活动信息。即使在系统从私营转为市政管理后，这种手工设计的传统依然得以保留。
如今，档案库保存了大约300张1932年至1969年间的“袖珍珍品”。尽管最初的设计者大多已不可考，但这些车票仍是公共环境下平面设计持续演变的杰出范例。在公交卡已变得标准化且平淡无奇的今天，这些历史文物为设计师提供了灵感，也提醒着人们视觉识别的力量。随着各城市寻求振兴公共交通客流量，密尔沃基车票的历史表明，将“视觉愉悦”带回日常通勤，或许是与乘客重建联系的一种有效方式。
最近在 Hacker News 上，一篇关于历史上手工设计交通票证的文章引发了一场讨论，进而演变为一场关于审美设计与现代实用性之间张力的更广泛辩论。
传统票证的支持者认为，美观且频繁更新的设计能够激发城市自豪感，不仅是有效的防伪手段，也成为了令人难忘的文化纪念品。相反，批评者则认为现代公共交通必须优先考虑无障碍和便捷性。他们主张，复杂的票务系统和人工流程加重了旅客的负担，公共交通应当是一种底层的公共事业——理想情况下应支持无缝对接的非接触式“感应支付”系统。
这篇讨论凸显了一种根本性的文化摩擦：一些用户担心，对“电子表格驱动”的效率和规避风险的执着，正在剥夺世界的个性和美感。另一些人则坚持认为，政府服务，尤其是交通，首要职责是功能性和包容性，并认为不应以牺牲易用性为代价来追求“艺术”。归根结底，这场讨论反映出人们渴望在现代基础设施的效率与精心设计、具有触感的体验所带来的以人为本的魅力之间寻求平衡。