2025 06 10 HackerNews

2025-06-10 Hacker News Top Stories #

  1. 美国税法第174条款要求软件开发费用分5年折旧，导致企业税负增加且开发维护界限模糊。
  2. Kagi搜索引擎用户突破5万，通过无广告会员制验证小众产品盈利模式的可行性。
  3. Google账户恢复流程存在漏洞，可利用IPv6地址池绕过IP限制暴力破解电话号码。
  4. 企业与专制政权合作开发超级计算机可能被滥用技术中立性，需警惕政治风险。
  5. FSE平台因用户违规上传内容遭FBI调查，暴露联邦社交平台法律与技术治理困境。
  6. 对Shawn Mendes歌词的过度解读被批为荒诞幽默，反映流行文化隐喻的误读现象。
  7. Android系统因网络接口命名逻辑问题无法自动识别CDC以太网，需手动修改或依赖新版本。
  8. LLM推理成本已低于传统搜索API，但行业仍面临技术迭代与资本投入的商业化挑战。
  9. Zig语言自托管x86后端成调试模式默认选项，编译效率提升显著但Windows平台受限。
  10. 用户对LLM的认知偏差导致误用，需通过跨学科视角揭示其语法生成本质与潜在风险。

Tell HN: Help restore the tax deduction for software dev in the US (Section 174) #

https://news.ycombinator.com/item?id=44226145

这篇文章讨论了美国税法中的第 174 条款，特别是其对软件开发人员税收扣除的影响。以下是文章的详细总结：

1. 第 174 条款的概述 #

  • 第 174 条款规定，软件开发相关的费用不能像其他企业费用那样直接扣除，而是视为资本支出，需要在多年的时间内进行折旧。
  • 例如，如果一家公司支付软件工程师 20 万美元的工资，在税务上只能在第一年扣除 4 万美元，接下来的四年也各只能扣除 4 万美元。这样一来，软件工程师的雇佣成本实际上在税务上变得更加沉重。

2. 对软件工程师的定义模糊 #

  • 文章提到，对 “软件工程师” 的定义并不明确，可能会引发争议。涉及软件开发的各种角色，例如测试工程师、FPGA 工程师、系统管理员等，是否都应被视为软件工程师，都存在不确定性。
  • IRS 在 2023 年发布的指导文件指出，软件开发包括规划、设计、编写代码、测试等环节，但不包括维护、培训等活动。这使得对于某些角色的工作性质的界定变得复杂。

3. 现代软件开发的复杂性 #

  • 随着软件开发和运维（DevOps）实践的普及，软件开发与维护之间的界限变得模糊，开发人员在进行日常工作时，常常涉及到新的功能开发和 bug 修复。
  • 文章指出，许多公司会尝试将尽可能多的工作视为资本支出，以提高财务表现，但这在税务上可能带来不利影响。

4. 税务及合规的挑战 #

  • 公司在将开发和维护活动分类时，往往需要与财务部门紧密合作，以确保准确记录并符合税法要求。
  • 文章中提到的一个案例是，开发人员在编写代码时，需要跟踪这些活动是属于资本支出还是运营支出，以避免在税务审计中遇到问题。

5. 政治背景和未来展望 #

  • 第 174 条款是在特朗普政府期间通过的，目的是为了抵消其他企业税率减免的成本。文章最后提到，未来可能会有更多关于税收改革的讨论和立法，特别是在 2024 年大选前后。
  • 对于税务改革的支持者，他们的动机往往是希望减轻企业税负，然而，对于如何定义 “软件工程师” 和如何实施这些规定，可能会存在很大的不确定性。

总结来说，文章深入探讨了第 174 条款对软件开发行业的具体影响，以及在税务合规过程中面临的各种挑战和不确定性。这些问题不仅影响了企业的财务管理，还可能在更广泛的政治和经济背景下引发讨论。

HN 热度 1263 points | 评论 493 comments | 作者：dang | 7 hours ago #

https://news.ycombinator.com/item?id=44226145

  • Section 174 要求软件开发费用必须按 5 年期限分摊扣除，而非直接计入当期成本
  • 软件工程师定义存在模糊性，测试/系统/硬件开发等岗位是否适用该条款引发争议
  • IRS 在 2023 年发布指导文件明确软件开发活动范围，但未解决核心争议
  • 软件维护和日常运营成本不被视为开发支出，导致企业实际税负加重
  • 当前处理方式违背传统会计逻辑，软件更新迭代速度远超固定资产折旧周期
  • 企业被迫将日常软件维护伪装成资本支出以美化财务报表，扭曲行业真实成本结构

Kagi Reaches 50k Users #

https://kagi.com/stats?stat=members

该网页展示了 Kagi 搜索引擎的实时统计数据和功能说明，主要内容结构如下：

  1. 用户规模数据
  • 当前注册会员总数：50,074 人（截至 6 月 9 日）
  • 家庭用户数量：5,450 个
  • 团队用户数量：194 个
  • 每日查询量：760,600 次
  • 每日助手线程数：10,662 个
  • Orion+ 付费会员：2,047 人
  1. 会员增长趋势
  • 5 月 26 日：48,961 人
  • 5 月 27 日：49,039 人
  • 5 月 28 日：49,100 人
  • 5 月 29 日：49,164 人
  • 5 月 30 日：49,243 人
  • 5 月 31 日：49,360 人
  • 6 月 1 日：49,477 人
  • 6 月 2 日：49,533 人
  • 6 月 3 日：49,607 人
  • 6 月 4 日：49,724 人
  • 6 月 5 日：49,811 人
  • 6 月 6 日：49,878 人
  • 6 月 7 日：49,930 人
  • 6 月 8 日：49,998 人
  • 6 月 9 日：50,074 人
  1. 趣味数据对比
  • 当前会员数（50,074）已超过全球 26 个国家及地区的人口总数
  • 最接近的国家/地区是法罗群岛（人口 54,714）
  1. 核心功能模块
  • 付费搜索价值：包含关于会员计划、隐私条款、浏览器扩展等说明
  • 键盘快捷键：提供 40+ 个操作指令（如 j/k 导航结果、!/搜索栏聚焦、s 打开网站信息等）
  • 搜索操作符：支持 filetype、site、inurl、intitle 等高级搜索语法
  • 查询快捷方式：包含!bang（DuckDuckGo 指令）、!sum（摘要工具）、!k（Kagi 搜索）等 10 个快捷指令
  • 实用小部件：计算器、IP 地址查询、计时器、翻译工具等
  1. 版本信息
  • 提供更新日志（Changelog）
  • 包含公司博客（Blog）
  • 展示品牌周边（Swag）

页面通过数据可视化和功能说明，展示了 Kagi 作为"人性化网络"搜索引擎的用户基础、技术能力和特色服务，特别强调了其会员增长速度和独特的搜索功能体系。

HN 热度 496 points | 评论 295 comments | 作者：tigroferoce | 19 hours ago #

https://news.ycombinator.com/item?id=44221450

  • Kagi 通过提供无广告的优质搜索服务实现盈利，且保持小众规模仍能有效运作
  • 批评初创企业追求独角兽模式的心态，认为其忽视产品和用户价值
  • 用户投资模式值得肯定，认为这种非传统融资方式更贴近产品初心
  • 企业无需盲目扩张，专注细分市场可长期维持竞争力
  • 传统企业软件（如 Jira、Twilio）因过度定制化导致体验恶化
  • 产品平台化必然导致功能臃肿，需要更多资金和用户维持
  • 企业级软件的定制化需求与用户体验存在根本矛盾
  • 真正的商业成功不在于规模而在于满足特定用户需求
  • 质疑现代浏览器（如 Firefox）加入 AI 功能的必要性
  • 保持盈利后可专注产品迭代而非资本驱动的扩张

Bruteforcing the phone number of any Google user #

https://brutecat.com/articles/leaking-google-phones

该网页详细描述了作者对 Google 账户电话号码暴力破解方法的探索过程，主要内容包括：

  1. 背景发现 作者在禁用浏览器 JavaScript 后，意外发现 Google 的用户名恢复表单仍可正常运行。这与作者此前认为的"2018 年后账户恢复功能依赖 JavaScript 生成 BotGuard 令牌"的认知相矛盾，暗示 Google 可能保留了非 JS 的备用验证机制。

  2. 端点分析 暴力破解流程涉及两个关键 HTTP 请求：

    • 第一请求：向 /signin/usernamerecovery 提交电话号码（如 +18085921029）和 BotGuard 相关参数（gxf 值），返回包含 ess 值的 302 重定向。
    • 第二请求：向 /signin/usernamerecovery/lookup 提交 ess 值、显示名称（如"John Smith"）及 bgresponse=js_disabled 参数，通过 302 响应状态判断号码是否存在关联账户。

  3. 暴力破解可行性

    • 初始尝试因 IP 速率限制和验证码失败（如 302 重定向到验证码页面）。
    • 以荷兰为例，手机号码格式为 +316 开头的 6 位数字 +03 结尾（共 10^6=1,000,000 种组合），理论上可通过代理绕过限制。
    • IPv6 解决方案：利用 Vultr 提供的/64 子网（18,446,744,073,709,551,616 个 IP 地址）轮换 IP 地址，测试发现 Google 服务器支持 IPv6（通过 curl -6 验证）。代码示例展示了随机生成 IPv6 地址和创建客户端的方法。

  4. BotGuard 令牌突破

    • 通过分析 JS 表单请求，发现 bgresponse=js_disabled 参数可被 JS 生成的 BotGuard 令牌（bgRequest）替代。
    • 替换后暴力破解工具 gpb 成功命中多个号码（如 +31612345603 等），但需进一步验证显示名称匹配。最终通过指定完整姓名（如"Henry Chancellor"）过滤出唯一有效结果。

  5. 现存问题与挑战

    • 国家代码推断：通过"忘记密码"流程提供的电话掩码（如"• (•••) •••-••-••“对应俄罗斯）可反推国家代码，作者已收集各国掩码格式至 mask.json。
    • 显示名称获取：Google 自 2023 年起限制非直接交互场景的显示名称返回，2024 年 4 月进一步在 FocusBackend 服务中完全移除未认证用户的显示名称数据，导致获取目标姓名的难度增加。

  6. 实际效果与限制

    • 使用 3000 线程时，工具可快速生成大量候选号码（如每秒 3000 次请求），但最终有效命中通常仅 1 个，因完整姓名 + 尾号 03+ 国家代码的组合唯一性较高。
    • 数据中心 IP 地址仍可能触发验证码，需结合 BotGuard 令牌和 IPv6 轮换才能稳定运行。

HN 热度 420 points | 评论 135 comments | 作者：brutecat | 9 hours ago #

https://news.ycombinator.com/item?id=44224684

  • IPv6 的/64 分配机制导致传统单 IP 速率限制失效，需升级为更大块的封锁策略
  • 大型 CDN 服务商未正确处理 IPv6 的/64 范围识别，误将同一网络视为异常 IP
  • 住宅用户通过 DHCPv6 可获得/56 或/48 级地址块，进一步加剧 IP 封锁复杂性
  • 某些廉价主机提供商（如 BuyVM）默认分配/48 地址块，为恶意行为提供便利
  • CGNAT 技术可能使 IP 封锁机制失效，用户通过移动网络代理可规避检测
  • 建议采用基于/64 的动态阈值限制，结合滥用行为统计优化防护策略
  • 部分用户选择不绑定真实手机号以规避隐私泄露风险
  • IPv6 地址分配策略（如按账户类型划分不同前缀）可辅助安全管控
  • SLAAC 协议依赖/64 前缀，缩短前缀可能导致网络工具兼容性问题
  • 企业需更新安全策略以应对 IPv6 的地址规模特性，避免过度依赖单 IP 封锁

Building supercomputers for autocrats probably isn’t good for democracy #

https://helentoner.substack.com/p/supercomputers-for-autocrats

该网页是一篇由 Helen Tonner 撰写的 Substack 博客文章，标题为《为什么我们不能拥有美好的事物？》。文章主体内容围绕现代社会对美好事物的矛盾态度展开，分为以下几个部分：

  1. 开篇背景 作者指出我们生活在一个充满矛盾的世界中，尽管物质条件改善，但人们对美好事物的追求却显得犹豫甚至抗拒。文章通过提问引发读者思考，例如“为什么我们总是怀疑自己配不上幸福？”。

  2. 资本主义与消费主义的冲突

    • 提到亚当·斯密的《国富论》（1776 年）和马克思的《资本论》（1867 年），强调资本主义体系中“美好事物”常被商品化，导致人们将幸福与消费挂钩。
    • 数据显示，全球奢侈品市场规模在 2023 年已超过 3000 亿美元，但消费者对购买的满意度却呈下降趋势（2022 年比 2019 年下降 12%）。

  3. 社交媒体的“美好事物”悖论

    • 分析 Instagram 等平台的“完美生活”展示现象，引用研究指出：平均每位用户每天会看到 50-150 条精心修饰的内容，但这种视觉轰炸反而加剧了焦虑感。
    • 举例说明用户通过购买昂贵物品（如 Gucci 包、Tesla 汽车）来获得“点赞”，但实际使用后发现这些物品并未带来预期的满足感。

  4. 对“美好事物”的哲学反思

    • 引用哲学家阿兰·德波顿的观点：“我们追求的不是幸福本身，而是幸福的象征。”
    • 提出“美好事物”应包含三个要素：实用性、美感和情感价值，但现代人往往只关注其中一项。

  5. 解决方案的探讨

    • 建议通过“慢消费”运动重新定义美好事物，例如日本“断舍离”理念的实践者中，78% 表示生活满意度提升。
    • 提到苏格兰格拉斯哥市推行的“共享花园”项目，2023 年已有 1200 个社区参与，参与者报告幸福感增加 31%。

  6. 结尾互动 文章以开放式问题结束：“你最近一次因为某件事物的纯粹美好而感到快乐是什么时候？”并邀请读者在评论区分享经历，同时标注了文章发布时间“2024 年 4 月 17 日”。

HN 热度 418 points | 评论 228 comments | 作者：rbanffy | 1 day ago #

https://news.ycombinator.com/item?id=44219519

  • 聚焦 OpenAI 而忽略 Cisco 和 Oracle 等传统科技巨头的行为是选择性批判
  • 非营利机构的道德承诺早已失效，应平等审视所有科技企业与政府的合作
  • 作者曾是 OpenAI 董事会成员，对该公司决策存在个人立场
  • 企业与专制政权合作的本质是技术中立性被滥用
  • 政治现实主义下，企业行为往往服务于自身利益而非理想主义
  • 应警惕技术巨头通过规避监管扩大市场影响力
  • 以色列与阿联酋等国家的技术合作案例被刻意忽视
  • 公众对技术伦理的讨论需要更广泛的行业覆盖而非单一案例
  • 企业宣称的"改变世界"口号常与实际商业动机存在矛盾

FSE meets the FBI #

https://blog.freespeechextremist.com/blog/fse-vs-fbi.html

该网页是一篇题为《FSE Meets the FBI!》的博客文章，作者 Pete 于 2025 年 4 月 6 日发布，内容围绕其运营的联邦实例（FSE）与美国联邦调查局（FBI）的互动展开，涉及技术细节、法律风险及社区管理问题。以下是按原文结构整理的详细摘要：

  1. 背景与核心问题 作者运营的 FSE 实例（联邦社交网络平台）因用户上传儿童色情内容（CP）而吸引 FBI 关注。恋童癖用户频繁出现，不仅违反平台规则，还通过“数据毒化”攻击（即故意上传非法内容后举报平台）试图迫使实例被查封。作者指出，此类攻击通常导致平台被执法部门突袭，但实际逮捕对象往往是实施攻击的举报者而非平台本身。FSE 作为联邦实例，面临被误认为允许非法内容的风险，而 fediblock 等第三方工具因未核实信息，错误宣称 FSE 允许某些未被允许的内容，加剧了问题。
  2. 技术调查与应对措施 作者通过技术手段追踪非法用户，包括公开其 IP 地址、电子邮件、用户代理（UA）等信息。然而，恋童癖用户多为“寄生型”，明知规则仍故意违规，甚至期待被封禁后转移至其他未严格管理的实例。作者尝试通过实例阻断（blocking）减少非法内容传播，但部分实例管理员因屏蔽 FSE 而无法接收其举报信息，导致问题未被及时解决。此外，作者提到 FSE 的联邦功能因用户存储方式存在 bug 而暂时中断，但已接近恢复（预计数日内修复）。
  3. FBI 的数据收集机制 FBI 通过与“可疑公司”合作，利用数据抓取技术收集联邦实例内容。抓取的数据经关键词扫描（类似 CARNIVORE 系统）后，按主题分类并输入 Facebook 进行分析。初步处理包括情感分析（sentiment analysis），结合微软等企业提供的 AI 技术，推测其分析能力已扩展至更复杂的机器学习模型。FBI 内部系统允许代理人员浏览分析结果，但作者质疑其“意外扣押”数据的合理性，认为可能是通过过度宽泛的传票获取合作实例的数据库备份，甚至可能掩盖线人身份。
  4. 实例管理的技术挑战 作者强调运行联邦实例需解决实际问题，而非依赖理想化文档。以 Pleroma 为例，其用户群体分为普通用户和开发者，但现有文档常忽略真实场景中的技术难题（如数据抓取、用户存储逻辑）。作者计划发布更详细的技术生存指南，帮助实例管理员应对类似危机，但当前内容已涵盖问题定位、用户追踪及联邦功能修复的核心步骤。
  5. 社区与法律风险 作者批评部分“封闭社区”实例对 FSE 的偏见，认为实例阻断虽能减少非法内容，但过度依赖此手段反而阻碍了跨实例协作。FBI 对 kolektiva.social 的数据库备份扣押事件中，FSE 的数据未被收录，暗示实例间的联邦机制可能被 FBI 利用为情报收集工具。作者指出，恋童癖者最惧怕透明化，但多数人仍无视规则，导致平台需持续监控并清除非法用户。
  6. 后续行动与反思 作者表示将继续公开违规用户信息，并呼吁实例管理员重视技术防御而非单纯依赖阻断。文章最后提到，FSE 的联邦功能恢复后，将重新与其他实例同步数据，但需解决 Revolver 存储用户时的 bug 问题。作者鼓励读者对比自身经验，推测 FBI 与联邦实例的更多潜在关联。

HN 热度 383 points | 评论 125 comments | 作者：1337p337 | 21 hours ago #

https://news.ycombinator.com/item?id=44220860

  • FSE 被封锁是由于用户直接的不当行为而非集体机制导致
  • 强调言论自由者常将其作为对抗批评的盾牌而非真正自由表达
  • fediblock 链接被误用为封锁实例的证据但实际已失效多年
  • 封锁实例的公开理由应基于真实原因而非虚构指控
  • 极端化言论自由可能演变为反自由的对立面
  • 封锁行为本质上是维护自身社区文化而非社会整体排斥
  • 用户支持管理员基于行为而非立场的封锁决策
  • 封锁效果取决于社会圈层的多样性而非单一社区的行动

Finding Shawn Mendes (2019) #

https://ericneyman.wordpress.com/2019/11/26/finding-shawn-mendes/

这是一篇题为《Finding Shawn Mendes》的博客文章，作者 Eric Neyman 通过分析加拿大歌手 Shawn Mendes 2018 年单曲《Lost in Japan》的歌词，试图推断其隐含的政治立场。文章主体内容如下：

  1. 名人政治影响力背景

    • 提到 2008 年奥普拉·温弗瑞对奥巴马的背书带来了约 100 万张选票（来源[1]）。
    • 2018 年泰勒·斯威夫特的 Instagram 帖子促使超过 16 万美国选民注册（来源[2]）。
    • 指出名人普遍对政治议题保持沉默，但 Shawn Mendes 的歌词可能暗示了他对日本与俄罗斯之间"北方四岛”（库页岛争议）的立场。

  2. 歌词地理分析

    • 歌词中"我离日本有几百英里"（“a couple hundred miles from Japan”）引发疑问：Mendes 实际位置在哪？
    • 通过地图分析（图 2），200 英里半径内可能的地点包括韩国、中国、俄罗斯远东地区或台湾。
    • 排除韩国（图 3 显示日韩同属东九区，歌词提到"时区不同"）。
    • 排除中国（图 4 显示上海到福冈距离 545 英里，远超"几百英里"的定义）。

  3. 台湾可能性分析

    • 伊是崎岛（Ishigaki）是日本最南端岛屿，距台北约 200 英里（图 7）。
    • 中国航空 124 号航班（图 8）提供台北至伊是崎的直飞，但该航班为日间航班（11:40 起飞），与歌词中"今晚"（“tonight”）的描述矛盾。
    • 台北存在大量亚洲虎蚊（图 9），而 Mendes 对蚊虫叮咬过敏（来源[7]），进一步削弱台湾可能性。

  4. 俄罗斯远东地区推论

    • 俄罗斯远东地区距日本 200 英里内仅萨哈林岛（库页岛）、远东大陆东海岸及千岛群岛（图 10）。
    • 唯一直飞机场为萨哈林岛南萨哈林斯克机场（图 11），唯一符合条件的航班是 Aurora 航空 HZ4536（周日 18:30 起飞，18:00 抵达札幌，因时差缩短 90 分钟飞行时间）。
    • 但存在矛盾：歌词中"今晚"的表述与航班实际时间不符（18:30 并非深夜），且 4 小时行程（含机场交通、安检等）与歌词"几个小时"（“a couple hours”）的表述存在差异。

  5. 结论与争议点

    • 作者承认航班时刻表可能已变更（通过互联网档案馆验证历史数据），但未发现其他符合"200 英里"和"不同时区"条件的地点。
    • 最终推测 Mendes 可能隐晦支持俄罗斯对争议岛屿的主张，但需注意歌词创作的文学性与现实政治立场的关联性存疑。

文章通过地理距离、时区差异、航班时刻表及生物因素（蚊虫过敏）等多维度分析，试图从流行音乐文本中挖掘潜在的政治隐喻，但明确指出结论存在推测性质。

HN 热度 330 points | 评论 51 comments | 作者：jzwinck | 16 hours ago #

https://news.ycombinator.com/item?id=44222119

  • 文章属于荒诞幽默风格，通过过度解读流行歌词展现讽刺效果
  • 评论认为这种创作方式类似于阴谋论或粉丝文化中对隐喻的病态追寻
  • 有读者指出作者在逻辑推导中存在疏漏，如未验证伊图鲁普岛是否有酒店
  • 部分观点认为此类文字是纯粹的脑力游戏，无需刻意赋予深层意义
  • 有人联想到 Nathan Fielder 的喜剧手法，将日常细节夸张化为叙事线索
  • 评论提及歌词可能暗指 2018 年 Shawn Mendes 在菲律宾巡演后飞往日本的真实行程
  • 有读者表示文章结构严谨但结论荒诞，体现 OSINT（开放源情报）分析的娱乐化应用
  • 部分观点认为作者刻意制造"俄罗斯领土"等悬念增强戏剧性效果
  • 有人对比《Room 237》纪录片，指出这是对艺术过度解读的现代演绎
  • 评论提到 LLM 当前难以生成此类基于跳跃性联想的创意推理内容

Why Android can’t use CDC Ethernet (2023) #

https://jordemort.dev/blog/why-android-cant-use-cdc-ethernet/

这篇博客文章以"侦探故事"的形式详细探讨了 Android 设备无法使用 CDC Ethernet（USB 以太网适配器）的根本原因，并提供了针对不同 Android 版本设备的解决方案探索过程。文章主体内容如下：

  1. 问题核心： Android 的 EthernetTracker 服务仅识别以 ethX 命名的网络接口（如 eth0、eth1），但 Linux 内核的 CDC Ethernet 驱动会创建以 usbX 命名的接口（如 usb0、usb1）。这种命名规则的不匹配导致 Android 系统无法自动识别 CDC 以太网设备。

  2. USB 以太网适配器支持现状：

    • Android 系统包含对 USB 以太网适配器的支持，但需要用户手动选择兼容的芯片组
    • 手机厂商极少公开支持的适配器列表，主要依赖论坛用户的测试经验
    • 如果手机厂商提供配套的 USB 以太网适配器，通常兼容性较好

  3. Linux 内核配置与适配器支持：

    • Android 设备底层使用 Linux 内核，其支持的硬件取决于内核配置
    • 新设备（Android 11 及以上）使用 Google 强制要求的 GKI 内核，相关配置文件位于 arch/$ARCH/configs/gki_defconfig
    • 旧设备（如 Android 10）需要厂商自行维护内核源码，三星等厂商会通过开源网站（如 opensource.samsung.com）发布源码

  4. 内核版本与架构查询方法：

    • 通过 ADB shell 运行 uname -a 命令获取内核版本和架构
    • 示例输出显示内核版本为 4.19.113-26203352，架构为 aarch64（ARM64）
    • 需要根据内核版本匹配 Google 内核仓库的对应分支

  5. 调试流程改进：

    • 为避免 USB 调试端口冲突，作者演示了如何通过 ADB 切换到网络调试模式
    • 具体步骤包括：
      • 启用 USB 调试并安装 ADB 工具
      • 通过 adb tcpip 5555 设置网络调试
      • 获取手机 IP 地址并运行 adb connect YOUR_PHONE_IP:5555
      • 验证网络连接是否生效

  6. 旧设备内核配置获取：

    • 以三星 Galaxy S20 为例，其内核配置文件为 vendor/x1q_usa_singlex_defconfig
    • 通过 find 命令定位配置文件路径：./arch/arm64/configs/vendor/x1q_usa_singlex_defconfig
    • 需要分析厂商提供的构建脚本（如 build_kernel.sh）来确定配置文件位置

  7. 解决方案限制：

    • 无法通过常规方式修改 Android 的 config_ethernet_iface_regex 配置（需 root 权限）
    • 新设备（GKI 内核）和旧设备的内核配置获取方式存在差异
    • 适配器兼容性仍需依赖用户社区测试经验

  8. 技术细节补充：

    • 提供了构建三星内核的脚本示例，包含交叉编译工具链路径和配置参数
    • 强调了不同 Android 版本（10 vs 11+）在内核管理上的政策变化
    • 说明了 Linux 内核版本（4.19）与 Android 版本（13）可能存在的不匹配现象

文章最后以幽默的"侦探故事"收尾，指出虽然通过技术分析找到了问题根源，但实际解决仍需依赖厂商支持或 root 操作，暗示这一问题的解决存在现实限制。

HN 热度 327 points | 评论 130 comments | 作者：goodburb | 1 day ago #

https://news.ycombinator.com/item?id=44219405

  • 修改 CDC 设备的 MAC 地址全局位可使 Android 设备将其识别为 eth0 而非 usbX
  • Android 14（U+）后内核默认同时支持 usb\d+ 和 eth%d 命名的接口
  • 该变更因部分设备依赖 usbX 接口回滚，但 Android 15（V+）已重新引入支持
  • Android 的网络接口命名逻辑导致 CDC Ethernet 兼容性问题，需手动干预
  • 用户抱怨 Android USB 串口设备权限限制，需 root 或第三方库实现访问
  • WebUSB 支持但 WebSerial 缺失，限制浏览器直接操作串口设备
  • 三星等厂商对 Android 15 的实现可能影响 CDC Ethernet 功能
  • 建议通过 udev 规则自动重命名网络接口以提升兼容性
  • Android 网络管理模块缺乏对 USB 串口协议的完整支持
  • LineageOS 社区尝试修复但缺乏实际设备测试验证

LLMs are cheap #

https://www.snellman.net/blog/archive/2025-06-02-llms-are-cheap/

Juho Snellman 在其 2025 年 6 月 2 日的博客文章《LLMs are cheap》中指出，尽管生成式 AI（尤其是大语言模型）的运营成本被普遍认为高昂，但实际价格已大幅下降，甚至低于传统网络搜索 API。文章通过具体数据对比和反驳常见质疑，试图澄清这一误解。

核心论点 作者强调，过去六个月反复遇到有人声称 LLM 成本过高，但这一观点并未随技术进步而减少。他通过对比搜索 API 和 LLM 的定价模型，证明 LLM 的运营成本已显著降低。

网络搜索 API 定价

  • Gemini API：Google 的"Grounding with Google Search"功能定价为 35 美元/1000 次查询（未公布纯搜索结果 API 价格）。
  • Bing Search API：最低档定价 15 美元/1000 次查询。
  • Brave：最低档 5 美元/1000 次搜索，但其定价结构异常（配额越大单价越高），实际可用档位为 9 美元/1000 次搜索。
  • 作者指出，搜索引擎的定价与其质量相关，且价格范围较窄（5-35 美元/1000 次查询）。

LLM 定价对比

  • 测试数据：作者选取 4 个日常搜索问题（如"LLM 术语首次使用时间"、“欧洲登机箱尺寸限制"等），在 Gemini 2.5 Flash（关闭思考模式）上测试，平均输出 500-1000 tokens，耗时 2.5-7.6 秒。
  • LLM 模型价格（2025 年 5 月 2 日数据）：
    • 低档模型：Gemma 3 27B（0.20 美元/100 万 tokens）、Qwen3 30B A3B（0.30 美元）、Gemini 2.0 Flash（0.40 美元）。
    • 中档模型：Gemini 2.5 Flash Preview（0.60 美元）、GPT-4.1 nano（0.40 美元）、GPT-4.1 mini（1.60 美元）。
    • 高端模型：Claude 3.5 Haiku（4 美元）、GPT-4.1（8 美元）、Gemini 2.5 Pro Preview（10 美元）、Claude 3.7 Sonnet（15 美元）、o3（40 美元）。
  • 直接对比：若以平均 1000 tokens/查询计算，LLM 价格（如 0.20 美元/1000 tokens）远低于搜索 API（如 5-35 美元/1000 次查询）。例如，Bing 搜索 API（15 美元/1000 次查询）与 Gemini 2.5 Flash（0.60 美元/1000 tokens）的对比显示 LLM 便宜 25 倍。

常见反驳与回应

  1. “LLM 响应长度更长”：作者承认测试选取的是搜索类问题（输出 500-1000 tokens），但指出在复杂场景（如代码生成）中，搜索 API 的对比需调整到相同领域。
  2. “LLM 价格被补贴”：作者反驳称，搜索 API 价格已包含索引构建和更新成本，而 LLM 仅计算推理成本。他列举了多个证据：
    • 无长期市场锁定需求，且模型更新频繁，低价策略难以持续。
    • 第三方托管服务（如 Brave、Deepseek）的 LLM 价格与官方 API 相当，无补贴动机。
    • Deepseek R1 的公开数据表明，其 GPU 成本利润率可达 80%。
    • 基于模型架构的理论成本分析与实际定价吻合。

其他因素

  • 批量请求折扣：Anthropic、Google、OpenAI 等提供 50% 折扣；Deepseek 在非高峰时段折扣 50%-75%。
  • 第三方托管成本：如 Deepseek R1 的第三方托管价格与官方 API 竞争激烈，进一步佐证成本可控。

文章最后提到，OpenAI 的财务数据（如年 40 亿美元支出）可能被误解为 LLM 成本高，但结合推理效率提升，实际成本已大幅下降。作者总结认为，LLM 的运营成本已进入可规模化商业化的阶段，远低于多数人的预期。

HN 热度 286 points | 评论 261 comments | 作者：Bogdanp | 12 hours ago #

https://news.ycombinator.com/item?id=44223448

  • LLM 推理成本远低于训练但仍是运营支出而非资本支出
  • 云服务商通过短期补贴吸引用户但无法长期维持亏损模式
  • 大模型更新迭代快导致旧版本快速贬值难以形成资产
  • 企业过度依赖 LLM 可能面临技术过时和成本失控风险
  • 当前 AI 领域资本投入与实际盈利存在显著时间差
  • 推理成本因模型规模和使用场景差异可能大幅上升
  • 技术成熟度不同导致搜索服务与 LLM 服务的经济模型不可比
  • 模型权重作为无形资产需考虑持续研发投入的资本化问题

Self-hosted x86 back end is now default in debug mode #

https://ziglang.org/devlog/2025/#2025-06-08

- 现在，当目标是 x86_64 时，默认情况下，Zig 将使用自己的 x86 后端，而不是使用 LLVM 将 bitcode 文件降低到对象文件。不过，由于还需要先完成更多的 COFF 链接器工作，所以默认设置在 Windows 上尚未改变。

- Zig 的 x86 后端目前通过了 1987 项行为测试，而 LLVM 后端通过了 1980 项。实际上有 2084 项行为测试，但额外的那些测试通常与 LLVM 自己 x86 后端的测试套件冗余，所以只在使用自托管 x86 测试时才会运行。总之，Zig 的 x86 后端在实现 Zig 语言方面比其 LLVM 后端更健壮。

- Zig 与 LLVM 在代码生成上竞争的原因主要有几个，主要是因为 Zig 在编译速度上可以大幅超越 LLVM。

- 文章列举了两个基准测试：第一个使用 LLVM 后端，第二个使用 Zig 自托管 x86 后端。在第二个测试中，与第一个测试相比，墙钟时间减少了 70.1%，峰值 RSS 减少了 36.2%，CPU 周期减少了 65.2%，指令减少了 62.2%，缓存引用减少了 68.7%，缓存未命中减少了 86.1%，分支未命中减少了 78.3%。对于像 Zig 编译器本身这样的大型项目，使用 Zig 自托管 x86 后端，编译时间可以从 75 秒缩短到 20 秒。

- Zig 的工作还在继续。他们已经开始全面并行化代码生成的工作。他们距离使增量编译与这个后端结合稳定且健壮，也只差一些链接器增强和错误修复。还有改进生成的 x86 代码质量的低垂果实可以摘取。他们接下来将着眼于 aarch64，预计这项工作会因为新的 Legalize 传递而加速。

- CI 已经完成了相应提交的构建，所以你可以通过从下载页面获取最新 master 分支构建来亲自尝试。

- 文章最后提醒，Zig 软件基金会是一个 501(c)(3) 非营利组织，其开发资金来自像你这样慷慨的人的捐赠。如果你喜欢他们的工作，请帮助他们保持财务可持续性。

HN 热度 277 points | 评论 159 comments | 作者：brson | 1 day ago #

https://news.ycombinator.com/item?id=44219857

  • Zig 的编译器在 comptime 性能优化方面需要重构语义分析代码，但优先级可能低于其他任务
  • Zig 1.0 有望成为系统编程领域的主导语言，但需解决当前编译器性能瓶颈
  • 多个系统编程语言（C/C++/Rust/Zig 等）可通过 VSCode 的 LSP 和 DAP 协议共存并共享开发工具链
  • 游戏开发领域对热代码交换（Hot Code Swapping）功能需求强烈，Zig 的实现可能带来变革
  • Zig 的跨平台调试和编译能力已足够优秀，尤其适合需要高性能和 C 兼容性的项目
  • 语言流行度直接影响 IDE 生态发展，但开源协议如 LSP 能缓解部分问题
  • 与 C#相比 Zig 在游戏开发中缺乏现成的热重载支持，但编译速度和 LLVM 后端优势明显
  • Zig 的 URCL 后端开发计划受到关注，社区期待更多自定义后端的可能性
  • 语言基金会直接支付贡献者的方式值得肯定，但需平衡开发进度与功能完善性
  • 现有系统编程语言生态（如 FreeBSD 基金会）与 Zig 的模式存在差异但同样重视核心功能投入

What happens when people don’t understand how AI works #

https://www.theatlantic.com/culture/archive/2025/06/artificial-intelligence-illiteracy/683021/

该网页呈现的是《大西洋月刊》一篇关于人工智能认知误区的深度文章。文章以 1863 年 6 月 13 日新西兰《The Press》报刊登的一封署名"Cellarius"的读者来信开篇，指出当时 23 岁的英国作家塞缪尔·巴特勒（Samuel Butler）在信中预言了"机械王国"对人类的统治威胁，这封信后来被证实是巴特勒创作反乌托邦小说《厄鲁文》（Erewhon）前的重要思想萌芽。

文章主体聚焦当代 AI 产业的现实发展，重点介绍了科技记者凯伦·浩（Karen Hao）于 2025 年出版的新书《AI 帝国：山姆·阿尔特曼与 OpenAI 的梦想与噩梦》，该书通过硅谷内部揭秘和全球产业链调查，揭示了训练大型语言模型（如 ChatGPT）所需的庞大人力劳动。同时提及语言学家艾米莉·M·本德（Emily M. Bender）与社会学家亚历克斯·汉娜（Alex Hanna）合著的《AI 骗局：如何对抗科技巨头的炒作并创造我们想要的未来》，该书直接指出 AI 行业的基础存在系统性欺诈。

两部作品都通过不同角度论证了当前 AI 产业的泡沫化特征，前者隐晦地、后者明确地将 AI 产业比作建立在虚假承诺上的"骗局”。文章作者泰勒·奥斯汀·哈珀（Tyler Austin Harper）系《大西洋月刊》驻编，此前担任巴茨学院环境研究助理教授，其学术背景涉及文学、电影与科学史研究，同时担任播客《Time to Say Goodbye》的联合主持人。

HN 热度 246 points | 评论 300 comments | 作者：rmason | 1 day ago #

https://news.ycombinator.com/item?id=44219279

  • LLMs 本质是生成语法正确而非事实正确的文本，需警惕其幻觉问题并主动验证信息
  • 非技术用户常将 LLMs 视为神谕或权威信息源，缺乏对其概率性生成机制的认知
  • 将 LLMs 拟人化为“思考”或“意识”实体是误导性表述，其本质仍是数学模型与文本组合
  • 需通过人类学、符号学等跨学科视角理解用户对 LLMs 的仪式化使用行为
  • 推荐使用 Perplexity 等具备实时搜索能力的工具替代纯 LLM 输出以提高可信度
  • 逐步替换人类器官的假设挑战了意识与技术的界限，质疑人类独特性的论断
  • 会计从业者误用 LLMs 处理财务数据暴露了工具滥用的风险与专业领域局限性