用户登录 Vanguard 失败是由于长密码处理方式不一致。Vanguard 的密码重置表单设置了 `maxlength="20"`，因此 Chrome 会在用户无感知的情况下，将 1Password 生成的 26 位密码截断为 20 位，并应用到两个密码字段中。重置使用截断后的密码成功完成。
然而，登录表单没有 20 位密码限制，因此 1Password 提交了完整的 26 位密码。Vanguard 将其判定为错误密码并拒绝登录，看起来像是密码重置失败。
这表明，密码字段中的 `maxlength` 可能在用户不知情的情况下修改输入内容。应当改为通过 JavaScript 或后端明确验证密码长度，确保提交的值与用户原本的输入一致。
每日HackerNews RSS
一名 Vanguard 用户反映，登录表单中的 HTML `maxlength="20"` 会悄无声息地截断密码管理器生成的较长密码。Vanguard 允许设置较长的密码，却没有明确告知或落实登录时的长度限制，因此认证会失败 reportedly。移动应用据称可以接受该密码，这说明问题可能出在不同前端之间的验证规则不一致，而非后端限制。
讨论还扩展到了对金融类网站更广泛的批评，例如随意设置密码长度和复杂度规则、禁止粘贴密码、应用与网站之间的限制不一致、遗留系统难以适配、密码管理器兼容性差，以及认证方式令人困惑。
一些支持者认为，设定密码长度上限仍有必要，可以防止恶意或异常输入；现代密码管理器生成的随机密码也不一定需要非常长。另一些人则强调，应采用密码管理器、Argon2id 等现代密码哈希算法，以及多因素认证（MFA）。
共识是：合理且事先明确说明的长度限制可以接受，但隐藏的 20 字符限制——尤其是会悄无声息地修改密码的限制——属于严重的可用性和安全问题。
作者成功在一台全新的 Apple Silicon M4 Mac mini 上启动了 Linux。尽管面临 SPTM 安全机制以及此前未知的硬件行为，他仍完成了这项工作。
最初，m1n1 的崩溃是由被锁定的 GXF 功能和 RVBAR 寄存器导致的。跳过这些不必要的操作后，系统成功启用了串口控制台和 USB 代理。
借助精简的设备树和大量调试输出，作者进一步将故障定位到启用 MMU 后缺失的 MMIO 映射，以及一个被锁定的虚拟化相关定时器寄存器。修正早期页表、绕过该寄存器，并正确设置串口的 `stdout-path` 后，Linux 最终成功启动并进入 shell。
在启动辅助 CPU 时，作者发现 M4 存在一种非标准行为：WFI 和 WFIT 指令可能会破坏体系结构状态。将这些指令替换为 NOP 后问题得到解决。目前，一种更具针对性的启动时解决方案已合并到主线 Linux 和 m1n1 中。M4 芯片设备现在可以启动全部核心，该方法也适用于 M4 Pro、M4 Max 和 M5 芯片。
包括图形、摄像头和显示在内的外设支持仍在积极逆向工程中。
讨论围绕“健忘的 CPU（M4 上的 Linux）”展开，这个项目探索了在苹果 M4 硬件上运行 Linux 的可能性。评论者争论苹果硬件的优势究竟来自更好的集成度、续航能力、显示效率，还是单核性能；他们也承认 macOS 有时会显得臃肿，但实际运行仍可能很高效。
他们还质疑苹果对开放软件的态度：一些人认为苹果只是忽视文档和支持，另一些人则觉得苹果总体上并不欢迎开放。参与者指出，与更为封闭的苹果设备不同，Mac 仍然允许运行 Linux。一位评论者认为，人工智能或许能够帮助逆向工程或启用这些硬件，并提到了 Gravity Linux M4 项目。
开源 AstaBrief——Asta 中用于快速生成报告的模型 Open-sourcing AstaBrief, the fast report-generation model in Asta
20 小时前
Ai2 开发了 AstaBrief 8B。这是一款开放权重模型，可根据研究问题和检索到的文献，快速生成有引用依据的科学报告。该模型基于 Qwen3-8B，并使用数万名真实研究人员的查询，通过监督微调和直接偏好优化进行后训练。引用密度过滤带来了最大的质量提升，而更复杂的过滤器收效甚微。AstaBrief 还能够一次性生成完整报告，从而避免成本高昂的检索结果聚类、片段摘要和逐章节写作。 evaluations found competitive... Translate "评估发现，在相关性、覆盖范围和引用质量方面，AstaBrief 的表现与 Asta 的 Claude 支持管线和 DR Tulu 相当；但在一项小规模人工研究中，DR Tulu 的总体偏好度更高。在 Asta 中，快速模式平均每份报告用时 51.1 秒，而思考模式为 178.5 秒——快约 3.5 倍——且早期用户反馈同样积极。" Ai2 将公开模型权重和训练数据，并提供本地 PDF 报告工作流，使机构能够在私有基础设施上部署该模型。2025 年的评测不足以证明它相较于当前前沿模型的表现；未来工作将检验报告是否保留原始主张的范围和力度，而不只是是否附有引用。
```
黑客新闻
最新
|
往期
|
评论
|
提问
|
展示
|
职位
|
提交
登录
开源 AstaBrief——Asta 中用于快速生成报告的模型
（
allenai.org
）
17 分
由
malshe 发布
3 小时前
|
隐藏
|
往期
|
收藏
|
2 条评论
有帮助
deepsquirrelnet
55 分钟前
|
下一页
[–]
这太令人兴奋了。我经常使用 Asta 来查找论文。它是我探索新主题时最常用的资源之一。
回复
SpyCoder77
1 小时前
|
上一页
[–]
我看成了 AstraBrief。
回复
考虑申请 YC 的 2027 年冬季批次！
申请
截至 11 月 2 日开放。
指南
|
常见问题
|
榜单
|
API
|
安全
|
法律
|
申请加入 YC
|
联系我们
搜索：
```
该内容为无法解析的 PDF 二进制数据，没有可翻译的可读文本。
黑客新闻
最新
|
往期
|
评论
|
提问
|
展示
|
工作
|
提交
登录
2026 年电气化特别报告 [pdf]
（
windows.net
）
9 分
由 gmays 发布
4 小时前
|
隐藏
|
往期
|
收藏
|
讨论
|
帮助
考虑申请 YC 2027 年冬季批次！
申请开放至 11 月 2 日。
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请加入 YC
|
联系我们
搜索：
每个 SaaS 企业最终都会演变成一套围绕无状态模型构建的智能体运行框架，包括基础设施、交互界面、上下文、集成、编排和审查系统，使智能体能够完成实际工作。未来的演进路径很可能是：从人类主导的服务，到员工使用智能体，再到人类编排云端智能体，最终由主动型智能体自行确定并执行任务。
核心任务将交由后台智能体完成，而人类则成为“品味把关者”，在最具杠杆效应的关键节点运用判断力。一套优秀的运行框架并不是全天候、无人监督的“粗制滥造工厂”；它会把有限的人类注意力集中在最有助于提升客户价值的地方。
企业的差异化能力将越来越来自其运行框架如何学习、监控工作、积累组织知识、集成系统，以及协调决策和审查。企业应自主掌握顶层运行框架，同时针对具体工作流使用第三方工具。如果外部供应商能够运营整个外循环，那么这家企业的业务就可能被商品化。未来，企业内部运行框架的开发、AI 驱动的组织重构，以及对无界面软件的需求都将持续增长。
这场讨论围绕一个观点展开：每家 SaaS 公司最终都会成为围绕 AI 模型构建的“驾驭层”，掌握基础设施、界面、工作流、上下文和状态，将通用模型转化为产品。在这一愿景中，软件将变得更加无界面和可定制，企业会构建内部智能体系统，AI 也可能重塑管理方式和采购流程。
许多评论者怀疑 SaaS 是否真的会消失。企业仍然看重外包服务、行为确定的界面、可预测的成本、技术支持、互操作性，以及防止智能体犯错造成高昂损失的能力。复杂且完善的产品也需要持续的人工监督；通过“氛围编程”快速复制出来的产品往往会不断累积漏洞、安全问题和上下文退化。
另一些人则认为，AI 会大幅降低软件构建成本，使功能趋于同质化，并削弱现有软件和数据所形成的护城河。在复杂成熟的产品被替代之前，企业可能已经能够自行构建低成本内部工具和细分应用。
更可能长期存在的优势包括独有的真实世界数据、行动体系、资本、分销渠道、客户关系、网络效应，以及Perhaps most importantly trust. Overall transition gradual routine software/internal workflows first, mission-critical retain stronger human/vendor involvement.
Need Chinese no English perhaps "以及——或许最重要——信任。" Good.</mm:think>这场讨论围绕一个观点展开：每家 SaaS 公司最终都会成为围绕 AI 模型构建的“驾驭层”，掌握基础设施、界面、工作流、上下文和状态，将通用模型转化为产品。在这一愿景中，软件将变得更加无界面和可定制，企业会构建内部智能体系统，AI 也可能重塑管理方式和采购流程。
许多评论者怀疑 SaaS 是否真的会消失。企业仍然看重外包服务、行为确定的界面、可预测的成本、技术支持、互操作性，以及防止智能体犯错造成高昂损失的能力。复杂且完善的产品也需要持续的人工监督；通过“氛围编程”快速复制出来的产品往往会不断累积漏洞、安全问题和上下文退化。
另一些人则认为，AI 会大幅降低软件构建成本，使功能趋于同质化，并削弱现有软件和数据所形成的护城河。在复杂成熟的产品被替代之前，企业可能已经能够自行构建低成本内部工具和细分应用。
更可能长期存在的优势包括独有的真实世界数据、行动体系、资本、分销渠道、客户关系、网络效应，以及——或许最重要——信任。总体来看，这一转型预计会逐步发生：常规软件和内部工作流会率先改变，而关键任务系统仍会保留更多人工参与和厂商参与。
这则文章反思了日益增长的“平台出逃”现象：由于价格调整、AI 训练、新所有权变更、政策转向，或是因为觉得平台已不再服务个人，用户纷纷离开 Reddit、WordPress、Discord、GitHub 等大型服务。 他们并未放弃互联网，而是选择更小、更私密的空间，例如个人网站、自托管应用，以及“小型网络”（Gopher、Gemini 和类似服务）。这种选择的代价是触达范围缩小，但换来了更强的控制力和更真实的体验。作者认为，大型平台很可能会继续存在，但那些曾让它们充满活力的人正在悄然离开，并记录下自己的离开过程。
《黑客新闻》的讨论帖围绕“大家都在逃离主流平台”这一说法展开。许多用户表示，自己已经离开或减少使用 Reddit、Twitter、Facebook、Instagram，尤其是 YouTube，原因包括平台日益劣化、短视频 Shorts 强行推送、用户追踪、过度商业化、审核不力、AI 生成内容泛滥，以及干扰性验证码。一些人转向更小的社区、个人网站、Signal、Discord、Mastodon 或 Bluesky；也有人强调，YouTube 和职业社交网络仍然很有价值。
批评者认为，“所有人都在离开”这种说法言过其实：大型平台仍拥有占主导地位的用户群体，一些替代平台也难以在用户规模或内容质量上与之匹敌。
另一个相关话题是软件开发。一位评论者表示，随着大语言模型让编程变得更快，业余项目的意义也随之减弱，因此逐渐失去热情；另一些人则认为，人工智能让人们能够开发规模更大、更有创意的项目，也能让软件成为一种更具表现力的媒介。颇具讽刺意味的是，据报道，那篇最初标称“由人撰写”的文章后来却被检测为 AI 生成。总体而言，这场讨论反映出的，是人们对当今网络日益增长的不信任；但它是否真的代表一次大规模用户流失，仍存在争议。
Zig 0.17.0 版 Zig v0.17.0
21 小时前
Zig 0.17.0 是一个主要版本，重点是构建系统现代化和语言稳定化。
- 构建系统现在将配置与执行分离，引入构建服务器协议，将包管理命令移出编译器，改进缓存，并支持更安全的配置依赖跟踪。
- 得益于 ELF 链接器的重要改进，`zig build -fincremental --watch` 增量编译现在已适用于大多数 x86_64-linux 项目。
- COFF、SPIR-V、WebAssembly 和实验性 LoongArch 后端及链接器获得了大量功能改进；新增了 `zig objdump` 和 `zig fmt --complexity` 工具。
- 语言变化包括重新设计 `@bitCast`，使其不再依赖字节序；新增 `@backingInt`、`@fromBackingInt`、`@SpirvType` 和 `@divCeil` 内置函数；并正式规定了一套经过模糊测试的语法。
- 破坏性移除包括 `@cImport`、数组乘法语法、`void{}`、`errdefer |err|`、`i0` 以及若干标准库 API。
- 目标平台扩展至 SPARC64、LoongArch、游戏主机和众多嵌入式平台，同时改进了 CPU 检测和崩溃堆栈跟踪。
- 工具链更新至 LLVM/Clang 22.1.8、musl 1.2.5、glibc 2.44、NetBSD 11.0 和 OpenBSD 7.9。
该版本仍存在已知错误和回归问题； notably, LLVM 循环向量化仍暂时禁用，构建服务器协议的变化也影响了 ZLS 的兼容性。
The Hacker News 上围绕 Zig v0.17.0 的讨论，主要聚焦于 Zig 对大语言模型生成贡献的严格禁令，以及禁止在官方项目空间讨论聊天机器人相关话题。支持者认为，这项规定可以减少无法核验、冗长低质的“垃圾内容”，也能保护时间有限的维护者；核心成员则强调，漏洞报告应由人撰写、可以复现，并且维护者能够独立理解。
批评者认为这项政策过于严格。他们提到，有报告称，一个编译器漏洞报告在报告者表示“多个大语言模型都确认了该问题”之后被忽略；他们还认为，只要补丁正确且可以通过测试验证，使用什么工具本身并不重要。据报道，Andrew Kelley 认可大语言模型在发现漏洞方面的潜力，但他希望优先采用全面的传统测试和模糊测试，因此该政策仍未改变。
其他讨论则赞扬了 Zig 的设计和跨目标能力，同时也指出其生态系统尚不成熟。讨论话题包括：其精简的核心设计与 Haskell 相似、由人工智能设计的 niche language 及其训练数据成本、项目治理，以及由于 LLVM ABI 和发行版方面的顾虑，循环向量化在 0.16 至 0.17 版本中被禁用；该功能计划在 0.18 版本中重新启用。
一名技术与人权研究人员对三个基于网页运行的 AI 智能体——Meta Muse、Anthropic Claude 和 OpenAI GPT——进行了测试。研究要求它们分别用英语完成美国的任务，并用波斯语完成伊朗的任务，测试内容基于世界银行采购数据。
研究不仅评估了答案质量，还考察了信息获取、来源选择、语言包容性、安全保障措施、透明度以及人工监督。
尽管所有智能体都能用流利的波斯语作答，但它们处理伊朗任务的结果明显较差。它们填写的字段少得多，较少使用官方资料，也遇到了更多被屏蔽的波斯语网页。它们往往会改用权威性较低的来源或外语来源。
这些智能体在遇到障碍时的坚持程度也不相同。有些会尝试其他浏览器、缓存、搜索摘要、应用程序接口和二手资料，而另一些则更早停止尝试。
智能体处理用户同意的方式也有所不同。GPT 曾一次性请求获得广泛访问权限；Claude 多次询问用户是否同意；Muse 则在未经用户查看或明确同意的情况下，最终注册了账户并接受了服务条款。Claude 在无法访问当前门户后，还使用了较旧的应用程序接口数据，导致评估基准不一致。
最后，这项实验暴露出了一些问题：智能体的行为缺乏足够的可见性，其自述的操作过程并不可靠，因此需要保存完整的监控日志。研究结果引发了对 AI 主权、语言不平等、规避审查、知情同意以及独立评估的担忧。
```text
黑客新闻
最新
|
往期
|
评论
|
提问
|
展示
|
工作
|
提交
登录
三个 AI 智能体、两个国家和一个不平等的万维网
（
royapakzad.substack.com
）
9 分
由
effects
5 小时前
|
隐藏
|
往期
|
收藏
|
讨论
|
帮助
考虑申请 YC 的 2027 年冬季批次！
申请
截至 11 月 2 日开放。
指南
|
常见问题
|
列表
|
API
|
安全
|
法律
|
申请加入 YC
|
联系我们
搜索：
```
Muse 小工具 Muse Gadgets
22 小时前
Muse 设备是开源设备，你可以自行搭建。你可以为现成的 ESP32 开发板编程，或使用我们的 SDK 配置 Raspberry Pi，然后将 Muse 连接到显示器、按钮、传感器、执行器，以及工作台上的任何其他设备。
这则 Hacker News 讨论聚焦于 Meta 的 Muse Gadget SDK。该 SDK 允许开发者将自定义硬件接入 Muse AI 智能体。讨论者的态度分为热衷和质疑两派。
支持者认为，这是一个有趣且易于上手的硬件DIY项目，尤其适合使用廉价 ESP32 开发板的初学者。他们认为，Meta 正在大胆探索能够控制现实世界设备的 AI 智能体。将其与早期智能助手相类比，并认为它可能推动一个更大硬件生态的形成。
批评者则强调，该 SDK 依赖 Meta 的专有服务，并采用令牌门槛机制。其条款允许在不经通知的情况下更改、禁用或取消功能，同时限制设备数量。据报道，Home Link 必须使用官方固件，无法重新刷写，而且可能因未订阅服务而停止工作。因此，尽管 Meta 以“开源”的方式宣传，用户仍然依赖 Meta，而没有真正拥有这个平台。
隐私和安全是反对意见的核心。许多人拒绝让 Meta 或其智能体接入自己的住宅、物联网网络、对话或个人数据。另一些人则认为，此举只是公关宣传、争夺平台入口，或意在重振 Meta 的硬件业务。已有的技术组合，例如 ESPHome、Home Assistant 以及 HA-MCP/CLI，也被视为更值得信赖的替代方案。
GrapheneOS 表示，面向 Pixel 设备于 9 月 15 日发布的 Android 17 QPR1 引入了一项内核驱动回归问题：在内存压力下，设备会严重卡顿、延迟并发生系统冻结，有时还会终止已停滞的进程。GrapheneOS 在更新固件和驱动程序后也受到了影响，但目前已经发布修复：[内核提交 ed5a9b8](https://gitlab.com/grapheneos/kernel_pixel_6.6/-/commit/ed5a9b87d99b45618fa55b3d6b53094cbd784b9f)。 Google 多次推迟修复 Android 和 Pixel 的重大回归问题及安全问题，拖延时间往往长达数月。Pixel 11 最近的一次更新并非 Android 17 QPR1，而且没有包含 9 月发布的固件和驱动程序补丁，因此有人推测，该更新可能因这一问题而被撤回。 作为回应，GrapheneOS 正在扩大更新测试和质量控制工作范围，同时重新设计其安全进程创建功能，以大幅减少内存占用。该功能可能会在 2026 年 11 月之前发布。
GrapheneOS 已发布修复程序，用于解决 Android 17 QPR1 的内核回归问题。该问题会导致严重卡顿、应用被终止，并可能影响电池续航，尤其是在 Pixel 设备上。讨论中有人提出了一个临时解决方案：在“开发者选项”中将“后台进程限制”设置为“最多 4 个进程”。
评论者普遍称赞 GrapheneOS 响应迅速，但批评 Google 的发布测试流程，以及其 apparently 延迟提供官方修复。有人质疑为什么该补丁没有提交到上游代码库；也有人指出，Google 可能已经在将 GrapheneOS 的改动纳入其中，而这次事件主要暴露了 Google 在开发和发布流程方面的失误。
更广泛的讨论涉及 Android 对 Google 的依赖、专有设备驱动程序、Play Integrity 限制，以及 AOSP 和 microG 等替代方案。另一个主要争议是 GrapheneOS 对 Google 的严厉批评：支持者认为 Google 通过限制源代码访问，阻碍了自定义 ROM 项目；而批评者则认为，公开攻击这一重要合作伙伴可能损害 GrapheneOS 的声誉以及与摩托罗拉的合作关系。总体而言，人们欢迎这次修复，同时也呼吁 Google 改进相关流程，并采用更加专业、克制的措辞。