Log for Ubuntu 台灣社群
讓 Linux 以極簡裸機方式啟動 （★ 101 分）
這篇文章示範如何讓 Linux 核心只承載一個單一行程，而不是啟動完整作業系統，目標是在不到一秒內從開機走到應用程式。作者先以 C 寫出最小的 init 行程：列印訊息後呼叫 reboot(RB_POWER_OFF) 關機，避免 init 結束後造成 kernel panic（核心恐慌）。文章也整理現代 Linux 的 initrd/initramfs（啟動時解開到 RAM 的初始根檔案系統）流程：開機載入器交給核心與 initrd，核心解包後尋找 /init 或 rdinit 指定的程式；若找不到，才改掛載 root= 指定的根分割區與 devtmpfs，最後若 init 不存在或退出就會 panic。
實作上，作者把 C 程式靜態編譯，讓所有必要函式庫都包含在可執行檔中，再用 cpio 與 gzip 做出只含一個 /init 的 initrd。接著使用 QEMU（常用機器模擬器）與 KVM（Kernel-based Virtual Machine，Linux 核心虛擬化機制）測試，直接指定 vmlinuz 核心與自製 initrd 開機，並把主控台導到 ttyS0 方便觀察輸出。範例紀錄顯示核心約在 0.8 秒左右執行 /init，程式印出訊息後立即關機；後續範例則在 init 中掛載 devtmpfs 到 /dev，讓 QEMU 以 -hda 提供的磁碟映像出現在 /dev/sda，並成功讀取磁碟開頭位元組，證明最小系統仍可做基本裝置存取。
文章也把同一套做法搬到實體硬體：作者用 USB 隨身碟建立 EFI 分割區與 Linux 分割區，格式化後透過 ukify 製作 unified kernel image（把 EFI 載入 stub、Linux 核心與 initrd 合成單一開機映像），放到 /EFI/BOOT/BOOTX64.EFI 讓筆電以 UEFI（Unified Extensible Firmware Interface，統一可延伸韌體介面）開機。最後作者嘗試自製更小的 Linux 核心，從 make tinyconfig 開始，再以 menuconfig 打開必要選項，例如 initramfs gzip 支援、ELF（Executable and Linkable Format，可執行與可連結格式）二進位支援、devtmpfs、TTY、序列埠、常見檔案系統與 UEFI stub。這樣的核心可從一般發行版約 16 MB 縮到 1 至 2 MB，可能縮短啟動時間並降低攻擊面，但代價是缺少功能時往往要等程式真的用到才會發現。
Hacker News 討論中，不少人認為這是很好的底層學習與實驗材料，但也質疑單一行程系統的實用性。支持者指出，嵌入式裝置、SoC（System on a Chip，系統單晶片）、一次只做特定工作的設備、簡化版防火牆或 microVM（微型虛擬機器）隔離環境，都可能受益於快速啟動與較小攻擊面；反對者則提醒，一旦要做真正有用的事，例如網路、磁碟或感測器存取，就得掃描 PCIe（Peripheral Component Interconnect Express，高速週邊元件互連）、初始化控制器、讀分割表與掛載檔案系統，整體延遲未必還能維持在一秒內。此外，普通 PC 從按下電源到交給 Linux 前，UEFI 或 BIOS（Basic Input/Output System，基本輸入輸出系統）本身就可能花上數秒，因此文章展示的是核心與 init 階段極快，不等於整台機器必然一秒可用。
討論也補充了多種延伸方向：可加入 BusyBox（整合常見 Unix 工具的輕量工具集）形成極小 userspace（使用者空間），用 Linux 原始碼樹中的 gen_init_cpio 簡化 initramfs 製作，或採用 Buildroot、suckless 的 sinit、Go 生態的 gokrazy 等工具。也有人建議從 make allnoconfig 或 make localyesconfig 開始調整核心，可能比 tinyconfig 更容易保留目前硬體需要的功能。另一方面，部分留言把這類設計與 unikernel（把應用程式與作業系統能力打包成單一映像）相提並論，提醒正式環境若沒有 strace、iotop 等除錯與觀察工具，維運會變得困難。另有讀者修正文章對 SSD（Solid-State Drive，固態硬碟）年代的回憶，認為真正讓一般人感受到大幅加速的是 2010 年代初期而非 2000 年代初期；但整體而言，討論多肯定這篇文章作為理解 Linux 開機、initramfs、裝置檔案與自製核心的清楚實作導覽。
👥 48 則討論、評論 💬
https://news.ycombinator.com/item?id=48543269
這篇文章示範如何讓 Linux 核心只承載一個單一行程，而不是啟動完整作業系統，目標是在不到一秒內從開機走到應用程式。作者先以 C 寫出最小的 init 行程：列印訊息後呼叫 reboot(RB_POWER_OFF) 關機，避免 init 結束後造成 kernel panic（核心恐慌）。文章也整理現代 Linux 的 initrd/initramfs（啟動時解開到 RAM 的初始根檔案系統）流程：開機載入器交給核心與 initrd，核心解包後尋找 /init 或 rdinit 指定的程式；若找不到，才改掛載 root= 指定的根分割區與 devtmpfs，最後若 init 不存在或退出就會 panic。
實作上，作者把 C 程式靜態編譯，讓所有必要函式庫都包含在可執行檔中，再用 cpio 與 gzip 做出只含一個 /init 的 initrd。接著使用 QEMU（常用機器模擬器）與 KVM（Kernel-based Virtual Machine，Linux 核心虛擬化機制）測試，直接指定 vmlinuz 核心與自製 initrd 開機，並把主控台導到 ttyS0 方便觀察輸出。範例紀錄顯示核心約在 0.8 秒左右執行 /init，程式印出訊息後立即關機；後續範例則在 init 中掛載 devtmpfs 到 /dev，讓 QEMU 以 -hda 提供的磁碟映像出現在 /dev/sda，並成功讀取磁碟開頭位元組，證明最小系統仍可做基本裝置存取。
文章也把同一套做法搬到實體硬體：作者用 USB 隨身碟建立 EFI 分割區與 Linux 分割區，格式化後透過 ukify 製作 unified kernel image（把 EFI 載入 stub、Linux 核心與 initrd 合成單一開機映像），放到 /EFI/BOOT/BOOTX64.EFI 讓筆電以 UEFI（Unified Extensible Firmware Interface，統一可延伸韌體介面）開機。最後作者嘗試自製更小的 Linux 核心，從 make tinyconfig 開始，再以 menuconfig 打開必要選項，例如 initramfs gzip 支援、ELF（Executable and Linkable Format，可執行與可連結格式）二進位支援、devtmpfs、TTY、序列埠、常見檔案系統與 UEFI stub。這樣的核心可從一般發行版約 16 MB 縮到 1 至 2 MB，可能縮短啟動時間並降低攻擊面，但代價是缺少功能時往往要等程式真的用到才會發現。
Hacker News 討論中，不少人認為這是很好的底層學習與實驗材料，但也質疑單一行程系統的實用性。支持者指出，嵌入式裝置、SoC（System on a Chip，系統單晶片）、一次只做特定工作的設備、簡化版防火牆或 microVM（微型虛擬機器）隔離環境，都可能受益於快速啟動與較小攻擊面；反對者則提醒，一旦要做真正有用的事，例如網路、磁碟或感測器存取，就得掃描 PCIe（Peripheral Component Interconnect Express，高速週邊元件互連）、初始化控制器、讀分割表與掛載檔案系統，整體延遲未必還能維持在一秒內。此外，普通 PC 從按下電源到交給 Linux 前，UEFI 或 BIOS（Basic Input/Output System，基本輸入輸出系統）本身就可能花上數秒，因此文章展示的是核心與 init 階段極快，不等於整台機器必然一秒可用。
討論也補充了多種延伸方向：可加入 BusyBox（整合常見 Unix 工具的輕量工具集）形成極小 userspace（使用者空間），用 Linux 原始碼樹中的 gen_init_cpio 簡化 initramfs 製作，或採用 Buildroot、suckless 的 sinit、Go 生態的 gokrazy 等工具。也有人建議從 make allnoconfig 或 make localyesconfig 開始調整核心，可能比 tinyconfig 更容易保留目前硬體需要的功能。另一方面，部分留言把這類設計與 unikernel（把應用程式與作業系統能力打包成單一映像）相提並論，提醒正式環境若沒有 strace、iotop 等除錯與觀察工具，維運會變得困難。另有讀者修正文章對 SSD（Solid-State Drive，固態硬碟）年代的回憶，認為真正讓一般人感受到大幅加速的是 2010 年代初期而非 2000 年代初期；但整體而言，討論多肯定這篇文章作為理解 Linux 開機、initramfs、裝置檔案與自製核心的清楚實作導覽。
👥 48 則討論、評論 💬
https://news.ycombinator.com/item?id=48543269
GitHub 面臨 AI 造成的運算容量吃緊，微軟轉向 AWS 求援 （★ 106 分）
這篇報導聚焦 Microsoft 在 GitHub 面臨 AI（人工智慧）帶來的運算容量壓力時，轉向 AWS（Amazon Web Services，Amazon 的雲端運算平台）尋求協助。討論中引用的關鍵數字指出，GitHub 的 commit（程式碼提交）量預估在 2026 年可能達到 140 億次，遠高於 2025 年的 10 億次，顯示 AI 程式輔助工具、自動化機器人與大量程式碼變更流程，正在快速推高平台後端負載。原始頁面的快照未呈現完整正文，但核心脈絡指向 GitHub 的成長速度已超出 Microsoft Azure（Microsoft 的雲端平台）可即時承接的範圍，因此需要借助 AWS 的容量。
討論者普遍認為，commit 數量本身未必能完整解釋壓力來源，因為單次 commit 的資料量可能很小；真正耗費資源的是每次提交背後引發的一連串作業，包括 Git 儲存庫複寫、重新打包、雜湊計算、Pull Request（PR，合併請求）差異比對、GitHub Actions 工作流程，以及 CI（Continuous Integration，持續整合）建置與測試。也有人指出，pull、clone、爬蟲、濫用或低效率的自動化流程，可能比文字形式的程式碼提交更容易造成 I/O（輸入輸出）與運算壓力。
不少開發者分享自身經驗，認為 AI 工具與機器人不只增加程式碼量，也放大了工程流程的浪費。例如有人提到團隊常在 PR 開啟後連續推送 10 到 20 個 commit，卻每次都觸發完整 CI；也有人把 CI 當成遠端測試環境而非在本機先跑測試，導致雲端運算資源被大量消耗。部分公司會用冷卻時間、自動取消舊 CI 作業、限制分支規則等方式控管成本。對於「commit 成長 14 倍」的解讀，許多留言也提醒，這不等於功能產出增加 14 倍，可能只是 AI 讓人更快地產生、修改、重做或修補程式碼。
技術層面上，討論也延伸到 Azure 與 AWS 在高 I/O 工作負載上的差異。有留言回憶早期 Microsoft 與 GitHub 互動時，GitHub 共同創辦人曾明確表示 IOPS（Input/Output Operations Per Second，每秒輸入輸出操作次數）非常重要，而虛擬磁碟速度不足會是遷移到 Azure 的障礙。這讓一些人把此事類比為 Microsoft 早年收購 Hotmail 後，試圖將原本技術堆疊遷往 Windows NT 卻進展不順的「Hotmail 時刻」。也有人藉此反駁「各家雲端平台都差不多」的說法，認為大型程式碼託管平台的底層儲存與 I/O 能力，會直接決定可承受的規模。
整體來看，社群對 Microsoft 使用 AWS 的看法不完全負面：有人嘲諷 Microsoft 自家雲端無法完全承接 GitHub 的需求，也有人認為這很可能只是短期補強；但也有意見認為，比起讓 GitHub 在 AI 浪潮下因容量不足而服務品質下滑，跨雲調度是務實選擇。另有留言批評原始網站本身品質不佳，例如前端頁面結構空洞、無限捲動體驗差、標題標籤異常等，但這些評論主要影響資訊來源觀感，並不改變討論核心：AI 程式開發正在把 GitHub 這類基礎設施推向新的容量與成本壓力測試。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48549918
這篇報導聚焦 Microsoft 在 GitHub 面臨 AI（人工智慧）帶來的運算容量壓力時，轉向 AWS（Amazon Web Services，Amazon 的雲端運算平台）尋求協助。討論中引用的關鍵數字指出，GitHub 的 commit（程式碼提交）量預估在 2026 年可能達到 140 億次，遠高於 2025 年的 10 億次，顯示 AI 程式輔助工具、自動化機器人與大量程式碼變更流程，正在快速推高平台後端負載。原始頁面的快照未呈現完整正文，但核心脈絡指向 GitHub 的成長速度已超出 Microsoft Azure（Microsoft 的雲端平台）可即時承接的範圍，因此需要借助 AWS 的容量。
討論者普遍認為，commit 數量本身未必能完整解釋壓力來源，因為單次 commit 的資料量可能很小；真正耗費資源的是每次提交背後引發的一連串作業，包括 Git 儲存庫複寫、重新打包、雜湊計算、Pull Request（PR，合併請求）差異比對、GitHub Actions 工作流程，以及 CI（Continuous Integration，持續整合）建置與測試。也有人指出，pull、clone、爬蟲、濫用或低效率的自動化流程，可能比文字形式的程式碼提交更容易造成 I/O（輸入輸出）與運算壓力。
不少開發者分享自身經驗，認為 AI 工具與機器人不只增加程式碼量，也放大了工程流程的浪費。例如有人提到團隊常在 PR 開啟後連續推送 10 到 20 個 commit，卻每次都觸發完整 CI；也有人把 CI 當成遠端測試環境而非在本機先跑測試，導致雲端運算資源被大量消耗。部分公司會用冷卻時間、自動取消舊 CI 作業、限制分支規則等方式控管成本。對於「commit 成長 14 倍」的解讀，許多留言也提醒，這不等於功能產出增加 14 倍，可能只是 AI 讓人更快地產生、修改、重做或修補程式碼。
技術層面上，討論也延伸到 Azure 與 AWS 在高 I/O 工作負載上的差異。有留言回憶早期 Microsoft 與 GitHub 互動時，GitHub 共同創辦人曾明確表示 IOPS（Input/Output Operations Per Second，每秒輸入輸出操作次數）非常重要，而虛擬磁碟速度不足會是遷移到 Azure 的障礙。這讓一些人把此事類比為 Microsoft 早年收購 Hotmail 後，試圖將原本技術堆疊遷往 Windows NT 卻進展不順的「Hotmail 時刻」。也有人藉此反駁「各家雲端平台都差不多」的說法，認為大型程式碼託管平台的底層儲存與 I/O 能力，會直接決定可承受的規模。
整體來看，社群對 Microsoft 使用 AWS 的看法不完全負面：有人嘲諷 Microsoft 自家雲端無法完全承接 GitHub 的需求，也有人認為這很可能只是短期補強；但也有意見認為，比起讓 GitHub 在 AI 浪潮下因容量不足而服務品質下滑，跨雲調度是務實選擇。另有留言批評原始網站本身品質不佳，例如前端頁面結構空洞、無限捲動體驗差、標題標籤異常等，但這些評論主要影響資訊來源觀感，並不改變討論核心：AI 程式開發正在把 GitHub 這類基礎設施推向新的容量與成本壓力測試。
👥 33 則討論、評論 💬
https://news.ycombinator.com/item?id=48549918