Microsoft は、WSL がついにネイティブ感覚になると約束し続けていますが、私は待ちくたびれています
<本文>
新しいコンテナーをスピンするために Windows 11 デスクトップから Proxmox ノードに SSH 接続しようとすると、スムーズに進むことはほとんどありません。場合によっては接続が切断されることがあります。許可の問題がある場合もあります。しかし、警告やエラー メッセージは表示されず、ただ沈黙するだけです。そこで、WSL を再起動し、再接続して、続行しました。それを何度も繰り返したので、今ではそれが筋肉の記憶になっています。
私の自宅ラボでは、さまざまなサービスを実行する少数の VM、Raspberry Pi 4、およびいくつかの ESP32 ボードを備えた Proxmox ホストを実行しています。これらのデバイスは年中無休で稼働し、期待どおりに動作します。これらを使用したい場合、最も信頼性の低い Linux 環境は、Windows ターミナルを備えた Windows Subsystem for Linux (WSL) です。
Microsoft は WSL がネイティブに感じられると宣伝し続けていますが、その約束はまだ果たされていません。
関連
私が PC で Windows と Linux のデュアルブートをやめた 5 つの理由
もう面倒なことをする価値はありません。
ホームラボセットアップで WSL を使用しようとしています
毎回ぶつかる壁
WSL はコマンドセンターであることを想定しています。ホームラバーとして、Linux ノードに SSH で接続し、Docker 構成をテストし、Linux へのデュアルブートを行わずにすべてを管理したいと考えています。
Windows 上の WSL をブリッジとして使用しました。最初はいくつか問題がありましたが、WSL を使用して Linux マシンを管理することに慣れてきました。しかし、完全に信頼できるほど高速でも効率的でもありませんでした。
WSL2 はセットアップ、互換性、および実際のパフォーマンスの点で本当に優れています。ただし、優れているということはネイティブと同じではありません。 Linux ファイル システム、ネットワーク、USB パススルーの回避策を使い始めるとすぐに、壁にぶつかります。これらの問題は GitHub で未解決のままです。
WSL のウィンドウ マウント ポイント (/mnt/c/) にあるプロジェクト ファイルへのアクセスは、Linux ファイル システムでネイティブに動作する場合に比べて時間がかかります。これは、Windows 上の WSL と NTFS が OS の境界を越えて効率的に通信できないためです。
たとえなんとかできたとしても、ファイルのアクセス権をめぐって戦わなければならず、問題を発見するにはかなりの調査が必要でした。さらに、WSL2 では USB パススルーを管理するために別のツールを使用する必要があり、複数段階のセットアップを手動で実行する必要があります。
WSL は、ネイティブではないことを思い出させるまではうまく機能します
国境を越えた摩擦は依然として存在する
たとえば、私は自宅の研究室を Tailscale とつなぎ合わせて、外出中でもアクセスできるようにしました。これが、どこからでも Pi、Proxmox ノード、NAS にアクセスする方法です。しかし、WSL を使用する場合、それはそれほど単純ではありません。アクティブな接続の使用を一時停止し、再開しようとすると、エンド ノードに到達できなくなります。
数分間苦労した後、間違ったノードに ping を実行していることがわかりました。 WSL を再起動することが唯一の解決策です。私はそれをモニターの付箋に書きましたが、2回の再インストールを超えて長持ちしました。
/var/run/docker.sock で多くの権限エラーが発生したため、私は WSL を諦め、すべてを Docker Desktop に移動しました。しかし、これにより新たな問題が発生しました。2 つの Docker エンジンが同時に実行されているにもかかわらず、CLI は 1 つだけを選択します。端末を切り替えたり、WSL を再起動すると、警告なしに別のエンジンが選択されることがあります。このようにして、Docker が正常に実行されるようになりましたが、場所は間違っていました。
時間の経過とともにメモリ消費量が着実に増加するため、WSL を実行したままにするのは罪のように感じられます。 WSL を実行したままにすると、PC の動作が徐々に重くなり、解決するには WSL を再起動するしかありません。振り返ってみると、Proxmox ノード上の Linux VM で SSH がどれだけ簡単に実行できるかを常に比較しています。
WSL はいつ維持を獲得しますか
すべてが悪いわけではありませんが、十分ではありません
SSH セッション、スクリプトの実行、OS の更新、ストレージ間でのファイルの rsync などの単純なタスクの場合は、すべて WSL で正常に機能します。しかし、ホームラボの設計がシンプルであることはほとんどありません。まず、ネットワークのカスタマイズには、カスタム DNS、スプリットトンネル VPN、および複数の VLAN の使用が含まれます。これが、WSL が最もつまずく理由です。WSL は、アクティブな接続を一時的に中断し、後で再開することに対応できないからです。
WSL とホームラボの修正についてはニュースレターを購読してください
ニュースレターで実践的な WSL とホーム ラボのトラブルシューティングを入手してください。実用的な修正、構成ガイダンス、SSH、Docker、ネットワーキング、ファイル システムの問題に対する現実的な回避策を購読すると、さらに幅広いホーム ラボの内容が得られます。
アップデートを取得する
購読すると、ニュースレターとマーケティング電子メールの受信に同意し、利用規約とプライバシー ポリシーに同意したものとみなされます。いつでも購読を解除できます。
私は簡素化されたワークフローに従います。つまり、Pi または Proxmox に直接 SSH 接続して、サービスがそれぞれのマシンに含まれるようにします。ファイルを移動する場合は、rsync を好みます。これは私のホームラボでは明らかに機能します。ただし、これは回避策です。
WSL はネイティブ エクスペリエンスを提供するために正確な摩擦を取り除くことになっているため、これは奇妙です。
関連
WSL は素晴らしいですが、ネットワークは混乱しています — これが私がそれを修正した方法です
これほど複雑ではないはずです
もう別の「ほぼネイティブ」を待つ必要はありません
私がいまだにデスクトップでデュアルブートをしていないのは、WSL のせいです。私は次のアップデートでエクスペリエンスが真にネイティブになることを願いながら、変更ログを読み続けています。たくさんの新機能ではなく、基本的な修正が必要です。通常のプロセスと同様に、リリースによるメモリ管理が最上位にあります。サスペンドとレジュームのサイクルを乗り越えるネットワーキング。ファイル システムのパフォーマンスも向上するため、OS を切り替える必要がありません。
それらが良いアップデートのお知らせ投稿に貢献しないとしても、私は気にしません。私は、メイン PC の 1 つの端末ウィンドウよりもはるかに予測可能な動作で 9 台のデバイスからなる自宅ラボを管理しています。 Raspberry Pi を隅にある USB 充電器で動作させると、より安定した動作が可能になります。このことはマイクロソフトにとって思っている以上に悩ましいはずだ。
*️⃣ 出典リンク:
Windows ターミナルを使用した Windows Subsystem for Linux (WSL)、PC で Windows と Linux のデュアルブートをやめた 5 つの理由、Linux ノードへの SSH、WSL2 の方が本当に優れています、USB パススルーの回避策、Tailscale と連携したホーム ラボ、すべてを Docker デスクトップに移動、ストレージ間でのファイルの rsync、カスタム DNS、スプリット トンネル VPN、複数の VLAN、、、、、、 利用規約 、 プライバシー ポリシー、WSL は素晴らしいですが、ネットワークはめちゃくちゃです — これが私がそれを修正した方法です 、デスクトップでデュアルブートしないでください、