在代理式人工智能（Agentic AI）辅助下的软件工程，需要平衡两种截然不同的模式：“温室”与“透镜”。 “温室”用于探索；它拥抱混乱与迭代，旨在当你尚未拥有明确目标时，挖掘出潜在的价值。“透镜”用于执行；它将所有精力集中于特定的已知目标，以实现既定成果。这两种模式并无高低之分，它们只是适用于不同工作阶段的工具。 当我们混淆了当前所处的模式时，挫败感便油然而生——例如本该实验时却在打磨原型，或者本该交付时却在漫无目的地搭建架构。真正的专业能力，在于能够识别当前所需的模式，并利用你的“领域智库”（即你对项目的思维模型）来引导流程。这种内在的指南针能让你从“温室”的实验中筛选出精华，或摒弃“透镜”模式下的干扰。要做到高效，必须培养一种纪律性：明确当前的目标，并有意识地在积蓄能量与聚焦能量之间进行切换。
每日HackerNews RSS
抱歉。
抱歉。
本项目展示了一个开源 Python 脚本，旨在为 Fusion 360 等 CAD 软件生成参数化摆线减速机。
该项目的开发经历了多次迭代。最初的微型化尝试（1:9 速比）因 3D 打印精度无法满足严苛的公差要求而失败。后续设计增加了占地面积以提供更大的间隙，最终成功完成了“版本 3”。这款功能性 90mm 减速机专为 NEMA 17 步进电机设计，输出扭矩为 1.28 N·m，效率达 66%。
所提供的 Python 脚本利用精确的参数方程来定义转子几何形状、外壳销和偏心距。用户可以自定义销数量 ($N$)、节圆半径 ($R$) 和偏心距 ($E$) 等变量。文档包含了优化策略，例如使用 MR128 轴承替代外壳销，或使用金属包裹的输出销来提高刚度和机械效率。对于希望通过增材制造实现高扭矩、紧凑型摆线驱动装置的用户而言，本项目是一项极佳的资源。
一位15岁的开发者最近在 Hacker News 上分享了一个项目：一个自制的**摆线减速机**。这篇帖子在社区中引发了热烈的讨论，主要集中在以下三个方面：
* **工程验证**：大多数用户赞赏这位少年的行动力、工艺水平和文档记录，并鼓励他不必拘泥于“准工程师”的标签。虽然一些评论者指出“工程师”在某些地区或行业是受保护的职称，但另一些人则认为，工程学的定义在于构建和解决问题的过程，而不仅仅是凭证。
* **鼓励与指导**：社区提供了切实的建议，例如测量齿隙和效率以提供真实的性能参数。许多用户还向这位少年推荐了像 *Hack Club* 这样的资源，以便他与更多年轻的创客建立联系。
* **人工智能的影响**：辩论的很大一部分集中在人工智能工具如何改变开发环境。虽然有些人感叹 AI 让项目显得没那么“手工制作”或“充满魔力”，但另一些人则认为，它仅仅是一种工具，让创作者能够更快地实现更宏大的目标，从而将工程师的角色从劳动力转变为架构师。
在为 PennyLane 构建量子编译器 Catalyst 的过程中，开发团队意外地创建了一个基于 MLIR 的独立 JAX 编译流水线。 为了优化量子-经典混合工作流，团队需要捕获经典的 Python 和 JAX 代码，将其表示为 MLIR，并支持原生的控制流和动态数组形状。通过绕过传统的 XLA 编译器后端，直接将 JAX 表示转换为标准的 MLIR 和 LLVM，他们发现 Catalyst 可以将纯粹的非量子 JAX 代码编译为独立的机器码。 相比基于 XLA 的标准 JAX 工作流，这种架构具有几项独特优势： * **独立二进制文件：** 无需依赖繁重的外部运行时（如 PJRT/Bazel）。 * **动态形状：** 支持可变长度的张量，无需触发昂贵的重新编译。 * **原生控制流：** 无缝集成标准的 Python 循环和条件判断。 * **边缘部署：** 通过去除运行时开销，支持部署到嵌入式设备或定制硬件上。 尽管该“意外”产生的编译器并非旨在取代大规模深度学习任务中的 XLA，但它为从事定制硬件、边缘机器学习或专业编译器基础设施研究的人员提供了一种灵活且低开销的替代方案。
抱歉。
本指南提供了优化 ASRock BC-250 性能与效率的核心方案。
**关键调整：**
* **显存 (VRAM)：** 将显存分配提升至 6GB（取代默认的 512MB），以避免纹理质量问题。
* **着色器 (Shaders)：** 禁用 Steam 的预缓存着色器下载，因为它们会与 BC-250 生成的缓存冲突。在 `/etc/environment` 中将着色器缓存上限设置为 5GB 以提升性能。
* **GPU：** 使用 `cyan-skillfish-smu` 调节器以实现动态时钟缩放及能效优化。使用 `BC250 Live Manager` 解锁额外的计算单元 (CUs) —— 若芯片体质允许，目标可设为 40 个。
* **CPU：** 使用 `bc250-smu-oc` 对 CPU 进行降压及超频（目标频率约为 3.8–4.0GHz），以改善散热并提升速度。
* **Bazzite 特别说明：** 禁用 `hhd` 守护进程，以消除 2D 游戏中的持续性微卡顿。
* **散热：** 配备一个高品质风扇并设置自定义 BIOS 风扇曲线即可，增加额外风扇的边际效益极低。
在进行任何更改后，请务必进行压力测试，并逐步调整电压与频率，以确保系统在设置开机自启前达到稳定状态。
近期的一场 Hacker News 讨论将论文《持久状态机：基于 INT4 内存单元的 LLM 注意力机制》标记为“AI 垃圾内容”和“伪术语大杂烩”。
批评者认为该论文缺乏科学可信度，原因如下：
1. **缺乏同行评审：** 该论文是在 Zenodo 上自行发布的，而非通过认可的渠道。
2. **发布节奏可疑：** 作者在不到一周的时间内发布了八个版本，绕过了标准的迭代反馈流程。
3. **技术主张逻辑混乱：** 论文试图模糊地将有限自动机理论、深度学习和 FPGA 硬件等不同领域结合起来，却未能提供必要的数学逻辑支撑。
4. **指标不切实际：** 论文仅基于未经证实的模拟，就得出了夸张的性能结论（例如 2129 倍的加速），而缺乏实际物理测量或硬件综合支持。
怀疑论者普遍认为，该论文看起来像是缺乏实质研究基础的生成式内容。他们建议社区对那些堆砌术语、令读者困惑，却无法提供具体证据或同行评审严谨性的论文保持警惕。
Go 1.27 引入了语言、标准库和性能方面的多项重大改进。 **核心语言与性能更新：** * **泛型方法：** 方法现在可以声明独立于接收者的类型参数。 * **结构体字面量：** 嵌入式结构体中的提升字段现在可以直接进行赋值。 * **类型推断：** 广义函数类型推断使泛型函数在转换和复合字面量中的使用更加灵活。 * **性能：** 新的内存分配器针对大小进行了优化，提升了小对象分配的速度；实验性的 `simd` 包实现了可移植的硬件加速向量化。 **库与工具改进：** * **标准化功能：** `encoding/json/v2` 包正式转为稳定版，并新增了 `uuid` 包。 * **安全性：** `crypto/mldsa`、`x509` 和 `tls` 增加了对后量子 ML-DSA 数字签名的支持。 * **开发体验：** 包含 `strings.CutLast`，增强了 `math/big` 的除法舍入功能，并改进了如 `synctest.Sleep` 和内存测试服务器等测试工具。 * **诊断：** 新增的 `goroutineleak` 分析和改进的追溯标签有助于识别并发问题。 * **工具链：** `go test` 现在包含版本一致性检查 (`stdversion`) 以捕捉版本差异；`go doc` 新增了 `-ex` 标志，用于显示可运行示例。 总体而言，Go 1.27 在重大功能扩展与长期易用性改进之间取得了平衡。
设计图标 Designing Icons
2 天前
此网站需要启用 JavaScript。
这篇 Hacker News 帖子围绕 material.io 上名为“图标设计”（Designing Icons）的指南展开了批评性讨论。
用户普遍认为该标题具有误导性，并指出它应当明确标注为“Material Design”指南，而非图标设计领域的普适权威。评论者对谷歌的 Material Design 美学表达了强烈不满，将其形容为“平庸”、“二流”以及“糟糕至极”。
多位参与者表达了对 Windows XP 时代更为多元的图标设计语言的怀念。此外，一些人指出了该指南本身的技术缺陷，并提到页面上的图标示例在移动设备上难以辨认。总的来说，社区认为 material.io 的准则过于主观，且缺乏旧有设计标准所具备的视觉水准。
本文旨在阐述 (D)TLS 1.2 密钥交换算法（特别是 RSA 和有限域 Diffie-Hellman，即 FFDHE）中存在的重大安全漏洞。 主要安全顾虑包括： * **缺乏前向安全性：** 非临时密钥交换及 RSA 均不具备前向安全性。 * **侧信道攻击：** 在 DH 和 ECDH 实现中重复使用公钥，容易导致“Raccoon”攻击和无效曲线攻击等计时攻击。由于实施必要的防御措施极其复杂，此类漏洞依然普遍存在。 * **FFDHE 问题：** FFDHE 面临互操作性挑战、缺乏安全组协商机制，且因使用弱群或自定义群，容易受到小子群攻击和离散对数攻击。 * **RSA 漏洞：** RSA 密钥交换天生易受 Bleichenbacher 类攻击。由于安全对策难以实现且 RSA 密钥缺乏域隔离，此类攻击反复以多种形式（如 ROBOT、DROWN）出现。 为降低上述风险，本文正式弃用并建议不再使用受影响的密码套件。本文更新了多项既往 RFC，并为 (D)TLS 1.2 提供了符合 BCP 195/RFC 9325 现行最佳实践的指导建议。
RFC 10015 通过废除过时的密钥交换方法，旨在加强 TLS 1.2 和 DTLS 1.2 的安全性。随后的 Hacker News 讨论凸显了在维护安全性与支持旧有系统之间的矛盾。
一些用户质疑为什么管理员不直接升级到 TLS 1.3。然而，该 RFC 的支持者认为，许多企业和政府依赖于旧有基础设施，由于成本、技术债务或硬件限制，这些设施无法轻易更新。对于这些组织而言，维护一个安全的 TLS 1.2 版本是实际的必要，而非可选。
批评废除措施的人士认为，强制执行这些标准可能会无意中“中断”现有连接，迫使管理员进行复杂的配置更改。相反，其他人则坚持认为，此类更新对于防止降级攻击至关重要，因为攻击者会利用陈旧且不安全的加密套件来削弱连接安全性。归根结底，这场讨论反映了一场更广泛的辩论：如何在互联网安全协议的快速发展与支持老旧且普及的技术这一现实之间取得平衡。