AprilNEA's Notebook

TinyCorp 成功让 MacBook 通过 USB4 运行 Nvidia GPU AI 初创公司 TinyCorp 成功开发出驱动程序，让 Nvidia RTX 30、40、50 系列显卡能够通过外置 GPU 扩展坞在 ARM 架构的 MacBook 上运行。该公司在 X 平台展示了 MacBook Pro M3 Max 通过 USB4 连接 ADT-UT3G 扩展坞运行 RTX GPU 的演示。 不过这些驱动程序专为 AI 开发设计，不支持显示输出功能。对于 AI 开发者来说，这项技术能让他们在 MacBook 上运行本地大语言模型和其他 AI 模型，性能远超苹果 M 系列 GPU。TinyCorp 此前已成功让 AMD 显卡在苹果芯片 MacBook 上运行，现在将这一技术扩展到了 Nvidia GPU。 Tom's Hardware 🍀在花频道🍵茶馆📮投稿

简单复盘一下 AWS 这次事件作为一个 AIGC Startup SRE 的一些操作吧，希望能帮到大家 从入职开始发现我们主要的集群在 USE1 之后，我就开始做一些准备了。 我主要做的事情有这几件事 1. 将我们核心的几个数据库做了多地的备份，形成了 USE1，Tokyo，SG 三地备份。这样在极端情况下，我们损失一部分数据，但是也能保证服务的继续 2. 将我们 SG 的测试集群从原本的 EC2 自己简单搭的 K3S，重构为了一个标准的 AWS EKS 集群。这样可以在灾害时刻快速 warmup 一个集群，复用 AWS 已有组件。将 manifest 变更的代价降至最小 3. 简单梳理了一个 SOP，包含用户公告，DNS 切换，封版等事宜 回到今天，我大概在 AWS 事故发生后的10min，发现了我们容器中有新的 Pod 无法 setup。 在和 AWS 支持确认是 USE1 的问题后，我意识到 ECR 的事件必然关联其余事件，于是我就果断按照我自己规划的 Tier1 等级事件开始处理（对于 SRE 来说，这种事情宁可错，但是不能错过） T+0 min，我发布了全员公告，开始进入紧急模式。我 setup 了一个全员公开会议。所有人员可以随时加入 T+2 min，我确认事件如我所预期的一样，在逐渐扩大，我发出了两个指令，1. 全线禁止任何代码合入/提交（主要是避免新创建资源会导致 Pod rotate 进而影响流量），2. 请运营同学准备公告 T+3 min, 我开始按照 SOP，开始进行数据库在 SG 区域的恢复，并且级联创建诸如 OpenSearch / Redis 等在内的依赖 T+5 min，我们开始正式的确认上下游依赖的具体问题，确认一个新上线的核心服务受到影响 T+10min，我们停服公告和其余服务的受影响公告发出 T+10min，我请另外两位同时协助 setup 新的 ECR 以及清理测试环境已有资源，并同步 CTO ，在极端情况下，我们可能会存在保体验，丢数据的决策。 T+15min， 我们最终确认目前已创建的资源以及流量入方向不会受到太大影响。切换方案挂起，但是我们继续准备相关资源 T+30min，我们第一个数据库恢复完毕 T+40min，我们第二个数据库恢复完毕 T+1h，我们所有关联的核心 infra，RDS/ES/Redis 都 stand by，并且按照生产架构设置主从等优化选项。同时我们也开始正在新的集群启动新的服务 所幸，最终 AWS 的 crash 没有影响我们全部服务。我们无须面对切换流量后复杂的数据修复工作 大概 T+2h 到 T+3h 后，我正式通报全员，紧急状态解除。为保险起见，今晚依旧对 feature 封版。 回顾整个事故，我还可以做的更多 1. 将我之前为自己准备的极端 case SOP，对全员公开。这样确保我即便不在线，也有人能接替我 2. 我们可以做一些提前的预先演练 3. 指令下达可以更果断一些 差不多就是这样，一点分享，希望能帮到大家

Cloudflare 宣布向所有用户开放企业级功能 Cloudflare 宣布将在未来一年内向所有客户开放几乎所有功能，无需企业账户即可购买使用。该公司表示将取消"企业专属"功能概念，让任何规模的团队都能使用最先进的配置选项。 首个开放功能是仪表板单点登录（SSO），现已向所有计划用户免费提供。Cloudflare 还新增 GitHub 社交登录支持，并承诺未来所有新功能都将遵循这一开放模式，无需销售团队介入即可自助购买。 Cloudflare 官方博客 🍀在花频道🍵茶馆📮投稿

Cloudflare 宣布将发布稳定币 NET Dollar，用于 GenAI agent 的自动化内容付费等。 - cloudflare.com/~ - https://netdollar.cloudflare.com/ linksrc: https://t.me/tsuThoughts/871 #Cloudflare#Crypto#GenAI

https://twitter.com/qqqqqf5/status/1971102803021218166

Protobuffers 的設計是錯的（2018） （★ 103 分） 這篇文章主張 Protocol Buffers（簡稱 Protobuf）是一個設計不良的序列化技術。作者指出 Protobuf 的型別系統薄弱且充滿限制，許多功能組合不良，顯示其設計是隨興拼湊而來。他批評像是 `map` 與 `oneof` 等關鍵結構不但缺乏一致性，還製造出許多不合理的限制，例如 `oneof` 不能重複、`map` 不能巢狀以及列舉型別(enum) 不能作為鍵值，這使得系統難以維護並阻礙了程式碼的泛型化。文章建議，若改採更嚴謹且現代化的型別系統，如將訊息設為「乘積型別」(product types)、`oneof` 為「和型別」(coproduct types)、並支援參數化，便能大幅減少複雜度與限制。 作者也批評 Protobuf 在處理「可選欄位」與「預設值」上的設計帶來嚴重後果。因為所有純量型別欄位都會被預設初始化，導致系統難以區分「未設定值」與「預設值」，對於需要前後相容的 API 來說是一場噩夢。此外，其訊息型別的存取行為異常，會在不經意間建立新物件或覆寫欄位，使得類似 `msg.foo = msg.foo` 這樣的操作不再是無副作用的。這些問題不僅讓 API 設計變得危險，也使應用程式難以保證一致性。 至於 Protobuf 向外界宣稱的前後相容性，作者認為其本質上是「過度寬鬆」而非真正解決方案。它能處理未知欄位，看似支援不破壞性的轉換，但實務上大多程式並不會真正保留這些未知欄位，反而造成大量額外的驗證與防禦性程式碼，這將問題分散到整個程式庫，使維護更為混亂。作者強調，Google 之所以推廣這樣的設計，與其特殊規模與成本考量有關，但對於一般新創或中小型公司而言，花人力處理這些折衷反而代價更高。 最後，作者強調 Protobuf 最大的危害是不斷滲透程式碼庫。由於它的資料結構設計並不自然貼近應用邏輯，開發者往往要在「維護一組內部資料型別」與「直接將 Protobuf 用於業務邏輯」之間做痛苦選擇。實務上後者更常發生，導致整個系統充滿難以維護的代碼生成與不合語言慣例的結構，結果是寫出的程式龐雜又脆弱。作者最後語帶諷刺地警告「凡引入 Protobuf 的專案皆將失去希望」。 在 Hacker News 的討論中，不少人認同作者指出的問題，例如產生的程式碼笨拙、不支援「必填欄位」、以及鬆散型別設計讓 API 消費者必須額外檢查資料。然而，也有許多工程師認為作者過於苛刻。有人指出 Protobuf 本來就不是要成為一個完美的型別系統，而是要在跨語言、跨平台傳遞高效資料時提供足夠的兼容性與速度。許多評論者分享經驗，指出雖然 Protobuf 設計有缺陷，但其「簡單、好用、效能佳」足以應付大多數產業場景，特別是在需要前後兼容部署的分散式系統裡。此外，Protobuf 的廣泛支援與工具鏈，讓它在現實世界中仍比 MessagePack、CBOR、Thrift 等替代方案更實用。 也有人提出，雖然 Protobuf 不是理想的資料建模工具，但若僅將其限制在序列化和通訊格式，而避免讓其滲透進應用邏輯，問題會減少許多。像 Cap’n Proto、FlatBuffers 或 Typical 等新興方案被提及，但社群普遍認為沒有一個替代品能同時提供 Protobuf 現有的跨語言支援與完整生態。因此，爭論的核心在於「理論優雅」與「工程實用性」之間的張力。總結來說，多數工程師雖然承認 Protobuf 有很多怪異甚至令人痛苦的設計，但也普遍認為它在真實世界的妥協仍有其價值。 👥110 則討論、評論 💬 https://news.ycombinator.com/item?id=45139656

技术回溯 好用的新技术出现后，往往会取代旧技术，之后可能作为 过时技术，被存档在历史书、课本和纪录片里。但有时候，新技术会出现了无法修复的问题，于是不得不将旧技术作为补充，甚至完全回溯到旧技术。 证书吊销列表（CRL）是检查证书吊销状态的的机制，主要被浏览器用作检查网站 数字签名。不过之后被在线证书状态协议（OCSP）取代，因为资源占用更小，看起来似乎也更安全。 但在 2020 年，macOS 的 OCSP 被认为具有隐私风险，因为 OCSP 使用 HTTP 明文与哈希交换信息，那么中间人可以注意到用户在什么时候打开了某个软件。之后虽然出现了 OCSP 装订技术，用藏木于林来增加隐私，但这增加了复杂性，还是不能完美解决问题。 既然 OCSP 的吊销证书机制不够好用，那么便退回到 CRL，并配套使用有效期短的证书。只要证书快速吊销（最短 6 天），那么证书泄漏所造成的风险也就变小，也就不需要具有实时查询功能的 OCSP，只要使用 CRL 便足够安全了。 最大最知名的免费证书机构 Let's Encrypt，已在上个月 关闭 OCSP 服务。这个稍微比 CRL 先进一些的技术，在活跃十多年后，还是被旧技术代替了。（至少在浏览器领域） 类似的情况也挺常见，比如担心 GPS 的可靠性，所以美国海军，恢复 了天文导航和六分仪使用的训练。全触屏，没有实体按键的手机（Meizu Zero）与汽车被认为不够实用，所以目前大多产品还是有保留实体按键。以及动态网站在过去几乎完全取代了静态网站，但因为 SEO、性能与安全问题，静态网站生成器又开始变得流行了。 #技术

#互联网观察 ▎苹果或将在下周发布全新 AirTag 2，传闻升级超宽频芯片与安全功能 在经历了超过四年的等待后，苹果有望在下周的年度 iPhone 发布会上正式推出第二代 AirTag 定位追踪器。根据 9to5Mac 早前的消息，苹果原计划在今年秋季发布新品，结合往年惯例，这一时间点极有可能落在 9 月的 iPhone 发布会上。 AirTag 2 传闻亮点 • 第二代超宽频芯片：追踪范围或将提升至当前版本的 3 倍。 • 防拆扬声器设计：进一步强化反跟踪安全性。 • 电量提示优化：新增“极低电量”提醒功能。 • 与 Vision Pro/空间计算整合：具体细节暂未公布。 • 外观设计：外形与现有款式相近。 • 电池形式：依旧采用 CR2032 纽扣电池，需定期更换，不支持可充电设计。 ▎新闻来源 https://www.macrumors.com/2025/09/02/airtag-2-rumored-features/ 频道 @AppDoDo官推 @APPDOTG

从未想过用 Git 以外的版本控制工具，直到我了解了 jj 的逻辑，只看了一个视频就听懂并接受了。于是我开始思考，如果原本根深蒂固的思想很容易就被一个新的思想覆盖，或许确实说明这个老的思想不够符合大脑的直觉偏好。回想了一下，我当年花了一两年才把 git 的分支和冲突处理用明白，jj 却让我首次意识到，版本管理不该如此复杂繁琐。我感觉长期被 git 压迫的大脑猛然呼吸了一口新鲜空气，也许它真的是下一代更好用的版本控制工具。 https://github.com/jj-vcs/jj 视频（可以直接从 12:39 开始看）: https://youtu.be/2otjrTzRfVk?si=q4UaeFVPMw1uqYmv&t=759

#GoogleIO 哈哈，过了

#AI#ClaudeCode https://fixupx.com/AprilNEA/status/1942810855835590832

写代码从来不是瓶颈｜Pedro Tavares 多年来，我一直认为软件开发的瓶颈根本不在于写代码本身。 真正的瓶颈从来都是代码审查、通过指导与结对编程传递知识、测试、调试，还有人与人之间沟通协调所产生的“人类开销”。所有这些都被嵌套在纷繁复杂的任务票据、计划会议和敏捷开发流程之中。 这些旨在提升质量的流程，往往比实际写代码的速度慢得多，因为它们需要思考、共同理解，以及理性判断。 现在，大语言模型（LLM）的兴起使得生成可运行的代码变得前所未有的简单快捷，一种新的论调便随之出现：过去写代码才是瓶颈，现在我们终于打破了它。 但事实并非如此。 尽管借助LLM，新增代码的边际成本正在无限趋近于零，但理解、测试、信任这些代码的成本却比以往更高了。 LLM只是转移了工作，而非移除了工作 像Claude这样的工具能加快初步的代码实现，但结果通常是产生更多代码，进而给审查、集成和维护代码的人带来更大的压力。 这种现象尤其明显，当： * 提交代码的人可能自己都没完全理解代码的逻辑。 * 生成的代码引入了团队不熟悉的模式或违反了已有的惯例。 * 一些边缘情况或潜在的副作用并不明显。 于是，我们陷入了这样一种状况：代码生产变得容易了，但验证代码却更加复杂，这并不会真正提高团队整体的速度。 这其实并不新鲜。开发者早就自嘲自己进行的是“复制粘贴工程”，而LLM所带来的速度和规模则进一步放大了这种复制粘贴的现象。 理解代码才是真正的困难所在 > “代码最大的成本是理解，而不是写出来。” LLM确实减少了产生代码所需的时间，但它们并未降低理解代码行为、发现细微的Bug或确保长期可维护性的努力。甚至，在面对由LLM生成的代码时，这些任务可能变得更难，因为审查者要区分生成代码与手写代码之间的差异，以及弄清为何要选择某个特定的方案。 团队仍然依赖信任和共同背景 软件开发本来就是一个协作过程，它依赖于共同的理解、目标一致和互相指导。然而，当代码的生成速度远超沟通和审查的速度时，团队可能会陷入一种“默认质量”而非“确保质量”的模式。这无形中给审查者和指导者带来巨大压力，可能进一步以微妙的方式拖慢团队的整体节奏。 LLM很强大，但并未解决根本问题 LLM在快速原型开发、脚手架搭建和自动化方面确实带来了真正的价值。然而，它们无法消除清晰思考、谨慎审查以及周密设计的必要性。相反，随着生成代码越来越多，这些基础工作变得更为关键。 是的，写代码的成本确实降低了。但团队一起理解代码的成本并没有降低。 这才是真正的瓶颈。我们不应假装它不存在。 原文：Writing Code Was Never The Bottleneck