Jump to...
redirecting...

Log for Ubuntu 台灣社群

GitHub 似乎數不好東西 (★ 64 分)

文章指出 GitHub 出現兩項明顯的介面計數異常。其一是儲存庫的合併請求(Pull Request, PR)分頁標籤會多算數量:完成合併後尤其常見,標籤顯示有兩筆 PR,實際清單卻只有一筆。其二是組織清單的分頁失效;作者因長年加入許多組織,必須前往第二頁尋找要與 Sentry(應用程式錯誤監控服務)串接的專案,但頁碼列只顯示第一頁、第三頁與下一頁,第二頁完全消失。由於彈出式視窗無法直接修改網址,作者只好在瀏覽器開發者工具以 JavaScript 強制跳轉至目標頁面。

討論者普遍認為,問題很可能源自不同資料來源未同步,例如主要資料庫與 Elasticsearch(分散式搜尋索引引擎)之間出現延遲,或多層快取保存了不一致的結果。有人指出,GitHub 的議題與 PR 清單可能改由搜尋索引供應資料,因此使用者剛完成關閉、合併等操作時,畫面未必立刻反映最新狀態。這類最終一致性(eventual consistency,資料短暫不同步後才逐步一致)的設計在大型服務並不罕見,但評論者認為,至少應避免同一頁面同時呈現互相矛盾的計數與清單。

不少人分享更影響工作的案例:已核准的 PR 仍顯示等待審查,造成案件延誤數週;GitHub Actions(GitHub 的自動化工作流程服務)排程可能晚數小時觸發,甚至完全未執行;API(應用程式介面)查詢進行中的工作流程時,也會在數秒內忽隱忽現。另有使用者表示,多年前的 PR 無法在搜尋結果或分頁清單找到,卻仍可由直接網址開啟。有人因排程不可靠,已改用 AWS(Amazon Web Services)EventBridge Scheduler 與 Lambda 處理觸發工作。

社群對嚴重程度看法不一:較寬容者認為,這是大型組織常見的快取不同步問題,把它稱為「嚴重」或許過頭;批評者則認為,當計數、審查狀態、排程與 API 輸出都無法信賴時,已不只是表面瑕疵,而是可靠性與產品品質問題。也有人把 GitHub 近年的狀況歸咎於 Microsoft 收購後的策略,認為資源過度投注在 Copilot 等 AI 功能,忽略基礎穩定性;不過這項歸因主要屬使用者推測。另有留言指出,未獲儲存庫存取權前就能看到議題數量,可能還涉及資訊揭露風險。

👥 45 則討論、評論 💬
https://news.ycombinator.com/item?id=49730302
NVIDIA 宣布支援以 Rust 原生開發 GPU 程式 (★ 180 分)

NVIDIA 宣布 CUDA Rust,讓開發者能以 Rust 原生撰寫 GPU(圖形處理器)核心函式,直接編譯為 PTX(NVIDIA GPU 使用的中間組譯碼),不再只是由 Rust 呼叫其他語言寫成的核心函式。此計畫分成兩條路線:較低階的 SIMT(單指令多執行緒)模式,讓開發者定義單一執行緒工作並大量啟動;以及較高階的 Tile 模式,以資料區塊為單位描述運算,由編譯器決定實際執行緒與硬體對應方式。NVIDIA 建議優先採用 Tile,只有在需要細緻掌握執行緒、共享記憶體與硬體細節時,才改用 SIMT。

SIMT 路線的 cuda-oxide 是客製化 Rust 編譯後端,可把標註為 GPU 核心函式的 Rust 程式,經由中介表示法與 LLVM 編譯為 PTX。它以 `DisjointSlice` 確保各執行緒只能寫入各自的輸出元素,並用啟動合約驗證區塊大小、索引維度與裝置限制,避免常見的越界與記憶體別名存取問題。不過,cuda-oxide 仍需 Linux、支援 Compute Capability 8.0 以上的 GPU、CUDA 12 以上版本、LLVM 與固定版本的 Rust nightly 工具鏈;共享記憶體等高效能功能目前仍可能需要不安全區塊。

Tile 路線的 cutile-rs 則可在 Rust 1.89 以上穩定版搭配 CUDA 13.3 使用,首次啟動核心函式時以 JIT(即時編譯)方式透過 CUDA Tile IR(Tile 中介表示法)編譯。開發者以張量區塊描述運算,輸出張量必須先分割成互不重疊的區段,藉由 Rust 所有權機制保證每個 Tile 只有唯一寫入者;執行網格大小也由分割方式自然推導,不必手動計算。cutile-rs 已發布為 Rust 套件,並用於 Hugging Face 的 Grout 推論引擎及 mistral.rs;但 NVIDIA 強調兩個專案都仍在早期階段,功能範圍與介面仍會調整,尚不適合正式環境。公司也規劃讓 CUDA Rust 與 CUDA C++、CUDA Python 互通,減少語言選擇造成的綁定。

Hacker News 討論對此抱持期待但審慎的態度。部分 Rust 與 CUDA 使用者認為,兩條路線的記憶體安全保證與建置流程改善值得嘗試,但既有的 cudarc 與標準 CUDA 範例較多、對照也更直接;採用新的 Rust 核心函式方言,可能提高沿用既有經驗與除錯的門檻。批評者則指出,除錯時可能得同時排查 Rust、cuda-oxide、CUDA 與 Tile IR 等多層問題,而且 CUDA 仍是 NVIDIA 專有平台,供應商綁定並未消失;Triton、Mojo、Julia 與 rust-gpu 等工具則被視為替代選項。另一項顯著焦點是原文附帶 AI 產生摘要,許多人質疑技術文件若過度依賴大型語言模型,可能削弱文字可信度與可讀性;也有人反駁,不論 AI 是否協助撰寫,開發者仍應查閱原始文件、範例與實作細節。

👥 62 則討論、評論 💬
https://news.ycombinator.com/item?id=49724881