為什麼 Archlinux 不適合伺服器使用

2021-07-15 12:07:48 字數 2469 閱讀 5121

寫在前面:我使用 archlinux 已經快三年了,而且最近兩年中它已經是我的主系統,工作、娛樂都是用它完成的, windows 只是用來刷刷 bios ……我個人還是很喜歡 archlinux 的 kiss 哲學的,軟體包時刻跟隨上游並且保持原汁原味,滾動更新隨時體驗新特性,最喜歡的大概還是 arch user repository 了吧……說了這麼多,其實核心意思只有乙個——我不是什麼 archlinux 黑,我個人一直都在用它,只是客觀地陳述它絕非「銀彈」或什麼「最好的發行版」,它有它適合的物件和環境,而這絕不包括「生產伺服器」!

唔這兒的 qa 不是 q&a 而是指 quality assurance 。乙個發行版絕不只是把上游的源**收集、打包就完事兒了,如果這麼弄完壓根就啟動不起來、動不動 kernel panic 、軟體包依賴混亂甚至死迴圈……那這肯定不能算是乙個能用的「發行版」。避免這些問題的方法就是所謂的質量保證,包括完善的多階段測試、 bug tracker 等等。發行版在基本奠定了技術基礎之後(主要是包管理器、自動構建系統等等),絕大部分時間都是花費在軟體包的維護、測試之上,各大發行版也是上游軟體的主要 bug reporters (某些重量級團隊還是**貢獻者)。

由於 archlinux 的特點和哲學,其實這不是什麼大問題。折騰 archlinux 的都不是小白,在社群的配合之下一般最後都能順利找到問題根源(大多數時候是上游 bug ……)然後找到 workaround 並向上游反饋。包括我在內的不少使用者其實是樂在其中的(雖然嘴上抱怨不斷)。 archlinux 的「使用者」在一些大型發行版裡其實應該是「志願者」之類的存在……

這應該是 archlinux 最大的問題了。很多 linux 使用者都不理解為何 debian 和紅帽系都要把每個核心版本分開打包,然後再做乙個虛包指向最新版核心,更新核心時不會自動刪掉舊版本,還得之後手動刪除……

這其實是有非常重要的理由,而且不限於是「保險起見」,新核心啟動不起來的時候可以選擇舊核心。更重要的原因是—— linux kernel 是模組式的、動態載入的,而 /usr/lib/modules/linux-kernel 是屬於核心軟體包的。如果在更新核心的時候刪掉了舊版核心的軟體包(也就刪掉了模組目錄),就會使得還未載入的模組無法再被載入了。覺得沒有影響?那麼我告訴你——硬體驅動都是以核心模組形式存在的。舉個例子,如果你使用 archlinux ,在某此啟動之後都沒有插過 u 盤,然後更新了核心,你就發現 u 盤插進去以後怎麼都認不出來(usb ehci 模組和 vfat 檔案系統模組都沒掛載……)。你說伺服器上不會有硬體變動?那麼你一定是忘記了 openvpn 之類的軟體,在啟動之後需要建立乙個虛擬裝置(比如 openvpn 的 tap 或者 tun ),如此一來也就無法使用了。

最終的結果就是,使用 archlinux ,要麼你就別更新核心,要麼更新了核心以後就立即重啟以免遇到奇怪的問題。這種粗暴的更新方式難道不是比 windows update 還要糟糕麼?(用過 windows server 的人一定遇到過更新以後要求你重啟,甚至如果你正好處於乙個活躍會話,那麼如果你不立即取消掉那個對話方塊, 15 分鐘後就直接給你重啟了……)

比起複雜甚至臃腫的 yum/rpm 和 apt-get/dkpg , archlinux 的包管理器要簡單許多,乙個 pacman 就搞定了「源」和「包」兩頭,完成了別的發行版兩個軟體才能做到的事情。

可如果真要是這麼簡單的乙個程式就能做好的事情,為什麼別的發行版都要這麼「笨」地開發如此複雜的工具?答案其實很簡單——軟體包管理本來就是非常複雜的事情。我不是乙個包管理者,在這方面沒有什麼發言權,但單從乙個使用者角度來看也足夠意識到其存在的不足了。依賴、推薦不夠靈活,只有 depends opt-depends suggestions 三種,缺乏「虛包」的支援。一些常見的需求比較難以優雅地實現,比如:乙個軟體有多個不同的實現時,只能通過設定相同的 provides 然後再互相 conflicts 實現,這樣一來每加乙個新的實現就要修改之前所有的相同 provides 的包,而且也缺乏 dpkg-reconfigure 之類的工具來選擇乙個虛包到底使用哪乙個實包從而實現靈活地在不同實現之間切換的功能(比如 oracle jdk 和 openjdk 之間的切換,在 archlinux 裡只能安裝乙個然後刪除掉另乙個)。

另外, archlinux 的打包粒度太大(比如乙個 php 包就包括了大量非必須模組,得靠修改配置檔案來啟用或禁用,而在 debian 和紅帽裡則是被拆成了很多個包)。當然,也有人認為 debian 的粒度太細就是了。不過就我兩年的使用經歷看來 archlinux 的包的確偏大,對於桌面版沒有什麼問題,這年頭大家的硬碟也都挺大,但在伺服器上一般都是希望安裝盡可能少的軟體以盡可能減少漏洞和 bug 。

當然,比較簡單的包管理器也有乙個好處,就是降低了打包的門檻。這也是 aur 能夠這麼方便易用、內容豐富的部分原因。

最後,吐槽一下 pacman 不會自動清理包快取,哪怕是很早以前的。我在用了兩年之後包快取有30多個g,直接把我的根分割槽都佔滿了……

related posts:

archlinux 中 grub 和 mkinitcpio 的 bug

解決hp compaq presario cq35系列在ubuntu下的音效卡驅動問題

**:

為什麼我不適合學程式設計?

為什麼我不適合學程式設計?活動 內容 faq 我喜歡靠自己的努力來解決問題。也許是因為在學校裡,沒有養成好的集體活動的習慣。也許是因為我這個家庭最小的孩子想在這個大家族中證明什麼東西。不管是什麼吧,每當我有什麼事情需要完成時,我都會自己去構思,計畫,研究,學習相關技能,然後付諸行動。自從記事兒起我就...

真的不適合

1 做事情的時候聽 真的不適合我。曾經嘗試了很多次,甚至現在有時候也會想著寫 的時候聽 看書的時候聽 但是,真的,這不適合我。以後有這種想法的時候,及時告誡自己,真的不行,效率奇低!2 宿舍不是適合我學習的地方。從實驗室把電腦扛回宿舍,一本正經想要學習。最後都以跟室友聊天 吃零食 東摸摸西看看結束。...

開源不適合VMware

2008 10 14 12 08 julie 51cto.com ipo的巨大成功也使vmware承擔了重大的責任,同時,很多沒有意義的事情接踵而來。vmware也許可以忍受在辦公室內做些無意義的事情,但是它卻不容忍著發生在其技術的源 上。我們詢問公司是不是可以做些不同尋常地舉措比如將其旗艦技術源 ...