Log for Ubuntu 台灣社群
各位好，
系統版本：Ubuntu 25.10
顯卡：Intel Arc A380
目前遇到在開機時連續出現
[FAILED] Failed to start gdm.service - GNOME Display Manager
也嘗試使用Ctrl + Alt + F2進入 TTY模式，
但目前是卡在使用者帳號名稱一直顯示錯誤，
有什麼方法可以找回正確的「使用者帳號名稱」？
或者有他方式進行修復？
還是…
乾脆用來Live CD把資料備份出來，
等下週Ubuntu 26.04發布後重裝系統？
感謝各位！
系統版本：Ubuntu 25.10
顯卡：Intel Arc A380
目前遇到在開機時連續出現
[FAILED] Failed to start gdm.service - GNOME Display Manager
也嘗試使用Ctrl + Alt + F2進入 TTY模式，
但目前是卡在使用者帳號名稱一直顯示錯誤，
有什麼方法可以找回正確的「使用者帳號名稱」？
或者有他方式進行修復？
還是…
乾脆用來Live CD把資料備份出來，
等下週Ubuntu 26.04發布後重裝系統？
感謝各位！
聞起來像是作業系統核心升級引入的 regression，可以按住 Shift 鍵開機，出現 GRUB 開機選單後選擇舊版的作業系統核心開機看看還能不能重現問題
還是有啦
開機選單選救援模式 (rescue/recovery mode)，拿到 shell 之後再調閱 gdm 服務的運行紀錄看看服務具體是掛在哪裡
開機選單選救援模式 (rescue/recovery mode)，拿到 shell 之後再調閱 gdm 服務的運行紀錄看看服務具體是掛在哪裡
PiCore：Tiny Core Linux 的 Raspberry Pi 移植版 （★ 100 分）
piCore 是 Tiny Core Linux 在 Raspberry Pi 上的移植版，最初由 Robert Shingledecker 規劃，現在則由小型開發團隊與社群共同維護。它不是傳統的 Linux 發行版，而是一套讓使用者自行組裝客製化系統的工具箱，強調體積小、核心新，適合做嵌入式設備、家電型應用，或當成學習 Linux 的平台。它最核心的概念是整個系統都在 RAM（隨機存取記憶體）中執行，開機完成後幾乎不再使用開機媒體，也沒有一般意義上的安裝流程。預設的 Cloud Mode（雲端模式）會透過網際網路從套件庫下載延伸套件，檔案系統放在 RAM 中，套件以唯讀方式掛載，因此重新開機後不會自動保留變更，每次都會回到乾淨一致的狀態。
如果需要保留下載的套件與個人變更，piCore 也提供 Mounted Mode（掛載模式），必須在 SD 卡上另外建立一個 ext4（Linux 常見檔案系統）分割區，讓系統把延伸套件與備份放進持久儲存空間，並可手動或用指令稿決定哪些檔案要備份、哪些內容在下次開機時自動還原。安裝方式是把壓縮檔內的原始 SD 卡映像檔寫入 SD 卡後直接開機；第一個分割區是 VFAT（FAT 相容檔案系統），存放開機載入器、韌體與基礎系統，開機後不再掛載，也不會再寫入。若使用預先附帶 SSH（Secure Shell，安全遠端登入協定）或 X 視窗環境的映像檔，第二個 ext4 分割區已先建立，但可能還需要用 fdisk 重新切分，再以 resize2fs 擴充檔案系統容量。系統預設也會在 RAM 內建立 zlib 壓縮的 swap（交換空間），若工作負載較重，建議另設 swap 分割區以取得較佳效能；預設帳號是 tc，終端機會自動登入，SSH 版本另有密碼，但禁止直接以 root 登入。官方同時建議使用者查閱論壇與《Into the Core》手冊，雖然該書以 x86 版本為主，但共通概念也適用於 piCore。
延伸到實際使用經驗，討論區裡不少人把 piCore 視為一種很聰明的 immutable Linux（不可變式 Linux，盡量讓基底系統維持唯讀）的實作，特別點名它是 piCorePlayer 的基礎，而 piCorePlayer 常被拿來把 Raspberry Pi 變成 Squeezebox 播放端或 Lyrion 音樂伺服器。也有人提到自己多年來一直很喜歡 Tiny Core Linux，看到這篇又想把收在箱子裡的舊 Pi 拿出來重玩，顯示這類極小型、可快速重置的系統，在家用音樂、輕量裝置與實驗場景仍然很有吸引力。同時也有人提醒，這份 README 是 5.x 時代的舊版說明文件，現在公開版本已到 16.0，甚至已有 17.0 預覽版，所以某些細節可能過時，但整體設計理念依然大致適用。
討論中也出現較技術性的分歧。有人認為 Tiny Core 這種設計品味，原本值得比 ostree（以版本化、唯讀部署為核心的 Linux 系統更新機制）得到更多關注；也有人反駁說，Tiny Core 為了在 Linux 上實現不可變系統，採用了不少令人頭痛的折衷做法，因為許多 Linux 軟體預設都假設某些路徑必須可寫。另有使用者從維運角度發想，認為若能把 piCore 當成臨時救援系統開機，再用 dd（區塊層級複製工具）配合 nc（netcat，網路資料串流工具）把整台機器做遠端完整備份，對無頭式 Raspberry Pi 會很實用，甚至可結合 Raspberry Pi 新近加入的 A/B try-boot 機制，做成近似線上復原環境；不過也有人指出，這類工作其實在 initramfs（Linux 開機初期的暫存根檔案系統）階段就已能做到。整體而言，社群對 piCore 的評價偏正面，既欣賞它的小巧、可控與用途明確，也清楚它在現代 Linux 生態中必須面對的維護與設計取捨。
👥 12 則討論、評論 💬
https://news.ycombinator.com/item?id=47784244
piCore 是 Tiny Core Linux 在 Raspberry Pi 上的移植版，最初由 Robert Shingledecker 規劃，現在則由小型開發團隊與社群共同維護。它不是傳統的 Linux 發行版，而是一套讓使用者自行組裝客製化系統的工具箱，強調體積小、核心新，適合做嵌入式設備、家電型應用，或當成學習 Linux 的平台。它最核心的概念是整個系統都在 RAM（隨機存取記憶體）中執行，開機完成後幾乎不再使用開機媒體，也沒有一般意義上的安裝流程。預設的 Cloud Mode（雲端模式）會透過網際網路從套件庫下載延伸套件，檔案系統放在 RAM 中，套件以唯讀方式掛載，因此重新開機後不會自動保留變更，每次都會回到乾淨一致的狀態。
如果需要保留下載的套件與個人變更，piCore 也提供 Mounted Mode（掛載模式），必須在 SD 卡上另外建立一個 ext4（Linux 常見檔案系統）分割區，讓系統把延伸套件與備份放進持久儲存空間，並可手動或用指令稿決定哪些檔案要備份、哪些內容在下次開機時自動還原。安裝方式是把壓縮檔內的原始 SD 卡映像檔寫入 SD 卡後直接開機；第一個分割區是 VFAT（FAT 相容檔案系統），存放開機載入器、韌體與基礎系統，開機後不再掛載，也不會再寫入。若使用預先附帶 SSH（Secure Shell，安全遠端登入協定）或 X 視窗環境的映像檔，第二個 ext4 分割區已先建立，但可能還需要用 fdisk 重新切分，再以 resize2fs 擴充檔案系統容量。系統預設也會在 RAM 內建立 zlib 壓縮的 swap（交換空間），若工作負載較重，建議另設 swap 分割區以取得較佳效能；預設帳號是 tc，終端機會自動登入，SSH 版本另有密碼，但禁止直接以 root 登入。官方同時建議使用者查閱論壇與《Into the Core》手冊，雖然該書以 x86 版本為主，但共通概念也適用於 piCore。
延伸到實際使用經驗，討論區裡不少人把 piCore 視為一種很聰明的 immutable Linux（不可變式 Linux，盡量讓基底系統維持唯讀）的實作，特別點名它是 piCorePlayer 的基礎，而 piCorePlayer 常被拿來把 Raspberry Pi 變成 Squeezebox 播放端或 Lyrion 音樂伺服器。也有人提到自己多年來一直很喜歡 Tiny Core Linux，看到這篇又想把收在箱子裡的舊 Pi 拿出來重玩，顯示這類極小型、可快速重置的系統，在家用音樂、輕量裝置與實驗場景仍然很有吸引力。同時也有人提醒，這份 README 是 5.x 時代的舊版說明文件，現在公開版本已到 16.0，甚至已有 17.0 預覽版，所以某些細節可能過時，但整體設計理念依然大致適用。
討論中也出現較技術性的分歧。有人認為 Tiny Core 這種設計品味，原本值得比 ostree（以版本化、唯讀部署為核心的 Linux 系統更新機制）得到更多關注；也有人反駁說，Tiny Core 為了在 Linux 上實現不可變系統，採用了不少令人頭痛的折衷做法，因為許多 Linux 軟體預設都假設某些路徑必須可寫。另有使用者從維運角度發想，認為若能把 piCore 當成臨時救援系統開機，再用 dd（區塊層級複製工具）配合 nc（netcat，網路資料串流工具）把整台機器做遠端完整備份，對無頭式 Raspberry Pi 會很實用，甚至可結合 Raspberry Pi 新近加入的 A/B try-boot 機制，做成近似線上復原環境；不過也有人指出，這類工作其實在 initramfs（Linux 開機初期的暫存根檔案系統）階段就已能做到。整體而言，社群對 piCore 的評價偏正面，既欣賞它的小巧、可控與用途明確，也清楚它在現代 Linux 生態中必須面對的維護與設計取捨。
👥 12 則討論、評論 💬
https://news.ycombinator.com/item?id=47784244
SDL 全面拒收由 AI 撰寫的程式碼提交 （★ 39 分）
跨平台多媒體函式庫 SDL（Simple DirectMedia Layer）在 GitHub 上的這則議題，起因於有貢獻者發現部分審查過程出現人工智慧（AI, Artificial Intelligence）工具 Copilot（GitHub 的程式撰寫助手）痕跡，因此要求專案建立大型語言模型（LLM, Large Language Model）使用政策，甚至全面禁止這類工具。維護者 icculus 回應，專案原本沒有正式規定，也坦言最近幾天的部分貢獻很可能已由 AI 協助撰寫，甚至完全交給 AI 而未揭露。他個人最傾向的做法，是只要 PR（Pull Request，合併請求）含有 AI 產生的程式碼就直接關閉，但也先提出較溫和版本，包括要求揭露 AI 使用情況、維護者承諾不在 SDL 程式碼中使用 AI、所有 PR 一律由真人審查，以及每 3 個月重新檢視政策。
討論很快轉向更嚴格路線。多名參與者主張，與其要求揭露，不如直接拒收 AI 程式碼與 AI 審查；理由不只包含程式品質與維護負擔，也包含倫理、環境衝擊，以及所謂的「授權漂白」風險，也就是模型輸出來源不明，可能把不相容授權的內容洗成看似可用的新程式碼。核心維護者 slouken 最後明言，既然 AI 產生程式碼的來源無法確認，就不能在 SDL 採用的 zlib 授權（寬鬆開源授權）下接收。最終，SDL 透過另一個合併請求把「全面拒收 AI 貢獻」寫進 PR 範本與 AGENTS.md，這是供 AI 代理工具讀取的指示文件，議題也隨之結案，之後還回補到其他 SDL 分支與相關函式庫。
後續測試則顯示，光把規則寫進 AGENTS.md 不一定可靠。icculus 嘗試要求 ChatGPT 產生會破壞 SDL3 的 PR，發現它既不會讀取 AGENTS.md，也未必會看最新版本的 Git 儲存庫；其他人測試 Claude（Anthropic 的聊天式 AI）時，結果也不一致，有人說必須額外加入 CLAUDE.md，或明確要求檢查系統提示，工具才會遵守規範。這意味著 SDL 此次新政策雖然已定案，但在實務上仍需仰賴人工把關，而不是期待 AI 工具會自動守規矩。
這件事在 Hacker News 引發的主要分歧，不是 SDL 有沒有權利訂規則，而是全面禁止 AI 是否比加強審查更實際。贊成 SDL 的人認為，開源專案的審查能量本來就有限，若沒有清楚政策，維護者很容易被 AI slop（低品質 AI 內容）PR 淹沒；明文禁令至少能讓善意貢獻者先知道界線，也讓審查者有依據拒絕來路不明的程式碼。也有人把這視為 Hacker News 與遊戲開發圈態度差異的縮影：前者常把 AI 當成不可逆趨勢，後者則更重視手藝、品質與長期維護。對不少留言者來說，像 SDL 這種跨平台底層函式庫的價值不會因 AI 出現而消失，反而越是自動化開發，越需要穩定、長期維護的基礎元件。
質疑者則認為，若程式碼本身可讀、可維護，且經過人類仔細審查，工具來源未必該成為唯一判準；真正的難題可能是現行審查制度已經無法處理廉價且大量的程式碼供給，因此未來需要更嚴格的信任機制，而不只是禁令。也有人批評 SDL 維護者拿 ChatGPT 沒讀 AGENTS.md 當例子，說服力偏弱，因為那比較像工具整合失靈，不足以單獨作為整體政策的理由。不過在授權議題上，多數留言仍偏向 SDL 一側：拿 Stack Overflow（程式問答網站）程式片段來類比的人，遭到其他人反駁，因為那類片段通常較短、較通用，或可追溯授權來源，和大規模吸納未知來源內容的 LLM 輸出不同。另有一批人把矛頭指向 GitHub 與 Copilot 生態，甚至主張改用 Codeberg（歐洲非營利原始碼託管平台）等服務，以降低平台本身鼓勵 AI 貢獻的誘因，但也有人回應，只要平台夠熱門，AI 機器人終究都會湧入。
👥 51 則討論、評論 💬
https://news.ycombinator.com/item?id=47790791
跨平台多媒體函式庫 SDL（Simple DirectMedia Layer）在 GitHub 上的這則議題，起因於有貢獻者發現部分審查過程出現人工智慧（AI, Artificial Intelligence）工具 Copilot（GitHub 的程式撰寫助手）痕跡，因此要求專案建立大型語言模型（LLM, Large Language Model）使用政策，甚至全面禁止這類工具。維護者 icculus 回應，專案原本沒有正式規定，也坦言最近幾天的部分貢獻很可能已由 AI 協助撰寫，甚至完全交給 AI 而未揭露。他個人最傾向的做法，是只要 PR（Pull Request，合併請求）含有 AI 產生的程式碼就直接關閉，但也先提出較溫和版本，包括要求揭露 AI 使用情況、維護者承諾不在 SDL 程式碼中使用 AI、所有 PR 一律由真人審查，以及每 3 個月重新檢視政策。
討論很快轉向更嚴格路線。多名參與者主張，與其要求揭露，不如直接拒收 AI 程式碼與 AI 審查；理由不只包含程式品質與維護負擔，也包含倫理、環境衝擊，以及所謂的「授權漂白」風險，也就是模型輸出來源不明，可能把不相容授權的內容洗成看似可用的新程式碼。核心維護者 slouken 最後明言，既然 AI 產生程式碼的來源無法確認，就不能在 SDL 採用的 zlib 授權（寬鬆開源授權）下接收。最終，SDL 透過另一個合併請求把「全面拒收 AI 貢獻」寫進 PR 範本與 AGENTS.md，這是供 AI 代理工具讀取的指示文件，議題也隨之結案，之後還回補到其他 SDL 分支與相關函式庫。
後續測試則顯示，光把規則寫進 AGENTS.md 不一定可靠。icculus 嘗試要求 ChatGPT 產生會破壞 SDL3 的 PR，發現它既不會讀取 AGENTS.md，也未必會看最新版本的 Git 儲存庫；其他人測試 Claude（Anthropic 的聊天式 AI）時，結果也不一致，有人說必須額外加入 CLAUDE.md，或明確要求檢查系統提示，工具才會遵守規範。這意味著 SDL 此次新政策雖然已定案，但在實務上仍需仰賴人工把關，而不是期待 AI 工具會自動守規矩。
這件事在 Hacker News 引發的主要分歧，不是 SDL 有沒有權利訂規則，而是全面禁止 AI 是否比加強審查更實際。贊成 SDL 的人認為，開源專案的審查能量本來就有限，若沒有清楚政策，維護者很容易被 AI slop（低品質 AI 內容）PR 淹沒；明文禁令至少能讓善意貢獻者先知道界線，也讓審查者有依據拒絕來路不明的程式碼。也有人把這視為 Hacker News 與遊戲開發圈態度差異的縮影：前者常把 AI 當成不可逆趨勢，後者則更重視手藝、品質與長期維護。對不少留言者來說，像 SDL 這種跨平台底層函式庫的價值不會因 AI 出現而消失，反而越是自動化開發，越需要穩定、長期維護的基礎元件。
質疑者則認為，若程式碼本身可讀、可維護，且經過人類仔細審查，工具來源未必該成為唯一判準；真正的難題可能是現行審查制度已經無法處理廉價且大量的程式碼供給，因此未來需要更嚴格的信任機制，而不只是禁令。也有人批評 SDL 維護者拿 ChatGPT 沒讀 AGENTS.md 當例子，說服力偏弱，因為那比較像工具整合失靈，不足以單獨作為整體政策的理由。不過在授權議題上，多數留言仍偏向 SDL 一側：拿 Stack Overflow（程式問答網站）程式片段來類比的人，遭到其他人反駁，因為那類片段通常較短、較通用，或可追溯授權來源，和大規模吸納未知來源內容的 LLM 輸出不同。另有一批人把矛頭指向 GitHub 與 Copilot 生態，甚至主張改用 Codeberg（歐洲非營利原始碼託管平台）等服務，以降低平台本身鼓勵 AI 貢獻的誘因，但也有人回應，只要平台夠熱門，AI 機器人終究都會湧入。
👥 51 則討論、評論 💬
https://news.ycombinator.com/item?id=47790791