這篇文章指出，我們正處於一個「機率時代」的科技轉折點。傳統的軟體設計基於確定性邏輯：輸入 `x` 會穩定地輸出 `y`，這讓產品開發、測試與成長模式都能以「漏斗式思維」構築，目標是百分之百地控制輸入與輸出。但隨著大型語言模型 (LLM, Large Language Model) 與通用型人工智慧的崛起，這種範式被打破。AI 系統接受的是近乎無限的開放輸入，輸出的則是機率分佈，不再保證正確性或一致性。這種隨機性雖帶來驚人彈性與新用途，也造成可靠性的缺口，讓使用者因心理預期與技術現實的落差而感到挫折。

作者將這種轉變比擬為從牛頓的確定性物理走向量子力學的不確定性。在 AI 產品的建構上，傳統的工程方法強調完美控制與可靠性，但在新環境下，過度設限只會扼殺模型的潛能。因此企業需要從工程思維轉向科學方法，接受不確定性、進行假設與驗證，並以「最小可行智慧」(Minimum Viable Intelligence) 為標準，找出在市場及使用者需求間的平衡。資料 (data) 成為新的核心營運系統，不只是上游訓練模型的原料，下游的使用者互動與行為分析更是理解 AI 產品成效的關鍵。像 Replit 就經歷了數週內全面重構的案例，以具實驗性的方式快速應對模型更新的挑戰。

文章最後強調，這一波轉變不同於以往的技術革新。它不是單純的最佳化，而是本體論上的改變：產品開發不再是線性規劃與工程控制，而是觀察、實驗、假設、迭代的循環。在這個環境中，組織結構、產品設計乃至於財務模式都要因應調整，以擁抱未知與新興的可能性。

在 Hacker News 討論中，不少人認為這篇文章對 AI 的「機率化」特質過度渲染甚至帶有炒作意味。有評論指出，概率系統並非新鮮事，自 1940 年代以來資訊理論與隨機性方法早已在工程領域應用；文章把 LLM 包裝成徹底顛覆性的事物，忽略了既有的理論基礎。也有人質疑作者用數學符號強行建立新敘事，但其實邏輯含混，甚至迴避了真正棘手的幻覺 (hallucination) 問題——在物理或數學問題上本就有標準答案，AI 回答錯誤不能僅以「有些問題沒有正確答案」來推託。

另一派則認為文章的觀點貼近「苦澀教訓」(The Bitter Lesson) ——也就是通用演算法與資料規模最終會擊敗人工設計的專門方法。他們認為確定性與機率性本來就會共存，未來的產品可能是用確定性的介面與規範來包裹機率核心，以取兩者之長。一些開發者提到自己的感受：傳統寫程式的樂趣在於「人類設計、規則清晰」，然而在機器學習中卻變成必須像科學家一樣不停實驗與統計，這種轉變讓許多人不適應。

討論中也不乏對 AI 市場過熱的批評，認為現況帶有泡沫與群體狂熱的特徵，被資本與行銷強行推動，並未真正找到最佳應用場景。不過也有人指出，即使存在泡沫，AI 的長遠影響仍將深刻且不容忽視。整體而言，這場對話展現了對 AI 發展既期待又質疑的分歧：一方面承認它帶來了新範式的挑戰與潛能，另一方面則提醒人們要警惕過度神化或不切實際的幻想。

這篇文章介紹了一種能夠透過手機喇叭控制電子購物車輪鎖的方式。許多大型連鎖超市使用 Gatekeeper Systems 的智慧購物車輪子來防止推車被帶出停車場或遺棄在周邊街道，這些輪子會接收地下線路發出的 7.8 kHz 訊號來判斷是否上鎖。管理人員則能用遙控器發送相同頻率但不同調變的訊號來解鎖。由於 7.8 kHz 屬於人類可聽範圍內，因此手機喇叭播放特製聲音檔時能產生寄生電磁場 (parasitic EMF)，進而模擬鎖定或解鎖的信號，達到控制效果。作者此前也曾在 DEF CON 29 資安研討會上公開過這個研究，展示了日常裝置如何被轉化為非預期的干擾工具。

在 Hacker News 的討論中，許多使用者表示這種創意正具有駭客精神，讓人聯想到過去有人嘗試用微控制器或 Arduino 類似技術來模擬此類信號，甚至有案例用藍牙喇叭惡搞將整片停車場的推車同時鎖起來。一些人則提出疑問，例如是否能透過超市的廣播系統 (PA system) 播放聲音來觸發，並有人指出這需要依賴手機喇叭所帶來的電磁場效應才能成功，並非單純透過音響就能達成。

不少人分享自己對這類防竊推車系統的反感經驗，包含推車在停車場路中突然鎖死，讓帶著小孩和大包小包的家長陷入危險。也有人提及這些輪子常常故障，導致推車在店內操作困難且發出噪音。部分留言者建議與其使用上鎖機制，倒不如採用類似歐洲超市的投幣押金制度，例如 Aldi 用 25 美分作為推車使用押金，能更有效促使顧客歸還推車，甚至還能為無家可歸者提供回收推車的小額收入。

其他評論則帶點玩笑與懷舊氛圍，有人回憶二十年前在麻州劍橋的超市惡作劇上鎖過整片購物車，也有人笑稱超市永遠不會移除這些系統，除非整間店被拆掉重建。綜合而言，討論一方面指出了這項安全機制的技術漏洞和被創意濫用的可能，另一方面也反映多數消費者對這種過度干預使用體驗的設計頗為不滿，並提出了更實際、友善顧客的替代解方。

作者回顧了網頁伺服器從早期因應「C10k 問題」(如何同時處理一萬個連線) 的演進過程，從最初每個請求都產生新行程，到使用多執行緒、`poll()`、`select()`，再到 `epoll`，逐步降低系統呼叫 (syscall) 負擔。不過，即便 `epoll()` 已經比過去高效，頻繁的 syscall 成本仍不可忽視。新一代的 `io_uring` 提供了解方：應用程式將操作指令寫進記憶體中的佇列，由核心非同步處理，再透過完成佇列回報結果，讓伺服器可以在高併發下避免頻繁 syscall。只要保持佇列有任務，甚至可以做到每個請求皆不需要 syscall，`strace` 監控中將顯示完全沒有系統呼叫。

除了核心的 I/O 機制外，作者也談到效能最佳化的其他面向。例如建議一個 CPU 核心專門對應一個執行緒，以避免共享資料結構造成鎖爭用，並在具有 NUMA(非一致性記憶體存取) 硬體的機器中，確保執行緒使用本地記憶體來降低延遲。在記憶體分配上，伺服器可以為每個連線預先分配固定大小的區塊，減少碎片化與額外 syscall。至於伺服器端的 kTLS 功能，則能將 TLS 加解密工作移交給 Linux 核心，應用程式處理握手後即可讓傳輸視為純文字；這不僅能搭配 `sendfile()` 避免資料複製，若網卡支援，還能將加解密運算卸載給硬體，以釋放 CPU 資源。

另一項最佳化是 descriptorless files，透過 `register_files` 將檔案描述子事先註冊，讓使用者空間僅看到整數 ID，避免描述子在核心與使用者空間間不斷傳遞的額外成本。作者並以 Rust 撰寫了一個實驗性伺服器 `tarweb`，專門從一個 tar 檔提供內容，整合 io_uring 與 kTLS。然而，目前 Rust 生態系尚缺乏對 `setsockopt()` 的完整 io_uring 支援，因此作者還提交了補丁 (PR) 以改善。雖然 `tarweb` 還遠不成熟，TLS 函式庫在握手可能仍會動態分配記憶體，但它已能展示出「零 syscall」處理 HTTPS 請求的可行性。

Hacker News 討論區普遍對此專案表示興奮與期待。許多人期待看到效能測試的基準數據，並回顧過去從 CGI 每請求衍生行程，到 Apache、nginx 的事件驅動架構之演進歷程。有工程師分享到自己嘗試 io_uring 與傳統 epoll 實作進行比較，但目前仍難以超越 nginx 的成熟表現。也有人提出若能進一步做到 DPDK 風格的「繞過核心」(kernel bypass) ，效能將可能更大幅提升；另有讀者指出像 LUNA 專案已經在嘗試類似概念。

討論也延伸到 Rust 安全模型挑戰。有開發者指出 io_uring crate 對資源釋放與記憶體安全保護不足，Rust 的所有權檢查器 (borrow checker) 無法保障非同步操作中記憶體的安全，導致開發者必須手動確保緩衝區不被釋放或覆寫。有讀者形容這種情況像「燙手山芋式所有權」(hot potato ownership)，難以用純安全 Rust 實現，可能需要透過特殊緩衝區管理或新的 crate 來解決。整體來看，社群雖認為以 Rust 實作「零 syscall」HTTPS 伺服器尚在起步，但對未來潛力與可能的重大效能突破抱有高度興趣。

文章作者認為長期依賴大型語言模型（LLM, Large Language Model）會削弱人類思考能力。他以小孩抄作業、夫妻一方從不碰帳單、或是習慣全靠導航的人為例，說明過度把認知負擔交給外部工具，會導致我們喪失自行思考與應對的基本能力。作者引用 Nassim Taleb 在《反脆弱》一書的「適度壓力讓人更強」理論，指出正如肌肉需要舉重、免疫系統需經歷病原挑戰，心智同樣需要摩擦與不適，才能讓思考敏銳、創造力成長。如果一味依賴 AI，便可能像「破窗理論」描述的城市衰敗一樣，逐步累積成全面的思維懶惰與認知退化。

近期的研究也支持這種擔憂。實驗將參與者分成三組：僅靠自己思考寫作、使用 Google 搜尋、以及完全依賴 ChatGPT。結果顯示，83% 使用 LLM 組別的人在完成文章後不久，無法正確引用自己文章裡的內容；同時，他們的腦部活動也顯示出低度參與與記憶留存不足。研究者稱這種現象是「認知債務」（cognitive debt）：短期的便利是從自己的思維能力貸款，但未來要付出利息，代價就是思維與記憶的退化。作者建議孩子們不要直接用 LLM 解題，而是先動腦算，再拿答案去對照 AI 的說明，這樣才能讓 AI 成為助力，而不是取代思考的拐杖。

在 Hacker News 的討論中，有不少人認為文章標題過於危言聳聽。有人指出，LLM 就像其他工具一樣，本身不會讓人變笨，真正的問題在於使用者若省略思考，才會導致能力退化。多位開發者分享經驗，認為 LLM 在程式撰寫、學習新技術、提高生產力方面能帶來正面幫助，尤其是對有經驗的人來說，它能加快測試與探索的速度。但也有人提醒，若單純讓 LLM 生成結果而自己不理解、不驗證，便會出現「人是編輯而不是作者」的情況，與文章中研究指出的記憶空洞現象相呼應。

討論中也有人將這個問題與過去對「文字發明」或「計算機」的爭論相比。蘇格拉底曾認為書寫會削弱記憶力，後來有人擔心計算機會讓人數學變差，但歷史證明這些工具改變了技能結構，而非全面削弱能力。一些留言指出，關鍵在於使用方式：如果把 LLM 當作快速回饋與輔助思考的工具，反而能提升學習效率；若純粹依賴生成結果，才會出現「變笨」的風險。還有觀點認為，這關乎「誰是我們」：對個人來說可能讓思考懶散，但從整體社會與經濟效率的角度，AI 可能讓人類集體更聰明。

總體而言，文章與討論並非單純唱衰 LLM，而是提醒「適度使用」的重要性。就像核能既可用於發電也可造成毀滅，LLM 能帶來巨大的幫助，但是否變笨取決於我們是否還保有主動思考的習慣。對教育者、學生、開發者而言，真正的挑戰是如何設計使用方式，既能利用 AI 的效能，又不犧牲人類心智鍛鍊的機會。

Valve 在 2018 年推出 Proton，至今已經七年。Proton 是一個相容層，能在 Linux 平台上執行 Windows 遊戲，它讓 Linux 遊戲的發展出現了劇烈轉變。文章指出，如今大部分遊戲在 Linux 平台上幾乎能夠即點即玩，除了少數依賴特殊影片編碼或需要核心層級防作弊機制的遊戲。根據 ProtonDB 的數據，目前至少約有 15,855 款遊戲經過多份使用者測試報告後確認可玩，而 Valve 自家的 Deck Verified 系統也顯示有超過 21,000 款遊戲在 SteamOS 與 Steam Deck 上可正常執行。相較於過去僅有少量移植遊戲，如今玩家已經被選擇淹沒。

作者強調，他仍然清楚記得當初 Proton 發佈的興奮，因為這意味著玩家可以不再依附 Windows 也能暢玩主流遊戲。Valve 支持 Linux 與開源雖然帶有自身商業目的，最終是為了建立自家生態圈，例如 Steam Deck 與 SteamOS，但對 Linux 桌面玩家而言，這些付出仍帶來了巨大的紅利。而隨著 Proton 成熟與 Steam Deck 銷量上升，Steam 平台的 Linux 使用者市佔率也接近突破 3%，這在 Windows 長期壟斷的情況下相當不易。更重要的是，Proton 提供了 Valve 長期發展的基礎，讓未來即使推出新版本 Steam Deck 或其他硬體，也能「即插即用」支援現有遊戲，不必重新購買。

在 Hacker News 的討論中，許多使用者分享了自己完全轉向 Linux 玩遊戲的經驗。有玩家表示三年多來完全不需要 Windows，透過 Proton 搭配 Lutris（Linux 上的遊戲安裝管理工具）就能涵蓋大部分遊戲需求。也有人指出，雖然 Proton 大幅改善 Linux 遊戲體驗，但熱門的多人遊戲如《決勝時刻》或《Fortnite》因核心層級防作弊機制仍存在障礙，這也是玩家回到 Windows 的主要原因之一。值得一提的是，有用戶強調 Windows 本身在遊戲上的體驗並不如想像穩定，例如最新遊戲需要複雜的系統設定或與反作弊技術衝突，甚至會讓玩家硬體安裝過程中「翻車」。

多數玩家對 Proton 的演進給予高度肯定。有評論者回顧過去在 Wine（另一個相容層專案）上玩遊戲需要漫長的手動設定，甚至寫好幾頁教學才能讓遊戲運作，如今幾乎能即安即玩已是巨大進步。另一部分討論認為，Valve 能成功並非單靠自身，而是整合了 WINE、DXVK（DirectX to Vulkan 轉換層）等眾多開源專案的力量，特別有人致敬 DXVK 的主要作者 Philip Rebohle，認為他對 Proton 與 Linux 遊戲生態的影響關鍵重大。

整體來看，Proton 在這七年間不僅改變了 Linux 平台的遊戲生態，更象徵著開源社群與商業公司合作的一個成功案例。雖然未來仍有不確定性，例如若 Valve 戰略改變或被收購，可能對 Linux 遊戲造成衝擊，但目前 Proton 已經形成足夠的慣性，讓 Linux 遊戲在大眾市場逐漸站穩腳步。而隨著更多遊戲發行商（如 Microsoft 與 Sony）將自家遊戲推上 Steam 平台，Linux 玩家也能共享成果。

這篇長文回顧了社會科學、心理學與統計學中的一個常見觀察：在真實世界的資料集中，幾乎所有變數之間都存在非零相關。無論表面上看似互不相干的變數，當樣本足夠大時，透過統計檢定往往仍能顯著顯示某種相關性，這被稱為「crud factor」（雜訊相關現象）。這種現象挑戰了傳統虛無假設檢定 (Null Hypothesis Significance Testing, NHST) 的意義，因為假設「相關係數正好等於 0」在現實上幾乎不可能成立。當資料量極大時，任何微小差異都能被檢出為「顯著」，導致檢定只是在證明「樣本數夠多」，而不是理論本身受到驗證。

文章回顧自 20 世紀初以來多位統計學家與心理學家的批評，包括 Gosset、Thorndike、Berkson、Meehl 等人，都指出「零假設永遠是假的」這一點。Meehl 更指出在心理學這類複雜領域，個體差異變數相互交織，背景中的潛在因子與因果網絡使得一切都產生一定程度的相關。這不僅使統計推論難以指向明確因果，也讓方向性假設價值有限，因為隨機猜測方向也有 50% 的機率「正確」。因此，研究者往往只能得到形式上顯著，卻缺乏實質解釋力的結果。

這一問題還影響到社會科學、流行病學與教育研究等實務領域。例如，在探討教育干預或公共政策的有效性研究時，幾乎所有變數之間都會互相關聯，使得「殘餘混雜因子」難以控制。文章也延伸討論稀疏性假設（sparsity principle）與潛在樞紐變數的角色，指出少數核心變數如智力 (IQ)、覺醒度 (arousal) 可能解釋到大部分變異，其餘周邊變數往往扮演附帶或下游角色。於是，很多社會介入計畫的失敗，部分原因在於操弄了邊緣變數，卻沒辦法觸及真正的核心因子。

在 Hacker News 的討論中，許多人從哲學和幽默的角度切入。有網友引用《銀河便車指南》裡的橋段，形容宇宙任何物質都相互影響，甚至可以從一塊蛋糕推算出整個宇宙。也有人提到佛教的「緣起」概念，指出這與「萬事萬物皆相關」相呼應。另一些人則強調應該特別小心「統計顯著性」與「實質意義」的混淆，因為微小到無關痛癢的效果，在大樣本下也能掛上「顯著」。有討論者提醒，這其實讓社會科學經常得出一堆「統計上顯著，但實務上毫無意義」的結論。

最後，部分評論者討論了如何應對此現象，有人主張強調效應大小 (effect size) 與實際重要性，而不是單純的 p 值；也有人呼籲從邏輯與領域知識出發，避免淪為「只看數字」的統計幻象。亦有人指出，因果關係往往是雙向或循環的，而非單向線性，這也解釋為何人類在直覺上很難判斷真正的因果。本質上，「Everything is correlated」既是經驗現實，也是一種對科學方法的挑戰 —— 提醒研究者必須在數字之外，思考理論結構與核心變數，避免被「萬物微相關」的假象淹沒。

這篇討論的核心來自一份針對 GPT-5 在醫療領域的評估報告，作者指出相較於 GPT-4 世代的模型，GPT-5 在醫療專業任務上（特別是 MedHELM 基準測試）出現了些許退步。雖然 GPT-5 在特定任務上，例如事實回憶與推理表現（如 HeadQA、MedBullets、MedCalc），略優於前代，但在結構化查詢（EHRSQL）、公平性（RaceBias）、以及醫學文獻佐證詢答（PubMedQA）等方面卻有所滑落，整體呈現「進退參半」。同時，GPT-5 在延遲表現上不均衡：處理長任務時較快，但在短任務上則顯得偏慢，抗幻覺能力雖有提升，但程度仍屬有限。

不少開發者與使用者分享了親身體驗，許多人抱怨 GPT-5 在醫療查詢的回答過於模糊、省略關鍵細節，甚至在敏感處方藥相關議題上顯得「閃避」，導致品質不足。有些人稱其「感覺像成本工程」——也就是說模型表現只是小幅提升，但更像是在追求算力成本最佳化，而非真正提升效能。部分社群討論指出 GPT-5 偶爾會出現「死循環」或重複相同錯誤答案，不論使用者如何糾正，都難以跳脫回應迴圈，這被視為一種設計或工程上的缺陷。

另一方面，也有聲音認為 GPT-5 的改變雖未帶來「突破式」進展，卻符合漸進改善的發展軌跡。有開發者指出新模型在某些程式開發與應用場景中確實大幅縮短了完成時間；但同樣地，也有人發現用在既有程式後，反而讓工具表現退步，需要額外調整提示詞（prompt engineering）甚至回退到舊模型才能恢復水準。這反映了模型效能不僅依靠架構演進，還與使用方式、設定參數（如 `reasoning_effort`、`temperature`）密切相關。

討論中還延伸到「推理模型」是否真能展現邏輯思維。多數意見強調這並非真正的「理解」或「思考」，而是透過延伸計算與語言模式擴充來產生較像推理的表現。一些研究與經驗甚至指出「思維鏈」（Chain-of-Thought, CoT）的表現高度依賴訓練資料分布，當任務稍微超出訓練範圍，其表現往往迅速下降。因此，有人認為「推理模型」不過是更精緻的樣式比對，而非真實邏輯推演。也有人提出應避免過度擬人化用詞如「理解」與「思考」，因為這可能會誤導使用者，甚至讓一般大眾以為模型具備類人智慧。

總體來看，這場 Hacker News 討論展現了對 GPT-5「退步感」的廣泛觀察，並揭示出一種拉鋸：一方面模型在部分測試中展現不錯的提升，另一方面卻在專業與敏感領域表現乏力，反映出技術進展並非直線式上升。許多留言提醒，對模型的評估必須嚴格說明設定條件與測試方式，而不能僅依靠單次或孤立的經驗。即便在 AI 大模型快速演進的當下，如何平衡準確性、可解釋性與實用性，仍是高度爭議、尚未解決的課題。

作者延續多年來對 Go 語言的批評，指出該語言在設計上存在許多不必要且早就該避免的問題。文章強調 Go 的變數作用域處理讓開發者容易出錯，例如 `err` 變數常被迫在整個函式範圍內存續，導致程式碼可讀性下降並增加錯誤風險。同樣地，Go 存在「兩種 nil」的設計，讓介面型別與指標型別在比較時出現前後矛盾，進而被作者戲稱為「兩個十億美元的錯誤」，批評其缺乏深思熟慮。

作者進一步指出 Go 在可攜性（portability）上設計不良，例如需要在檔案最上方透過編譯條件註解來區分平台，使跨平台維護極度受苦。`append` 函式的語意也令人困惑，可能導致陣列意外被修改。此外，`defer` 關鍵字也被批評為笨拙，因為它無法像 C++ 的 RAII 或 Java 的 `try-with-resources` 那樣基於語法作用域自動釋放資源，而是必須人工確認何時需要 `defer`，連標準範例都需要雙重 `Close()`，造成資源管理易錯。

另一大問題是 Go 對例外（exception）的拒斥卻矛盾地要求程式碼仍需具備「例外安全」，因為標準函式庫在某些情境下會吞掉 `panic`。作者批評這迫使開發者承擔例外處理的成本卻無法獲益。同時，Go 對非 UTF-8 字元的鬆散處理導致資料可能在備份或檔案系統操作中被跳過或遺失。除此之外，垃圾回收（GC）雖被設計成自動觸發，但在雲端服務或容器環境下往往造成記憶體佔用逐步膨脹，增加營運成本。文章總結認為，雖然社群與業界早已掌握如何設計更好的語言，但 Go 依舊延續了糟糕的選擇，最終讓大家背負大量有缺陷的程式碼庫。

在 Hacker News 的討論中，許多開發者對作者觀點表示部分認同，但也指出 Go 的優點使它在業界持續流行。有人強調它編譯速度快、生成靜態執行檔、內建標準函式庫齊全且依賴少，因此維護性佳，這也是 Go 能超越其他企業背後推動的語言（如 Dart）的原因。也有人提到 Go 本質上是 Google 為取代 C/C++ 在網路服務中的用途而設計，因此應比較的對象不該是 Rust 或 Haskell，而更偏向追求簡單部署和一致性。

批評者則指出 Go 的「簡單」常常是犧牲抽象與可擴充性換來的。雖然程式碼看似乾淨，但實際上延伸功能困難，導致長期維護成本高。有開發者形容它是「八成達標但永遠缺失最後關鍵二成」，再加上為了相容舊程式碼而限制改進空間。也有人認為 Go 有點像早年的 PHP：缺點為人詬病，但因夠簡單、夠快上手，加上 Google 背書，仍獲得廣泛採用。從另一角度看，許多企業軟體不追求最佳品質，只需要「夠用」，而 Go 剛好滿足了這種現實需求。

整體而言，文章作者尖銳攻擊 Go 的技術問題，但社群討論顯示出更多務實觀點：Go 不是完美的語言，卻在編譯速度、部署、並行處理（goroutines）等面向帶來實際價值。與其說 Go 是「優雅的程式語言」，不如說它是「一個現實世界中實用的工具」。對部分開發者而言，它的缺陷依然令人沮喪；但對企業來說，Go 已經提供了足夠的平衡，這或許就是它持續受到廣泛使用的原因。

Google 與 Meta 簽訂了一份為期六年的雲端合約，價值超過 100 億美元。根據知情人士透露，這份協議主要圍繞人工智慧 (AI) 基礎設施，Meta 將持續投入龐大的資本於 AI 指令運算和模型開發。過去 Meta 主要依賴 Amazon Web Services (AWS) 與 Microsoft Azure 的雲端資源，但隨著對 AI 運算需求急速攀升，公司需要更多計算資源來支持 Llama 模型家族以及在旗下各項產品中的 AI 功能部署。Google 此舉則是為了追趕 AWS 與 Azure 在市場的領先地位，藉由爭取到大型企業合作來強化其 Google Cloud 競爭力。這也顯示出大型科技公司之間雖在廣告業務彼此激烈競爭，但在雲端與 AI 基礎建設上卻出現策略性合作。

在財務方面，Google 母公司 Alphabet 報告顯示，Google Cloud 在 2025 年第二季營收達 136 億美元，營業利益為 28.3 億美元，營收成長率高達 32%，遠超過整體公司的 13.8%。這份與 Meta 的合約固然龐大，但相較於 Meta 當年度 650 億美元的資本支出 (Capex) 規模，實際上僅佔很小比例，被視為一種補充性配置。Meta 除了自行營運龐大資料中心外，也在策略上承諾與 AWS 和 Azure 保持合作，可見這份 Google 的合約更多是資源彈性配置的一環，而不是轉向主要依賴 GCP (Google Cloud Platform)。

在 Hacker News 討論區，許多評論者試圖解析這份合作的本質。有觀點指出，Meta 仍大規模自建資料中心，但短期內無法即時興建足夠的中心以滿足算力需求，因此轉向外部雲端供應商作「彈性緩衝」。也有人提到這可能與 Google 的 TPU (Tensor Processing Unit，張量處理器) 有關，Meta 希望借用這項專用於 AI 運算的硬體優勢。然而，討論中亦有人提醒，Google 在 TPU 的資源分配策略下，內部常會優先使用最新硬體，租賃給客戶的則多是前幾代，這可能影響外部客戶效益。

此外，也有評論者提出 Google 自身雲端服務的挑戰。與 AWS 提供的細緻資源、多樣化服務相比，或與 Azure 的企業深度整合相比，Google Cloud 在廣度上仍難以全面競爭。批評者指出，GCP 常僅適合短期高記憶體運算或簡單容器化應用，且服務穩定度與支援品質仍有待加強；不過亦有人強調 BigQuery 等分析工具在資料查詢上仍具領先地位，相對 AWS Athena 或 Azure Synapse 更具優勢。

總體來說，這份交易雖金額龐大，但對 Meta 而言更像是一項戰術性配置，用以加快 AI 發展速度並分散供應風險；對 Google 則是一場聲望和戰略的勝利，有助於強化其雲端市佔率並展示 TPU 基礎設施的價值。外界普遍認為，這樣的合作未來可能愈趨頻繁，因為各大科技公司需要同時在內部建設與外部租用之間尋找平衡，以應付 AI 算力需求持續爆炸性的成長。

原始文章探討科學家如何逐漸認為 X（前 Twitter）已不再具備專業用途，並轉往新興平台 Bluesky。原因在於 Twitter 在馬斯克接手後改名 X，演算法推送改變，訂閱制與特定帳號獲得演算法偏好，導致大量雜訊、錯誤資訊、廣告與爭議性內容湧入，使其難以維繫過去在科技與科學圈中的高品質交流環境。文章指出，過往 Twitter 是科研人員、業界專家與一般公眾交流的重要平台，但隨著平台生態惡化，許多學者轉向其他選擇，如 Bluesky 或 Mastodon，以尋找更穩定且專業的互動空間。

Hacker News 上的討論呈現分歧。一部分使用者認為 Bluesky 尚未完全成形，缺乏像 Twitter 早期那樣的廣大科技與哲學討論社群，但其「無演算法推播、容易過濾不想看的內容」的特性，讓許多人覺得比 X 更乾淨、更容易維持專業討論。一些研究人員在那裡依然找到對科學、加密技術等主題感興趣的聽眾，雖然整體聲量較小，但討論品質反而更高。

另一方面，也有評論認為 Bluesky 正在形成「知識泡泡」，代表學界人士彼此關起門來溝通，對外部社群失去影響力；批評者質疑相關論文過度概化，甚至帶有政治動機。部分使用者更指出 Mastodon、Nostr 等去中心化平台不應被忽視，因為許多專業人士仍在那裡維持交流。同時，有人認為無論是哪一方，社群媒體天然就是嘈雜與混亂，科學家過度依賴這些平台並不能真正替代傳統專業管道。

不少討論則集中在如何定義「專業有用」。有使用者回顧 Twitter 的「黃金時期」——學者得以接觸跨領域觀點並快速傳播研究成果，而如今的 X 更像是梗圖與對立言論的集散地，難以作為嚴肅對話場所。箇中分歧在於，有人仍認為 X 擁有全球影響力，因此不得不留下；但更多專業人士選擇轉往 Bluesky，寧可犧牲曝光也要保有高「訊號對雜訊」比例的專業圈子。整體上，討論揭示了一個關鍵現象：隨著平台性質變遷，專業群體正在重新衡量社交媒體在知識交流中的價值與角色。

原文作者以一名軟體工程師的角度，描述他對當前「AI 程式碼文化」的困惑與反感。他指出，許多新進工程師依賴大型語言模型 (LLM, Large Language Model) 生成的「氛圍程式碼 (vibe-coded code)」，不僅難以理解，也難以維護。作者發現資深工程師在審查這些作品時非常挫折，因為任何建議一旦提供，新人工程師往往只是將回饋丟給 LLM 再吐回看似修改過的版本，毫無真正學習。甚至在公司展示場合，有新人引以為傲地高調表示「這是由 Claude 寫出來的四千行程式碼」，而管理層竟還以此作為成功案例來鼓勵。作者質疑，若工程訓練僅淪為 AI 代工，傳承與人才培育的價值將蕩然無存。

他更舉例，朋友們經歷過整個工程小組花一個月時間審查 LLM 生成的品質低落的程式碼，所花人力遠比省下的算力費用昂貴。雖然表面上這些工具似乎能加速開發，但實際上卻變成耗費更多心力在錯誤修正、需求釐清上的惡性循環。作者主張，真正值得驕傲的工作應該是本身帶來價值與穩定的成果，而不是單純依賴模型自動生成。他甚至呼籲讀者暫停使用 AI 開發，嘗試以自身搜尋與學習來得到結論，他認為自力得出的結果遠比模型吐出的內容可靠得多。

在更宏觀的產業層面，作者對人工智慧產業鏈表示悲觀。他認為所謂 AI 新創公司多半是依賴風險投資金，使用這些資金回頭購買 OpenAI 等平台的算力額度，最後便無以為繼而消失。他質疑即使是 OpenAI 目前也難以在財務上實現長期獲利，因為模型訓練與運行本質上消耗龐大電力，產生成本結構上難以規模化的問題。他直言這很可能是一個「皇帝的新衣」式的產業幻象。

在 Hacker News 的討論中，不少人呼應原作者對企業文化的批評，認為許多管理層只是盲目追求「AI 效率」的形象而忽略實際品質，更有人將這股風潮比喻為比區塊鏈、NFT 熱潮更具破壞性。一些工程師憂心若新人只靠 LLM 組裝程式碼，十年後恐怕會升任資深職位卻缺乏真正的程式實力，造成企業長遠的技術空洞。然而，也有不同觀點指出，問題不在於 AI 工具本身，而在於如何使用。支持者認為 AI 可以快速協助建立原型、撰寫測試或文件，若搭配良好的開發流程與人類判斷，能夠發揮輔助作用，而不是簡單代工。

許多留言進一步點出「垃圾進、垃圾出」的原則，若開發者只是丟出模糊需求，AI 輸出的成果自然品質低落；但若提供嚴謹的規格與檢驗，就像帶領新人一樣，AI 仍可成為有效工具。有開發者強調要將 AI 視為輔助思考或橡皮鴨除錯 (rubber duck debugging) 的夥伴，而不是完全倚賴的程式員替代品。不過，也有人尖銳反駁，認為把程式碼審查時間浪費在「AI 泥漿」毫無經濟效益，早該承認這一輪是被過度炒作的泡沫。

綜合來看，這場爭論凸顯了業界的根本矛盾：工程師期望建立穩健、可靠的系統並培養後進，但企業卻一味追逐短期效率與市場話題。人工智慧在軟體開發中是助力還是累贅，關鍵不在技術本身，而在於企業與個人如何選擇使用它們，以及是否有勇氣面對那些「看似成功卻本質空洞」的報告與展示。

這篇文章強調了一項常被忽略的管理關鍵技巧：修復（repair）。作者指出，當你成為管理者後，犯錯是無可避免的，你可能會給出讓人受挫的回饋、做出錯誤判斷、忘記重要承諾，甚至在會議中失控。真正重要的不是是否犯錯，而是之後如何處理。作者借用心理學家 Becky Kennedy 在親職教育書籍《Good Inside》中的觀點，說明「修復」才是維繫關係的核心能力：承認錯誤、負起責任，並重新建立連結。這個概念同樣適用於管理工作，因為好主管不是不會犯錯，而是能在錯誤之後用正確方式彌補，進而讓團隊更信任他。

文中舉例說明，一些主管會在客戶簡報或董事會報告時隨意承諾功能或時程，結果團隊被迫加班熬夜完成，代價是過勞、技術債和壓力累積。如果主管最後假裝沒事發生，團隊會逐漸流失人才；反之若主管主動道歉並具體承認責任，承諾下次會先諮詢團隊，反而能在挫敗中建立信任。作者同時也提出修復的四個要點：清楚具體指出錯誤、不要把焦點放在自己身上、用行動證明改變、並給予時間讓信任逐步重建。這樣的彌補不僅能止損，還能讓管理者更有自信做出決策與冒險，不再被完美主義綁住。

Hacker News 討論中，許多人對「道歉與修復」這點相當認同。其中有人補充，有力的道歉在於具體而真誠，而不是「抱歉你會這樣感覺」這類假性道歉；如果錯是在公開場合犯下，修復也該在相同場合完成，否則會失去誠意。另一些人則點出企業的激勵結構常導致壞文化，許多主管寧願保住職位而不是真心改善，甚至高層也偏好層層疊加的管理架構，這讓基層工程師常感到被犧牲。部分評論者則認為這篇文章過於「心理化」，管理的重點應是清楚執行任務，避免反覆錯誤，而非沉迷於道歉的形式。

也有人呼應了作者的觀點，指出工作關係本質上也是人際關係，「修復」並非軟弱，而是建立長期信任的基礎。有人強調真正的技巧不只是謙卑，而是「精準的自我覺察」，讓責任承擔和調整行為變成反射動作。討論中還有人把焦點延伸到資深工程師（Senior Engineer），認為他們同樣需要具備謙卑與修復的能力，否則會因傲慢而毒害整個團隊氛圍。另有評論指出，優秀主管真正的價值，在於替團隊擋下不合理的高層要求，並敢於對上層說「不」，而不是把壓力一再轉嫁。

整體來說，文章與討論的交集在於：好主管的價值不在於「零失誤」，而在於出錯後如何修復並重建信任。這既是職場管理技巧，也是人際互動根本法則。若能具體承認錯誤、展現責任感並付諸實際改變，就能在不完美中建立更強的團隊凝聚力。

這篇文章指出人工智慧（AI）最大的障礙之一，是它「自信卻錯誤」的特性。作者以大型企業導入 AI 的經驗為例，解釋 AI 常在輸出答案時信誓旦旦卻錯得離譜，導致一連串副作用。首先，企業與使用者因為無法預知 AI 哪些時候會出錯，被迫對每個輸出逐一驗證，形成所謂的「驗證稅」，嚴重降低投資報酬率。其次，信任感會被不對等地摧毀：一次高自信的錯誤輸出，比十次正確輸出更容易打擊使用者的信心，迫使人們退回原本的人力流程。再者，若缺乏對錯誤來源的透明度（例如缺乏情境脈絡、資料過時或是模型本身推理錯誤），開發者與使用者都無從改善系統，只會削弱持續優化的動機。最後，在複雜流程下，即便模型有 90％ 的準確率，也會因為誤差累積，導致三次任務中有兩次出錯，這幾乎註定了無法實際投入關鍵應用。

然而，作者強調 AI 並不需要達到百分之百正確才有用，真正需要的是能「誠實表達不確定性」並持續改進的系統。他提出「準確性飛輪」的概念：AI 必須能在原生層級表達自己的信心程度與不確定來源；使用者則能在缺口處提供修正與提示；而模型再將這些修正吸收，進一步提升規劃與知識領域的準確度。如此一來，就能建立一個閉環，讓 AI 逐步穩定成為可長期落地的工具。作者也建議企業在投資 AI 前檢查兩點：系統是否能明確指出自己不確定與原因；以及是否會從修正中學習，避免往後重蹈覆轍。文章最後提出具體方案：例如將 AI 的輸出轉化為該領域專屬 DSL（領域特定語言）的計畫，再編譯成可驗證的決策與操作；同時不斷讓模型專精於組織的專有語義與資料流，才能提供更穩健的計劃與信心判斷。

在 Hacker News 的討論中，許多評論者提出不同觀點。有些人認為，將 LLM（大型語言模型）批評為「自信卻錯誤」其實低估了更根本性的問題：LLM 並非具備世界模型或真正的智能，而只是高度進化的統計自動補完工具。這樣的系統自然無法像人類般評估自己所知範圍，更難確切表達信心與不確定性。也有人強調，人類專家同樣容易出錯與偏頗，只是錯誤形式不同；因而要求 LLM 永遠正確並不合理，但至少應能在需要時回答「我不知道」。另一派則指出，AI 往往會「過度順從修正」，導致它學會用更圓滑但仍錯誤的方式回答，這反而讓使用者更容易接受潛藏的謬誤。這種「表面糾正」的現象，讓許多人覺得所謂「快速修正」未必可靠。

另一些討論圍繞在可能的解決方法，像是透過引入不確定性標記、讓模型自我審核，或用另一個 AI 來評估答案。例如有開發者分享 Anthropic 嘗試透過「自知名詞辨識」管道，讓模型在不確定時回答「不知道」，提升抗幻覺（hallucination）的效果。不過這些能力往往脆弱，容易在訓練過程被破壞。也有人建議，實務上 AI 在產生程式碼等可驗證領域確實比較可靠，因使用者能快速執行並檢驗；但在難以驗證的文字或決策任務中，驗證成本一旦高過自行完成的成本，AI 的價值便會急速下降。

綜合來看，這篇文章雖將「自信卻錯誤」視為核心瓶頸，但 Hacker News 上的回應更凸顯這只是整個問題群的其中一環——它揭示了 LLM 缺乏世界模型、自我校正與增量學習能力的限制。若不能建立可解釋的不確定性與具體改進機制，AI 仍將止步於試點專案，無法大規模落地。這也意味著，未來的突破或許不只是演算法最佳化，而必須在模型架構與學習方式上出現新的躍進。

英國媒體監管機構 Ofcom 因認為 4chan 未遵守《線上安全法》(Online Safety Act) 的規定，打算對該網站處以 20,000 英鎊的罰款，並加上每日持續罰金。然而，4chan 的美國律師事務所 Byrne & Storm 強調該平台是一間在美國註冊的公司，英國的執法通知在美國沒有法律效力，因此拒絕支付任何罰款。律師 Preston Byrne 更批評 Ofcom 的行動是一場「違法的騷擾運動」，意圖對美國科技公司施加言論審查，這與美國憲法第一修正案保障的言論自由相衝突。

在此過程中，4chan 所屬律師團隊還呼籲川普政府動用一切外交及法律手段，保護美國企業不受「域外審查」影響。英國方面則表示，《線上安全法》的要求僅針對在英國境內的使用者。但若 4chan 持續無視規範，Ofcom 除了處罰金外，還可能要求英國法院下令搜尋引擎刪除結果、阻斷支付功能，甚至要求網際網路服務供應商 (ISP) 直接封鎖英國使用者的存取。這凸顯了英美在網路治理與言論自由價值觀上的顯著落差。

Hacker News 討論中，許多人認為英國對 4chan 的罰款在實際執行上毫無約束力，因為該公司在英國沒有資產，與當年「波士頓茶葉事件」反抗英國稅制的局面相比，多少有相似歷史諷刺意味。一些評論強調，線上平台面臨越來越多國家不同法律框架時，長遠下來勢必導致全球網路的碎片化，最後可能演變成各國各自的「國內網路」，違背了網際網路最初的開放性精神。

部分技術取向的評論則指出，縱使 Ofcom 強制封鎖，虛擬私人網路 (VPN) 或洋蔥路由 (Tor/Onion networks) 等工具仍能繞過限制。不過，也有人提醒，政府即便明知技術封鎖不可能徹底阻擋，仍會製造所謂寒蟬效應，使非技術熟練的使用者放棄使用，進而達到行政效果。有觀點甚至警告，若未來 VPN 也遭全面禁止，政府將進一步取得控制與追責的藉口。

另一些聲音則懷疑 4chan 是否真的是基於意識形態出於對言論自由的捍衛而拒絕合作，還是單純因為該網站長期缺乏營運維護，無意也無力去改造平台以符合法規。有人提到 4chan 早前因使用過時技術堆疊而被駭客入侵，顯示管理層對基本維護都缺乏投入，自然更不可能實作年齡驗證或內容監控機制。總體而言，討論呈現出對英國管制過度與成效有限的強烈批評，同時也透露網際網路自由與國家安全、監管力道不斷拉鋸的全球趨勢。

Thunderbird 團隊在今年 4 月宣布推出「Thunderbird Pro」，這是一組全新的訂閱型服務，旨在擴充現有應用程式功能，讓使用者能在不依賴第三方平台的情況下提升工作效率。核心服務包括 Thundermail 郵件託管、Appointment 排程工具，以及 Send 檔案分享功能，全部均為開源軟體，且支援自架設置。這些功能將與目前的桌面版與行動版 Thunderbird 無縫整合，但服務本身完全為選用性質，並不影響現有版本的免費功能。Thunderbird 明確表示，傳統版本將繼續維持免費，並仰賴社群捐款來支持開發和獨立性。

Thundermail 作為 Thunderbird 首次推出的電子郵件托管服務，將支援 IMAP、SMTP 與 JMAP 通訊協定，使其能與 Thunderbird 及其他郵件客戶端相容。使用者可選擇掛載自有網域，或取得官方提供的 @thundermail.com 與 @tb.pro 郵箱地址。初期伺服器部署於德國，未來將拓展至更多國家。Appointment 則從原本的網頁應用轉為高度整合進撰寫視窗，讓會議連結能直接嵌入郵件中，並規劃支援多種會議型態與群組排程。同時，Thunderbird 也積極參與開放標準 VPOLL 的討論，期望解決現有協定對群組排程支援不足的問題。

Thunderbird Send 則基於現有 Filelink 功能，提供端對端加密的大型檔案傳輸，初期訂閱者可取得 500 GB 儲存空間且不設單檔大小上限，藉此擺脫 Google Drive 與 OneDrive 等平台依賴。Send 將以系統附加元件形式推出，使功能更新能更快速推送，不受主要版本釋出的限制。未來，Thunderbird 還考慮引入 Markdown 筆記功能，以及更進階的共同文件或試算表協作用途；另外先前曾預告的 Assist 人工智慧輔助專案仍在研發，強調需先顧及隱私與實際需求後才會正式推出。

在 Hacker News 上，討論多聚焦於此舉是否為開源專案提供了可持續的資金來源。許多評論者認為，將高成本功能以訂閱形式收費，而非讓捐款人承擔，是合理且健康的模式，也肯定 Thunderbird 沒有犧牲現有免費版本功能。有人指出目前少數郵件服務才兼容 JMAP，而 Thunderbird 的加入有助於推廣該協定；另有人提到 Thundermail 建立在 Stalwart 伺服器軟體之上，顯示與現有開源生態的緊密連結。部分使用者則表達對 Thunderbird 傳統桌面版是否會逐漸被 Pro 版本取代的擔憂，不過官方已明確表示這兩者將並行不悖。

另外，一些開發與產品相關的觀點也出現在討論中。有人提到 Thunderbird 過去曾承諾進行深度重構與介面重設，但實際推出的結果與設計藍圖仍有落差，令人感到保留。也有使用者談到對 Thunderbird Send 的興趣，但關心如何防堵垃圾郵件與惡意檔案濫用，認為付費模式或可減少類似風險。另一方面，針對新郵件網域名稱 @thundermail.com，不少人認為這是一個質感不錯且容易記憶的選擇，有助於品牌建立。

總體來看，Thunderbird Pro 在維持免費核心應用的基礎上，嘗試以附加開源訂閱服務來開拓新收入，既展現出穩健的永續經營思維，也延續了社群導向的透明與開放合作模式。社群對此普遍給予肯定，但仍會持續觀察其在產品落實、隱私保護以及功能穩定性上的成效。

FFmpeg 8.0「Huffman」正式推出，這次被形容為有史以來規模最大的一個版本。除了全面更新基礎設施外，最重要的亮點是引入了全新的 Vulkan 計算型編解碼框架，讓影像運算能直接透過 GPU 通用算力完成，不再依賴特定硬體加速器。這次新增的 Vulkan 編解碼器包含 FFv1（編碼與解碼）與 ProRes RAW（目前僅解碼），未來也將加入 ProRes 與 VC-2 支援。這些特性在非線性影片編輯與無損螢幕錄影／直播場景上，能顯著加快處理速度並降低延遲。同時，FFmpeg 8.0 也加入了多個新格式與濾鏡，例如語音轉錄相關的 Whisper 濾鏡、色彩檢測、CUDA 影像填充等，凸顯它在影音處理領域上持續擴張的能耐。

新版還支援更多硬體加速，包括 Vulkan VP9 解碼、VAAPI VVC、OpenHarmony（華為鴻蒙系統的多媒體框架）下的 H.264/H.265 編解碼，以及 Vulkan AV1 編碼。相較於過去僅依靠 CPU 或少數硬體驅動，這些進展讓跨平台影音處理工作更高效靈活。此外，專案基礎設施也完成了現代化，郵件伺服器更新，並引入了新的開發者平台 code.ffmpeg.org（採用 Forgejo），為日後開發社群的協作建立更穩健的基礎。

在 Hacker News 的討論中，許多人對 Whisper 語音轉文字模型被整合進 FFmpeg 十分興奮，因為這等於可以在轉檔或轉播過程中直接產生字幕，但也有人指出實際即時轉錄效果還取決於硬體效能，例如桌上型 GPU 仍難以完全達到即時水準。不過，對於影音工作者、教育內容製作者甚至成人內容消費者來說，能夠快速自動產生字幕有潛在的巨大價值。此外，社群也提到 FFmpeg 這樣的指令工具往往需要「咒語等級」的參數記憶，愈來愈多人開始透過大型語言模型 (LLM, Large Language Model) 或基於 GUI 的輔助工具，來生成正確的 ffmpeg 指令，使影音處理變得親民。

另一些評論則強調 FFmpeg 幾乎無所不在，不只是 Linux 生態上 VLC 或 Handbrake 等工具的基礎，實際上大部分影音應用程式或串流平台都在背後使用它的核心函式庫 libavcodec。有人甚至認為它已是僅次於 OpenSSL、zlib 與 SQLite 的全球前四大最常用開源函式庫。在技術層面上，社群關注點放在 Vulkan 編解碼的潛力，部分開發者特別對其未來的跨平台支援，以及在非 Windows 環境（如 Asahi Linux on Mac）也能利用 Vulkan 1.3 標準運作感到期待。

總體來看，FFmpeg 8.0 的發表不只是功能更新，更代表了影音處理邁向跨平台 GPU 加速與智慧化處理的新階段。無論是字幕自動生成，或是更快更穩定的高規格影像轉檔，它都鞏固了 FFmpeg 作為全球多媒體基礎設施的地位，而這也讓開源社群對未來版本的拓展充滿期待。

LabPlot 是一款免費的開源跨平台科學繪圖與資料分析軟體，專門為需要進行高品質繪圖、資料整理與基礎分析的使用者而設計。它提供直覺性的互動式工具，讓使用者能快速完成統計分析、回歸、曲線與峰值擬合，並支援 Python、R、Julia 等語言的互動式筆記本環境。除此之外，LabPlot 也內建繪圖數位化功能，可以從圖片中擷取資料，並支援即時資料處理。軟體相容多種常見的資料格式，包括 CSV、Excel、MATLAB、SPSS、JSON、HDF5 等，並可在 Windows、macOS、Linux、FreeBSD 以及 Haiku 上運行。近期版本更新持續帶來效能提升與更多格式支援，且獲得 NLNet 基金會的資助，顯示該專案在自由開源科學工具的生態系中具備長期發展的潛力。

在 Hacker News 的討論中，有人指出 LabPlot 的 GitHub 倉庫其實只是鏡像，主要開發工作在 KDE 的 GitLab 上進行。部分使用者對資料庫支援感到困惑，有人認為它僅能連接 SQLite，對希望直接連接大型資料庫或 REST API 的研究人員來說不太便利；另有使用者則引用官方文件，表示實際上透過 Qt SQL 驅動可支援更多資料庫。這反映出該工具在整合外部資料連線方面可能需要更明確的說明與改善。

另一個焦點是 LabPlot 在科學社群中的定位。有使用過 Origin 或 SciDavis 的人提到，雖然功能不及商業軟體，但 LabPlot 對於只需要 GUI 操作的研究者或不熟悉程式設計的使用者非常合適。對於已經習慣透過 Python、R、Julia 等語言處理資料的使用者，LabPlot 未必能取代現有工具，但它提供了一個跨語言、統一介面的替代方案，有人甚至認為它可能成為 Jupyter Notebook 的替代選擇之一。

此外，也有人關注授權條款。根據官方 FAQ，LabPlot 採用 GNU GPL 2.0 或更新版本授權，允許自由使用、分發、修改，但若發佈修改版本，必須公開相應的原始碼。討論中亦提到圖表繪製工具的歷史演變，從 1980 年代需要專業軟體如 Deltagraph，到現今免費開源方案普及，顯示科學圖表已成為一種「必須也普遍」的工具。另一方面，介面設計也受到批評，有人認為深色背景在大螢幕上閱讀不便，建議增設日夜間模式。

整體來說，LabPlot 被視為自由開源科學軟體生態中的一個重要選項，它雖然無法完全取代如 ggplot、MATLAB 或 Origin 這類高度專業化或程式導向的工具，但在提供跨平台、多格式支援及圖形化操作的便利性上，仍擁有獨特的吸引力。對於不想陷入複雜程式碼的研究人員，以及偏好視覺化操作的教學與研究場景，LabPlot 正逐漸展現其價值。

Waymo，Alphabet 旗下專注自動駕駛技術的公司，正式獲得紐約市運輸局核發的首張測試許可，將於曼哈頓和布魯克林市中心展開自駕車測試。首波計畫將投入最多八輛測試車輛，並持續至九月底，未來不排除延長。依據紐約州法律，目前所有自駕車仍須配備一名駕駛員在前座隨時介入。市長 Eric Adams 在聲明中指出，紐約市一向開放科技創新，這項測試是讓城市邁向二十一世紀交通模式的重要一步。

Waymo 近年積極擴張自駕服務，全美包括奧斯汀、舊金山灣區已經有商轉，費城也即將開始測試，並規劃在亞特蘭大、邁阿密與華盛頓特區落地。該公司執行長曾在五月宣佈，他們的自駕計程車 (robotaxi) 累計已完成一千萬趟旅程。對於紐約市而言，這並非首度嘗試，早在 2021 年 Waymo 曾在部分街道以人工駕駛方式進行資料蒐集。市府則在去年推出安全規範和准入制度，要求業者定期提供測試的資料，並需與警方與緊急服務機構密切合作。

在 Hacker News 的討論中，有人指出曼哈頓下城是紐約市交通最複雜的區域，充斥多層道路、高樓間造成的 GPS 干擾，以及比其他城市更為混亂的駕駛行為，因此是最具挑戰的測試地點。一些人認為 Waymo 的高精地圖和 3D 感測技術能顯著減少對 GPS 的依賴，但也有人質疑冬季暴雪和冰雪路況仍是一大難題。與人類不同的是，Waymo 可能在極端天候直接停駛，雖然理論上這樣更安全，但卻也顯示出技術限制。

另一個爭論點在於紐約市獨特的駕駛文化。當地駕駛往往激進並不完全遵守交通規則，例如雙排違停或闖黃燈才是當地「默契」。有評論擔心自駕車如果完全守法，反而無法順利在流量龐大的街道上行進，甚至可能遭到人類駕駛故意刁難或「霸凌」。有些人則提出，Waymo 在舊金山的實務經驗已顯示，他們並不是死板照本宣科，而是嘗試學習「事實上的交通規則」──例如在安全狀況下略微超速、在路口提前切入，模擬人類駕駛的互動行為。

許多人把討論延伸到社會面向，像是計程車執照（出租車 medallion 制度）如何影響 Waymo 的商業化，以及如果這些車輛大規模投入，會否抵銷紐約市目前透過擁擠費 (congestion pricing) 改善交通的努力。一些人則保持樂觀，認為就算自駕技術尚未完美，只要事故風險低於人類駕駛，就具備推廣價值。更進一步，若自駕車成為普遍存在，人們或許會逐漸習慣守法駕駛行為，進而間接提升整體道路文化。可以預見，這場測試不僅是技術挑戰，更將深刻影響紐約的交通生態與公共政策。

文章以「🤦🏼‍♂️」這個表情符號為例，說明為何在不同程式語言中，字串長度會出現看似矛盾的數字：在 JavaScript 中長度是 7，在 Python 3 中是 5，而在 Rust 中則為 17，但在 Swift 中卻只顯示為 1。原因在於這個表情實際上是由多個 Unicode 標量值 (Unicode scalar values) 組成，包括基本的「摀臉」符號、膚色修飾符、性別符號、零寬連接符 (Zero Width Joiner)，以及變體選擇器，最後才渲染成使用者看到的一個表情。各語言回傳的「長度」其實反映了不同層次：UTF-8 編碼單元數、UTF-16 編碼單元數、Unicode 標量值數量，或是擴展字素叢集 (extended grapheme clusters) 的數量。

作者指出，雖然程式設計師在網路上常拿 JavaScript 的 `.length` 當笑話，但其實這個行為並非「錯誤」，因為不同語言的設計理念不同。像 Swift 強調人類直覺，回傳「1」代表「一個可見單位」；Rust 則強調效能和一致性，回傳 UTF-8 編碼單元數；而 Python 的實作比較混亂，雖然表面上是按 Unicode 標量值計算，但允許出現非正規的代理對 (surrogate pairs)，因此被作者批評為「最糟」。文章進一步探討，每種「長度」在不同場合各有用處：記憶體配置時需要知道編碼單元數，UI 文字處理需要知道字素叢集，通訊協定有時以標量值長度設限，而真要估算顯示寬度，甚至還要考慮字體與 East Asian Width 等條件。

在公平性與國際化方面，文章舉了《世界人權宣言》的多語翻譯進行統計。許多人擔心 UTF-8 對中文、日文、韓文不公平，因為這些文字通常會佔 3 個位元組，但實際上漢字的資訊密度極高，因此同樣內容所需的 UTF-8 長度反而比許多以拉丁字母書寫的語言還短。韓文與日文的結果也顯示，存取長度差異背後更多是語言結構差異，而非編碼方式造成的不公。最後，作者強調「沒有一種量測方式能完美衡量字串長度」，程式語言應根據實際需求提供不同的計算方法，而不是追求單一「正確答案」。

在 Hacker News 討論區，使用者對此產生許多延伸思考。有些人注意到 `.length` 在技術上不同於「人看到的長度」，因此「沒有上下文的長度」其實毫無意義。他們認為應區分用途：若是資料庫或通訊，就需要位元組數；處理文字游標則需字素叢集；顯示則必須依賴字型渲染。而許多人認同 Rust 的做法：以 UTF-8 儲存並回傳位元組數，其他長度則透過迭代器額外計算。有開發者強烈批評 Python 3，認為經過十多年的轉換卻仍處理不佳；對比之下，某些語言如 Raku 提供了明確的 API，例如 `.chars`、`.codes`、`.bytes`，讓開發者清楚指定想要的資訊，避免混淆。

部分討論更聚焦在國際化與字型處理，例如德語「ß」在 Unicode 的大寫轉換問題，或泰文、梵文等文字的複雜組字行為。也有人提到 Wordle 等遊戲案例，說明「五個字母」可能在某些語言下難以界定。此外，有人認為「UTF-8 萬用」本身並非萬靈丹，因為隨 Unicode 更新，字素叢集判定仍可能不一致，導致不同版本環境下出現差異。整體而言，討論反映了社群共識：我們應接受「字串長度」沒有單一定義，而是在具體情境下選擇正確的計算方式，並設計合宜的 API，才是真正解決問題的方法。

美國國務院宣布，川普政府正在針對超過 5500 萬名持有有效美國簽證的外國人進行「持續審查」，以檢查是否存在任何可能導致簽證撤銷及驅逐出境的違規情況。這項審查涵蓋所有簽證，包括旅遊簽證、學生簽證及交換簽證。當局表示，若發現持有人逾期停留、涉及犯罪、威脅公共安全、支持恐怖組織等情事，簽證將立即被撤回，當事人若人在美國境內，將面臨驅逐。根據國土安全部的數據，美國目前約有 1280 萬名綠卡持有人及 360 萬持臨時簽證者，顯示審查對象涵蓋範圍極廣，甚至不乏目前身處境外、持有多次往返簽證的人。

川普政府近來也宣布將停止發放給國際商用卡車司機的工作簽證，理由是過多外籍駕駛危害道路安全並壓低美國卡車司機的生計。國務卿盧比歐（Marco Rubio）強調，這項政策將立即生效，並表示當局會暫停處理相關簽證，以檢視篩選及審查程序是否足夠嚴謹。批評者指出，外籍勞工長期以來彌補了美國卡車司機的短缺，驟然限制恐帶來供應鏈衝擊，並對大學、醫院等高度依賴外籍勞工的機構造成深遠經濟影響。

這次全面審查也與美國政府針對留學生及具有「反以色列」或「親巴勒斯坦」立場者的打擊擴大有關。新規定要求簽證申請人上傳所有社群媒體帳號，且在面談時必須關閉手機或應用程式的隱私保護設定，以便政府徹底檢視過往紀錄。國務院指出，自川普再度上任以來，學生簽證被撤銷的數量大幅增加，其中不少理由涉及酒駕、攻擊及與恐怖組織相關聯的行為。這顯示未來簽證核准與撤銷將不僅止於行政效率問題，而是明顯帶有政治及安全審查色彩。

在 Hacker News 上，許多評論者認為這項舉措的真正目的，在於製造恐懼氛圍，迫使外籍人士噤聲，避免批評美國政府及其對以色列的政策。有使用者指出，川普政府正透過與 Palantir 等監控公司合作，建立清單鎖定被認為親巴勒斯坦或批判以色列的非公民學生與抗議者，目的是讓校園異議者隨時都有被驅逐的風險。另有人質疑，若要真正檢視 5500 萬簽證，單憑官僚系統根本不可能實現，實際更像是一種政治宣示與心理戰，以阻嚇外國人來美就學或就業。

部分留言則擔憂這會造成「寒蟬效應」，不僅外籍學生與專業人士會三思而後行，甚至連歸化公民也可能成為未來下一輪審查對象。一些評論者還分享了親身經驗，例如學生簽證被莫名撤銷，最後靠法律抗爭才得以恢復，說明「錯誤」裁決並不少見。最後，討論中也有人提到 Hacker News 使用者的疑慮：此類政治新聞即便與科技界息息相關，但仍經常被標記為「離題」。然而不少人強調，對於在美國求學或工作的工程師、研究員與新創創業者而言，簽證政策就是直接影響生活與職涯的重要議題，完全值得討論。