Log for Ubuntu 台灣社群
自由開源軟體專案如何處理法律下架請求 （★ 111 分）
自由開源軟體 (FOSS, Free and Open Source Software) 專案在面對強制下架請求時，如何回應往往攸關專案的穩定與社群安全。F-Droid 透過研究不同的法律專家、數位人權組織以及成熟的 FOSS 專案維護者，整理出一套應對策略。文章指出，處理得當的下架請求只是行政流程的一環；若忽視或隨意應付，則可能導致基礎設施中斷、貢獻者陷入法律風險，甚至成為濫用力量的受害者。
研究顯示，多數成功的做法有幾個共同點。首先，不要成為「容易下手的目標」。一些組織會要求所有法律相關通信必須以正式郵件遞交、使用當地語言並引用本國法律，這種高門檻往往讓許多模糊或騷擾性的投訴自然消失。其次，建立透明且有紀錄的流程，例如集中到專用的 legal@ 郵箱、要求提供完整法律依據與舉證，再進行比例性與合法性檢視。第三，策略性運用司法管轄權，避免對境外模糊需求過度配合；有效的門檻應該是法院命令或官方政府文件，而不是無法驗證的電子郵件。
針對被要求下架的開發者，F-Droid 提倡盡可能的通知制度：在法律允許下，開發者會先得到通知，並有 14 天左右的回應窗口來提供授權證明、公有領域聲明或合理使用抗辯。如果最終仍然被認定有效，下架必須伴隨內部紀錄與申訴機制。這種模式與 GitHub 的 DMCA 下架政策和《馬尼拉原則》(Manila Principles) 等國際標準相符，避免專案過度順從，進而助長審查或濫權。
然而透明公開並非各國皆容許。例如在印度，收受政府下架令後連開發者都不能告知；但在俄羅斯則有公開名單制度，卻可能引來報復或後續法律糾紛。為平衡風險，最佳實踐包括定期公布半年報 (即便有刪節)、內部紀錄所有請求、公開刪除原因與依據，並清楚說明哪些內容因法律所限無法揭露。F-Droid 也正修訂自己的下架政策，加入歐盟與荷蘭法律依據、明確的提交流程、開發者通知與透明度報告，以在全球環境中維護法律韌性。
Hacker News 討論中，許多開發者分享了自己處理下架請求的經驗。有評論提到，美國 DMCA（數位千禧年著作權法）設計的「通知與反通知」制度理論上保障了內容創作者，但實務上許多平台的回應機制品質低落，常無法真正讓開發者行使抗辯。另一位指出，整個「下架請求」本質上就是一種折衷：平台想免除責任，權利人則想直接追究平台，但在網路上追查實際發佈者過於困難，只能找到中間點。也有人批評大型企業設計的流程刻意模糊，讓小型開發者難以捍衛自身權益，僅方便大公司維持控制。
部分開發者認為，F-Droid 所提出的完整證據與法律依據要求，能有效抑制惡意或隨意的投訴，因為單單舉證的負擔就能讓不少濫用者卻步。另外有維護 FOSS 工具的開發者坦言，幾乎每週都會收到下架通知，處理過程既繁瑣又無趣，甚至必須公開透明地記錄下架清單，以作為日後依循。也有人分享自身專案曾遭俄羅斯主管機關要求下架，F-Droid 直接封鎖當地用戶存取專案頁面，卻未提供所謂的申訴窗口，顯示理論與現實之間仍存在落差。
整體來看，社群共識偏向支持 F-Droid 建立制度化、透明化的處理流程，認為這有助於抵抗濫權與不當審查。但也有人指出，當國家機構涉入，下架過程往往難以完全透明，許多開發者最終仍須在法律壓力與社群責任中尋求平衡。這場對話突顯了 FOSS 專案在全球化環境中面臨的挑戰：如何堅守自由、透明原則，同時又能存續與合法營運。
👥 10 則討論、評論 💬
https://news.ycombinator.com/item?id=45224421
自由開源軟體 (FOSS, Free and Open Source Software) 專案在面對強制下架請求時，如何回應往往攸關專案的穩定與社群安全。F-Droid 透過研究不同的法律專家、數位人權組織以及成熟的 FOSS 專案維護者，整理出一套應對策略。文章指出，處理得當的下架請求只是行政流程的一環；若忽視或隨意應付，則可能導致基礎設施中斷、貢獻者陷入法律風險，甚至成為濫用力量的受害者。
研究顯示，多數成功的做法有幾個共同點。首先，不要成為「容易下手的目標」。一些組織會要求所有法律相關通信必須以正式郵件遞交、使用當地語言並引用本國法律，這種高門檻往往讓許多模糊或騷擾性的投訴自然消失。其次，建立透明且有紀錄的流程，例如集中到專用的 legal@ 郵箱、要求提供完整法律依據與舉證，再進行比例性與合法性檢視。第三，策略性運用司法管轄權，避免對境外模糊需求過度配合；有效的門檻應該是法院命令或官方政府文件，而不是無法驗證的電子郵件。
針對被要求下架的開發者，F-Droid 提倡盡可能的通知制度：在法律允許下，開發者會先得到通知，並有 14 天左右的回應窗口來提供授權證明、公有領域聲明或合理使用抗辯。如果最終仍然被認定有效，下架必須伴隨內部紀錄與申訴機制。這種模式與 GitHub 的 DMCA 下架政策和《馬尼拉原則》(Manila Principles) 等國際標準相符，避免專案過度順從，進而助長審查或濫權。
然而透明公開並非各國皆容許。例如在印度，收受政府下架令後連開發者都不能告知；但在俄羅斯則有公開名單制度，卻可能引來報復或後續法律糾紛。為平衡風險，最佳實踐包括定期公布半年報 (即便有刪節)、內部紀錄所有請求、公開刪除原因與依據，並清楚說明哪些內容因法律所限無法揭露。F-Droid 也正修訂自己的下架政策，加入歐盟與荷蘭法律依據、明確的提交流程、開發者通知與透明度報告，以在全球環境中維護法律韌性。
Hacker News 討論中，許多開發者分享了自己處理下架請求的經驗。有評論提到，美國 DMCA（數位千禧年著作權法）設計的「通知與反通知」制度理論上保障了內容創作者，但實務上許多平台的回應機制品質低落，常無法真正讓開發者行使抗辯。另一位指出，整個「下架請求」本質上就是一種折衷：平台想免除責任，權利人則想直接追究平台，但在網路上追查實際發佈者過於困難，只能找到中間點。也有人批評大型企業設計的流程刻意模糊，讓小型開發者難以捍衛自身權益，僅方便大公司維持控制。
部分開發者認為，F-Droid 所提出的完整證據與法律依據要求，能有效抑制惡意或隨意的投訴，因為單單舉證的負擔就能讓不少濫用者卻步。另外有維護 FOSS 工具的開發者坦言，幾乎每週都會收到下架通知，處理過程既繁瑣又無趣，甚至必須公開透明地記錄下架清單，以作為日後依循。也有人分享自身專案曾遭俄羅斯主管機關要求下架，F-Droid 直接封鎖當地用戶存取專案頁面，卻未提供所謂的申訴窗口，顯示理論與現實之間仍存在落差。
整體來看，社群共識偏向支持 F-Droid 建立制度化、透明化的處理流程，認為這有助於抵抗濫權與不當審查。但也有人指出，當國家機構涉入，下架過程往往難以完全透明，許多開發者最終仍須在法律壓力與社群責任中尋求平衡。這場對話突顯了 FOSS 專案在全球化環境中面臨的挑戰：如何堅守自由、透明原則，同時又能存續與合法營運。
👥 10 則討論、評論 💬
https://news.ycombinator.com/item?id=45224421
SkiftOS：一個以 C/C++ 從零開始自製、支援 ARM、x86 與 RISC-V 的作業系統 （★ 103 分）
skiftOS 是一個由開發者花了超過六年的時間，以現代 C++ 自行從零開始打造的自製作業系統專案。它不是 Linux 或 Windows 的複製品，而是一個用來探索作業系統內部原理、練習系統程式設計技巧的試驗場，並且力求保持簡潔、一致與可用。雖然仍在早期開發階段，但 skiftOS 已經具備圖形化介面、核心應用程式，以及以微核心為基礎的架構，讓開發者能自在地嘗試各種點子。
在功能設計上，skiftOS 具備一套反應式使用者介面框架，靈感來自 SwiftUI 與 Flutter，強調字體排版、間距與主題的一致性。系統中的應用程式涵蓋了檔案管理、文字編輯、媒體播放、影像檢視、終端機、計算機、工作管理器、設定，甚至還有遊戲等基礎功能，便於開發者快速理解與參與貢獻。不像大多數類 Unix 系統，skiftOS 並非 POSIX 相容，而是以 Plan 9、Haiku、Fuchsia 等系統為靈感，設計出獨立的 API 與使用者空間。
在技術核心方面，skiftOS 採用能力控制 (capability-based) 微核心設計，強調安全性與模組化，應用程式只能存取被核准的記憶體或硬體資源，避免「全面存取」的風險。系統還包含自製的 UEFI 開機載入器、支援 ARM、x86 與 RISC-V 的多架構建置系統，以及專屬的輕量級 HTML/CSS 瀏覽器引擎 Vaev。瀏覽器目前只支援 HTTP，網路堆疊仍相當簡陋，但排版與介面渲染已較為完整。此外，驅動程式被設計在使用者模式下執行，透過能力 (capability handles) 與核心互動，這種結構提供了模組化與安全隔離的基礎。
在 Hacker News 的討論中，許多參與者對開發者能獨立實作出一套作業系統表達驚艷，尤其對其自製瀏覽器引擎感到不可思議。也有人詢問網路、聲音與檔案系統支援狀況，開發者解釋目前大部分功能仍屬於框架與範例階段，本質上是一個為學習與樂趣而打造的微核心實驗專案，而非完整成熟的作業系統。有些評論對於其不依循 UNIX 傳統設計表示讚許，認為這是一種跳脫既有路線的探索精神。
另一方面，安全性也是熱門問題。開發者指出 skiftOS 的應用程式不會直接存取全部記憶體或硬體，而是透過授權才可使用特定資源，不存在預設的全域權限。這讓系統在設計思路上與傳統單核心架構有所不同，更貼近學術界與下一代作業系統研究的方向。總體而言，Hacker News 社群普遍欣賞這樣的個人長期專案，不僅展現了技術實力，也提供了一個思考未來作業系統設計方式的契機。
👥 13 則討論、評論 💬
https://news.ycombinator.com/item?id=45229414
skiftOS 是一個由開發者花了超過六年的時間，以現代 C++ 自行從零開始打造的自製作業系統專案。它不是 Linux 或 Windows 的複製品，而是一個用來探索作業系統內部原理、練習系統程式設計技巧的試驗場，並且力求保持簡潔、一致與可用。雖然仍在早期開發階段，但 skiftOS 已經具備圖形化介面、核心應用程式，以及以微核心為基礎的架構，讓開發者能自在地嘗試各種點子。
在功能設計上，skiftOS 具備一套反應式使用者介面框架，靈感來自 SwiftUI 與 Flutter，強調字體排版、間距與主題的一致性。系統中的應用程式涵蓋了檔案管理、文字編輯、媒體播放、影像檢視、終端機、計算機、工作管理器、設定，甚至還有遊戲等基礎功能，便於開發者快速理解與參與貢獻。不像大多數類 Unix 系統，skiftOS 並非 POSIX 相容，而是以 Plan 9、Haiku、Fuchsia 等系統為靈感，設計出獨立的 API 與使用者空間。
在技術核心方面，skiftOS 採用能力控制 (capability-based) 微核心設計，強調安全性與模組化，應用程式只能存取被核准的記憶體或硬體資源，避免「全面存取」的風險。系統還包含自製的 UEFI 開機載入器、支援 ARM、x86 與 RISC-V 的多架構建置系統，以及專屬的輕量級 HTML/CSS 瀏覽器引擎 Vaev。瀏覽器目前只支援 HTTP，網路堆疊仍相當簡陋，但排版與介面渲染已較為完整。此外，驅動程式被設計在使用者模式下執行，透過能力 (capability handles) 與核心互動，這種結構提供了模組化與安全隔離的基礎。
在 Hacker News 的討論中，許多參與者對開發者能獨立實作出一套作業系統表達驚艷，尤其對其自製瀏覽器引擎感到不可思議。也有人詢問網路、聲音與檔案系統支援狀況，開發者解釋目前大部分功能仍屬於框架與範例階段，本質上是一個為學習與樂趣而打造的微核心實驗專案，而非完整成熟的作業系統。有些評論對於其不依循 UNIX 傳統設計表示讚許，認為這是一種跳脫既有路線的探索精神。
另一方面，安全性也是熱門問題。開發者指出 skiftOS 的應用程式不會直接存取全部記憶體或硬體，而是透過授權才可使用特定資源，不存在預設的全域權限。這讓系統在設計思路上與傳統單核心架構有所不同，更貼近學術界與下一代作業系統研究的方向。總體而言，Hacker News 社群普遍欣賞這樣的個人長期專案，不僅展現了技術實力，也提供了一個思考未來作業系統設計方式的契機。
👥 13 則討論、評論 💬
https://news.ycombinator.com/item?id=45229414
在 QEMU/UTM 上安裝 Windows 98 的技巧與注意事項 （★ 100 分）
這篇文章分享了在 QEMU 與 UTM（特別是 iOS 平台的 UTM SE 模擬器）上安裝 Windows 98 的一些技巧與注意事項，讓使用者能在 iPad 或 Mac 上更順暢地運行 90 年代的 Windows 以及 DOS 軟體。由於 Windows 98 預設依賴舊式的即插即用 BIOS (PnP BIOS)，在 QEMU/SeaBIOS 下可能會遇到裝置管理器出現「Plug and Play BIOS device」錯誤。解決方法是利用 Windows 98 對 ACPI（進階組態與電源介面）有限的支援，在開機時從安裝光碟輸入 `setup /p j` 指令，使系統安裝過程中直接切換至 ACPI，避免後續麻煩的驅動問題。
在硬體選項的模擬上，文章建議使用 i440（pc-based）系統配置，以確保對舊版 Windows 的良好相容性；輸入方面則需關閉 USB 輸入裝置，避免 Windows 98 開機卡死，改以 PS/2 滑鼠或透過 UTM 的自動滑鼠捕捉方案操作。顯示卡最適合選擇 Cirrus VGA (`-vga cirrus`)，雖然有顏色閃爍與 blitting 的 bug，但可提供基礎加速驅動。網路則建議使用 PCI 介面的 NE2000、Tulip 或 PCNet 來省卻 ISA 配置的麻煩。音效卡方面，SB16 雖然方便 DOS 軟體但缺少正確的 MIDI 支援；若是單純 Windows 使用者則推薦 ES1370，驅動可直接在 Windows 98 光碟中找到。
效能表現方面，雖然 QEMU 的 TCG 解譯器效能不算出色，但在 M1 Pro 的 MacBook Pro 上能相當於約 750MHz 的 Pentium III，對於文書或 2D 遊戲相當夠用。若是在 iPad Pro 上運行則大約落在 Pentium 100 水平，能流暢跑像 SimCity 2000、MechWarrior 2 之類的 1995 年前後遊戲，但不適合 3D 加速需求較高的作品。非遊戲軟體如 Office 97 與 Visual C++ 則能穩定執行。
在 Hacker News 的討論部分，有人詢問 Windows 98 與 iPad 觸控輸入的相容性，其他網友補充說 iPad 上 UTM 提供不同滑鼠模擬模式，若沒有驅動支援只能當作「巨大觸控板」來用。也有人建議若不一定要使用 iPad，可以透過 DOSBox 來跑 Windows 98 或 DOS 軟體，並受惠於 Ad Lib 音效模擬。不過部分參與者指出 QEMU 對老硬體的仿真並不精確，開發重心主要放在支援新系統，若追求高度硬體仿真可改用 x86box 或 pcem 這類強調精確度但相對較慢的模擬器。
一些技術性留言也深入到細節，例如 Windows 98 雖包含 Microsoft GS Wavetable Synth 作為 MIDI 解決方案，但 DOS 直通遊戲仍可能出現問題；另有人提到 90 年代微軟曾考慮支援 CPU 的 HLT (Halt 指令) 節能模式，但由於相容性問題最終移除，導致 Windows 95/98 在閒置時 CPU 使用率仍維持 100%，這在模擬環境下也會反映出來。多數人仍將 QEMU/UTM 視為便捷但有限的兼容方式，而對音效或遊戲需求較多的用戶則推薦 DOSBox 或專用模擬器。
整體來說，文章提供了一套在 Apple 裝置上透過 UTM 安裝 Windows 98 的具體方案，適合想要重現舊系統軟體體驗的愛好者。討論中則補充了 QEMU 模擬不夠精確的限制，以及替代工具的價值，使讀者能更準確地選擇最合適的模擬環境來復刻經典應用與遊戲。
👥 19 則討論、評論 💬
https://news.ycombinator.com/item?id=45227749
這篇文章分享了在 QEMU 與 UTM（特別是 iOS 平台的 UTM SE 模擬器）上安裝 Windows 98 的一些技巧與注意事項，讓使用者能在 iPad 或 Mac 上更順暢地運行 90 年代的 Windows 以及 DOS 軟體。由於 Windows 98 預設依賴舊式的即插即用 BIOS (PnP BIOS)，在 QEMU/SeaBIOS 下可能會遇到裝置管理器出現「Plug and Play BIOS device」錯誤。解決方法是利用 Windows 98 對 ACPI（進階組態與電源介面）有限的支援，在開機時從安裝光碟輸入 `setup /p j` 指令，使系統安裝過程中直接切換至 ACPI，避免後續麻煩的驅動問題。
在硬體選項的模擬上，文章建議使用 i440（pc-based）系統配置，以確保對舊版 Windows 的良好相容性；輸入方面則需關閉 USB 輸入裝置，避免 Windows 98 開機卡死，改以 PS/2 滑鼠或透過 UTM 的自動滑鼠捕捉方案操作。顯示卡最適合選擇 Cirrus VGA (`-vga cirrus`)，雖然有顏色閃爍與 blitting 的 bug，但可提供基礎加速驅動。網路則建議使用 PCI 介面的 NE2000、Tulip 或 PCNet 來省卻 ISA 配置的麻煩。音效卡方面，SB16 雖然方便 DOS 軟體但缺少正確的 MIDI 支援；若是單純 Windows 使用者則推薦 ES1370，驅動可直接在 Windows 98 光碟中找到。
效能表現方面，雖然 QEMU 的 TCG 解譯器效能不算出色，但在 M1 Pro 的 MacBook Pro 上能相當於約 750MHz 的 Pentium III，對於文書或 2D 遊戲相當夠用。若是在 iPad Pro 上運行則大約落在 Pentium 100 水平，能流暢跑像 SimCity 2000、MechWarrior 2 之類的 1995 年前後遊戲，但不適合 3D 加速需求較高的作品。非遊戲軟體如 Office 97 與 Visual C++ 則能穩定執行。
在 Hacker News 的討論部分，有人詢問 Windows 98 與 iPad 觸控輸入的相容性，其他網友補充說 iPad 上 UTM 提供不同滑鼠模擬模式，若沒有驅動支援只能當作「巨大觸控板」來用。也有人建議若不一定要使用 iPad，可以透過 DOSBox 來跑 Windows 98 或 DOS 軟體，並受惠於 Ad Lib 音效模擬。不過部分參與者指出 QEMU 對老硬體的仿真並不精確，開發重心主要放在支援新系統，若追求高度硬體仿真可改用 x86box 或 pcem 這類強調精確度但相對較慢的模擬器。
一些技術性留言也深入到細節，例如 Windows 98 雖包含 Microsoft GS Wavetable Synth 作為 MIDI 解決方案，但 DOS 直通遊戲仍可能出現問題；另有人提到 90 年代微軟曾考慮支援 CPU 的 HLT (Halt 指令) 節能模式，但由於相容性問題最終移除，導致 Windows 95/98 在閒置時 CPU 使用率仍維持 100%，這在模擬環境下也會反映出來。多數人仍將 QEMU/UTM 視為便捷但有限的兼容方式，而對音效或遊戲需求較多的用戶則推薦 DOSBox 或專用模擬器。
整體來說，文章提供了一套在 Apple 裝置上透過 UTM 安裝 Windows 98 的具體方案，適合想要重現舊系統軟體體驗的愛好者。討論中則補充了 QEMU 模擬不夠精確的限制，以及替代工具的價值，使讀者能更準確地選擇最合適的模擬環境來復刻經典應用與遊戲。
👥 19 則討論、評論 💬
https://news.ycombinator.com/item?id=45227749