Arch Linuxは難しくない。不必要な単純化をしないだけだ -Windows、Ubuntu、Debian、Gentooを経て、僕がArch Linuxを使い続ける理由-
要点
Arch Linuxは、上級者だけが使える難解なOSではない
利用者に都合よく構造を隠さない代わりに、高い透明性を保っている
そのため、仕組みを理解した後の管理は、むしろ単純で分かりやすい
Archの本質は、Linuxを管理する薄いレイヤーと、それを支える文化・コミュニティにある
最初から詳しい必要はないが、自分の操作に自分で責任を持つ必要がある
序
僕は2018年頃から、Arch Linuxを私生活のメインPCで使い続けている。
開発、ブラウジング、文書作成、動画、音楽、ゲームなど、仕事以外の用途はほぼArchで完結している。日常的な管理に使う時間は平均すれば1日5分程度で、大きなトラブルも年に1、2回あるかどうかだ。
Archに対しては、次のようなイメージがある。
インストールが極端に難しい
頻繁に壊れる
毎日長時間メンテナンスしなければならない
端末操作しかできない
ゲームや日常用途には向かない
難しいことをしたい人が使うOSである
しかし、僕の実感は逆だ。
Archは難しいのではない。 不必要な単純化を行わない代わりに、透明性を担保している。 ゆえに、むしろ簡単である。
この記事を読んで少しでも興味を持ったなら、インストール手順を解説する個人ブログを探す前に、まずArchWikiを開いてみてほしい。
Arch Linuxにたどり着いた理由
僕がArchを選んだ理由は、最新性、透明性、自由度、運用コストのバランスが最もよかったからだ。
僕が初めてPCを使ったのは、2000年頃だった。当時のOSはWindows 98で、その後も長い間、家ではWindowsを使っていた。
大学へ進学してから、数値計算のためにWSL上のDebianを使い始めた。研究室の端末はMacだった。先輩に教えてもらいながら、Ubuntu、Debian、Gentooなど、複数のLinuxディストリビューションにも触れた。
それぞれに長所はある。しかし、使い比べるうちに、機能の多さよりもOSが利用者をどのように扱うかが気になるようになった。
Windows
Windowsは、最初から多くのものがお膳立てされている。
普通に使うだけなら便利だが、少し細かいことをしようとすると、急に何が起きているのか分からなくなる。
設定がGUI、レジストリ、管理ツールなどに分散している
アップデートでUIや設定の場所が変わる
不要なアプリ、広告、おすすめ、クラウドへの誘導が増える
ソフトごとに異なるアップデーターが動く
管理者であるはずなのに操作を拒否される
原因が分からないまま自動修復される
いつの間にか設定が変わっている
セットアップ時にMicrosoftアカウントを要求されるようになったとき、僕の中でWindowsは完全に死んだ。
自分で購入したPCを使い始めるために、Microsoftとのオンライン上の関係を要求される。OSが利用者の道具ではなく、企業のサービスへ接続する入口になったと感じた。
macOS
macOSは、Windowsよりはましだった。それでも、Appleの流儀に従うことを強く求められる。
ハードウェアとOSが密接に結びついているため、端末の寿命をAppleに決められる。ソフトウェアの管理も、App Store経由のものと、それ以外の方法で導入したものとに分かれていく。
以前、管理者権限でコマンドを実行したにもかかわらず、エラーで拒否されるのではなく、実行結果だけがなぜか反映されなかったことがある。
できないなら、できないと明示してほしい。
操作を受け付けたように見せながら、裏側で無効化される。そのような環境では、何を信用して管理すればよいのか分からない。
Ubuntu
Ubuntuは、WindowsやmacOSよりも自分で制御できる。ただし、お膳立てや独自の管理層はまだ多い。
新しいソフトウェアを使おうとすると、外部リポジトリ、Snap、手動で導入したバイナリなど、管理経路が分裂しやすい。
Canonicalが用意した完成品としては優れているが、僕には少し余計なものが多かった。
Debian
Debianは透明性が高く、余計なこともしない。
一方で、基本的には枯れたソフトウェアを安定して使うためのディストリビューションである。
サーバーや長期間固定したい環境には適している。しかし、日常的に利用するPCで新しいソフトウェアを使いたい僕にとっては、無条件に古かった。
Gentoo
Gentooは非常に自由だ。
ビルドフラグを指定し、環境を細かく最適化できる。しかし、すべてをソースからビルドするのは、手間も時間もかかる。
汎用PCとして毎日使うには、自由度に対する運用コストが高すぎた。
Arch Linux
Archは、新しいソフトウェアへ素早く追従できる。
構成を自分で選べる。ブラックボックスが少ない。特定企業の製品戦略にも強く依存しない。
それでいて、Gentooのようにすべてをソースからビルドする必要はない。
Archは最も自由なLinuxではない。 日常的に運用できる範囲で、最も実用的に自由なLinuxだった。
Arch Linuxは「完成品のOS」ではない
Archの本質は、独自機能を大量に提供することではなく、Linuxと上流ソフトウェアを管理しやすくすることにある。
Linuxカーネル、デスクトップ環境、ブラウザ、オフィスソフト、開発ツール。
Arch上で動いているソフトウェアの大半は、Archが開発したものではない。外部の上流プロジェクトが作ったものだ。
Archが提供しているのは、それらを一貫した方法で扱うための、薄く洗練された管理レイヤーである。
その中心にあるのがpacmanだ。
カーネルも、ドライバも、デスクトップ環境も、ブラウザも、ライブラリも、基本的には同じパッケージ管理システムの上に載っている。
パッケージを検索する
導入する
依存関係を管理する
一括して更新する
不要になったら削除する
どのファイルがどのパッケージに属するか調べる
孤立したパッケージを見つける
キャッシュを管理する
必要なら以前のバージョンへ戻す
これらを、一貫した考え方で扱える。
僕は、pacmanを中心とするArchのパッケージ管理を、すべてのLinuxディストリビューションの中で最も優れた仕組みだと思っている。
AURは管理体系を外部へ拡張する
AURもArchの重要な要素だ。ただし、AURだけがArchの力の源なのではない。
AURは、公式リポジトリに含まれないソフトウェアも、PKGBUILDを通じてpacmanの管理体系へ載せる仕組みである。AURヘルパーを使えば、操作感としては公式パッケージに近い形で検索、導入、更新できる。
一方で、AURは公式リポジトリではない。
PKGBUILDの内容を確認する
配布元の素性を調べる
メンテナンス状況を見る
利用者数や評価を確認する
重要な構成を安易に依存させない
こうした判断は利用者自身が行う必要がある。
それでも、公式外のソフトウェアまで、管理可能なパッケージとして扱えることには大きな価値がある。
ArchはLinuxの上に別の世界を作らない
Archは、巨大な独自エコシステムをLinuxの上に構築しようとしない。上流のソフトウェアを、なるべく上流に近い状態で利用者へ届ける。
そのため、次の利点が生まれる。
ソフトウェアの公式ドキュメントがそのまま通用する
他のディストリビューション固有の改変に悩まされにくい
Arch固有の問題と上流の問題を切り分けやすい
新しい機能を早く利用できる
問題があれば上流まで遡って調査できる
上流へ問題を報告しやすい
Arch側の保守コストも小さくなる
Arch公式も、Simplicityを「不必要な追加や変更を行わないこと」と説明し、上流からの変更を最小限にする方針を掲げている。
ArchはOSというよりも、Linuxの管理層であり、文化・コミュニティそのものだ。
独自機能を増やさないことは、機能不足ではない。
薄いからこそ見通せる。薄いからこそ参加できる。薄いからこそ持続できる。
隠さないから、むしろ簡単である
Archの簡単さとは、クリック数が少ないことではない。原因と結果の間に、理解不能な中間層が少ないことだ。
WindowsやmacOSは、内部構造を隠すことで、表面的な操作を単純化している。通常の利用範囲なら、それでよい。
用意された設定画面を開き、用意された選択肢から選ぶ。OSが自動的に判断し、利用者が仕組みを知らなくても動くようにする。
しかし、用意された経路から少し外れると、途端に難しくなる。
どの機能が設定を管理しているのか分からない
状態がどこに保存されているのか分からない
誰がいつ変更したのか分からない
自動修復によって何が変更されたのか分からない
検索してもOSの世代によって手順が異なる
管理者であっても最終的な制御権を持てない
表面を単純に見せるため、裏側へ巨大で複雑な管理レイヤーが追加されている。
Archは反対に、不必要な単純化をあまり行わない。
設定は設定ファイルとして存在する
サービスはサービスとして存在する
エラーが起きればエラーが表示される
ログが記録される
パッケージとファイルの関係を追跡できる
ディレクトリ構造が比較的素直である
利用者の知らないところで勝手に状態を変えにくい
だから、問題が起きたときに見る場所がある。
ログを見る。設定ファイルを見る。サービスの状態を見る。パッケージの履歴を見る。直前に自分が行った操作を確認する。
原因がすぐには分からなくても、原因へ近づくための観測点が存在する。
Windowsでは、自分は管理者であっても所有者ではない。 Archでは、面倒も含めて自分が所有者である。
もちろん、Archなら何でも簡単に解決できるわけではない。
以前、デュアルGPUを搭載したノートPCで、内蔵GPUと外部GPUを適切に切り替えようとしたことがある。
ドライバ、描画環境、電源管理、メーカー固有の実装などが絡み合い、あまりにも複雑だったため、最終的には利用を諦めた。
Archが透明でも、ハードウェアやベンダー実装まで単純になるわけではない。
調べれば解決できることと、解決にかかるコストが目的に見合うことも別だ。
それでも、何が複雑なのかすら見えない環境より、複雑さが存在する層を特定できる環境の方が、僕には扱いやすい。
Archは普通のPCとして使える
Archは、インストールして眺めるための教材ではない。ブラウジング、開発、文書作成、動画、音楽、ゲームまでこなせる汎用OSである。
僕がArchを最初に導入したのは、2018年頃だった。当時は修士課程で、研究室に購入してもらったノートPCを使っていた。もともと入っていたWindowsを消してDebianを導入し、その後Archへ入れ替えた。現在も、一般的なx86_64ノートPCにArchをネイティブインストールしている。
用途は次のとおりだ。
ソフトウェア開発
Webブラウジング
LibreOfficeによる文書作成
動画・音楽の視聴
Google Drive上のファイル操作
Steamによるゲーム
ビデオ通話
日常的なファイル管理
その他諸々
仕事用PCは会社側の制約があるので別だが、私生活の汎用PCとしては、ほぼすべてArchで完結している。
XFCEを使う理由
デスクトップ環境にはXFCEを使っている。理由は単に軽いからではない。
GNOMEは、お膳立てが多く、エコシステムも巨大だ。一部を受け入れると、関連する仕組みもまとめて導入することになる。
KDEは高機能で見た目もよいが、やはり巨大な統合環境であり、重い。
XFCEは、必要な機能を部品単位で導入できる。
軽い
シンプル
不要なほどレガシーではない
特定の操作思想を強く押しつけない
必要な機能だけを追加できる
ウィンドウ管理のショートカットも自由に設定できる
タイル型ウィンドウマネージャーも使ったことはある。
開発作業には便利だが、ゲーム、ブラウジング、動画、ビデオ通話などを含む汎用PCでは不便な場面も多かった。
XFCEでもショートカットを設定すれば、必要な範囲でタイル型に近い操作ができる。
フローティング型を土台にしつつ、必要なタイル操作だけを足す。
これで十分だった。
ゲームもできる
Arch上ではSteamを利用している。
ArchWikiの標準的な手順に従い、必要な32bitライブラリなどを導入し、ファイアウォールも必要に応じて設定している。
最近遊ぶのはLinuxへ正式対応したタイトルが中心だが、Windows向けゲームもSteam内部の互換機能を介して動く。
FactorioはArch上で1,200時間以上プレイしている。
最新の重量級AAAタイトルや、特定のアンチチートに依存する対戦ゲームを中心に遊んでいるわけではない。そのため、すべてのゲームが動くとは言わない。
それでも、僕の用途ではゲーム環境として困っていない。
ゲームをするためだけにArchを選ぶ理由はない。 しかし、Archを使いたい人がゲームを諦める必要もない。
高価なPCも必須ではない
以前、3万円ほどで購入したジャンクPCへArchを入れ、数年間使っていたこともある。
ゲーム性能を求めなければ、標準的なx86_64 PCの多くは実用になる。
ArchやXFCEは、OS側の都合で大量のリソースを消費しない。
端末の寿命を、OS提供者の都合ではなく、自分の用途を満たせるかどうかで決められる。
特殊なハードウェアは別だ。
タブレットとの兼用
着脱式キーボード
タッチペン前提
メーカー独自の入力装置
一般的でないCPUアーキテクチャ
Apple独自ハードウェア
こうした構成では、個別の調査が必要になる。
最初に使うなら、普通のx86_64 PCらしいPCを選ぶのがよい。
環境は使いながら育っていく
Archの快適さは、最初から便利なことではなく、不満を自分で解消し、その結果を環境へ蓄積できることにある。
Archの価値は、特定の用途に強いことではない。
「これをやりたい」「ここをもう少し変えたい」と思ったとき、たいてい実現する方法が存在することだ。
例えば、僕はGoogle Driveをrcloneでマウントし、ローカルディレクトリに近い感覚で使っている。
以前は別のFUSEベースのクライアントを使っていたが、トラブルが多かった。利用者同士で情報共有しながらしばらく使った後、最終的にはrcloneへ移行した。
Google側で自分用のAPIキーを発行すると、速度も大きく改善した。
ほかにも、次のような変更を行ってきた。
GRUBからsystemd-bootへ変更した
AURパッケージのビルドを速めるため、一時領域をRAM上へ置いた
pacmanの並列ダウンロードが標準化される前から並列化していた
CtrlとCaps Lockを入れ替えた
サスペンドのためにカーネル起動パラメータを調整した
システム情報を素早く確認できる表示を追加した
ウィンドウ操作のショートカットを設定した
必要なときだけ呼び出せるターミナルを用意した
ファイアウォールを必要に応じて設定した
一つ一つは小さな変更だ。
しかし、過去に感じた不満と、そのときに行った判断が、少しずつ環境へ蓄積されていく。
Archの環境は、完成するものではない。 使いながら育っていくものだ。
興味深いことに、僕は環境を完全再現するためのスクリプトを管理していない。
パッケージ一覧も、細かなセットアップ手順も保存していない。
再インストールするたびに、その時点で必要なものを、必要な形で入れ直す。
結果として毎回似た環境にはなる。
しかし、それは以前の環境をコピーしたからではない。同じ人間が、同じ目的に対して、もう一度現在の判断を行った結果だ。
同じ環境を復元したいのではない。 今の自分に必要な環境を、もう一度作りたい。
重要なデータはクラウド側へ置いているので、基本的な環境は30分から1時間程度で再構築できる。
保存するべきなのは、必ずしも環境そのものではない。
環境を作り直せる知識と、失ってはならないデータである。
Arch Linuxは本当に壊れやすいのか
Archは理由もなく頻繁に壊れるOSではない。ただし、利用者が管理を放棄しても動き続けるOSでもない。
Archを使い始めた頃、何度か環境を壊したことはある。
グラフィックドライバ周辺の構成を壊した
更新中に電源が切れた
ストレージが物理的に寿命を迎えた
複雑なデュアルGPU構成を扱えず諦めた
しかし、これらの多くは、Archが突然自然崩壊したものではない。
設定を変更した。更新中に電源が落ちた。ハードウェアが壊れた。複雑すぎる構成へ手を出した。
ほとんどの場合、原因は説明できる。
安定運用に特別な秘術は必要ない
普段意識していることは、次のようなものだ。
更新を長期間ため込まない
どのパッケージが更新されたか確認する
設定ファイルの更新候補が生成されたら差分を見る
公式情報を定期的に確認する
ログと失敗したサービスを確認する
AURを重要な構成へ安易に使わない
バックアップを取る
更新中に電源を落とさない
平均すれば、日常的な管理は1日5分程度だと思う。
大きなトラブルが起きるのも、年に1、2回あるかどうかだ。
Archのニュースを毎日精読しているわけでもない。更新内容を軽く確認し、暇なときに公式サイトを見る程度で回っている。
Archは、放置すると壊れる。 しかし、使い続けていれば壊れない。
特に、長期間電源を入れないPCには向かない。
更新を大量にためると、キーリングや依存関係の問題で更新に失敗することがある。多くは再実行や先行更新で解決できるが、半年ぶりに起動して何も考えず使うような用途には適していない。
今すぐ使えるとは限らない
もう一つの欠点は、突然必要になったものを、必ずすぐに使えるとは限らないことだ。
時間をかけて調べれば、カメラ、マイク、会議ツールなども利用できる。
しかし、あと5分でオンライン会議が始まるときに、初めて接続したカメラが動かない可能性はある。
解決策が存在することと、今すぐ解決できることは別だ。
事前検証できない環境や、何を要求されるか分からない業務では、WindowsやmacOSの方が適することもある。
Archは万能ではない。ただし、その制約も含めて見通せる。
Archの自由とは、責任を引き受けることだ
Archを使うために必要なのは、最初からの高度な知識ではない。自分の選択と操作に、自分で責任を持つ姿勢である。
Archのインストールは難しいと言われる。
しかし、ArchWikiを読み、書かれている内容に従えば、インストール自体は終わる。
公式のインストールスクリプトも存在する。
それでも、僕なら初めて使う人には、Wikiを読みながら自分でインストールすることを勧める。
インストールだけを簡単にしても、その後の利用が簡単になるわけではないからだ。
運用を始めれば、次のことを自分で管理する必要がある。
ブート方式
ファイルシステム
ネットワーク
ユーザーと権限
サービス
デスクトップ環境
パッケージ
ログ
セキュリティ
手動インストールは、苦行でも上級者アピールでもない。
自分の環境が、どのような部品によって構成されているのかを知る最初の工程だ。
最初から、すべてを理解している必要はない。
極論すれば、最初は意味を完全に理解せず、Wikiに書いてあるコマンドを実行してもよい。
ただし、その責任は自分にある。
Archを使ううえでのすべての責任が自分にあること。
何かおかしくなったら、まず自分を疑うこと。
ここでいう「自分を疑う」とは、自分を責めることではない。
自分が選んだ構成、自分が実行した操作、自分が見落とした前提から、原因調査を始めるということだ。
Wikiが悪い
Archが勝手に壊れた
AIが出したコマンドだから自分に責任はない
メンテナーが初心者向けに解決すべきだ
このように考える人には、Archは向いていない。
Archの魅力は、単に自由であることではない。
自由に伴う責任まで、自分で引き受けられることだ。
AIはArchを簡単にするのか
AIはArchを使えない人を使えるようにするものではない。自分でもできる調査や作業の時間を短縮するものだ。
AIによって、Archの運用は以前より楽になった。
関係しそうなWikiページを探す
エラーから調査範囲を絞る
長いドキュメントを整理する
ログや設定を調査する
障害情報を収集する
パッケージの配布元や評判を調べる
方針が決まっている作業を実行する
こうした用途では非常に便利だ。
僕がAIを使う場面は、主に二つある。
何を調べるべきか、最初の仮説を作りたいとき
自分でもできるが、手作業の工数が大きすぎるとき
しかし、AIの回答が正しいとは限らない。
古い情報や、現在の環境に合わない手順、危険なコマンドを提示することもある。
最終的に実行するのは利用者であり、責任も利用者にある。
「AIがあるからArchを使える」のではない。
「できるけれど手間がかかること」の時間を短縮できるだけだ。
AIは参入に必要な能力をなくさない。
調査コストを下げるだけである。
Archはコミュニティによってできている
Archのコミュニティにある厳しさは、初心者を排除するためではない。無償の共有財を持続させるために必要な規範である。
Archの実体は、pacmanやパッケージだけではない。
ArchWiki
AUR
パッケージメンテナー
フォーラム
バグ報告
コメント
投票
上流への報告
利用者同士の情報共有
これらを支える文化まで含めてArchだと思う。
Archのコミュニティでは、次のような態度が求められる。
まずWikiを読む
自分で検索する
エラーやログを提示する
実行した操作や環境を説明する
要望を出すなら自分でも調査する
利用者だからといって、無条件に奉仕されるとは考えない
これは、技術者として当然の態度でもある。
オープンソースであることは、無料の商用製品であることを意味しない。
利用者は顧客ではない。メンテナーも、無償のサポート窓口ではない。
Archのような優れた環境は、相互の協力によって成立している。
貢献は大きなコードを書くことだけではない
全員が同じだけ貢献する必要はない。技術力も、使える時間も、人によって異なる。
それでも、何らかの形で循環へ参加することは必要だと思う。
例えば、次のようなことも貢献になる。
トラブルの情報を共有する
解決した結果を報告する
AURへ有益なコメントを残す
パッケージへ投票する
Wikiの誤りを修正する
ArchについてSNSへ投稿する
初心者へ分かる範囲で説明する
必要なPKGBUILDをAURへ公開する
上流へ問題を報告する
僕自身も、AURへPKGBUILDを公開したことがある。
問題があったパッケージへコメントしたり、Wikiを少し編集したりしたこともある。
大規模なソフトウェアを開発したわけではない。
それでも、貢献ではある。町内会のようなものだ。
全員が道路を舗装する必要はない。しかし、異常を報告する人も、掃除をする人も、新しい住民へ案内する人もいなければ、町は維持できない。
初心者は、まず使えばいい。
使いながら、自分が必要とする範囲を理解する。
Archの全貌など、開発者であっても把握していないだろう。
使う。理解する。気づいたことを返す。
この循環が、Archを支えている。
企業には再現しにくい
Archと同じ仕組みを企業が作ることは難しいと思う。
技術的に作れないという意味ではない。
企業がOSを提供するなら、普通は次のような独自性を入れたくなる。
自社アカウント
独自UI
独自サービス
クラウドへの誘導
おすすめ機能
他社との差別化
利用者データの収集
有料サービスへの導線
しかし、自我を出すほど管理レイヤーは厚くなり、上流から離れ、利用者から内部が見えなくなる。
Archは、自我を出さないことによって価値を生んでいる。
しかし、自我を出さない製品は、企業にとって収益化しにくい。
独自性を加えなければ商売上の旨味がない。
独自性を加えれば、Archのよさが消える。
この矛盾がある。
もしArchの公式プロジェクトが大きく道を誤れば、フォークや後継が現れるだろう。
なければ、自分たちで作ることもできる。
フォークできるからこそ、極端におかしな方向へ進みにくい。
企業の善意を信じる安心ではない。
離脱し、分岐し、思想を継承できることによる安心だ。
Arch Linuxに向いている人
Archへの適性は、現在の知識量よりも、分からないことに直面したときの態度によって決まる。
向いている人
エラーが出たら内容を読む
分からないことを検索する
Wikiや公式ドキュメントを読むことに抵抗がない
問題の原因を切り分けることを楽しめる
PCをブラックボックスとして使いたくない
日常的なPC利用から何かを学びたい
ITやコマンドラインに強い抵抗がない
自分の環境を自分で管理したい
自分の操作に責任を持てる
Archを使うことで、僕はLinuxの起動やサービス管理を理解できるようになった。
ログから問題を切り分ける癖がついた。ソフトウェアを、一枚の完成品ではなく、部品の組み合わせとして見るようになった。
ただし、個別の知識自体は、問題へ何度か直面すれば身につく。
一番大きかった変化は、次の確信を持てるようになったことだ。
調べて、理解して、手を動かせば、要求は実現できる。
トラブルは解決できる。
僕はもともと理論物理を学んでおり、理屈を考えることや技術的なものが好きだった。
Archがその性質をゼロから作ったわけではない。
しかし、物事の仕組みを理解する姿勢が、日常的なコンピューター環境の改善へ直接つながることを示してくれた。
同時に、そういう人をさらに育てる環境でもある。
向いていない人
PCは何も考えず動けばよい
OSの管理に時間を使いたくない
エラーやログを読みたくない
問題が起きたら提供者に解決してほしい
長期間PCを放置したい
特殊なハードウェア機能が必須である
WindowsやmacOS専用ソフトが主要用途である
突然必要になったものが即座に使えない可能性を許容できない
その場合は、WindowsやmacOSを使った方がよい。
僕も、特定の音楽制作アプリを使うためだけにiPadを持っている。
汎用環境を一つの専用ソフトへ合わせる必要はない。特殊な用途だけ、専用端末へ分離すればよい。
Archは万人向けではない。
しかし、「上級者向け」という表現も正確ではない。
Archに必要なのは、最初からの知識ではない。
調べ、理解し、その結果を自分で引き受ける姿勢である。
興味を持ったら、まずArchWikiを読んでほしい
Archを始める第一歩は、インストールコマンドをコピーすることではない。Archが何を目指しているのかを読み、自分でWikiをたどることだ。
この記事では、詳しいインストール手順は書かない。
コマンドを順番に並べた個人ブログを読めば、インストール自体はできるかもしれない。
しかし、そこで何を選択したのか理解していなければ、その後の管理で困る。
Archを試したいなら、できれば壊しても困らない余ったPCを一台用意してほしい。
仮想マシンには、仮想化固有のグラフィックやネットワークの問題が混ざることがある。
デュアルブートも、ブート周辺のトラブルを増やすので、最初の環境としては勧めにくい。
一般的なx86_64ノートPCかデスクトップへ、ArchWikiを読みながら導入するのがよい。
最初は、情報量の多い標準的な構成を選んでもいい。
ext4
一般的なUEFI構成
GRUB
NetworkManager
XFCEなどの一般的なデスクトップ環境
ただし、最終的には自分で説明を読み、自分で選んでほしい。
重要なのは、最初から完璧な環境を作ることではない。
自分で選び、自分で使い、自分で壊し、自分で調べることだ。
インストールが終わっただけでは、Archを運用できるとは言えない。
2、3回環境を壊し、自分で調べて復旧した頃に、ようやく自分の環境になる。
Windowsの代用品が欲しいだけなら、Archを選ぶ必要はない。
しかし、自分のPCで何が動き、なぜそう動き、いつ何が変更されたのかを理解したいなら、Archは唯一無二の選択肢だと思う。
Archは難しいのではない。
構造を隠さず、利用者へ責任を返しているだけだ。
その責任を引き受けられるなら、Archほど単純で、見通しがよく、安心して使えるOSはない。
自分のPCを、自分の管理下へ取り戻したい。
そう思ったなら、まずArchWikiを開いてみてほしい。
最初に読んでほしいArchWiki
Arch Linux
Archの概要と、Simplicity、Modernity、Pragmatism、User centrality、Versatilityという原則が説明されている。
Frequently asked questions
Archが向いている人、向いていない人、初心者に求められる姿勢、安定性に対する考え方などがまとまっている。
Installation guide
公式のインストールガイド。
短いが、各工程から詳細なページへリンクされている。コマンドだけを抜き出さず、リンク先も含めて読むことが重要だ。
General recommendations
基本システムをインストールした後、ユーザー管理、セキュリティ、パッケージ管理、デスクトップ環境などを整えるための入口となるページ。
System maintenance
更新、バックアップ、ログ、孤立パッケージ、設定ファイルの扱いなど、安定して運用するための基本がまとまっている。
pacman
Archの中核であるパッケージマネージャーの解説。
Arch User Repository
AURの仕組み、利用方法、注意点、コメントや投票、パッケージ公開について説明されている。