Log for Ubuntu 台灣社群
Debian 討論是否允許使用大型語言模型 (LLM)
Debian 專案正在討論如何使用大型語言模型 (LLM)，以及是否允許使用 LLM。其中一項提議是明確禁止使用 LLM，但僅限於 Debian 本身，上游專案以及上游安全性修補程式不在此限。另一項提議則是允許透過人工智慧協助貢獻，但必須確保 AI 產生的程式碼符合 Debian 的各項規範，貢獻者也必須承擔責任並履行揭露義務。開發人員指出，LLM 涉及著作權與授權方面的問題，也無法確保品質與準確性，還會增加社群審查者的負擔。人工智慧公司在訓練大型語言模型時，無視著作權與授權規定擷取資料，傷害了整個自由軟體社群；它們還對無數使用者所依賴的網站發動一波又一波的拒絕服務攻擊，而模型訓練本身也會消耗大量資源。
• https://www.debian.org/vote/2026/vote_002
Debian 專案正在討論如何使用大型語言模型 (LLM)，以及是否允許使用 LLM。其中一項提議是明確禁止使用 LLM，但僅限於 Debian 本身，上游專案以及上游安全性修補程式不在此限。另一項提議則是允許透過人工智慧協助貢獻，但必須確保 AI 產生的程式碼符合 Debian 的各項規範，貢獻者也必須承擔責任並履行揭露義務。開發人員指出，LLM 涉及著作權與授權方面的問題，也無法確保品質與準確性，還會增加社群審查者的負擔。人工智慧公司在訓練大型語言模型時，無視著作權與授權規定擷取資料，傷害了整個自由軟體社群；它們還對無數使用者所依賴的網站發動一波又一波的拒絕服務攻擊，而模型訓練本身也會消耗大量資源。
• https://www.debian.org/vote/2026/vote_002
在一塊 8 美元的微控制器開發板上執行擁有 2,890 萬個參數的大型語言模型（LLM） （★ 103 分）
這個 GitHub 專案展示了一個能在約 8 美元的 ESP32-S3 微控制器（microcontroller）上執行的 28.9 百萬參數大型語言模型（LLM，Large Language Model）。模型完全在晶片本身運作，不需連線至伺服器，並能以每秒約 9.5 個 token（文字片段）的速度，把文字逐字寫到外接的小型顯示器上。模型採 4 位元量化後約 14.9MB；相較於過去在同類晶片上執行的 26 萬參數模型，規模約大了一百倍。
關鍵做法是把模型中約 2,500 萬個參數放進快閃記憶體（flash）的查詢表，而不是全部塞進 ESP32-S3 僅 512KB 的 SRAM。每次處理一個 token 時，只需從快閃記憶體取出約 6 列、約 450 位元組的資料，真正需要頻繁運算的部分則留在快速的 SRAM，輸出層與工作記憶體放在 8MB 的 PSRAM。這套 Per-Layer Embeddings（逐層嵌入）概念源自 Google 的 Gemma 3n 與 Gemma 4，專案則將它改用於微控制器的記憶體配置；整體硬體另有 16MB 快閃記憶體。
模型以 TinyStories 訓練，因此只能寫出簡短、簡單且大致連貫的故事，不能回答問題、遵循指令、撰寫程式或掌握事實。專案作者強調，這項成果的重點不在模型能力，而在於如何把較大的模型安置到極小的硬體上。儲存庫也提供韌體、接線、燒錄步驟，以及訓練、消融實驗與量化程式；作者並保留修正參數計算錯誤的提交歷史，讓讀者能追蹤數字如何更正。
Hacker News（HN，科技新聞討論網站）的留言多半對每秒約 9.7 個 token 的速度感到驚喜，並認為這種架構可能延伸至約 2,000 萬至 3,000 萬參數的文字轉語音（TTS，Text-to-Speech）模型，讓完全離線的 ESP32 裝置接近即時朗讀；這仍屬留言者提出的可能應用，並非本專案已展示的功能。也有人提出，若把不同模型層分配給多枚微控制器，再以專用線路和 PIO（可程式化輸入／輸出）互連，或許能探索更大的模型，但低速記憶體的頻寬會成為主要瓶頸；在更強的硬體上，快閃記憶體與 SRAM 的速度差距及運算需求通常更大，未必能直接放大這套方法。
討論也延伸到硬體價格：留言者指出，約 8 美元通常是包含 PSRAM、快閃記憶體與兩個 USB-C 連接埠的開發板價格，不等同於單買晶片；另一派則比較了約 1 美元的 RP2350，以及能以約數美元提供 Linux、最高 256MB 記憶體和 1 TOPS INT8 張量處理器的 Milk-V Duo。整體意見認為，這類裝置未必適合一般人工智慧應用，但它證明了在成本極低、完全離線的硬體上執行語言模型，已從概念展示逐漸變成可實驗的工程方向。
👥 22 則討論、評論 💬
https://news.ycombinator.com/item?id=49050512
這個 GitHub 專案展示了一個能在約 8 美元的 ESP32-S3 微控制器（microcontroller）上執行的 28.9 百萬參數大型語言模型（LLM，Large Language Model）。模型完全在晶片本身運作，不需連線至伺服器，並能以每秒約 9.5 個 token（文字片段）的速度，把文字逐字寫到外接的小型顯示器上。模型採 4 位元量化後約 14.9MB；相較於過去在同類晶片上執行的 26 萬參數模型，規模約大了一百倍。
關鍵做法是把模型中約 2,500 萬個參數放進快閃記憶體（flash）的查詢表，而不是全部塞進 ESP32-S3 僅 512KB 的 SRAM。每次處理一個 token 時，只需從快閃記憶體取出約 6 列、約 450 位元組的資料，真正需要頻繁運算的部分則留在快速的 SRAM，輸出層與工作記憶體放在 8MB 的 PSRAM。這套 Per-Layer Embeddings（逐層嵌入）概念源自 Google 的 Gemma 3n 與 Gemma 4，專案則將它改用於微控制器的記憶體配置；整體硬體另有 16MB 快閃記憶體。
模型以 TinyStories 訓練，因此只能寫出簡短、簡單且大致連貫的故事，不能回答問題、遵循指令、撰寫程式或掌握事實。專案作者強調，這項成果的重點不在模型能力，而在於如何把較大的模型安置到極小的硬體上。儲存庫也提供韌體、接線、燒錄步驟，以及訓練、消融實驗與量化程式；作者並保留修正參數計算錯誤的提交歷史，讓讀者能追蹤數字如何更正。
Hacker News（HN，科技新聞討論網站）的留言多半對每秒約 9.7 個 token 的速度感到驚喜，並認為這種架構可能延伸至約 2,000 萬至 3,000 萬參數的文字轉語音（TTS，Text-to-Speech）模型，讓完全離線的 ESP32 裝置接近即時朗讀；這仍屬留言者提出的可能應用，並非本專案已展示的功能。也有人提出，若把不同模型層分配給多枚微控制器，再以專用線路和 PIO（可程式化輸入／輸出）互連，或許能探索更大的模型，但低速記憶體的頻寬會成為主要瓶頸；在更強的硬體上，快閃記憶體與 SRAM 的速度差距及運算需求通常更大，未必能直接放大這套方法。
討論也延伸到硬體價格：留言者指出，約 8 美元通常是包含 PSRAM、快閃記憶體與兩個 USB-C 連接埠的開發板價格，不等同於單買晶片；另一派則比較了約 1 美元的 RP2350，以及能以約數美元提供 Linux、最高 256MB 記憶體和 1 TOPS INT8 張量處理器的 Milk-V Duo。整體意見認為，這類裝置未必適合一般人工智慧應用，但它證明了在成本極低、完全離線的硬體上執行語言模型，已從概念展示逐漸變成可實驗的工程方向。
👥 22 則討論、評論 💬
https://news.ycombinator.com/item?id=49050512
Cloudflare 為客戶推出新的 AI 流量管理選項 （★ 100 分）
Cloudflare 宣布為所有客戶新增 AI 流量管理選項，不再只以「是否為 AI」區分爬蟲，而是依照實際用途分成 Search（搜尋索引）、Agent（代表使用者即時執行工作的代理程式）與 Training（用於訓練或微調模型）三類。Search 會建立網站資料庫，理應帶來導流或其他合理回報；Agent 通常是替人完成即時任務；Training 則會把內容長期吸收到 AI 模型中。Cloudflare 也鼓勵業者將同時具備多種用途的爬蟲拆分，以便網站管理者了解對方行為並分別授權。
自 2026 年 9 月 15 日起，新加入 Cloudflare 的網域，在顯示廣告的頁面上將預設封鎖 Training 與 Agent，Search 則預設允許。若爬蟲同時用於 Search 和 Training，規則會採用所有用途中的最嚴格限制，因此 Googlebot、Applebot 與 BingBot 等多用途爬蟲，可能在網站管理者封鎖 Training 時一併遭到封鎖；現有客戶可在期限前選擇不採用這項預設變更。企業方案另提供 BotBase，這是一個可搜尋的已知機器人與代理程式資料庫，讓管理者依分類或個別爬蟲建立安全性規則。
Cloudflare 同時提出內容使用程度的三層設定：`immediate` 代表只能互動、不得儲存或重用；`reference` 代表可建立索引、摘錄並連回原站；`full` 則允許摘要與完整重製。這些偏好可透過 robots.txt（網站根目錄中供自動化爬蟲讀取的規則檔）裡新增的 `use` 欄位表達，但本身仍不是強制封鎖機制。Cloudflare 也會追蹤爬蟲是否遵守承諾，濫用 Content Signals 的機器人可能失去 Verified（已驗證）資格；此外，公司正測試以 `Forwarded` 標頭傳遞代理程式背後的實際操作者，建立可延伸但也可能排除匿名使用者的「傳遞式信任」。
Hacker News 上的討論對這套方案抱持複雜態度。許多人認為它本質上仍接近君子協定：robots.txt、內容訊號與爬蟲自我分類都缺乏外部強制力，網站也很難技術性地區分「允許閱讀與搜尋索引」和「禁止訓練」。不少人更在意 Cloudflare 先前宣傳的按次付費爬取計畫，指出申請後長期沒有回音，認為真正有價值的是讓 AI 爬蟲直接付費，而不是再增加管理選項。
Googlebot 是另一項爭議焦點。討論者指出，真正的 Googlebot 通常相對克制，但偽造 User-Agent（使用者代理程式）十分普遍；也有人分享 Google 爬蟲造成網站負載過高，卻因網站需要搜尋曝光而難以完全封鎖的經驗。部分留言認為 Google 將搜尋與 Gemini 訓練共用爬蟲，等於迫使網站在曝光和內容保護之間二選一；也有意見認為 Cloudflare 同時提供建立 AI 代理程式的基礎設施、又替網站封鎖代理程式，可能讓自身平台獲得不對等優勢。
支持者則認為 Cloudflare 並非「兩面下注」，而是在全面開放與全面封鎖之間提供依用途、內容使用方式與信任程度調整的中間路線。批評者擔心 Cloudflare 替超過兩成網站設定預設規則，實際上會影響整體網路流量，卻未經網際網路工程任務組（IETF）等多方共同制定；另有人提醒 CAPTCHA、瀏覽器指紋與 Anubis 等工作量證明（Proof of Work，要求客戶端先消耗計算資源）的防爬措施，可能誤傷使用隱私工具的真人，且未必能長期阻擋具備大量資源的自動化爬蟲。
👥 72 則討論、評論 💬
https://news.ycombinator.com/item?id=49052564
Cloudflare 宣布為所有客戶新增 AI 流量管理選項，不再只以「是否為 AI」區分爬蟲，而是依照實際用途分成 Search（搜尋索引）、Agent（代表使用者即時執行工作的代理程式）與 Training（用於訓練或微調模型）三類。Search 會建立網站資料庫，理應帶來導流或其他合理回報；Agent 通常是替人完成即時任務；Training 則會把內容長期吸收到 AI 模型中。Cloudflare 也鼓勵業者將同時具備多種用途的爬蟲拆分，以便網站管理者了解對方行為並分別授權。
自 2026 年 9 月 15 日起，新加入 Cloudflare 的網域，在顯示廣告的頁面上將預設封鎖 Training 與 Agent，Search 則預設允許。若爬蟲同時用於 Search 和 Training，規則會採用所有用途中的最嚴格限制，因此 Googlebot、Applebot 與 BingBot 等多用途爬蟲，可能在網站管理者封鎖 Training 時一併遭到封鎖；現有客戶可在期限前選擇不採用這項預設變更。企業方案另提供 BotBase，這是一個可搜尋的已知機器人與代理程式資料庫，讓管理者依分類或個別爬蟲建立安全性規則。
Cloudflare 同時提出內容使用程度的三層設定：`immediate` 代表只能互動、不得儲存或重用；`reference` 代表可建立索引、摘錄並連回原站；`full` 則允許摘要與完整重製。這些偏好可透過 robots.txt（網站根目錄中供自動化爬蟲讀取的規則檔）裡新增的 `use` 欄位表達，但本身仍不是強制封鎖機制。Cloudflare 也會追蹤爬蟲是否遵守承諾，濫用 Content Signals 的機器人可能失去 Verified（已驗證）資格；此外，公司正測試以 `Forwarded` 標頭傳遞代理程式背後的實際操作者，建立可延伸但也可能排除匿名使用者的「傳遞式信任」。
Hacker News 上的討論對這套方案抱持複雜態度。許多人認為它本質上仍接近君子協定：robots.txt、內容訊號與爬蟲自我分類都缺乏外部強制力，網站也很難技術性地區分「允許閱讀與搜尋索引」和「禁止訓練」。不少人更在意 Cloudflare 先前宣傳的按次付費爬取計畫，指出申請後長期沒有回音，認為真正有價值的是讓 AI 爬蟲直接付費，而不是再增加管理選項。
Googlebot 是另一項爭議焦點。討論者指出，真正的 Googlebot 通常相對克制，但偽造 User-Agent（使用者代理程式）十分普遍；也有人分享 Google 爬蟲造成網站負載過高，卻因網站需要搜尋曝光而難以完全封鎖的經驗。部分留言認為 Google 將搜尋與 Gemini 訓練共用爬蟲，等於迫使網站在曝光和內容保護之間二選一；也有意見認為 Cloudflare 同時提供建立 AI 代理程式的基礎設施、又替網站封鎖代理程式，可能讓自身平台獲得不對等優勢。
支持者則認為 Cloudflare 並非「兩面下注」，而是在全面開放與全面封鎖之間提供依用途、內容使用方式與信任程度調整的中間路線。批評者擔心 Cloudflare 替超過兩成網站設定預設規則，實際上會影響整體網路流量，卻未經網際網路工程任務組（IETF）等多方共同制定；另有人提醒 CAPTCHA、瀏覽器指紋與 Anubis 等工作量證明（Proof of Work，要求客戶端先消耗計算資源）的防爬措施，可能誤傷使用隱私工具的真人，且未必能長期阻擋具備大量資源的自動化爬蟲。
👥 72 則討論、評論 💬
https://news.ycombinator.com/item?id=49052564
Shell 裡的冒號什麼都不做，但還是用它吧 （★ 108 分）
文章介紹 shell（命令列直譯器）裡看似什麼都不做的 `:`：它是 null command（空指令），會評估參數後丟棄結果。這個指令可追溯至 1971 年的 Thompson shell，早期也曾兼具標籤與 Unix 的註解標記功能。它最實用的搭配方式，是與 parameter expansion（參數展開）結合：`${name:?diagnostic}` 會檢查變數是否未設定或為空，若條件成立，就把診斷訊息寫入標準錯誤輸出，並以非零狀態結束；若變數有值，則展開該值。因此，` : "${1:?missing argument, aborting.}" ` 可以用一行取代檢查必要引數的 `if` 敘述，錯誤訊息也會自動包含變數名稱。
文章還展示了空指令的其他用途，例如用 `: "${DATA_DIR:=/var/data}"` 設定預設值、用 `: > error.log` 將檔案截斷為零長度、在括號與重新導向中測試檔案是否可讀或可寫，以及用 `trap : INT` 提供訊號處理時所需的指令。搭配 `set -u` 時，`:` 也能讓多個變數展開並觸發未設定變數檢查。文章特別說明，參數展開即使沒有空指令仍會發生，但 shell 可能會把展開後的字串當成要執行的指令；空指令的作用，就是評估這些表達式後安全地忽略結果。相較於傳統變數指定寫法，這種方式也能讓變數名稱只出現一次，減少打錯字的機會。
Hacker News 討論普遍認為，使用 `:?` 為必要的環境變數提供清楚錯誤訊息確實實用，但許多人不贊成為了少打幾個字而犧牲可讀性。有人指出，若 `$1` 之後還會在腳本中反覆使用，應先指定給具名變數；也有人批評 `:` 把「檢查條件」與「展開變數」綁在一起，想只做其中一件事時反而必須寫出難懂的技巧。文章作者接受這些回饋，補上具名環境變數的範例，並表示檔案截斷等用法主要是展示空指令的能力，不是鼓勵直接用在正式環境。
討論也指出，`: > file` 在檔案不存在時會建立檔案，而且截斷檔案其實不需要 `:`；原本的可讀性與可寫性範例也沒有充分說明重新導向會在指令執行前處理。至於 `< file`、子 shell 與 `:` 是否多餘，參與者之間出現爭論；作者以 zsh 及 Bash 的 POSIX 相容模式（POSIX 是 Unix 可攜式作業系統介面標準）測試，說明不同 shell 的行為可能不同，空指令還能避免單獨重新導向造成輸出，因此不能一概而論。
更廣泛的意見是，這些技巧適合用來理解 shell 的運作方式，卻不一定適合寫進長篇或多人維護的腳本。許多留言認為，將多行 `if` 壓縮成一行會變成難讀的「符號噪音」，腳本一旦涉及複雜資料結構，就應改用 Python 等較完整的程式語言。關於大型語言模型（LLM, Large Language Model）產生 Bash 腳本的討論也呈現類似看法：模型可以寫出能執行的腳本，卻常過度複雜，仍需要人工閱讀與修正；Bash 更適合短小的命令列工作，而非持續擴大的應用程式。
👥 36 則討論、評論 💬
https://news.ycombinator.com/item?id=49047453
文章介紹 shell（命令列直譯器）裡看似什麼都不做的 `:`：它是 null command（空指令），會評估參數後丟棄結果。這個指令可追溯至 1971 年的 Thompson shell，早期也曾兼具標籤與 Unix 的註解標記功能。它最實用的搭配方式，是與 parameter expansion（參數展開）結合：`${name:?diagnostic}` 會檢查變數是否未設定或為空，若條件成立，就把診斷訊息寫入標準錯誤輸出，並以非零狀態結束；若變數有值，則展開該值。因此，` : "${1:?missing argument, aborting.}" ` 可以用一行取代檢查必要引數的 `if` 敘述，錯誤訊息也會自動包含變數名稱。
文章還展示了空指令的其他用途，例如用 `: "${DATA_DIR:=/var/data}"` 設定預設值、用 `: > error.log` 將檔案截斷為零長度、在括號與重新導向中測試檔案是否可讀或可寫，以及用 `trap : INT` 提供訊號處理時所需的指令。搭配 `set -u` 時，`:` 也能讓多個變數展開並觸發未設定變數檢查。文章特別說明，參數展開即使沒有空指令仍會發生，但 shell 可能會把展開後的字串當成要執行的指令；空指令的作用，就是評估這些表達式後安全地忽略結果。相較於傳統變數指定寫法，這種方式也能讓變數名稱只出現一次，減少打錯字的機會。
Hacker News 討論普遍認為，使用 `:?` 為必要的環境變數提供清楚錯誤訊息確實實用，但許多人不贊成為了少打幾個字而犧牲可讀性。有人指出，若 `$1` 之後還會在腳本中反覆使用，應先指定給具名變數；也有人批評 `:` 把「檢查條件」與「展開變數」綁在一起，想只做其中一件事時反而必須寫出難懂的技巧。文章作者接受這些回饋，補上具名環境變數的範例，並表示檔案截斷等用法主要是展示空指令的能力，不是鼓勵直接用在正式環境。
討論也指出，`: > file` 在檔案不存在時會建立檔案，而且截斷檔案其實不需要 `:`；原本的可讀性與可寫性範例也沒有充分說明重新導向會在指令執行前處理。至於 `< file`、子 shell 與 `:` 是否多餘，參與者之間出現爭論；作者以 zsh 及 Bash 的 POSIX 相容模式（POSIX 是 Unix 可攜式作業系統介面標準）測試，說明不同 shell 的行為可能不同，空指令還能避免單獨重新導向造成輸出，因此不能一概而論。
更廣泛的意見是，這些技巧適合用來理解 shell 的運作方式，卻不一定適合寫進長篇或多人維護的腳本。許多留言認為，將多行 `if` 壓縮成一行會變成難讀的「符號噪音」，腳本一旦涉及複雜資料結構，就應改用 Python 等較完整的程式語言。關於大型語言模型（LLM, Large Language Model）產生 Bash 腳本的討論也呈現類似看法：模型可以寫出能執行的腳本，卻常過度複雜，仍需要人工閱讀與修正；Bash 更適合短小的命令列工作，而非持續擴大的應用程式。
👥 36 則討論、評論 💬
https://news.ycombinator.com/item?id=49047453