WSL は強力ですが、本物の Linux デスクトップに勝てない理由は次の 3 つです
<本文>
Windows Subsystem for Linux (WSL) は、サードパーティのハイパーバイザーを必要とせずに Linux ディストリビューションを実行する簡単な方法として、Windows 10 でデビューしました。 WSL 2 は、その多数の欠点を改善し、Windows 上で複数の Linux ディストリビューションを実行および管理する簡単な方法になりました。私は個人的に、ローカル LLM を備えた PaperlessNGX インスタンスの Docker を実行する Ubuntu VM でこれを使用しています。 WSL は GPU パススルーをサポートするようになったため、NVIDIA RTX 3060 GPU を使用してローカル LLM を実行することは問題になりません。
しかし、大幅な改善にもかかわらず、実際の Linux デスクトップのエクスペリエンスに勝るものはありません。私がこれを重い気持ちで言ったのは、WSL がデュアルブートとそれに伴う複雑さよりも Linux を使用するのに最適な方法のように思えるからです。 WSL が依然として実際の Linux デスクトップ エクスペリエンスに影を落としていない 3 つの理由を見てみましょう。
共有リソース
まだ仮想化です
WSL は Windows ネイティブのハイパーバイザー (Hyper-V) を使用して、軽量の仮想環境を作成します。インストールする Linux ディストリビューションは、CLI を備えた最小限のものです。その結果、バックグラウンドで実行されてシステム リソースを消費するデスクトップ環境がなくなるため、エクスペリエンスがはるかに速く感じられます。
これは、軽量サーバーを作成したり、Docker を実行したり、個人使用やテストのためにアプリを展開したい人にとっては素晴らしいアプローチです。ただし、最小限のインストールを選択することによって節約されるリソースは、物語の一面にすぎません。 Windows 11 自体が動作するには 2GB 以上のメモリが必要で、WSL と並行してアプリを実行すると GPU の使用量も急増します。
Ubuntu のような本格的な Linux デスクトップを GNOME デスクトップ環境で実行している場合、パフォーマンスは確実に低下します。システムは、Windows ワークロードと WSL 内で実行される Linux ディストリビューション ワークロードの間でやりくりする必要があります。真の Linux デスクトップは、何の制約もなくすべてのリソースにアクセスし、それらを使用できます。
ハードウェア制御が制限されている
理解するのは簡単ではありません
WSL を使用すると、基本的にはハードウェア仮想化を通じてシステム リソースにアクセスできる仮想化環境を実行することになります。 WSL2 はいくつかの興味深い変更をもたらしましたが、ハードウェアとネットワークに対する全体的な制御は依然として制限されています。
システムでは NAT アダプターが使用されていますが、他の方法もいくつか使用できます。 Linux システムには異なる IP アドレスがあり、場合によっては面倒になることがあります。 WSL を使用する場合、ハードウェアとの対話は難しい場合がありますが、同様の制約を共有しない Linux デスクトップを実行する場合は問題ありません。
NVMe ドライブを使用しているにもかかわらず、WSL 内で実行される IO 操作でさえも時間がかかります。ワークフローで大規模な I/O 操作が必要な場合、そのイライラは想像できるでしょう。 WSL と Windows の両方で同じシーケンシャル書き込み速度をテストしたところ、1 GB のシーケンシャル書き込みタスクを完了するのに WSL では 32 秒かかりましたが、ネイティブ ハードウェアではわずか 3 秒しかかかりませんでした。
ホーム ディレクトリを使用すると、ディスクのほぼ完全なパフォーマンスが得られますが、/mnt/c/ ディレクトリで同じことを実行しようとすると、ひどい結果が得られることに注意してください。
見た目のパフォーマンスが標準以下
WSLg はかろうじて大丈夫
WSL2 では、Windows マシン上でグラフィカル ユーザー インターフェイスを備えたアプリを実行できる WSLg と呼ばれる機能が導入されました。デスクトップ環境のない Linux ディストリビューション上の Windows マシンで GIMP のようなツールを直接実行することを想像してみてください。 WSL の Weston ではそれが可能であり、軽量プログラムの場合はまったく問題ありません。
WSL は CLI の観点から機能し、WSLg はある程度の休息を提供し、対応する CLI と格闘するのではなくアプリを実行できるようにします。デスクトップ環境はありませんが、正気を保つためにデスクトップ環境をインストールしてみてください。
ただし、純粋にデスクトップ エクスペリエンスのために WSL を使用する予定がある場合は、パフォーマンスの低下やその他の課題に備えてください。これは簡単な作業ではないため、どれが自分のニーズに合うかを確認する必要があります。 GUI インターフェイスを使用したい場合は、Tasksel を使用してデスクトップ環境を追加し、別の PC からリモートでその環境に接続できます。
WSL と Linux についてさらに詳しく知りたい場合は、ニュースレターを購読してください
より明確に理解するには、ニュースレターを購読して、WSL のトレードオフ、ネイティブ Linux のパフォーマンス、GPU パススルー、WSLg の動作、実際のパフォーマンスの比較、その他の Windows/Linux ツールのトピックを詳しく取り上げ、トレードオフを検討するのに役立ちます。
購読する
購読すると、ニュースレターとマーケティング電子メールの受信に同意し、Valnet の利用規約とプライバシー ポリシーに同意したものとみなされます。いつでも購読を解除できます。
WSLg は、Linux システムのように GPU に直接アクセスするのではなく Windows 経由でレンダリングするため、全体的なパフォーマンスが低下する可能性があります。 Linux ツールを完全に実行することよりも、Windows 上で Linux ツールを実行できるようにすることに重点が置かれています。ゲームについて疑問がある場合は、仮想化環境内で実行するよりも、システムに Linux をインストールしてから GPU ドライバーと Steam を構成する方が良いでしょう。
WSL は GPU にアクセスするために Windows と通信する必要があるため、変換中に多くのパフォーマンスが失われます。これは WSL が意図したタスクではないことは確かで、GPU CUDA コアを利用できるローカル LLM ワークロードでより便利です。
ネイティブ Linux インストールの方が優れています
WSL2 により、Windows 内で Linux システムを簡単にセットアップして実行できるようになりました。クロスプラットフォームのファイル転送、GPU アクセス、Windows 上での Linux アプリの実行をサポートしています。ただし、完全なデスクトップ エクスペリエンスではなく、Linux のより技術的な側面が必要な場合にのみ適しています。
また、WSL と Windows の両方を実行するには堅牢なシステムも必要です。デュアルブートして気が狂うよりはマシですが、ベアメタル Linux インストールとは比べものになりません。利用可能なすべてのシステム ハードウェアを活用でき、仮想化に何も無駄にする必要がなく、好きな目的に使用できます。
*️⃣ 出典リンク:
Linux ディストリビューション、Linux デスクトップ、Windows ネイティブ ハイパーバイザー (Hyper-V)、Docker、、WSL2、NVMe ドライブ、デスクトップ環境、、、 利用規約、 プライバシー ポリシー、Steam、ローカル LLM、