Arch Linux の日本語コミュニティである Arch Linux JP Project では ArchWiki を始め、英語の Arch Linux ドキュメントの日本語への翻訳を行っていますが、今年から ArchWiki に加えて3つの翻訳プロジェクトを立ち上げたのでお知らせします。

• Arch Description Translation Project
• Arch Linux マニュアルページ
• Arch Linux カーネルドキュメント

Arch Description Translation Project

簡単に説明すると Debian の Debian Description Translation Project の Arch Linux 版で、Arch Linux の公式リポジトリに含まれているパッケージの説明文の翻訳活動です。

Arch Linux のパッケージは本家サイトのパッケージ検索ページで検索することができ、同じデザインの検索ページを日本語サイトでも備えています。ただし、ミラーサーバーの pacman データベースからパッケージデータを作成しているため、本家サイトよりも情報が少なく、特にバージョンが上流と比べて古いかどうかを示す out-of-date フラグは本家サイト特有の情報となっています。

また、ドイツ語の Arch Linux コミュニティサイトである archlinux.de には本家とはまた異なる優れたインターフェイスの検索ページが搭載されています ¹。

日本語ウェブサイトにも何か特有の機能があると面白いと考えて、Debian で活発に行われているパッケージ説明文の翻訳 ² に肖って archlinux.jp のパッケージ検索ページに説明文の翻訳を表示する機能を組み込みました。

翻訳作業自体は pacman の翻訳にも使われている Transifex をベースとしています。1週間ごとに週末にまとめて新しいパッケージの説明文ソースを更新、それまでに翻訳された説明文をウェブサイトに取り入れる仕組みとしています。日本語以外の翻訳も可能で、パッケージ検索ページではブラウザの言語に合わせて適切な翻訳文が表示されます。

パッケージの数では膨大なコミュニティによって支えられている Debian に軍配が上がりますが、ユーザーが投稿できる AUR から頻繁にパッケージが上げ下げされる Arch Linux には他のディストリビューションにはないソフトウェアパッケージを見かけることもしばしばあります ³。

新しいソフトウェアを見つけるときの土壌として、検索ページを活用していただけるといいかなと思います。また、Transifex のアカウントがあればすぐにプロジェクトに登録して投稿できるので興味があれば是非翻訳にご協力お願いします。

Arch Linux マニュアルページ

私は2012年頃から ArchWiki の翻訳作業に途中参加させていただいており、2013年〜2014年の間は本家の英語版から1日以上文章が古くならないように丸2年間更新を続けていましたが、2015年からは逐次的に更新しています ⁴。

理由のひとつとしては英語版の4211ページに対して1602ページと、中身の質とカバー率についてはともかく全体的に進捗が進んで一段落したこと、私事の仕事の負担が高まり取れる時間が少なくなったことがあります。がそれらの些細な理由よりも、英語版と日本語版の性質の違いが大きかったです。

特にここ最近の傾向として英語版は整理整頓を題目にリファクタリングが頻繁にかけられています。原文ソースである英語版の文章の作業量はさほど大きなくても (セクションの入れ替えやページの結合・分散自体は MediaWiki の力を借りれば簡単)、比較を行いつつ整合性を取って追従する作業は2倍・3倍になります。さらになんとか追従した1週間後にあっさり変更がリバートされると心が折れました。

また、リファクタリングの一環として ArchWiki の対象とする物事を絞って、インターネット上に他の英語ドキュメントがある場合は ArchWiki から文章を削除するという作業がかなり進みました (大きいところではビギナーズガイドをまるっと削除など)。確かに英語視点ではドキュメントの整理整頓ですが、参照先のドキュメントに日本語版がないことも多く、そのまま追従すると欠損に近くなり判断に迷ってしまい手が遅くなっていきました…。

前者は能力不足を認めざるをえないですが、後者については前向きに捉えてインターネット上のドキュメントの日本語版をさらに翻訳対象とできないか考え、特にマニュアルページの存在を元に記事の内容が削られることが多いため、Arch Linux の全マニュアルページの日本語版の作成を開始しました。

こちらのプロジェクトも Arch Description Translation Project における Debian Description Translation Project と同じくお手本があります。本家 ArchWiki の管理者が作成しているマニュアルページ集です ⁵。日本語版となる Arch Linux マニュアルページではウェブページとしての利用価値を重視して Sphinx で作成しました。ArchWiki と同じく、幅広く翻訳していきたいと思いますが、最初は Arch Linux に関連するページを先に手がけていきます。

Arch Linux カーネルドキュメント

マニュアルページと同じく、Linux のカーネルドキュメントも ArchWiki から頻繁に参照されているドキュメントです。同じ Sphinx で作成できるということで、マニュアルページのおまけ程度でカーネルドキュメントの日本語版のページを作成しています。

Arch Linux マニュアルページでは最終的に特に選抜をせずに全ページを訳すところを目指したいですが、こちらは主に ArchWiki からリンクされているドキュメントだけを選び取って訳す形になるかと思います。

奥付

上記のプロジェクト立ち上げに伴い、ArchWiki に投入できる作業量は更に減少する予定です。日本語版の ArchWiki の古さに眉を顰めている読者の方がいれば、編集に参加していただると幸いです ⁶。

堕落的な私でも2年間は全ページを英語版と同じ最新状態に維持できたことから分かる通り、非常に簡単な作業です。ちょっとやる気がある人なら容易にできるはず。一日の終わりに英語版の最近の更新を見て、一日分の編集を反映させるだけで終わります ⁷。

編集に直接参加する形が億劫であれば、どこかおかしいところを見つけて意見・提案していただけるのも大感謝です ⁸。

脚注

日本語の Arch Linux ウェブサイトを開始して、もうすぐ二年目、Arch Linux でサイトを稼働させるようになって一年になりますが、今後新しいことをするためにサーバーを移転しました。

• 旧 IP : 153.126.164.237
• 新 IP : 160.16.119.98

サーバーの本格的な移転作業は昨日行いましたが、再起動を行ったり設定の変更をしたりで一時ウェブサイトに繋がらない時間帯がありました。ご迷惑をおかけしたことを謹んでお詫びします。新しいサーバーも Arch Linux で稼働しています。

今はまだ旧 IP アドレスでもアクセスできますが、そのうちアクセスできなくなる予定です。旧サーバーではメモリが 512MB しかなかったためリソース不足が理由で色々出来なかったことも新サーバーではやってみたいです。

サーバー増強で出来るようになったこととして、ArchWiki に Elasticsearch による検索機能を導入しました ¹。日本語による検索が貧弱だったのが改善されたはずです。

今後ともよろしくお願いします。

4年ぶりにメイン PC を新調しました。特に強いモチベーションがあったわけではありませんが、Steam に Linux 対応タイトルが拡充されつつあるので、ある程度ゲームを遊べるスペックを選択。比較的新しいパーツで無難なところに落ち着きました。

勿論 Arch Linux をすぐインストール。久方ぶりで Wi-Fi に手間取りました。使用しているドングルが NetworkManager でないと接続できなかったので結局有線で。それ以降は数十分でインストールできました。

設定

UEFI や SSD の構成は初めて。が特に躓くところはありませんでした。ブートローダーは systemd-boot を使用。SSD なので TRIM や IO スケジューラを設定して、後は WD の IntelliPark を無効化 (公式リポジトリの idle3-tools を使用)。

グラフィック環境は特に変更なし、そのまま移行しました。いい加減 Wayland に環境を変えないといけないと思いつつも、今のところ選択肢は (デスクトップ環境をインストールしないのであれば) Sway か Weston しかないような。後で。

ドライバーは GTX 1060 に対応しているプロプライエタリドライバーで。KMS サポートしているのは好印象だけど pacman フック使うと警告が出る (無害)。プロジェクターに接続するのに多少手間取りましたが問題なし。

メモリが 16GB あるので、Firefox のキャッシュなどはできるだけメモリを活用するように設定。スワップは一応作成しましたが、swappiness は最小値で。

周辺機器

高揚感にまかせて周りのデバイスも一新しようと一緒に購入。別段何か設定しなくても動作しています: G300s (マウス), Steam Controller (コントローラ), Realforce91UG-S (キーボード), Nexus 5X (スマートフォン)。

Bluetooth ヘッドホンも快調 (BT-MicroEDR1 + JBL E40 BT)。

感想

ARK: Survival Evolved がクラッシュして遊べません😔。Undertale は動いたからいいや。

Slack の方では発表していたのですが、正式な記事にはしていなかったので今更ながらこちらでも報告します。

今年に入ってから、archlinuxjp.org の全てのサービスはさくらの VPS を借りて Arch Linux で動作しています。去年まではレンタルサーバーを借りていました。手元のデスクトップ PC ではずっと同じ環境をローリングし続けているので、正味数年ぶりの Arch Linux インストール作業でしたが、ウェブ上の様々な記事を参考にしてなんとか移行できたという形です ¹。

これまでは CloudFlare を通して HTTPS 接続できるようにしていましたが、Arch Linux でサーバーをたてるのにあわせて本家サイト (archlinux.org) でも使われている Let's Encrypt を使用するようにしました。CloudFlare では、はてなブックマークで登録したときに、ページがちゃんと取得されていなかったのですが、Let's Encrypt では問題なさそうです (移行前までにブックマークされたページは更新されてないようですが)。

また、一時 ArchWiki で 502 エラーが頻発する問題に悩まされていましたが MediaWiki から APCu を利用しないように設定したら収まったようです。現在、ウェブサイトには月間で15万〜20万 PV のアクセスがあります。本家サイトみたいに長期にわたって安定させて、「Arch Linux はウェブサーバーにも使えるんだ」という一例になることを目指したいと思います。今後とも、どうぞよろしくお願い致します ²。

ウェブサイトの次の目標としては、パッケージの説明文を翻訳できるようにしたり ³、archweb サイトの開発をもっとやりやすいように拡充とか、中国やフランスの Arch コミュニティのようにカスタムリポジトリを作成して日本語関連のパッケージを入れたり、なんて考えています。

原文: Help Vampires: A Spotter’s Guide

ヘルプバンパイア (Help Vampire) はあらゆるオンラインコミュニティで存在を確認できます。それが親しいところであれ縁遠いところであれ。

彼ら吸血鬼はヘモグロビンで呼吸する代わりに、人々の命とエネルギーを吸い取ります。他者を助けるのが好きな人々を食い物にして、精根尽き果てさせてしまうのです。

彼らは邪悪な怪物ではありません。ヘルプバンパイアという存在です。生きとし生ける物なら誰でも持っている基本的な衝動、食欲本能に従って行動しているにすぎません。それに、自分がヘルプバンパイア状態になっているということすら気づいていないことが多い。だから、あなたが手に持っている杭は下ろしてください。

上記の観点から、ここではヘルプバンパイアの体質改善・再教育についての情報を提供し、さらにヘルプバンパイアを見分けて捕捉する方法も教授していきます。この文章を読み進めるうちにあなた自身がヘルプバンパイアだと気づいたら、どうすればバンパイアの牙を制御することができるか理解してください。

ヘルプバンパイアの見分け方

ヘルプバンパイアを見分けるのにはコツがいります。一見すると普通の人のように見えるので。だけど、以下の簡単なチェックリストを使って個々人のふるまいをよく観察することで、世に蔓延るヘルプバンパイアを識別できるようになると思います:

• 何度も場にあがっているような同じ質問を繰り返している（しかも頻繁に）
• 全知全能の Google 様にたずねようとは全然しない、あるいはそもそも検索する方法がわかっていない
• 質問をするときにどうしても明瞭で具体的にしようとしない
• 助けていただいているというか、助けてもらって当然というふしがある
• まるで質問に答える側が Ruby on Rails を使う理由を証明しなくてはならないかのように怒り出す
• 彼が考えていることをすべてやってくれる人を待ってるのが明らか（自分から動こうとしない）
• 質問しておきながら答えをもらったことに何も反応しない、彼の代わりに他人がしたことに感謝すらない

他にヘルプバンパイアだとわかるものとして、明確ではあるけれど「答えられない」質問をするというのもあります。見掛けはもっともらしい質問に思えるのだけれど、答えられない理由が色々あったりするのです。例えば、「掲示板を作るにはどうすればいいですか？」あるいは「チャットサイトの作り方を教えて欲しい」といった質問。こんな質問をする目的は以下の三つ：

• 第一に、答えられない質問に答えようとする哀れな犠牲者を見つけるため
• 第二に、犠牲者をコミュニティから離反させるように誘導するため
• 最後に、犠牲者の頭を混乱させて、その間に魂をストローで抜き取るため

以上は自律的に行われます。繰り返しますが、ヘルプバンパイアを責めてはいけません。杭も同様。吸血鬼たちは自分たちが何をしているのかわかっていません。彼らはただそうせざるを得ないだけ。きっと救う手立てはあると私は信じています。

ヘルプバンパイアの狼煙

コミュニティから有用性がなくなってきているなら、それはヘルプバンパイア問題の兆候にほかありません。外からみるとコミュニティが人で賑わっていて活発なようでも、近づいてみると全ての会話が浅いところで留まっていて、ちょっと難しい質問になると途端に会話が途切れているようなら、ヘルプバンパイアが来襲している可能性が高い。

ヘルプバンパイアはインターネット上の流浪の民です。彼らはコミュニティに活気や知性を嗅ぎつけるとすぐ移住してきます。そこにある食べ物を食い尽くしたところで（もう何も期待できないと感じて）離れていき、残されたコミュニティは干上がってしまうのです。

吸血鬼たちのロマのような行動はコミュニティを次々と破壊し、たとえヘルプバンパイア問題が通りすぎてもコミュニティが生き返ることはありません。「最も聡明な人々」はまともな会話ができなくなることを悟ると、ヘルプバンパイアが来ない「壁に囲まれた庭」のコミュニティに逃げていきます。閉ざされたコミュニティはヘルプバンパイアの毒牙から守られますが、ヘルプバンパイアではないユーザーも遠ざけることになるのもやむを得ません。こうしてコミュニティからベテランがいなくなり絶望的な状態になります。

もしもあなたがヘルプバンパイアなら

分かったら止めよう。もちろん、それは簡単ではないし、誰もヘルプバンパイアになりたいなんて思ってないのは分かります。

コミュニティで質問をする前に、どこか別のところで答えが得られないか試行錯誤しよう。自分を広げることになるし探索能力の向上にも繋がります。物事をさらに深く学べるかもしれません。それに、自らおこなったことはいつかきっと自分に返ってくるはず。

どんなときでもまずは王道から：

1. トラブルシューティングを諦めない。自分で調べるよりも匙を投げて誰かに助けを求める方が楽なんじゃないかと思ってしまうこともよくありますが、そんなときこそ、あと十分間だけ頑張ってみれば突破口が得られたりするものです。自分に自信を持って、もう少しだけ足を伸ばしてみよう。
2. Google を使う。エラーメッセージの一部を Google で検索したり、ソフトウェアの名前を検索キーワードに追加してください。無駄だと諦めてしまう前に最低でも三回か四回は検索してみましょう。
3. メーリングリスト・フォーラム・ニュースグループ。おそらく、同じ問題に出会ったことがある人が地球上に何人かいるはずです。幸運にも私達が生きている時代は過去を検索することができます。先人が残してくれた痕跡を調べてみましょう。
4. ドキュメント。たとえ難解でとても読むことができそうになくても、試してみる価値はあります。理解を深めれば深めるほど、ドキュメントも簡単に理解できるようになるでしょう。
5. 質問をする。ただし今までとは違った問い方で。直接的に質問をするのではなく、「誰かこんな問題にであった人はいませんか？」あるいは「私の方向性が正しいか確認していただけますか？」と聞いてみよう。おそらく、以前からいた誰かがブログ記事などの役に立つ情報を知っていて、それが光明になるはず。これなら、コミュニティの時間に敬意を示していることになるし、抱えている問題が（たぶん）一人だけではないことがわかる。

質問をするときは、できるかぎり詳しい情報を提供するようにしてください。他人が質問しなくてもいいように、まずは自分自身に以下の質問をするのです:

• 使っているソフトウェアのバージョンは何か？
• 使っているオペレーティングシステムは何か？
• 何をしようとしていて何ができないのか？
• 何度も問題がおこるのかときどき発生するのか？
• エラーメッセージは何か？
• いつ問題が発生したのか？
• 何が分からないのか？
• サンプルコード、特にエラーが発生する箇所を示すことはできないか？

可能であればコードサンプルはすぐに提示できるようにしておきます。そして、IRC チャンネルで会話するときに、コードサンプルを pastebin に貼り付けてください。プロジェクトの一部のコードを投稿するときは、コメントを付して分かるように。コードを何も知らない人が見ても理解できるように簡単な説明を付けるべきです。

ヘルプバンパイアを改心させる

コミュニティ内のヘルプバンパイア問題を解決したいのであれば、以下のように行動すれば良い結果が得られるでしょう:

1. ヘルプバンパイア（や普通の人々）が自立して物事を解決できるように資料を作成する。
2. ヘルプバンパイアが吸血する糧になるようなことを全て止める。
3. ヘルプバンパイアに正面から立ち会う。

一目瞭然ですが、暴力を肯定するようなことは全くありません。杭も、キックボクシングも、聖水も必要ありません。機知に富んだ言葉のやり取りだけです。

#1: 資料の作成

コミュニティの資料があっちこっちに散らばっていて、まとまっておらず、鼠の巣よりも難解になっている場合、しっかりとしたヘルプ資料を作成することでヘルプバンパイアの活動は劇的に減ります。

最低限、以下のことが明確に書かれている、読みやすいページを作成するべきです（それがコミュニティによって編集されていればさらに良い）:

• FAQ。見せかけだけではない、本当のよくある質問集。明瞭な言葉遣い、そして質問に対して何をするべきかという情報が書かれている。
• 最新のエラーリスト、あるいはソフトウェアの最新版で引っかかる可能性が高い問題のリスト。
• 有用な資料のリスト。トピックごとにまとめられていればベスト (例: “インストール”, “デプロイ”, “サードパーティのアドオン”, “初心者用のチュートリアル”, “上級者向けのチュートリアル” など)。
• シンプルなコミュニティガイドライン。何が適切なのか知ってさえいれば、ほとんどの人（ヘルプバンパイアも含む）は適切に振る舞うものです。

資料のページは一つのページにまとまっているのが好ましいでしょう。情報を検索するのが楽になり、検索エンジンを使わなくてもよくなります。

#2: 糧を与えるような行為を止める

次に、ヘルプバンパイアをヘルプバンパイアのままにしておくようなことをコミュニティから排除しましょう。

自活させる。たとえ親切心からだとしても、よくある質問に直接答えるのは絶対に止めてください。質問者を助けることにはなりません。相手を怠惰にさせてヘルプバンパイアを増長させるだけです。返信するにしても、答えが書かれている URL を教えるだけにとどめます。ただし、バンパイアが自分で調べてそれでもまだ答えが見つけられないのであれば喜んで助け舟を出すと伝えてください。

思考力を育てる。たとえ毎日五十回はされている質問でなかったとしても、直接に解決方法を答えてはいけません（質問者がバンパイアではなく真の探求者とわかっている場合は別）。質問には自分で考えるように激励する（あるいは道筋を示す）ようにしてください。ヘルプバンパイアがどうしても自分で考えようとしない、また、不満を述べるようであれば、資料となるページの URL を与えて、それ以上の介助は保留しましょう。

自助努力や他人の手助けをしていたら褒める。先に自分で調査をして、賢い質問をした人、あるいは他人を助けようと努力した人には礼を言いましょう。コミュニティの誇りだと伝えてください。特に、積極的に自分を変えようとしている人には惜しみない賛辞と絵文字を。助け合いはトリクルダウン経済です。

親切心を持つ。傲慢な態度を取るのではなく、誠意と激励を持って接すれば、人々やヘルプバンパイアがコミュニティの貴重なメンバーになるやもしれません。何も知らない無知な人々のように見えても、あなたの気概は伝わります。

#3: ヘルプバンパイアに正面から立ち会う

「君はヘルプバンパイアだ」。鋤を鋤と、ヘルプバンパイアをヘルプバンパイアと率直に呼びます。バンパイアな生き方を改めるならばコミュニティのメンバーとして歓迎すると伝えましょう。また、バンパイアとは何なのか教えてあげてください。

優しく、厳しく。ヘルプバンパイアを叱るのは無意味です。自分がヘルプバンパイアであることを悟るまでどうしようもないからです。バンパイアを苛めることは野生動物に餌付けをするのと似ています。ヘルプバンパイアが強情で腹を立てたとしても、冷静に #2 を守るようにしてください。

どうしようもない場合は淘汰する。少数ながらヘルプバンパイアの中には、自分には世話を受ける権利があると考えていて、他人の欲求を満たそうという気は毛頭ないという人もいます。平静に、あらゆる改善策を試して、最後は無視するようになっても、バンパイアが治らない場合……コミュニティから放逐してください。永遠に交流を断つということです。

よく Arch と Gentoo は並べられることが多い。「初心者向けではない」といった文句で両者が使われるのをよく見る。そういう文章を読むとまるで兄弟みたいだけど、実態は違うのではないか？

そこで、様々な数字を使って比較をしてみます。まず、数字で分かるのは優劣ではなく、あくまで両者の性質が違っているということです。ディストリビューションは所詮色々なソフトウェアの寄せ集めというだけで、どれかが特別に優れているとかは全くないと思います。ただ、人によって好みが別れるだけです。

そして、筆者は Gentoo を使ったことがない (そして Arch 一筋) ので、Gentoo に関する記述は基本的に伝聞で眉唾であること、そして、一応分かりやすく数字を出しているが、単純に比較できない数字もあることに注意してください。

年齢

Arch: 13歳 vs. Gentoo: 13歳 (先代の Enoch も入れると16歳)

開発年数は同じです。どちらも2002年の3月に最初のバージョンがリリースされました。Arch が3月11日で Gentoo が3月31日なので、わずか20日分だけ Arch が年長となります。

誕生してからの知名度については、上の Google トレンドでわかるように最初は Gentoo が圧倒的に有名でした。段々と Gentoo が落ちていって、2011年のあたりで入れ替わっています。

人気度

Arch: 739 vs. Gentoo: 271

DistroWatch の各ディストリビューションのページのアクセス数による値です。Arch が倍以上多くの人に注目されている計算になります。

他に、定量的なディストリビューションの人気度を計算していたサイトとして DistroRank があります。こちらは大分前にサイトが消えており、かなり古いデータになりますが、検索エンジンの検索結果などの数字からランクを算出していました。

パッケージの数

Arch: 13634 vs. Gentoo: 18746

パッケージ数は Gentoo の方が5万ほど多くなっています。最初に単純に比較できない数字があると書きましたが、パッケージ数がまさにそれです。パッケージの数え方というのはディストリビューションによって大きく変わってきてしまいます。Gentoo では USE フラグによって実際のパッケージの中身を変幻自在にできる一方、Arch では普通、中身を変えるときは別のパッケージを作ります。

非公式なリポジトリとして Arch には AUR が、Gentoo には Overlay がありますが、Arch の AUR は半公式的存在で Arch のサーバー上でホストされているのに対し Overlay はそうではありません。ただし、Gentoo は Overlay を管理するツールが公式リポジトリに入っています。

どちらも Git ベースです。AUR は最近 AUR4 に移行して、メンテナのいないパッケージは削除され半数以上にパッケージが減っています (つまり今 AUR にあるパッケージは基本的にメンテナがいる)。Gentoo は公式リポジトリが新しく CVS から Git に移行して、GitHub でもホストされるようになりました。

パッケージマネージャのコマンド数

Arch: 61 vs. Gentoo: 111

Gentoo はパッケージマネージャが一つではありません。Portage 以外に Paludis と Pkgcore が存在します。その時点で、いわゆる Arch の "KISS" と Gentoo の "choice" の違いが分かる気がしますが ⁴、数字は Portage のものです。

pacman にはメインコマンドの pacman 以外に makepkg などが存在し、Portage には emerge 以外に repoman などが存在します。総じて、Portage は pacman よりも複雑ですが様々なことができ、逆に pacman は Portage よりも簡素ですが出来ることは限られるでしょう。

対応アーキテクチャ

Arch: 2 vs. Gentoo: 12

Arch は i686 と x86_64 しか対応していません。しかもエイプリルフールでしたが i686 の対応をやめるというアナウンスもありました。Arch Linux ARM はコミュニティによる移植です。i586 や PowerPC、MIPS などのアーキテクチャへの移植もありましたが、開発中止しています。

対して、Gentoo は公式であらゆるアーキテクチャをサポートしています。対応しているのは amd64, i486, Alpha, ARM, HPPA, IA64, PowerPC, PowerPC, S/390, sh, SPARC, MIPS です。既に開発・生産が終了しているアーキテクチャもあります。ハードウェアのアーキテクチャだけでなく FreeBSD など他のオペレーティングシステムへの移植も活発です。

パッケージのバージョンが最新である割合

Arch: 62% vs. Gentoo: 28%

ソフトウェアの上流 (開発元) と比べてバージョンがどれくらい違うのかを調べていた OSWatershed (今はサイト停止しています) からのデータです。Arch は大抵1週間以内に最新バージョンにパッケージがアップデートされています (カーネルなどの重要なパッケージは別)。

Arch Linux は他のディストリビューションと違って Out-of-Date フラグというのがウェブサイトに存在します。上流よりバージョンが古いとメンテナに通知できるシステムです。つまり、基本的に Arch Linux のパッケージは最新であることが保証されています。これは AUR も同じです。バージョンを古いままにしておくなら何らかの理由が必要とされます。ただの怠惰ならメンテナが変えられます。

また、Arch ではサポートが切れたソフトウェアはリポジトリから排除されています。例えば GTK+1 は公式リポジトリから AUR に移動されました。Gentoo では GTK+1 も含まれています。

開発者数

Arch: 35人 vs. Gentoo: 238人

Gentoo の方が大所帯で、Arch とは桁が違います。パッケージの数ほどの違いはないため、Arch の方が一人で大量のパッケージを管理できているということであり、逆に Gentoo では一つのパッケージに多くの労力が割かれているはずです。開発者の変動は両方とも去年と比べて微減か横這いでした。

ちなみに Arch も Gentoo も創始者は既にコミュニティから去っており、Gentoo の Daniel Robbins は Microsoft に移籍して Funtoo を興し、Arch の Judd Vinet は Google に移籍するふりをしてチアリーダーになりました。

ユーザーベースの規模を示す値としては、他に Arch と Gentoo に共通して存在する Wiki とフォーラムのユーザー数で比較ができます。ただし、コミュニティの場についてはそれぞれの規定が違うため単純な数字比較は難しく、また Gentoo の Wiki は作成されたのが最近です。フォーラムのユーザー数・投稿数は Gentoo の方が多く、Wiki のユーザー数・編集数は Arch の方が多いようです。ただし双方とも十分に巨大です。

Linux カーネルにあてられるパッチ

Arch: 1 vs. Gentoo: 8

Arch は出来る限りパッケージにはディストリビューション特有のパッチは適用しない方針です。確か前はカーネルのパッチは3つあったはずですが、いつの間にか1つにまで減っていました。Gentoo にはパッチがあてられていないカーネルの vanilla-sources がありますが、開発者からのサポートはありません。

Arch にあたっているパッチはデフォルトのログレベルを変更する一行のパッチです。gentoo-sources に適用されるのは様々なバグの修正や (Gentoo のデフォルト init である) OpenRC 対応のパッチなどのようです。

昔は Arch には Linux カーネルのパッケージが公式リポジトリに一つしかなく選択肢が存在しませんでしたが、近年になって長期サポート版の linux-lts を初めとして linux-grsec や linux-zen が追加されています。Gentoo は亜種としてセキュリティが強化された hardened-sources などが用意されています。

Arch のパッケージをパッチをあてない方針はあまり注目されないスローガンですが、基本的にパッチは上流でマージさせるべきで、それを出来るだけ早く下流で使えるように頑張ることがディストリの役割だということで、Arch の根本をなす大事な考えです。逆に Gentoo には初めからパッチをあてるのを支援する機構そのものがパッケージマネージャに組み込まれているのは重要な違いだと思います。

あとがき

この記事は Arch Linux Advent Calendar 2015 第二日目 (大遅刻) の記事です。カレンダーは突発的に作ってしまったのですが ²、他の方にも参加登録して頂けて感激しています。

数字による比較は前から暖めていたネタで、Arch と Gentoo の比較でソースコードベースとバイナリベースを説明するなんてもう何億何千万回もされているでしょうから他の方法を使いたかったのです ³。パフォーマンスのベンチマーク比較は Phoronix でよく見ます。Arch や Gentoo というディストリビューションではそういった計測結果はほとんど意味がないと思うので ¹、メモリ使用量の比較などはここでは載せませんでした。

ただ、下調べ不足で、パッケージ数については実際に入っているソフトウェアの数で比較とか、ソフトウェアのジャンルごとの数で比較とか色々やりたかったアイデアはありました。けど大変なので諦念。

脚注

Arch Linux 自体は非常にメジャーな Linux ディストリビューションですが ¹、実際に Arch が開発環境として何を生み出してきたのかはあまり知られていないと思います。その要因として、Arch の Arch Way では「あくまでディストリビューションは上流で開発されたソフトウェアをそのままの品質で利用できることに注力するべき」という方針が取られていることがあるでしょう。一般的な他のディストリビューションと違って ²、Arch では標準セットとして付属しているソフトウェアがとても少なく、配布形態が『素の Linux + パッケージマネージャ(pacman)』となっています。Arch Linux を使って素晴らしいソフトウェアを開発したからといって、インストールメディアに同梱されるわけではないわけです。

ディストリビューションにはそれぞれ、その土壌から生まれた (そして他のディストリでも重宝されている) 素晴らしいプロジェクトがあります。例えば、Fedora なら今や全ての Linux の共通 init となった systemd があるし、SuSE には革新的なスナップショット管理ツールの Snapper があります ³。どちらも、生まれる元になったディストリビューションの影響を色濃く受けています。

そこで、この記事では Arch Linux 発祥のプロジェクトを紹介することで、Arch Linux の素質やユーザーベースを知る手がかりとしたいと思います。

Archey ⁴

Linux のスクリーンショットのスレッドではお馴染み。あのディストリビューションのロゴを表示するスクリプト。元は Arch Linux で開発されている ⁵。画面上にシステム情報を表示するソフトウェアといえば、Gentoo 界隈で開発された Torsmo (今の Conky) が有名だが、それに対する Arch Linux のカウンターパートとして Archey があるということでいいかと。ちなみに、Arch には AA を表示するプログラムが他にも揃っており、例の牛さんを表示する cowsay や唄うポニーの ponysay がある。

MATE ⁷

おそらく、Arch Linux 以外でよく使われている一番有名なプロジェクト。ベーシックな機能をほどよくまとめたツールキットである GTK+2 とかなり地味なウィンドウマネージャ Metacity によるクラシカルなデスクトップ環境として人気があった GNOME 2 のフォーク。いわずとしれた GNOME 3 へのバージョンアップによる使い心地の大規模変更によって色々と不満が出たところに ⁸ 颯爽登場した。非常に好感を持って受け入れられたプロジェクトで、多数のディストリビューションで採用された。しかしながら、安定版が出ていないという理由で Arch Linux の公式リポジトリに追加されたのは他のディストリビューションより大幅に遅れて最後列になった ⁹。Arch Linux 由来らしく、最新の環境への対応に執心していて、デスクトップ環境で Bluetooth を使うための Blueman の Bluez 5 対応を率先したりしている。今集中しているのは GTK+3 への移行 ¹⁰。

AzPainter/AzDrawing ¹²

日本で開発されているペイントソフト。元々は Windows 用のソフトウェア (Windows 版は現在開発終了)。Painter はイラスト描画向けで、Drawing は線画描画向け。Wine での動作に多少の難がある SAI などのお絵かきソフトの代わりとして Linux でネイティブに使える。作者の当初の開発環境は Ubuntu ベースだったが2014年から Arch Linux に移している ¹³。SuSE 筆頭の KDE として Krita があり、Fedora 筆頭の GNOME に GIMP があるように、Arch ユーザーが生んだ代表的なペイントソフトとなることを期待 ¹⁴。

profile-sync-daemon ¹⁵

tmpfs で Firefox を高速化するスクリプト ¹⁶ が元になった、ブラウザを一気に軽くするデーモン。通称 psd。Fedora や Gentoo では公式リポジトリに含まれているが、本家 Arch では AUR に入るに留まり、公式リポジトリ入りは果たしていない。出自は Arch Linux なのだが。systemd の各種デーモンなど ¹⁷、新しい機能を取り入れるのが早い Arch で開発しているので、当然、overlayfs を使うなど先進的な機能を揃えている。

pacman ¹⁸

最後に真打登場。Arch Linux の屋台骨を支えるパッケージマネージャで、依存関係を解決するなど単なるパッケージマネージャというだけでなく、PKGBUILD から簡単にパッケージを作成して、それを AUR で共有できるというインフラまで含めて pacman の与するところは大きい。DNF や Portage などのパッケージマネージャが Python で書かれているのに対して、pacman は C で書かれている。パッケージマネージャ本体の拡張性や抽象性・全能性は劣るが、それゆえに理解がしやすくて軽快に動作するのが特徴 ²²。他のプラットフォームへの移植もされていて、GNU Hurd や FreeBSD、Windows の pacman が存在する。どの移植も一定の評価を得ていて ¹⁹、FreeBSD の方は ports コレクションに入っており ²⁰、Windows 版の MSYS2 は様々なところで利用されている。Windows で GTK をビルドするときは MSYS2 の使用が推奨されていて、GTK を使っている Firefox を MSYS2 でビルドするという計画もあるらしい。もはや Arch ユーザーにとっては空気みたいな存在だが ²¹、今でも活発に開発は継続している。次のバージョンの pacman 5.0 では長らく待たされていたフック機能が搭載されるとのことで期待大である ²³。

その他 ²⁴

• catwm - シンプルなタイル型ウィンドウマネージャ
• infinality-bundle¹¹ - フォントレンダリングを改善する fontconfig の設定集
• sway - Wayland 用の i3 のようなウィンドウマネージャ
• KeePassC - curses ベースの KeePass パスワードマネージャ
• Alopex - もふもふなタイル型ウィンドウマネージャ
• PyTyle - 手動タイルマネージャ
• bmpanel - 軽量なパネル
• monsterwm - モンスター級のウィンドウマネージャ
• jumanji - ウェブブラウザ
• uzbl - Unix 哲学に則ったブラウザ
• PCManFM-Mod (現 SpaceFM) - マルチパネルのファイルマネージャ
• subtle - タイル型ウィンドウマネージャ
• zathura - PDF ビューア
• luakit - Lua + WebKit = ウェブブラウザ

失念していたプロジェクトを以下に追記 (12/3)

• Papyros - マテリアルデザインのデスクトップ環境。Arch から派生したオペレーティングシステム ²⁷ 用のデスクトップ環境であるが Arch でも使える。非常に期待していたのだが、クラウドファンディング詐欺 ²⁶ で一時的に開発停止していた。
• netctl - ネットワーク設定ツールで netcfg の後継。数少ない Arch で公式に開発されているツール。Arch 以外の環境で使われている事例は知らない。

Arch から離れて別のディストリビューションとして結実した成果物は Arch ベースのディストリビューションを参照。初心者向け、ハッカー向け、DJ 向け、視覚障害者向けなど多数。

脚注

この記事は Arch Linux Advent Calendar 2015 第一日目の記事です。予想以上に記事を書くのに労力 ²⁵ を取られたので (ArchWiki を更新できなかったし)、もう書きません。

mikutter

Arch との蜜月な関係を誰でも知っているソフトはここでは扱わない。