2019/04/13 更新
Windows10 バージョン1809 (October 2018 Update)で再インストールしたので、それに合わせて記事を見直しました。
前回はWindows Subsystem for Linux上にインストールしたDebian GNU/LinuxでGUIを使えるようにしてみました。
今回はこのWSL上でのDebian環境をしばらく使った感想を紹介したいと思います。
WSL導入について
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 October 2018 UpdateのWSLでの感想です。
今後継続的にアップデートされると思いますので、状況は変わるかもしれません。
バックグラウンド動作ができない←できるようになりました!
当初WSLはプロセスのバックグランド動作ができず、SSHサーバなどのバックグラウンドプロセスを動作させても、WSLで起動したシェル(ターミナル)を閉じたら、バックグラウンドプロセスも終了してしまいました。
しかし2018年4月のアップデートでバックグラウンド動作ができるようになりました。
このため、一度SSHサーバを起動しておけば、あとはいつでもPuTtty等のSSHクライアントでWSLに接続できます。
これはかなり使い勝手が良くなりました。
さらに工夫するとWindows10の起動時に自動的にWSLのSSHサーバを動かすようにできるようです。これは後日挑戦してみたいと思います。
WSLは起動するといきなりシェル(bash)が立ち上がります。
ファイルシステムが不足している
Linuxといえば豊富なファイルシステムが特徴ですが、WSLのカーネルではその一部しかサポートしていません。
そのため、NFS等のLinuxでおなじみのファイルシステムが利用できません。これはその6で紹介したとおりです。
現状でもWSLが動作しているWindows10とのファイル共有なら問題ないのですが、それ以外のネットワーク上の機器とファイルを共有するのはちょっと面倒です。
WSLのアップデートにより、Windows10のネットワークドライブのマウントもできるようになりましたが、スピードが遅かったり、大文字・小文字の判別ができないなど、まだ制約があるようです。
できれば、他のLinuxのディスクをかんたんにマウントできるようにして欲しいところです。
特に私はネットワーク上のファイルサーバにホームディレクトリがあり、これをWSLでもホームディレクトリとして使いたいので、改善を期待しています。
ディスクI/Oが遅い?
WSLではWindows10でのCPUがそのまま見えるようです。
そのため、演算などの処理はオーバヘッドがなくCPUの実力が出せるようです。
一方、どうもディスクの読み書きは早くはないようです。
WSLのファイルシステムからWindowsのファイルシステムに変換する処理が入るからでしょうか。
そのためファイルの読み書きが多く発生するコンパイル処理などは少し不満が出るかもしれません。
例えばあるプログラムをWSLでコンパイルしたところ次のようになりました。
$ time make real 1m8.213s user 0m27.266s sys 0m30.031s
同じプログラムをCeleron J3160で動いているLinuxでコンパイルすると次のようになります。
$ time make real 1m13.474s user 1m2.661s sys 0m12.242s
単にコンパイル作業なので、ざっと「user」がコンパイル処理中のデータ処理時間、「real – sys」がファイルの読み書きにかかった時間(待たされている時間を含む)と見れば良いでしょう。
WSLを動かしているWindows10では2.9GHzのCPUを使っているので、データ処理が早くなっています。しかし、ファイル読み書きにかかっている時間が約3倍になっています。
このため、ファイルの読み書きが多い用途ではWSLでは不満が出るかもしれません。
サポートしていないシステムコールがある
WSLはLinuxのカーネルの機能をWndows10でエミュレーションして実現しているわけですが、全てのシステムコールをサポートしているわけではないようです。
下記にLTPというLinuxのテストをするシステムでWSLを評価した結果が掲載されています。
細かい内訳はわからないのですが、システムコールのうち73.81%カバーしているという結果のようです(Creator Updateの場合)。
私が試したなかではメッセージキュー(mq_open等)を使ったプログラムが、メッセージキューの作成に失敗して動作しませんでした。
自分が使おうとしているプログラムが、サポートしていないシステムコールを使っているのかどうか、というのは実際に動かしてみないとわかりません。
今後のWSLのアップデートでさらに互換性が上がるのを期待しましょう。
まとめ
今回はWindows Subsystem for Linux上に導入したDebian GNU/Linuxをしばらく使った感想を紹介しました。
1年前に試したよりも確実に進歩しておりかなり実用性が上がってきました。ネットワークファイルシステムが使えないなど、まだまだ改善の余地はありそうですが、今後の進化を期待したいところです。
次回はWSLでSSHサーバを自動実行する方法を紹介します。
コメント