Linkit 是一款免费的跨平台桌面书签管理器，可将保存的链接转化为有组织的知识资产。默认将书签本地存储在 SQLite 中，支持离线使用，并提供可选的免费 Supabase 云同步与行级安全。功能包括分类、集合、标签、笔记、评分、阅读状态、重复检测、链接健康检查、浏览器/Raindrop 导入和 Spotlight 快速捕获。AI 功能需要用户提供的 OpenAI/DeepSeek 兼容模型或本地 Ollama 模型，可实现摘要、智能标签、语义搜索、AI 策划集合、重复建议和洞察。应用还包含交互式知识图谱、多种工作区视图、12 种主题，以及英/中本地化。它可在 macOS、Windows 和 Linux 上运行，采用本地优先隐私保护，无付费墙，API 密钥存储在操作系统钥匙串中。
每日HackerNews RSS
对不起。
LLM 写代码并不会让框架、库、语言或 Rails 过时。Rails 仍然提供结构、安全更新、性能改进、生态支持和可预测的导航，帮助人类和 LLM 在不必重新发明底层管道的情况下构建产品。用 Rust 完全重写并非易事：它可能改变行为、引入 bug、扰乱用户，并需要大量测试，尤其是对 UI 密集型应用而言。通常更好的做法是优化现有应用并更新依赖。Rails 还提供实用的开发优势，例如即时代码重载和 REPL 工作流，并且 LLM 已在其上训练。作者仍对有针对性的重写持开放态度——可能是用 Go 提升后台性能或用 Svelte 做前端——但认为没有理由替换核心的 Rails 应用。最终，必须由负责人解释软件决策，而目前 Rails 仍然是构建和维护商业软件的明智且高效的选择。
讨论串在辩论，随着LLM编写更多代码，Rails是否仍值得使用。支持者引用了约定、可读性、生态系统、久经考验的模式，以及对代理的防护栏。怀疑者指出动态类型、升级摩擦、性能，以及在类型化语言中更强的AI结果；一些人报告迁移到Rust或Go。其他人认为框架和抽象仍然有用，完全重写往往不必要。总体而言，Rails仍适用于许多CRUD应用，但AI改变了通常的开发者体验与性能权衡。
《超级马力欧64》已被制作成 Apple Vision Pro 的互动立体模型，允许玩家将关卡放置在真实桌面上，并用控制器绕其行走，从任意角度观看场景。亮点包括在标题画面拉伸马力欧的脸、探索城堡房间，以及放大关卡直至身在其中。该项目反映了被 Xbox CEO 称赞对玩家有益的反编译与重建趋势，与任天堂下架粉丝移植版和模拟器的做法形成对比。
Hacker News 上的讨论帖介绍了一个项目，让用户在 Apple Vision Pro 上以桌面微缩场景的方式游玩《超级马里奥 64》。评论者称赞其怀旧吸引力，并认为 VR/AR 游戏有潜力，尤其是可以减少晕动症的微缩场景体验。讨论还比较了 Quest 3、Steam Frame 和 Vision Pro 等头显，权衡了舒适度、价格、透视和开放性。一些用户推荐《马里奥 64》为里程碑式游戏，而另一些人则争论其摄像机和操作。一个分支话题批评任天堂的商业做法和知识产权执法，而辩护者则指出其创新和游戏密钥卡。总体而言，该帖显示了对空间游戏的热情，但也注意到成本、舒适度和平台生态系统的持续担忧。
外部消防梯在19世纪高楼住宅发生致命火灾后变得常见，尤其是纽约1860年要求改造的法律。它们演变成铁梯/阳台系统，但专家对其有效性存在争议；三角衬衫厂火灾显示它们可能失效。随着时间推移，维护、通道堵塞、犯罪、对许多建筑不适用以及实际使用不佳等缺点超过了优点。现代规范转而依赖日常使用的、受保护的、室内防烟楼梯，以及喷淋、报警和耐火材料。建筑规范体现权衡，通常主要适用于新建建筑，形成持久影响；追溯性规定可能锁定某种方案。纽约1860年的改造要求帮助外部消防梯主导了一个多世纪。一个类似的警示：电梯担架尺寸规定提高了成本并降低了可及性。老式铁制消防梯仍带有怀旧色彩，但现代室内疏散通道更安全。
Hacker News围绕Practical Engineering关于消防逃生通道的文章的讨论，涵盖了外挂式逃生通道减少的原因：现代探测、喷淋、耐火构造，以及带自闭门的更安全内部楼梯间。评论者争论多出口是否仍必要，有人认为冗余仍需，有人认为改进的安全性和住房密度担忧支持规范变更。还有人指出逃生通道长期受批评，外挂改造是老旧建筑的折中方案。帖子还讨论消防员日益成为综合应急响应者，包括医疗和事故呼叫，以及对小型阴燃或烟囱火灾的大规模响应轶事。其他要点包括单楼梯建筑规范、成本与设计权衡、全球差异，以及逃生通道被阻塞或失效导致灾难的例子。总体而言，帖子反映消防安全、实用性与城市设计之间的平衡。
eMudhra 的八个中间 CA 私钥在 P-384 上被意外设为极弱的单字节值，任何人都能从公开证书在几秒内暴力破解。受影响的 CA 包括六个 TLS 中间 CA 和两个代码签名中间 CA（由 Sectigo 交叉签名），创建于 2025 年 4 月。浏览器很快屏蔽了它们，但许多非浏览器 TLS 客户端、CI/CD 工具、脚本、物联网设备以及 Windows 代码签名路径可能仍信任它们，因为它们默认不检查吊销或证书透明度。这使得可以为任意主机名伪造证书，以及可能签名恶意软件。用户应更新操作系统/浏览器 CA 捆绑包、certifi、Node、Homebrew 和容器镜像；无法更新的设备可能在证书于 2039 年到期前持续暴露。eMudhra 将事件归因于创建并选择了弱密钥的仪式脚本/HSM 错误。
Hacker News 讨论 eMudhra 证书颁发机构密钥：由于中间 CA 私钥实际上只是 4，因此可轻易破解。该弱点通过 Google 的 paranoid_crypto 扫描 CCADB 证书发现；未发现其他类似案例。评论者解释公钥仍然有效，因此可能签发有效证书，而浏览器/操作系统和许多无法更新的设备（路由器、电视、物联网设备）在吊销/屏蔽前仍面临风险。讨论串探讨原因——可能是密钥生成/仪式漏洞导致弱密钥——以及更广泛的信任问题：大量 CA、薄弱审计、CT 日志、CAA 记录，以及将信任移入 DNS 或收紧约束能否降低风险。用户讨论缓解措施：更新操作系统/运行时信任库、屏蔽中间证书，以及对老旧设备进行中间人攻击/越狱的可能用途。还辩论了故意与偶然及安全剧场。
文章称巴黎协定的1.5°C目标已不再可行。在Hacker News讨论中，一名气候科技工作者认为物理现实和任务未变，敦促人们尽管政治与资金周期波动仍持续努力。评论者争论气候变化主要是一个政治、民主还是结构性问题：有人强调投票和知情公民；有人归咎于权力集中、化石燃料利益或全球不平等。关于中国、美国、人均与总排放，以及国家行动是否重要，存在大量争论。许多人认为没有结构性变革，个体牺牲不足；另一些人则强调饮食、交通和能源使用等个人选择。核能、可再生能源、电动汽车和碳捕获被讨论，但在成本、可行性与政策上存在分歧。更广泛的主题包括人口政治、AI分流资本、对漂绿的不信任，以及对影响将不均分布的担忧。总体而言，该帖反映出对1.5°C目标已失的焦虑，以及对技术、政治或个体努力能否仍防止更坏结果的分歧。
请启用JavaScript和cookies以继续
Hacker News 链接了一篇 Science 文章，关于新的放射性碳年代测定修正印加年代学，HN 标题为“Bonanza of new dates rewrites the history of the Inca.” 评论者指出文章实际标题是“Redating the Inca empire”，有人认为 HN 标题是点击诱饵，暗示考古学家发现了印加扩张比先前估计早 50–100 年的证据。其他评论推测印加建筑所在文明可能源自征服者而非建造者，还有人拿《远古外星人》开玩笑。页面还包含一条 Y Combinator 2027 冬季申请通知。
本文将**退相干**定义为系统内局部有效但相互不兼容的模型的累积，使得变更代价高昂且容易出错。AI 正在以不可持续的速度加速这一过程：智能体在未完成工作的情况下生成更多代码与复杂性，而身处压力下的人类早已在增加退相干。与令人恐惧的智能爆炸不同，退相干阻止 AI 在孤立状态下自我改进，因为**相干性**——软件的适应性——只能通过现实世界的反馈来验证，而非在封闭环境中。这导致一种不同的威胁：**退相干崩溃**，即系统变得如此复杂，智能体能够维护它们却无法修复或简化它们，将社会锁定在逐渐衰退之中。本文敦促从快速、碎片化的变革转向重建相干性，强调开源协作是一种已被验证的模式，并警告若无此类努力，我们可能面临数年甚至数十年的停滞。
Hacker News 讨论帖讨论了《The Decoherence Trap》，它将 decoherence 描述为软件中局部有效但不兼容或冗余的模型不断累积，导致修改变得昂贵。评论者强调软件是对现实的建模，复杂度会组合式增长，而 AI 可以通过廉价添加功能而不进行重构或成本效益分析来成倍增加臃肿。其他人认为 AI 可能无法克服这一点，因为它缺乏现实反馈，不能独立维持超出人类限制的连贯性；上下文窗口大小和抽象层受到辩论。一些人反驳说 AI 可以直接衡量并优化修改的容易程度，而经验丰富的工程师仍然提供更好的设计。总体而言，讨论串将 AI 视为强大的加速器，其收益取决于人类判断、组织纪律以及对系统连贯性的持续关注。
NetWasm 是一个独立的 .NET 编译器、运行时和 SDK，可将 C# 和 .NET CIL 直接编译为小型独立 WebAssembly，无需附带桌面 CLR、Mono 或应用程序 DLL。它支持常规 dotnet CLI 工作流、已发布的 JS 模块/Web Workers、WIT/WASI Preview 2 组件、类型化互操作，以及 HTTP、JSON、XML、Regex、DI 等移植库。其紧凑的精确 GC 为 print-42 工作负载生成 47,798 字节的 WASI 组件，小于匹配的 Rust 配置，并且基准测试显示在某些工作负载上分配/GC 比 Mono AOT 更快。Blazor WebAssembly 大得多。NetWasm 提供多种 GC 策略、双目标定位、TUnit 测试以及 wasm32/wasm64 选项。它处于 1.0 前版本，有意采用更小的特性集：不支持广泛的运行时反射、动态加载或托管线程，且部分文件/套接字 API 尚未实现。核心库采用 MIT 许可；编译器/工具使用社区许可，符合条件的使用免费，并提供商业选项。使用 .NET 构建，使用 WebAssembly 主机运行。
一篇 Hacker News 帖子讨论了一个声称 C# 可以在 WASM 二进制体积上超越 Rust 的项目。评论者认为比较不公平：C# 输出经过后处理（例如使用 Binaryen），而 Rust 未充分优化，Rust 可以做得更小。该工具链是实验性的，旨在生成小型生产环境 C# WASM，解决 Blazor 二进制文件过大的问题，而不是证明 C# 能全面超越 Rust。
帖子还讨论了 C# 的优缺点：强大的后端工具链和现代特性，但在某些细分领域中开源库覆盖较弱、JIT/AOT 权衡，以及与 Rust 相比的类型系统限制。其他话题包括 WASM 的细分应用场景、UI 相关讨论，以及在 AI 辅助开发背景下 C# 是否仍将保持相关性。总体而言，标题被视为具有误导性，但项目本身有趣。
讨论 C++26 `std::polymorphic` 与 `std::indirect` 的帖子中，一名评论者批评 `std::indirect` 移动后处于无值状态，并建议删除其移动构造函数；其他人则认为应保留移动支持以兼容 `std::vector` 等容器，并指出移动后的对象很少被有意使用。回复还涉及类型要求、避免无值状态的代价，以及与 `std::variant` 和 Boost 的比较。另一位评论者提议对事件使用旧式带标签联合体，但其他人指出其内存泄漏、类型安全性弱、扩展性差，并推荐 `std::variant`。帖子还包含对 C++ 复杂性与维护负担的更广泛反应。总体上，它探讨了安全性、性能、易用性以及开放与封闭多态之间的权衡。