Crostini、WSL、Linux GUIアプリ対決

現在プレビュー中のWindows 10に搭載されているLinux環境WSL（Windows Subsystem for Linux）では、LinuxのGUIアプリを起動することが可能になった。もちろん、プレビュー版のWindows 10でしかいまのところ動作しないが、早ければ今年秋のアップデートで通常版に入る可能性がある。

LinuxのGUIアプリケーションは、ChromeBookのLinux環境（Crostiniと呼ばれる）では、すでに対応しており、Chromebookのアプリケーションエコシステムの拡大に寄与している。WSLは、昨年夏にLinux GUIアプリケーション対応を発表はしたが、ようやくプレビューが開始されたところ。この機能はWSLgと呼ばれ、X Window SystemとWaylandに対応したLinuxのGUIアプリをWindowsのデスクトップにウィンドウとして表示することが可能になっている。アプリのインストールは、WSL2側で行うが、インストーラーが行うメニュー登録などの機能を利用して、Windowsのスタートメニューに起動アイコンを登録できる。

Crostiniもこのあたりは同等で、Linux側でインストールしたLinux GUIアプリは、Chromebookのラウンチャーに登録され、アイコンから直接起動ができる。WSLgやCrostiniの概要については、すでにいろいろとニュースや記事があるので、それを参考にしてほしい。

このWSL2/WSLgとCrostiniをざっと比較したのが（表01）だ。比較は、筆者が思いついた項目で行っている。総論的にいえば、多少の違いはあるものの、いまのところどちらも同程度で、どっちが優れているとも言い切れない感じである。このため、Crostiniがいいのか、WSLgがいいのかは、結局、Chromebookがいいか、Windows 10 PCがいいかという話になりそうだ。

WSLgとcrostini、基本的な仕組みはほぼ同じ

WSLgもcrostiniも仮想マシンとコンテナー技術を使ってホストOSの上にLinux環境を実現している。Windowsの場合は、まったく違うプラットフォームなので、仮想マシンが必要になるが、Chromebookの場合には、ホスト側もLinuxカーネルを使う。しかし、ChromeOSは、OS自体へのアクセスが制限されており、セキュリティを低下させないため、仮想マシンを使って、ChromeOS自体とは分離させている感じがある。

どちらも、Linuxの実行環境、いわゆるディストリビューションに相当するものは、コンテナー技術を使ってインストールしている。crostiniは、LXCを使ってLinux環境を「パッケージ」化している。これに対して、WSLgは、配布形式にMicrosoftストアの標準形式であるAppxを使い、Linuxディストリビューションを仮想ハードディスクファイル（vhdx）ファイルにインストールする。

比較の詳細

簡単に比較項目について解説しておく。なお、評価はWSLgが「Windows 10 Build 21382」、ChromeOSが「90.0.4430.218」である。また、WSLgは、Linux環境としてUbuntu-18.04をインストールして利用、crostiniは、標準であるDebian 10（buster）だ。表の作成にあたり、基本的には、動作を確認した。

まずは、ファイル関連の機能だが、基本的には、どちらもホスト側とのファイル交換は可能だ。WSLgでは、標準でWindowsのCドライブが「/mnt/c」にマウントされた状態となる。また、ホスト側（Win32側）からは、「\\wsl$\ディストリビューション名」という仮想的なネットワークホストを介してLinux側のファイルシステムにアクセスができる。これに対して、Crostiniでは、ホスト側の「ファイル」アプリでフォルダーを「Linuxと共有」することでLinux側の「/mnt/cromeos」からアクセスが可能になる。ホスト側からは、同じくファイルアプリで「Linuxファイル」を開けばユーザーのホームディレクトリが見える。

ネットワークも、特に設定なく利用できる。ただし、仮想マシン内なので、どちらも仮想ネットワークに接続しており、ホストとは違うIPアドレスが割り当てられている。Linux環境側でWebサーバーなどを立ち上げ接続待ち状態にしたときには、ホスト側からlocalhostでLinux側に接続できるようになっている。

デバイスアクセスだが、まず、サウンド機能は、WSLg、crostiniともに出力、入力が可能。これは、自動的に設定されるので、ユーザーは特に何もする必要がない。しかし、Webカメラは、内蔵、外付けともに、WSLg、crostiniではLinux側からアクセスができなかった。

crostiniは部分的にUSBデバイスに対応

USBデバイスに関しては、WSLgは未対応、crostiniでは、特定のタイプのUSBデバイスのみLinux環境で利用が可能だ。Chrombookの「設定　⇒　デベロッパー　⇒　Linux開発環境（ベータ版）　⇒　USBデバイスを管理する」（写真01）に表示されたデバイスのみがLinux側で利用できる「可能性」がある。ChromebookにAndroidスマートフォンをUSB接続して、アプリケーション開発用のadbコマンドを使うことは普通に行える。これは、AndroidのUSBデバッグ接続（ADBと呼ばれる）に関しては、すでに対応が完了しているからだ。

• 写真01: Chromebookの「設定　⇒　デベロッパー　⇒　Linux開発環境（ベータ版）　⇒　USBデバイスを管理する」には、一部のUSBデバイスが表示され、Linux側での利用をオンオフできる

しかし、USBメモリを接続すると、前記の設定ページにUSBメモリが表示され、Linuxでの利用を許可することができる。Linux側ではlsusbやlsblkコマンドでは、USBメモリに相当するデバイス（写真02）が見えるがマウントすることはできなかった。crostiniの場合、chromeOSの下で仮想マシンterminaが動作しており、その中にlxcコンテナー（標準ではpenguinという名前）がある。前記の設定では、仮想マシンterminaはUSBメモリを認識しており、/dev/sdaというブロックデバイスが割り当てられている（写真03）。lsusbやlsblkで見えるのはこれなのであろう。しかし、lxcコンテナーには/dev/sdaへのアクセスが許されていないため、crostini内のLinuxではマウントができなかったようだ。ただ、USBメモリに関していえば、ChromeOS側でマウントし、これをLinux側と共有することができるので、実質アクセスは可能で、crostini側でマウントしなければならない必然性はない。

• 写真02: USBメモリをLinux側で有効にする設定をしたとき、crostiniのコンソールではUSBデバイスの一覧を表示するlsusb、バルクデバイス（ストレージデバイス）の一覧を表示するlsblkコマンドでみると、USBメモリを認識しているように見える。しかし、/devには、USBメモリに相当するsda（デバイス）やsda1（パーティション）が見えない

• 写真03: crostiniは、仮想マシンterminaの中でLXCコンテナーが動作する。仮想マシンterminaへは、croshからvshコマンドでアクセスができる。ここは、crostiniのLinux環境の「親環境」に相当するところ。ここでは、USBメモリは/dev/sdaとして認識されているが、LXCコンテナーは、これにアクセスする設定になっていないようだ

WSLgは、USBデバイスには対応していないが、Linux側でも仮想マシン支援機能が利用できる。WSLgでは/proc/cpuを開いてCPUの機能を調べると、仮想マシン支援機能であるvmxやsmxが表示されるが（写真04）、crostini側は未対応のようだ。このためWSLgでは、KVM（Kernel Virtual Machine）が利用でき、QEMUなどが利用できる。ただし、このためには、Windows側でNested VM機能が有効になっている必要がある（もちろんCPUが対応している必要もある）。

• 写真04: WSLg/WSL2では、Nested VMが利用できるCPUで、これが有効になっているなら、WSL2内で仮想マシン支援機能が利用でき、たとえばKVMが動作できる。/proc/cpuinfoを見るとプロセッサの仮想マシン支援機能があることを示すVMXという文字列が出る

こんな感じで、WSLgとcrostiniは、ほぼ互角という感じである。どちらも純粋なLinux環境とは違う部分があるものの、dockerが動作したり、GPUが利用できるなど、かなり「本物」に近いところまで来ているといえる。ただ、crostini自体はまだβ版扱いであり、GUIに対応しないWSL2は正式版にはなっているものの、GUIアプリ対応のWSLgは、プレビュー版のWindowsでしか動かない。Linux、Android、Web系の開発には十分利用できそうなので、開発系の方はそろそろ検討してみてもいいかもしれない。