DebianをWindows10上で動かす その8: しばらく使った感想

前回はWindows Subsystem for Linux上にインストールしたDebian GNU/LinuxでGUIを使えるようにしてみました。

今回はこのWSL上でのDebian環境をしばらく使った感想を紹介したいと思います。

WSL導入について

Windows Subsystem for Linuxというと、その字面からいって難しそうです。

しかしインストールは驚くほど簡単でした。

今回はWindows Subsystem for Linuxを使ってWindows10にDebina GNU/Linuxをインストールしてみます。さすがに正式版の機能となっているだけあってインストールは簡単です。面倒なのはWindows Subsystem for Linuxを有効化するところだけでしょう。

PCにLinuxを入れる場合は、インストールイメージをダウンロード→ブータブルUSBメモリの作成→USBメモリでの起動・・・と初めての人にはなかなか大変です。

ところが、Microsoft Storeでディストリビューションを選ぶだけです。

Microsoftの本気を感じます。

よかった点

WSLを導入してみて良かった点をいくつか上げたいと思います。

起動時間の早さ

VirtualBox等の仮想PCを使う場合、使いたくなって仮想PCを起動するとそれなりに時間がかかります。

一方、WSLの場合はあっという間に立ち上がります。

これならばちょっとLinuxを使いたいという時にも躊躇なく使うことができます。

メモリ消費量の少なさ

WSLどれくらいのメモリを使っているかを正確に知ることは困難なのですが、VirtualBox等の仮想PCのように大量のメモリを消費するということはありません。

起動時の早さと合わせて、これもWSLを気軽に使える理由の一つです。

Linuxとの互換性

WSLはLinuxではなく、Windows上でLinuxカーネルの動作を模擬するエミュレータです。

エミュレータとなると互換性が心配ですが、各ディストリビューションが動くということは互換性が十分確保されているということでしょう。

実際にDebianを入れてみると、本物のLinuxを使っているかのごとくアプリの追加や削除ができました。

SSHでログインしたときなどは、カーネルバージョンを調べない限りわからないと思います。

残念な点

逆に実際に使ってみて感じた残念な点です。

ただしこれはWindows 10 Creator UpdateのWSLでの感想です。

2018年4月にはまたアップデートがあるということですので、状況は変わっているかもしれません

バックグラウンド動作ができない

WSLは起動するといきなりシェル(bash)が立ち上がります。

このため通常のLinuxのようにサーバプログラム(デーモン)を動かすことができません。

また、WSLを立ち上げたシェルを閉じてしまうと、全ての子プロセスもしんでしまいます。

せっかくLinuxを使っているであれば、WebサーバやSSHサーバなどの各種サーバを動かしたいところです。しかし、現時点ではWSLのシェルを立ち上げて手動でサーバプログラムを起動しなければ行けません。

しかも、そのシェルはずっとそのまま開きっぱなしにしなければ行けません。

せっかくLinuxを使うのですからサーバとして活用したいところです。

噂ででは2018年4月のアップデートでバックグラウンド動作が解禁されるそうなので楽しみにしていましょう。

ファイルシステムが不足している

Linuxといえば豊富なファイルシステムが特徴ですが、WSLのカーネルではその一部しかサポートしていません。

そのため、NFS等のLinuxでおなじみのファイルシステムが利用できません。これはその6で紹介したとおりです。

今回はWindows Subsystem for Linuxとネットワーク上にあるLinuxファイルサーバ間でファイルを共有する方法を紹介します。本当はWSLからファイルサーバのディスクをマウントして使う方法を模索していたのですが、残念ながら今のWSLでは見つけることができませんでした。現時点ではscpを使うのが現実的と思います。

現状でもWSLが動作しているWindows10とのファイル共有なら問題ないのですが、それ以外のネットワーク上の機器とファイルを共有するのはちょっと面倒です。

特に私はネットワーク上のファイルサーバにホームディレクトリがあり、これをWSLでもホームディレクトリとして使いたいと考えています。

しかし、

  • WSLがNFSをサポートしていない
  • WSLはいきなりbashが起動してしまい、その前にマウント処理ができない

という壁があり、実現していません。

実はこれがいま一番改善して欲しいことだったりします。

ディスクI/Oが遅い?

WSLではWindows10でのCPUがそのまま見えるようです。

そのため、演算などの処理はオーバヘッドがなくCPUの実力が出せるようです。

一方、どうもディスクの読み書きは早くはないようです。

WSLのファイルシステムからWindowsのファイルシステムに変換する処理が入るからでしょうか。

そのためファイルの読み書きが多く発生するコンパイル処理などは少し不満が出るかもしれません。

とはいえ、CygwinやMSYSよりは早いようです。

あるプログラムをコンパイルしたところWSLでは次のようになりました。

$ time make
real    3m0.415s
user    0m28.734s
sys     0m45.484s

一方、MSYS64環境では次のようになりました。

$ time make
real    3m42.490s
user    0m11.412s
sys     0m35.351s

処理時間としてはWSLの方が1.5割ほど早くなっています。

またCPUを使っていない時間(realからuserとsysを引いた時間)をI/O待ち時間とすると、I/O処理はWSLの方が1.5倍ぐらい速いことになります。

MYSYSを使うぐらいならWSLの方が良さそうです。

サポートしていないシステムコールがある

WSLはLinuxのカーネルの機能をWndows10でエミュレーションして実現しているわけですが、全てのシステムコールをサポートしているわけではないようです。

下記にLTPというLinuxのテストをするシステムでWSLを評価した結果が掲載されています。

Following the release of Windows Subsystem for Linux, the development team has created and released a series of technical deep dive blog posts. For a better und...

細かい内訳はわからないのですが、システムコールのうち73.81%カバーしているという結果のようです(Creator Updateの場合)。

私が試したなかではメッセージキュー(mq_open等)を使ったプログラムが、メッセージキューの作成に失敗して動作しませんでした。

自分が使おうとしているプログラムが、サポートしていないシステムコールを使っているのかどうか、というのは実際に動かしてみないとわかりません。

今後のWSLのアップデートでさらに互換性が上がるのを期待しましょう。

まとめ

今回はWindows Subsystem for Linux上に導入したDebian GNU/Linuxをしばらく使った感想を紹介しました。

インストールはとても簡単で起動も早いなどのメリットがあるのですが、ネットワークファイルシステムが使えなかったり、バックグラウンドで動作させられなかったりと実運用では難しい面もあります。

4月に予定されているWindows 10の大型アップデートで改善することを期待したいところです。

次回はiOS 11.3について紹介したいと思います。