ミニマルシステム Linux
technique
- TOP
- Old Archives
- ミニマルシステム Linux
序
ミニマルシステムという言葉自体は様々な意味があるが、ここでは「必要最小限のソフトウェアのみが動作するシステム」であり、付随して「必要以上のリソースを要求するハードウェアを持たないシステム」の話をしたいと思う。
多くの場合、ミニマルシステムを語る文脈は(好みの問題もあるが)制限されたリソース下か、もしくはサーバーの話である。 リソースがないので軽量な環境が必要という話か、もしくはセキュリティ的にも管理的にもサーバーに余計なソフトウェアを置かないというような話か。
だが、ここではリッチデスクトップでミニマルシステムを使う話をしようと思う。
なぜそんな話になるかというと、私はどちらかといえばマッシヴシステムが好きであり、だからハードウェア的にもソフトウェア的にも機能・性能重視である。だからこそ得られる蓄積があり、強力な武器にはなっている。 私は「ソフトウェアが重かったとしても十分以上のコンピュータリソースがあれば問題ない」と考えていた。だが、それは違うということを最近知った。
そのキッカケは、ThinkStation P720の導入でサポートマシンへと転向したZ400 Workstationである。 Z400 Workstationはhpが2009年に発売したメインストリームワークステーションであり、私が持っている2010年モデルはXeon W3565プロセッサを水冷化しており、Quadro2000ビデオカードを搭載する。 W3565プロセッサは初代Core i7 extremeとほぼ同等のプロセッサであり、ビデオカードはもう一世代新しいゲーム用のGeForce 750Tiに換装している。一次記憶装置は16GBのDDR3 ECC unbuffered DIMMである。
このマシンは古いので、私のサブマシンであるAMD A10-7870Kプロセッサを搭載するものと性能は大差ない(GTX750Tiを載せるとビデオには少しアドバンテージがある)。 現代においてはローエンドクラスであり、Ryzen3 3200Gならば全面的にその性能を上回るだろう。CPU性能だけで言えば、Core i3でも圧勝である。1
実際、P720が導入されたのは「Z400ではタスク消化量よりもタスク増加量のほうが多い」という問題に対応するためである。 実はこの問題はP720でも依然として解決されていないのだが、現状タスクそのものを削減してしまった(つまり、やるべきことをやっていない)ので表面的には問題なく回っている。
この状態で、Z400は補助用に再生された。補助用といっても、これまでZ400はとんでもなく酷使されてきたことから「寝室で作業したい場合や、寝る前に軽く遊びたいときに使えるように」というのが主であり、計算リソースとして使われることは稀である。 これをミニマルシステムにしたところ、見違えるほど快適だったのだ。
実際の構成
メイン機はP720であり、P720はソフトウェア導入数も多く、商用フォントも多く載っている。 デスクトップ環境はCinnamonだが、XFce4ベースで、さらにKDEもフルセットで載っている状態だ。
すべてのソフトウェアを使っているわけではないが、最近は試した上で使わないと判断したものは消しているため、導入しているものの一部は少なくとも使うものになっている。
データはP720に搭載されたディスクとNAS群を併用する形。 主たるデータはiSCSI越しにマウントされている。
これと共に主力に位置づけられているのがThinkPad X1 Carbon (Gen4)である。 こちらはMimir Yokohamaの授業で使うため導入ソフトウェア数がP720よりも多い。ただし、実用していないソフトウェアが多く、設定やファイル数は少ない。ソフトウェア導入は仕方ないが余計なデータはあまり置かないように運用されている。
X1においてデータが必要となる場合は別途ポータブルSSDがあり、これをUSB接続することでデータを拡張できるようになっている。
ソフトウェア導入数という点を除けばX1は身軽で、Mercurialでデスクトップのデータを持ち出し、帰宅したらMercurialで反映するというような構成だ。 作業はほとんどVSCodeとSSHによるものなので、これらだけが設定などを作り込んだ状態になっている。
A10-7870Kマシンは10台という搭載数を活かしてストレージ群の一端を担うのが基本。Linux部分は完全にminimalで、まともに設定もされていない。ただ、全マシン中最も古い、2015年セットアップのマシンであるため、利用中に割と色々追加されたとかパッケージ変更があったりとかでゴミのあるシステムでもある。 基本的にデスクトップとして使うこと自体がないため、デスクトップとして使えるようにセットアップされていない。
Z400は最も最近セットアップされた状態であり、他のマシンがManjaro XFce4ベースであるのに対し、唯一Manjaro Cinnamon community editionベースになっている。 これが、「デスクトップとして使うことのできる完全なminimal system」になったわけだ。
ミニマルシステムのメリット
トラブルが少ない
マッシヴな環境を使っている人が少ないということもあり、マッシヴシステムはトラブルの宝庫である。 特に言えるのがマルチディスプレイにおけるトラブルの多さ。
そもそもデバイスやソフトウェアが少なければトラブルの発生要因が減るし、トラブルが発生した場合でも原因になりうるものが少ないので切り分けも解消も楽。
応答性がすごく良い
応答性に凄まじく影響するのが
- ディスプレイサイズ
- フォント数
である。 特にサイズの大きい日本語フォントは数を導入するとあらゆる場面で相当重くなり、あまりにも多くなるとトラブルの原因になる。
ディスプレイサイズに関しては応答性に直結し、Windowsだとビデオカードの性能があれば気にならなくなるのだが、Linuxの場合高性能ビデオカードの投入によって問題が解決しない。 実際、私のP720はRX580ビデオカードを搭載しているのだが、4k+FHD+FHDの構成で応答性はX1よりは良いものの、Z400よりもだいぶ劣る。
消費電力が少ない
ディスプレイの消費電力が大きいので、ディスプレイが小さい、少ないのは省エネになる。
また、動作プロセスが少なければ微々たるものではあるが省エネにつながるし、全体的に軽ければpowersave governerが使えるようになり(むしろそれがデフォルトであるが)、より少ない電力で動作させられるようになる。
集中できる
色々起動して情報を確認しながらというのは効率が良いし、ダレ防止にもなるが、一方で集中を欠いて進まなくなるリスクも抱えている。
状況によってはむしろ情報を制限したほうが効率的だ。
再セットアップが楽
設定が少なく、導入するパッケージも少ないので、バックアップを活用せずとも短い字かんで再セットアップができる。
ミニマルシステムが組めるレベルであれば、必要なパッケージや設定などは完全に把握しているだろうから、非常に短時間でできるはずだ。 それによってシステムのクリーンアップができる点も大きい。
ミニマルシステムに関する注意
「どうしても余計なものは(それが必要なものであっても)何一ついれたくない」という人が結構いるのだが、 ミニマルシステムを構築するためには「必要最低限とはなにか」ということを見極めることが必要であり、非常に豊富な経験が必要である。
むしろマッシヴシステムを使ったり、とことん試したりして知識を蓄積した上で行き着くところがミニマルシステムだ。
初心者のうちはとりあえずなんでもかんでも入れてみるほうが正しい。 最初から最小限にしようとするのは、知識好奇心の欠如となり、成長を阻害し、使いにくいままとりあえず使う事態となってしまう。
私なりの構築
ハードウェアから選ぶ
ディスプレイのドット数は非常に重要で、ディスプレイの総ドット数が増えるとすごく反応速度が落ちる。 1344x768は非常に速いが、犠牲は重い。
作業効率との両立で限界まで追求するなら、UWQHD(3440x1440)の大きめの曲面ディスプレイがベストであるように思う。 この場合、パワフルなビデオカードを用意しなくてはならない。
クロック数、処理能力の高いハードウェアと組み合わせることを考えると、今ならRyzen9とRadeon VIIという組み合わせが理想的なハードウェアではないだろうか。
もしくは、ミニマルシステムの利点を活かして応答性がよく快適なシステムを目指すのならば、Ryzen5 3500GでFullHDディスプレイに抑えるようなことも考えられそう。
ディスクの速度にはこだわりたい。NVMe SSDが基本。
パフォーマンスに悪影響を与えず、エクスペリエンスに影響するデバイス(例えばキーボード, マウス, スピーカー等)は良いものを選べば良い。
圧倒的Cinnamon
セットアップにおいて最も感じられるのは「KDE Applicationsを入れない」である。 Plasma workspaceそのものは問題ではないのだが、KDE Applicationsを入れると明らかに重くなる。
それと比べればGNOMEは軽いのだが、それでもそこまで軽くもない。
結局、軽量でハードウェアアクセラレーションもしっかりと効くCinnamonがベストだ、という結論に達する。 GNOMEのコンポーネントが少数入っており、使い勝手と軽量さが両立できるのがいい。 また、Cinnamonの機能によってカバーできる範囲がとても大きく、余計なソフトウェアを入れなくて済むというのも大きい。
TrackerやBalooのようなものに振り回されることがないのもポイントが高いだろう。 必要であればTrackerを入れることもできるが、ミニマルシステムの敵である。
community editionではあるが、Manjaro Cinnamonを採用するのはかなり良い結果になると感じた。 X-appsを使っているのでGNOME依存度も低い。
可能なら暗号化しない
暗号化は全体的な負荷が増え、応答性を低下させる。 可能であれば暗号化しないほうが良い。
ここに置かない
そのマシンそのものにデータを置くのは重量化への道である。
まずは「データ」を分けて、かつ分類することが大事だ。
その上で日常的に常に触るデータ、アプリケーションの一部として動作するデータはオフラインでも使える状態であったほうがよく、腰を据えて何かするときでなければアクセスしないデータは分けてしまって良いだろう。 大部分のデータが毎日は使わないというのであればNASのシャットダウンもできるようになるが、私の場合はそれは無理なので、NASのマウントはほぼ前提だ。
もちろん内蔵ストレージの量にもよるのだが、画像データ、音楽データ、ビデオデータなどで、「むちろん観る、聴くときはあるが、それがコンピュータ上の日常ではない」というものであればそのマシン上に置く必要はない。
私のように複数の部屋にマシンがある場合はNASが有効な手段である。 また、ラップトップ使いの場合でも外で使うデータというのは限られてくるだろうから、NASにおくというのは有効な手。 デスクトップのはあ゛胃は別ディスクを搭載する、ラップトップの場合はUSBディスクに搭載するという方法もある。
うまくデータを分けることはまず第一歩だ。
SSH
ミニマルシステムが唯一のシステムでは可能性を妨げてしまう。 ミニマルシステム使いはそのシステムを越えてシステムを活用する方法を持っていることだろう。
SSHはその中心的存在となる。まずはSSHをセットアップしよう。 ネットワークやアカウントが適切に管理されているのであれば、HostBased認証というのも手。
使うパッケージを入れてセットアップ
基本的に私の場合は使うソフトウェアがとても多いので、結局非常に多くのソフトウェアを入れることになるメイン以外に関してはパッケージを絞ることはできないが、メイン以外には日常的に使うパッケージに絞り込んでいる。
私だと、ほとんど使うソフトウェアはVSCodeとウェブブラウザに限られてしまう。
実際にはzsh-completions
, grml-zsh-config
,
zsh-theme-powerlevel9k
, gvim
,
vim-plugins
などのパッケージも入れているけれども。もちろん、日本語入力関係も。
あとはサブ環境でも使うものということで、Claws Mail, Discord, Telegramを入れる。 このあたりは各々の使い方により、という感じ。逆に、Thunderbirdは使わないので削除する。
入力系はiBusよりもFcitxのほうが応答性が良い。 Mozcよりもlibkkcのほうが応答は速いが、これはエクスペリエンスにとってプラスにならないのでこだわる必要はないだろう。
さらにこだわるなら、uimを使用する方法もある。 uim自体はextraに入っているが、uim-mozcはAUR。uim-mozcは依存関係でiBusがインストールされる。 uim-mozc-ut2をインストールする場合、PKGBUILDでiBusを外し、uimを有効にするという手順を経たほうがよさそう。 (コメント変更する対象のPKGBUILDは2つ)
しかし、2019-09-16現在、 AURのmozcがビルドできない。 こんな感じのエラーになる。
INFO: Running: ninja -C out_linux/Release mozc_server mozc_tool
ninja: Entering directory `out_linux/Release'
ninja: error: '../../third_party/zinnia/zinnia/character.cpp', needed by 'obj/third_party/zinnia/zinnia/zinnia.character.o', missing and no known rule to make it
Traceback (most recent call last):
File "build_mozc.py", line 1236, in <module>
main()
File "build_mozc.py", line 1223, in main
BuildMain(cmd_opts, cmd_args)
File "build_mozc.py", line 854, in BuildMain
BuildWithNinja(options, targets)
File "build_mozc.py", line 828, in BuildWithNinja
RunOrDie([ninja, '-C', build_arg] + ninja_targets)
File "/tmp/trizen-haruka/mozc/src/mozc/src/build_tools/util.py", line 99, in RunOrDie
'==========']))
build_tools.util.RunOrDieError:
==========
ERROR: ninja -C out_linux/Release mozc_server mozc_tool
==========
==> エラー: build() で問題が発生しました。
中止...
:: Unable to build mozc - makepkg exited with code: 4
原因は、.../src/mozc/src/third_party_zinnia
がからっぽ(Zinniaがない,
GitのsubmoduleとしてZiniaが登録されていない)からなので、ビルドが開始したところでCtrl+Zで停止して、
git clone 'https://github.com/taku910/zinnia/tree/master/zinnia'
rsync -r ./zinnia/ /tmp/trizen-haruka/mozc/src/mozc/src/third_party/zinnia/
って感じでZinniaつっこんであげれば良い。
uimのほうが反応がよくさくさく打てる一方、Fcitxの便利な機能は使えなくなるので微妙かもしれない。
よりレスポンスの速いアプリを選択
アプリそのものが素早いものを選択すると全体のエクスペリエンスがよくなる。
例えば、動画再生用にmpvを入れる、といったことだ。起動が早く、動作応答性も良い。 画像の場合、特に画像の数が非常に多いフォルダを開く場合にはViewniorやfehよりもXViewerが速い。
ウェブブラウザはレンダリングスピードなども関係してくるため、例えばSurfなんかが必ずしも快適になるわけではない。 w3mを使うという手もあるが、恐らくそれはそこまでエクスペリエンスをよくしない。
ドキュメントビューワーで速いのはEvince/XReader。よほど大きなドキュメントでない限り、僅かではあるがXReaderのほうが速い。 qpdfviewは便利な機能が載っているがそんなに速くない。
エディタに関しては標準でxedが入っているだけだけれど、Leafpadはぜひ入れておきたい。 エディタはどんなファイルを開くかによってだいぶフィーリングが変わるが、Leafpadが恐らく最速で開くことができ、大きいファイルに関してはVim/GVimで開くのが速い。Vim/GVimは常時動作も軽いので、軽快さ重視ならVimは良い。
メールクライアントで全面的に速いのはSylpheed。Claws Mailはそんなに速くない。
フォントは厳選
フォントに関しては別のページで検証しているけれど、本当に最小でいいのならばCicaだけ入れると大体話は片付く。
例えば
- Cica
- 源ノ明朝
- 源ノ角ゴシック
みたいな感じでクオリティの高いフォントをそれぞれひとつずつ入れれば片付く。
私の場合はもうちょっと色々入れてはいるけれども、それでも当該記事のレベルにとどめている。
PassmarkではRyzen3 3200Gは7820点もある。Xeon W3565は5780点。Core i3-9100は9095点。↩︎