Intel の Clear Linux ディストリビューションは、その不釣り合いに高いベンチマーク性能により、最近多くの注目を浴びています。 このディストリビューションは Intel によって作成および管理されていますが、AMD も、最高のスコアを得るために、新しい CPU のベンチマークを Clear Linux で実行することを推奨しています。
最近 Phoronix で Michael Larabel が Threadripper 3990X システムを 9 つの異なる Linux ディストロを使ってテストしましたが、そのうち 1つが Clear Linux で、Intel のディストリは他のテスト対象のディストロに比べて 3倍の 1位の結果を獲得しました。 すべてのテスト結果を 1 つの幾何平均にまとめると、Larabel は、このディストリビューションの結果が、テストした最も遅いディストリビューション (CentOS 8 および Ubuntu 18.04.3) より平均 14% 高速であることを発見しました。 ここで扱われていない疑問は、日常的なドライバーとして Clear Linux を実行するのはどのようなものか、ということです。 5876>
Clear Linux のインストール
インストールは他のオペレーティング システムとほぼ同じで、ISO をダウンロードし、サムドライブに保存し、起動し、実行します。 テキストモードのみの「サーバー」と、フル機能のライブデスクトップ環境を使用する「デスクトップ」の 2 種類のインストーラーが利用可能です。 私たちはデスクトップを選びました。 しかし、KVM 環境では、「failed to pass pre-install checks」というあまり役に立たないエラー メッセージが表示され、インストールが拒否されました。
少しオンラインで調査したところ、Clear Linux のライブ デスクトップ環境は BIOS モードで起動するが、実際の OS は UEFI を必要とするという事実が判明しました。 私たちの仮想化環境 – Ubuntu 19.10 の Linux KVM – では、最終ステップで「インストール前に設定をカスタマイズする」をチェックし、[概要] タブで BIOS から UEFI に変更しない限り、新しい VM は BIOS モードがデフォルトとなります。 そこで、VM を破棄し、適切な UEFI ファームウェアで再作成し、レースに出発しました。
VM のファームウェア・アーキテクチャを修正したら、Clear Linux の VM へのインストールは実際のハードウェア、すなわち、UEFI ファームウェアを備えた実際のハードウェアと同じくらい簡単なものとなりました。 BIOS モードしかサポートしていないレガシーなハードウェアに Clear Linux をインストールしたいと思っているのなら、それは無理でしょう。
インストーラーは明快でわかりやすいものです。 言語 (現在は非常に限られたリストから) とインストール先を選択し、新しい OS 用のユーザー名とパスワードをインストーラーに入力する必要があります。 また、QA や開発目的のために使用される電話による家庭の遠隔測定を許可するかどうかを知らせる必要があります。
インストール目標を設定する際、Clear Linux は「安全」なインストールか「破壊的」なインストールのいずれかを提案します。 私たちは安全なインストーラーをテストせず、利用可能な唯一のオペレーティング システムとして Clear Linux をインストールしました。
一度オプションを選択すれば、実際にインストールするには合計数分もかからないはずですが、一旦離れて戻ってくると、スクリーン セーバー ロック画面が起動するかもしれないことを覚えておく価値があります。 (Gnome3 に慣れていない場合は、クリックして上にドラッグするとロック画面が解除されます。)
インストール後の話です。 GIMP レース
ほとんどの場合、Clear Linux で従来のパフォーマンス ベンチマークを行うことにあまり意味はないように思えました。 Phoronix はすでに多くのベンチマークを行っており、そう、疑いなく、Clear Linux はほとんどのディストロより平均して速いのです。 しかし、ベンチマークで勝つことと速く感じることは必ずしも同じではありません。
比較のための基準、つまり、監視されたタイマーや真っ向勝負のレースがなければ、ほとんどの人は、身近なタスクを完了するのに33%以下の差しか感じないでしょう。 典型的な観察者（実際に時間を計っていない人）は、1時間の作業を40分で終わらせることに直面すると、「あれ、速いな」と思うでしょう。 同じ観察者が、1 秒のタスクの完了を待っているとき、一般に 1,300 ミリ秒あたりで顔をしかめ始めるでしょう。
また、Phoronix のベンチマークの大部分は、長時間かかる計算またはストレージ タスクに焦点を当てていることを指摘する必要があります。 この種のベンチマークは、ディストリビューション レベルでのソフトウェアの変更よりも、ハードウェアの変更によく相関します。 つまり、デスクトップ パフォーマンスに関連するタスクで Clear Linux のベンチマークが速くても、その差はデスクトップまたは特定のアプリケーション パッケージ自体の違いに簡単に打ち消されてしまうかもしれません。 最初の感覚を試すために、Ubuntu 19.04 ワークステーション自体でも GIMP を開き、Mississippi を数えてみたところ、Ubuntu デスクトップは Clear デスクトップの 2 倍の速度であることが判明しました。 人間の感覚はこんなものでしょうか？ その理論を検証するために、私は Ubuntu 18.04.4 VM と Clear Linux VM を並べて起動し、それぞれに 4 つの vCPU と 4GB の RAM が割り当てられました。 そして、両方のVMにNTPデーモンをインストールし、クロックを互いに1ミリ秒以内になるように設定し、独自のwhenitsスケジューリング・ユーティリティをインストールしました。 それぞれに同じリソースが割り当てられているにもかかわらず、Ubuntu 18.04 VM は依然として手堅く「勝利」しました。
さらに調査したところ、Ubuntu 18.04 は Clear より古いバージョンの GIMP を使用していることに気づきました。 そこで、Ubuntu VM からシステム提供の GIMP 2.08 をアンインストールし、最新の 2.10.14 (Clear が使用しているのと同じバージョン) を PPA からインストールしたのです。 結果は大きく変わりませんでした。GIMP は依然として Ubuntu VM で速く開き、その最後の「競争」の結果を、上の短いビデオクリップで横に並べて見ることができます。 しかし、人間の知覚の誤りや、「速い」ディストロがデスクトップ システムの通常の日々の操作に実際にどれだけの影響を与えることができるかの限界を実証しています。 ブートは別として、Clear Linux は、Ryzen 3700X ワークステーション上でホストされた VM でも、私が直接インストールした i7-6500U を搭載した Dell Latitude でも、一般的な使用において Ubuntu より明らかに速いとは感じられませんでした。 しかし、友人がすぐに気づいてヨダレを垂らすようなスピードアップを期待すると、おそらく失望するでしょう。
ソフトウェアのインストール
Ubuntu 19.10 と Clear Linux は、ソフトウェアのインストールと削除の GUI として Gnome Software Center を共に使用します。 Ubuntu のソフトウェア センターでは、Clear Linux にはないエディターズ ピックや注目のアプリケーションが目立つように配置されています。 たとえば、ゲーム Frozen Bubble はどちらのディストリビューションでも Software Center で入手できますが、Clear では flatpak として提供され、サード パーティのソース dl.flathub.org.
Ubuntu では Frozen Bubble はサード パーティではなく Canonical 自身の Universe リポジトリから提供されています。 しかし、Clear Linux ではインストールに 10 分近くかかったのに対し、Ubuntu では Canonical 独自のリポジトリから数秒しかかからなかったのです。
Will it Chrome? 実際にダウンロードされるのは Ubuntu ネイティブの .deb ファイルで、ブラウザ自体をインストールするだけでなく、リポジトリ リストも自動的に更新されるので、それ以降、Chrome は Ubuntu によって自動的に更新されます。 Clear Linux のコマンドラインから .rpm ファイルをダウンロードし、展開してインストールし、フォントの表示が変にならないように手動で再設定するという、ちょっとしたトリックがあります。
広告
残念ながら、Chrome は Ubuntu や他のほとんどのデスクトップ ディストリビューションのように自動的に更新されませんが、自分で更新することを覚えて、そのたびにコマンドラインで同じいくつかのステップ（フォントの再構成を含む）を踏まなければなりません。
パッケージ管理
もちろん、上級ユーザーは、どちらのディストリビューションでも、まずソフトウェア センターを気にすることはないでしょう。 Ubuntu は Debian ベースのディストリビューションであり、apt コマンド ライン ツールを使用してインストール、更新、削除、および検索を行うことができる .deb パッケージを使用します。 Clear Linux は apt や yum、zypper、pacman、pkg などの聞いたことがあるようなものは使いません。 その代わり、swupd と呼ばれる独自のコマンドライン パッケージ管理ツールを使用します。
ほとんどの部分において、swupd は他のパッケージマネージャと同様に動作します – パッケージをインストールする引数があり、パッケージ名/説明や含まれているファイルによってパッケージを検索する別のカップル、といった具合です。 残念ながら、私は swupd を一貫してイライラさせられると認めざるを得ません-特に、引数が冗長で奇妙な表現になっています。
Debian, Ubuntu, Fedora, OpenSUSE, CentOS, あるいは FreeBSD では、新しいアプリはリポジトリから <packagemanager> install <package> – たとえば apt install gimp – インストールするものでしょう。 しかし、swupdでは、代わりにswupd bundle-add <package>となります。 同様に、bundle-remove、bundle-list、bundle-info といった具合です。
これは些細で小さな違いに聞こえるかもしれませんが、私はかなり不愉快だと思いました。 例えば、bundle-add の代わりに add-bundle と間違えて入力するなど、不慣れなパッケージマネージャを使うときよりもずっと頻繁に構文を間違えてしまうのです。 たとえば、Ubuntu では uuid-dev に、Fedora では libuuid-devel にある特定のヘッダーのセットが必要だとわかったとき、Clear Linux では代わりに os-core-dev にあり、それを見つけるのは非常に厄介でした。 swupd search uuid を試しても os-core-dev のバンドルはまったくリストされず、私が必要とする実際のファイルを swupd search-file uuid.h で検索してもダメでした。 (このトピックについては後で詳しく説明します。)
swupd は動作しますが、これは NIH シンドロームの結果に酷似しているように感じられます。 Intel は、Clear Linux の秘密のソースの多くはパッケージにあると主張しており、おそらく純粋に独自の管理ツールをゼロから構築する必要があったのでしょう。
Will it ZFS?
Clear Linux で OpenZFS が動くかどうかを気にする人はそう多くはないでしょう。 しかし、私は間違いなく気にしており、この特定のドラゴンを追いかけるのに膨大な時間を費やしてきました。 しかし、「ただのラップトップ」であっても、ZFS の高速非同期レプリケーション、暗号化されたビットロットの検出と修復、インライン圧縮の使用、その他諸々の機能なしには、何もしたくありませんでした。 Clear Linux ZFS」で検索すると、Clear の FAQ にすぐにたどり着き、「ZFS は Clear Linux OS では利用できません」と述べ、代替手段として btrfs を提供しています。
Btrfs は ZFS とほとんど同じ機能を提供しますが、残念ながら、データヒーリングを備えた冗長アレイ、高速レプリケーション、インライン圧縮といった最も興味深い機能を実際に使用すると、急速に信頼性が低下していきます。 (実際、Synology や Netgear の ReadyNAS のような商用 NAS デバイスは btrfs を使っていますが、LVM や mdraid の上に重ねていますし、そうするのにはそれなりの理由があるのです。 詳細は Debian の wiki を見てください。また、Red Hat が RHEL 7.4 で btrfs を完全に非推奨としたことにも注目してください)
Clear Linux FAQ は、ユーザーが ZFS バンドル を要求して却下された古い Github issue も紹介しています。 別のユーザーは、署名されていないカーネル モジュールを動作させる手助けを求め、今は亡きリンクを経由していくつかのドキュメントへのポインタを取得しました。 web.archive.org でデッドリンクされたドキュメントのコピーを見つけましたが (その後、Clear Linux プロジェクトのメンバーが現在のバージョンへの更新リンクを提供してくれました)、それでも私が行くべき場所にはたどり着けませんでした。
linux-lts-dev バンドルは簡単にインストールでき、また、署名なしモジュールをロードするためのカーネル設定ファイルを作成できました。 しかし、LTS カーネルに切り替えることは必要で、ネイティブ カーネルは OpenZFS の公式サポートには少し最先端すぎたため、よりやっかいなことになりました。 カーネルのインストールは簡単でswupd bundle-add kernel-lts2018、しかし、Clear Linux を実際に起動させるのは、ちょっとした悪夢でした。
The distribution has not keep its boot management configuration in any place that a experienced *nix user might look for them –/boot、/etc/default、grub に関するものなど、あらゆるものに存在します。 私は実際の設定データの場所を見つけられませんでしたが、最終的には Clear Linux ユーザは clr-boot-manager というツールを使ってブート環境を操作することが期待されていることが分かりました。 残念ながら、clr-boot-manager set-kernel org.clearlinux.lts2018.4.19.103-113 と clr-boot-manager update (これは次の起動時に使用するカーネルを選択するはずです) はまったく何もせず、いろいろつつき回して、再起動し、uname -a を実行し、それでも 5.5 カーネルがかなりの時間動いているのを確認しました。 今度は再起動した後、カーネルリストが表示され、4.19 LTS カーネルを手動で選択しました。 これで、uname -a が 4.19 カーネルで動作していることを示し、ZFS をコンパイルする準備ができました！
問題は、残念ながらまだ終わっていませんでした。 OpenZFS のソースの tarball をダウンロードして展開し、chdir その中に入って ./configure を実行したところ、エラーが表示されたのです。 uuid/uuid.h missing, libuuid-devel package required. 残念ながら、swupd には libuuid-devel バンドルはありませんし、libuuid、uuid、uuid-dev、uuid-devel、あるいはそのほかのものもありません。 swupd search uuid と swupd search-file uuid.h のどちらも、有用な結果が得られるはずなのに、何も得られませんでした。
最後に、私は ZFS on Linux tracker で新しい課題をオープンし、誰かが Clear で ZFS を実行したこと、あるいは、自分で猿回しするのに必要な configure スクリプトに関する情報を得られるかもしれない、と期待しました。 Brian Behlendorf は OpenZFS の Linux 移植版の創立者であり、オールラウンドなナイスガイですが、その答えも知りませんでした。
しかし、Brian は最終的にパズルを解くヒントをくれました。 つまり、1 つの swupd bundle-add os-core-dev 後/configure と make install は両方とも正常に完了しました！
私が直面した残りの問題は、カーネルに挿入するモジュールへのパスを指定できる単純な Linux カーネル モジュール (LKM) 操作コマンド insmod が依存関係を解決せず、insmod /path/to/zfs.ko ではエラー unknown symbol で失敗したということです。
少し悩んだ末、結局、ZFS の package.ko ファイル (/lib/modules/extra 以下の個々のディレクトリにある) へのシンボリックリンクを /lib/modules 自体に直接ダンプすることにしました。 これで modprobe zfs が動作し、実際に Clear Linux 上で ZFS が動作するようになりました。 ハズレ！
これで ZFS は機能するようになりましたが、まだ紙一重のところがありました。 zpool と zfs コマンドは /usr/local/sbin にあり、Clear Linux のデフォルト PATH の一部ではありませんでした。 また、ZFS モジュールがブート時に自動的にロードされるように設定されていませんでした。 これらの残りの問題は、幸いにも解決するのはかなり些細なことです。 パスの問題を解決するには、PATH を更新して /usr/local/sbin を含めるか、ユーティリティを /usr/local/bin にシンボリックリンクします。 起動時に ZFS をオートロードするには、ディレクトリ /etc/modules-load.d を作成し、ファイル /etc/modules-load.d/zfs.conf を作成して、zfs.
このボサボサ話は ZFS 自体についてではなく、もっとよく知られたディストリビューションでは比較的簡単な問題が Clear Linux では大きな痛手になるという事実について話しているのです。 もちろん、この種の問題はすべて解決可能ですが、もしあなたが、自分自身や後に続く人たちのために問題を解決する努力の一部になりたいと思わないなら、日常的に使うものとして Clear を避けるべきでしょう。
良い点
- Clear Linux は、世界最大かつ主要なコンピュータサイエンス企業のひとつである Intel に支えられています。 安全であること、高速であること、正しいことをすること
- ほとんどのものがほとんど、あるいは全く手を加えることなく動作する
- The Fastest Linux In The West を手に入れることに執着しているなら、このディストロはそのためのものです-Arch と Gentoo ユーザーには申し訳ありませんが
- “This is Linux ! これは Linux だ!”
The bad
- ほとんどのものは調整しなくても動くが、ほとんどのユーザはすぐにそうでないものを欲しがる
- Intel の
swupdパッケージ管理ツールは不恰好で不毛、そしてすべてのパッケージを適切にインデックス化しない - ユーザはとても少なく、助けを求めていると過去へのタイムトラベルのように思える (DenverCoder9 あなたは誰でしたか ?) 。
The ugly
- Clear Linux は、少なくとも今のところ、広範囲で汎用的な日常使用よりも、実行速度が絶対的に重要な単純作業の繰り返しに適している
。