Jserv's blog

我心目中的 Linux Distribution

這篇 blog entry 主要是源自我過去在 Sayya BBS 個人板發表的札記，略作整理而成，必須聲明的是，每個人的喜好不同，這是單純是我個人的見解與需求，如得罪處，還請多包涵。至於整理發表的動機為何？主要是 Jan 15, 2005 參加 GOT 使用者聚會時，lloyd 前輩分享在賽陽 300 MHz 的筆記型電腦安裝 Gentoo，從零到 X Window System 安裝到好，前後耗費兩個月時間的經驗談，讓我有很大的震撼，當然啦，這樣的等待是值得的，因為整體效能因為針對 i586/MMX 以及許多自訂的 USE flags 而有所改進。 問題是，為何我們要花這麼多時間準備一個套件 (bootstraping) 呢？能否從 binary package 提供一勞永逸的解決方案？能否兼具便利與效能呢？... 種種的疑惑再度盤據於我心，於是，我試著分析現有 Linux Distributions 的特性，以及我的心得。 我玩過的 Linux Distro 有：

• Slackware
• Debian
• Libranet
• ubuntu
• RedHat
• Mandrake
• ArchLinux
• Peanut
• Gentoo

如果說推薦，我會說 Debian，但是真正欣賞的是 Linux Mandrake 與 Peanut Linux，特別是後者，讓我愛不釋手。就務實的角度來說，Debian 作得相當不錯，彈性相當大，也有相當驚人的開發者數量，但是，對我來說，還是欠缺了一種感覺，一種引人入勝的方式。 Debian 許多 policy 都是非常值得參考的，前瞻性也相當夠，但是卻也犧牲了許多特性，讓人覺得難以親近。有一度很沈迷 Debian 時，曾以成為 DebianDeveloper 為目標，但是現在卻完全不會有此念頭，這是因為現在的 Debian 已經不是我心目中的 Debian。與其說我厭倦 Debian，還不如說我一直在尋求 "The Better Debian"，ubuntu 剛推出時，吸引我頗多目光，大抵符合我的需求，但實際體驗後，發現還是有若干特徵沒有實作出來。 Linux Mandrake 有著令人驚豔的外觀與整合性工具，幾乎大項目都有 *Drake 的 toolset 可協助設定與處理，比方說 localedrake 這隻小程式功能很少，但是非常貼心，放眼看其他 Linux distro，卻很少有提出類似的設計。但是 Linux Mandrake 在我的感覺還是不夠嚴謹，當然，我的認知只到 MDK 9.2，後續的版本我沒有接觸過，或許有改觀。Linux Mandrake 在跨越 major release 的 upgrade 處理很糟，也一直沒有提出良好的解法，這幾乎是致命傷。 我心目中的 Linux Distribution 至少需要具備以下特徵：

• 與 Debian 相容
  • 以 Debian 制訂的 policy 為依歸
  • 直接使用 Debian package
• 有 software suite 的觀念
  • Debian 提供的 tasksel 還有很大的改進空間，但是就務實的角度來說，已經能夠針對特定語系做出不同的多國語文相關套件選擇
  • Mandrake 的作法可作借鏡
• 足夠小的 base system
  • Debian 與 Peanut Linux 在這方面很傑出
• 持續更新
  • Package upgrade 算是很重要的議題，而且必須能夠從相當舊的 package db 一路升級到最新的 repository
  • Debian 在這方面作得相當不錯
• 透明化自訂選擇最佳化
  • Gentoo 在這方面無疑是佼佼者
  • Debian 的 apt-build 是很不錯的出發點，但是還可以更好
  • 最佳化對於 server-side applications 相當重要，但是 Gentoo 的方式卻作得太過火，光是 bootstraping 耗費的時間又太久。好的作法是針對 critical package 予以重 build，而且這過程必須透明化
• Localized Backport
  • Debian 事實上有此議題，但是感覺還是很難作得好
  • Linux Mandrake 的作法給予不錯的出發點
  • 從 Fedora 最近的 release 來看，也將 i18n 作為重要的設計準則，是非常優秀的模式
• 友善的 Installer
  • 此處 "Installer" 的定義比較廣泛些，是的，Fedora Core 與 Linux Manadrake 都有相當友善的 GUI Installer，但是還是不夠威力，筆者認為，問題不在於 GUI 的友善度，而是是否能夠一勞永逸的 apply 預期的設定值
  • RedHat 有個 kickstart 的機制，而 Debian 有 FAI 的分支
  • Debian Installer 的發展也算是激勵我撰寫這個主題文章的原因之一
  • Installer 甚至可以與前述的 [透明化自訂選擇最佳化] 整合起來，背景執行最佳化處理，卻省去不必要的 bootstraping，並只處理最 critical 的部分，絲毫不影響正常工作
  • Installer 的挑戰在於是否能夠接受多重 profiles、多種 media，以及多種呈現型態
  • Installer 無疑是最重要的元件之一
• Toolset
  • Debian 與 Linux Mandrake 的作法相當可取
  • 如果能將 *Drake 的 toolset 跟 Debian base system 整合起來，就相當不錯，兼具親和力與套件管理一致性
• Just Works (TM)
  • "Just Work" 的觀念很簡單，但是卻在近年來才被大肆提出
  • Linux platform 的優勢在於選擇多，有驚人的套件數量，但是反而在某些層面造成使用者困擾
  • Linux distro 的責任在於挑選「足夠好」的 packages 與 configuration 組合
• Contributor Participating
  • 應該降低 contributor 參與的困難度
  • Debian 在這方面種種繁複的規定讓人望之卻步
  • Linux Mandrake 在這方面還不錯，很多 contrib
  • Gentoo 的開發模式相當的開放
• 套件管理
  • 這不必說，絕對是相當重要的議題，Debian 以此項目見長，這也是為何我心目中的 Linux distro 必須與 Debian 相容的原因之一。我們可以發現 Linux Mandrake、Fedora Linux，以及 Debian 這三者在套件管理的差異性越來越小，這就是一種趨勢。曾經有一度，我認為這種模式已經足夠了，但是看到 ArchLinux 提出的 Pacman 後，給我不小的震撼。
  • ArchLinux Pacman 在架構上來說比較簡單，但是最重要的特性是允許非官方的 contributor 自行維護 repository，待成熟後再與官方套件整合，這個特性相當重要，能克服部分在前述 [Contributor Participating] 的議題。
  • 在 core package set 來說，ArchLinux 有 "Current" 與 "Release" 之分野，我認為已經足夠，Debian 的作法在某些程度來說，實在太嚴苛了。
  • GNUpdate 提出許多重要的訴求，儘管其發展已經停滯一段時間，但是我們可由其 Components 列表發現以下重要元素：
    • genst - Generate Source Code Tree Tool
    • gnupdate - Graphical GNUpdate Package Tool
    • gnups - GNUpdate Package Server
    • gpkg - Command-line GNUpdate Package Tool
    • libgnurdf - GNUpdate RDF library
    • libpackman - Package Management library
    • libpql - Package Query Language library
    在完整度已經相當高了，ArchLinux 在許多層面來說，也是使用到 GNUpdate 的技術與理念。
  • 再者，上述所及，還是侷限於典型的套件管理系統，永遠都在處理相依性、套件升級，以及管理的議題，是否直接跳脫此思維模式，引入其他途徑呢？是的，有個 open source project，Zero-Install，是個相當大的突破。透過 autopackage，樹立很好的 ABI 基礎，然後使用 LazyFS 克服部署的困難度，是非常不錯的理念。 然而，Zero-Install 最大的弱點在於沒有辦法建立底層 Linux distro 的介面規範，這使得系統整合能力相當受限，那，反過來想，某個 Linux Distro 內建 Zero-Install 的設計是否可行？可以的，而且如虎添翼。
• 套件打包
  • 問題在於是否能夠容易的自訂化，甚至允許使用者再行打包。這是 FreeBSD/Gentoo 的 ports tree 大行其道的原因，我可以很容易指定要用 GTK1 還是 GTK2、要用 SSE optimization 還是 size optimization，或是功能本身的刪減，這是 pre-compiled binary 難以達到的項目。
  • 既然這是盲點，就應該有更好的機制去克服，放眼望去，rpm-build 與 apt-build 就是基於這個原則設計的，但是能夠調整的項目太少，沒辦法像 Gentoo 那樣用 "USE=..." 就輕鬆指定好。
  • 所以，我心目中的 Linux Distro 應該要預留調整編譯時期功能項目的可調適性，並且能夠依據規範作打包的動作，相繼處理 dependency 的問題。我認為 policy 夠嚴謹的話，不會有太大的問題，現在的 Fedora 與 Mandrake 都頗有水準，但是跨越 major release 似乎還有點問題，Debian 算是其中 (我是說 F/M/D 三者來比) 最傑出的，Debian 2.2 一路升級到 3.0r3 不會遇到大問題。

由 jserv 發表於 January 16, 2005 02:06 AM