Windows 10 HomeでWSLgをさっそく試してみた

最近のWindowsは、Linux環境をもWindows上に構築することができる、Web系開発者(?)などLinuxを主戦場にしているソフトウェアエンジニアにも優しい環境を目指しているようです。もちろんそれはWSL(Windows Subsystem for Linux)なわけですが、すでにMicrosoft社から、Linux GUIアプリについても「ユーザが特に何も準備することなく」実行可能にする、ということがアナウンスされています。

そのLinux GUI環境は「WSLg」という名前で呼ばれていて、Windows Insider Programに参加している方は、このWSLgを試すことができます。

僕はLinuxが主戦場であり、ここ数年はWindowsでもなくmacでもなくChromeOSでもなく、デスクトップ機にLinux(Kubuntu)を入れて開発を行っています。その環境が快適すぎるので今後も使っていくつもりですが、Linuxならではのデメリットももちろんあるわけです。例えば、Windowsでしか動かないアプリがあったり、ChromeでYouTubeを見ている時にGPUサポートを受けられずCPUパワーが使われてしまうとか、Windows環境でしか発生しない不具合に遭遇したときにWindows環境でないと修正確認できない、とかとかです。

そんな時にWindows側に仮想マシンを作ってLinuxを動かしてもいいんですけど、デュアルブートでWindowsも起動できるようにしてあって、でもめったに起動しないWindowsをもったいないとも思っていて、なんとかもっと活用したいなぁ、と思っていました。そこにWSLgのニュースが来て、しかも今では試せるとなれば、やらない選択肢はありません。

というわけで、このブログエントリは、Windows 10 HomeでWSLgを試してみた、という話になります。

結論として僕がWSLgを試した感想は、今までの「ソフトウェアエンジニアであればmac」っていう風潮は、間違いなくWSLgが変える、と思いました。

Windows Insider Programへの参加

WSLgを試すには、2021年6月2日時点では、Windows Insider Programに参加して、しかもDevチャネルを選択する必要があります。

Windows Updateが走った後、僕がWSLgを今回試した環境は、以下のようになりました。

Windows 10 Home
評価コピー, Build 21390.co_release,210521-1658

Devチャネルはもちろん安定しているとは言えない環境ですので、自己責任でお願いいたします。

そういえば、このDevチャネルに更新したら、WSL2 の時刻がずれる問題が解決されていました。前は wsl –shutdown を毎回するなどして時間を補正しないといけなかったのですが、その必要はなくなっていました。すばらしい!

WSL2 環境の更新

数か月前にWSL2環境をUbuntu 20.04で構築してあったので、それをそのまま使います。念のため、apt コマンドでインストールされているものたちを最新にしておきます。

// Ubuntu 20.04
$ sudo apt update && sudo apt upgrade

そして、WSL2 自体のアップデートも必要になるので、PowerShell を管理者モードで開いて、以下のコマンドを実行しましょう。

// PowerShell for Admin
PS C:\> wsl --update

これだけで、WSLg の準備は完了です。簡単ですね!

WSL2 のネットワークの遅さを解決

実は、上記の apt コマンドによる更新作業において、Windows側ではファイル転送が 200Mbps を軽く突破しているのに、WSL2 からは 1Mbps ちょいしか出ないという、悲惨な状況になっていました。これは「通信できないに等しい」と言っても過言ではないでしょう。最初からつまづいてしまい、WSLg を試すよりも先に、こっちの問題を解決しないといけなくなりました。

「WSL2 network slow」といったキーワードで検索するといくつか解決策がヒットするのですが、そのどれもが「仮想ネットワークアダプタの IPv4 Large Checksum Offload 機能を OFF にする」という対処であり、それを OFF にするためには、Windows の設定からネットワークアダプタの一覧を開いて、その中にある「vEthernet (WSL)」の設定を変更しにいく、という方法が紹介されていました。

しかし、Windows 10 Home では、ネットワークアダプタの一覧に、そんなアダプタは表示されないのです。

デバイスマネージャからはかろうじて vEthernet (WSL) アダプタ(Hyper-V Virtual Switch Extension Adapter という名前)が表示されるのですが、なんと設定変更ができるはずの「Advance」タブがありません。

「ここまでか・・・」と思いましたが、いろいろ調査を進めたところ、PowerShell からコマンドを叩くことで、設定を変更することができることがわかりました。

PowerShell を管理者モードで開き、以下のコマンドを実行します。

// PowerShell for Admin
PS C:\> Set-NetAdapterLso -IPv4Enabled $False -Name 'vEthernet (WSL)'

もし上記でもダメな場合は、以下も実行してみてください。

// PowerShell for Admin
PS C:\> Disable-NetAdapterLso -Name 'vEthernet (WSL)'

これを行った直後は、WSL2 から DNS が引けない状況になります。ここで、Windows の再起動を行います。

その後、WSL2 で Ubuntu に入り、ファイル転送を行ってみてください。おそらく、Windows 側での速度とほとんど同じパフォーマンスを得ることができると思います。少なくとも、僕の環境では超高速になりました。

検索していて、「毎回 Offload 設定の OFF をしないといけない」と書かれている情報もいくつか見かけたのですが、僕の Windows 10 Home では、一度速くなれば、その後は特に何もしなくても速いままとなっています。

WSLg の動作確認

本当に複雑な手順なしで、LinuxのGUIアプリを起動することができるようになります。ここまでで、ネットワークの問題がなかったとするならば、Insider Program で Dev チャネルにして、wsl –update をしただけです。しかし、もう準備は完了しています。

例えば、xeyes という有名なGUIアプリをインストールして起動してみましょう。

// Ubuntu 20.04
$ sudo apt install x11-apps
$ xeyes

マウスカーソルを目で追ってくれるGUIアプリが起動しました。

かわいいですよね!ただ、残念ながら、xeyes のウィンドウの外にマウスカーソルがあるときには、目で追ってはくれない模様です。

xeyes が起動するということは、もちろん様々なGUIアプリも起動するということです。試しに IDE である IntelliJ IDEA を起動してみました。あっさりと起動することがわかります。

すばらしい!

キーボードレイアウトの変更

起動した IDE で文字入力を試してみたところ、早速異変に気が付きました。今まで打ち込んできた記号群について、期待と異なる記号が入力されます。

普段 Windows 側では US 配列でキーボードを使っています。もちろん Windows Terminal から Ubuntu にコマンド入力しているときも US 配列のままで使えていました。

しかし、なんと、Ubuntu 側から起動した Linux GUI アプリでは、日本語配列となっていたのです。@ を打ち込むと、” が入力されます。なんで???

一瞬焦りましたが、これは純粋に Linux 側の X 関連の設定の問題です。WSLg だから、というよりは、WSLg での初期設定の影響でたまたまこうなった、っていうほうが表現としては正しいかと思います。

では、どう直すかですが、X のキーマッピングの変更を行うためのコマンドをインストールして、US 配列に変更してあげればよいです。具体的には、以下のコマンドを実行します。

// Ubuntu 20.04
$ sudo apt install x11-xkb-utils
$ setxkbmap -layout us

これにより、Linux GUIアプリでも、US 配列が適用されます。

この逆で「日本語配列がいいのに US 配列になっちゃってるよぉ」って場合には、us の部分を jp にすれば、日本語配列になります。

fcitx と mozc による日本語入力

以上の手順で Linux 側から GUI アプリを起動することができ、文字入力もできるようになりました。ただ、WSLg と Windows の GUI 環境はもちろんそれぞれ異なりますので、Windows 側の IME を使って Linux 側の GUI アプリに日本語入力を行うことはできません。つまり、Linux 側にも日本語入力のための環境を作る必要があります。

ここでは、fcitx と mozc の組み合わせで日本語入力環境を作ってみたいと思います。以下のようにコマンドを実行します。

// Ubuntu 20.04
$ sudo apt install fcitx-bin fcitx-mozc dbus-x11 language-pack-ja
$ sudo update-locale LANG=ja_JP.UTF8
$ sudo sh -c "dbus-uuidgen > /var/lib/dbus/machine-id"
$ im-config -n fcitx
$ vi ~/.zshrc

export QT_IM_MODULE=fcitx
export GTK_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export DefaultIMModule=fcitx
fcitx-autostart &> /dev/null

$ sudo service dbus restart
$ fcitx-autostart

以上を行い、念のため PowerShell から wsl –shutdown して WSL2 環境を再起動します。僕は zsh を使っていますが、Bash を使っている人は環境変数を .bashrc などに書いておくと良いでしょう。

そして、何らか GUI アプリを起動し、文字入力が可能な箇所で Ctrl + Space キーを押してみてください。mozc によって日本語変換が可能になっていることがわかると思います。

fcitx や mozc の設定変更は、以下のコマンドを実行して設定画面を開けば可能です。

// Ubuntu 20.04
$ fcitx-configtool

もし入力メソッドとして何も表示されなかった場合は、再度 fcitx-autostart コマンドを実行してみてください。fcitx-configtool にて表示されるようになると思います。

まとめ

今回は、WSLg による Linux GUI アプリの起動や各種設定について紹介してみました。もちろん Insider Program で試しただけなので、今後上記の手順が有効かどうかは保証できません。ただし、WSLg としては特に何も設定していることはなく、ほとんどが Linux 固有の設定変更です。つまり、Linux Desktop の構築をやったことがある方なら、おそらく様々な設定変更について勘が働くのではないかと思いますし、そうでない方についても Linux の一般的な設定方法が参考となりそうです。

ちょっと使ってみたところ、数回 GUI アプリがフリーズしてしまう(Linux 上ではプロセスが見えなくなっているが、ウィンドウが残ってしまっている状態)問題が出ましたが、それ以外は普通に動作していました。今後安定性が増してくれば、かなり魅力的な環境を手に入れることができると考えてよいでしょう。

おそらく、多くのソフトウェアエンジニアが、Windows に対して見方を変えるはずです。少なくとも、僕は見方を変えつつありますし、WSLg の今回の利用で、大きく印象が変わりました。

正式版が来るのが待ち遠しいです。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて