WSLを使用すると、ユーザーはデフォルトでUbuntuがインストールされているときに必要なディストリビューションを使用できます。
WSL環境では、ディストリビューションの関連性をよく理解していません。私の理解は、Linuxディストリビューションがオペレーティングシステムのスキンを意味するということです。オペレーティングシステムのコアの上にあるUI階層。ただし、WSLを使用する場合は、コマンドラインを使用するか、スタンドアロンの単一のGUIアプリケーションを実行するだけです。それでは、この文脈ではディストリビューションの関連性は何であり、どのディストリビューションを選択するかによってどのような違いがありますか？
ベストアンサー1
ここにある他の答えのいくつかは、「Linuxディストリビューション」の「一般的な」意味に焦点を当てており、これは質問の文脈を理解するのに間違いなく便利です。しかし、WSLの文脈で具体的にこの質問を投げることです。
どのディストリビューションを選択するかによって、どのような違いがありますか？
WSLディストリビューションに関連する「違い」を議論する前に、あなたの質問のこの部分に回答します。 Linuxディストリビューションの主な違い（ここではWSL /開発者の要件に焦点を当てています）は次のとおりです。
デフォルトのリポジトリで利用可能なアプリケーションのバージョン。 （過度の一般化）一般的に2つの方法があります。タイプ見つけることができるディストリビューション：
ほとんど更新されない傾向がある「安定した」ディストリビューション（セキュリティアップデートを除く）。しかし、フォーカスは、（最善を尽くして）すべてのパッケージが一緒にうまく機能し、システムを損傷しないことを確認することです。 Ubuntu（Ubuntu）、Debian（Debian）、Red Hat（Red Hat）が良い例です。
たとえば、Ubuntuは6ヶ月ごとにバージョンをリリースします。ただし、長期サポート（LTS）バージョン（例：22.04 LTS）のみが2年ごと（偶数年4月）に更新され、サポート期間は5年です。
「ローリングリリース」ディストリビューションは、新しいバージョンのソフトウェアが安定してテストされるとすぐにリポジトリに保存することに焦点を当てています。 ArchとKaliが一般的な例です。
別の例として、openSUSEには次のディストリビューションがあります。各どちらのモデルもMicrosoft StoreからWSLをインストールして使用できます。ストアでopenSUSEを検索すると、「Leap」バージョン（安定）と「Tumbleweed」（ローリング）バージョンが見つかります。
信頼できるバージョンを選択するかローリングバージョンを選択するかは、あなた次第です。私は個人的に両方を維持します。 WSLの1つの展開（ディスクスペースを除く）に制限する理由はまったくありません。私はしばらくローリングビルドとしてTumbleweedを使用しており、安定したビルドで最新のUbuntu LTSを使用しています。しかし、スクロールバージョン（Archベース）としてのArtixに感銘を受けました。
また、開発者として（Stack Overflowに最初に公開し、そこにプロファイルを公開したという事実に基づいて）使用する言語とツールによっては、これはそれほど重要ではないかもしれません。 SOタグを通じてノード/React/Web/フレームワークベースの開発をたくさんしているようです。 WSL（またはすべてのLinuxディストリビューション）では、事前パッケージされたNode.jsリポジトリのバージョンは使用されません。を通過するかインストール
nvmしますn。その後、もちろん（またはその他）を介してパッケージ/モジュールをインストールしnpmますyarn。システムにとって重要で変更しない言語（たとえば、LinuxディストリビューションでPythonバージョンを変更することはお勧めできません）の場合でも、Dockerまたは他の仮想化/コンテナ技術を使用して他の言語バージョンを使用できます。展開とは無関係のWSL。 （このトピックの詳細については、Ask Ubuntu about Docker Pythonに関する最近の回答を参照してください。apt-getを使ってさまざまなPythonバージョンをインストールする方法は？）。
したがって、開発者としてローリングリリースを選択する必要がある非開発者の理由がない場合は、安定したスタイルの展開を選択してください。可能長期的にあなたの人生をより簡単にしてください。
ドキュメントとサポートの可用性は、ディストリビューションを選択するもう一つの良い理由です。このため、ほとんどの新しいWSLユーザーにUbuntuを推奨する必要があります（言及したように、これはデフォルトのWSLディストリビューションです）。あなたが探しているほとんどのブログ、ビデオ、またはその他のトレーニング文書は、Ubuntuで作業を行う方法に焦点を当てています。ある程度はArchに移るかもしれませんが、今ではこの陣営の利点は依然としてUbuntuだと思います。
これは、Ubuntu（またはすべてのディストリビューション）文書を盲目的にWSLで実行できるという意味ではありません。 WSLには多くの違いがあります。つまり、指示を調整する必要があることがよくあります。これらの違いのいくつかを以下に説明しますが、試してみました。Ubuntuの回答に尋ねる。
一方、Kaliはプレミアムディストリビューションであることに注意してください。いいえWSLから。ここで素晴らしいメタ投稿をチェックしてください。あなたが尋ねるなら、Kali Linuxはあなたに適したディストリビューションではありません。
それでは、[WSL]の文脈での配布の関連性は何ですか？
WSLでは、「配布」という言葉は実際には多少オーバーロードされ、いくつかの意味を持ち、「一般」定義といくつかの重要な違いがあります。Linuxディストリビューション:
まず、重要なことに、WSLディストリビューションはルートファイルシステムパック。これには、次の簡単な内容が含まれます。単一の静的にリンクされた実行可能ファイル（BusyBoxなど）、パッケージ、スクリプト、パッケージ管理で構成された複雑なエコシステム（UbuntuまたはArch）などがあります。
パッケージは次のとおりです。
tarまたはtar.gz- 最新のWSLプレビューリリースのHyper-V仮想ディスクイメージ（
vhdまたは）。vhdx
ただし、実際にこれらの2つの形式のいずれかでファイルをパッケージ化できる場合は、少なくとも
wsl --importWSLディストリビューションでパッケージ化できます。 Microsoft StoreからWSLにインストールできる便利でテスト済みのディストリビューションがいくつかありますが、最終的にinstall.tar.gzはそれからWSLにインストールします。WSL のパッケージングには、次の追加の利点があります。本物Dockerイメージを含むすべてのソフトウェアをWSL "Deployment"に簡単に変換できます。ただ
docker pull ...、、、docker run ...そしてdocker export ...タールボールを作成してください。 Microsoft StoreにないRed Hatイメージが必要な場合は、そのDockerイメージをインポートしてください。忙しい箱？同じ。など。ただし、「ブータブル」ディストリビューションになるには、少なくとも次のものが必要です。
/etc/passwd1人以上のユーザーと。- デフォルトのエントリポイントとなるデフォルトユーザー用に定義されたシェル。
- ユーザーでない場合は、デフォルトユーザーを定義する必要が
rootあります（参照：/etc/wsl.confここ）またはレジストリキー。
「一般」Linuxディストリビューションは通常デフォルト値も提供します。
- システム初期化
- カーネルとドライバ
- ブートローダ（通常GRUB2）
- Xおよび/またはWaylandサーバー
これは WSL で必要または使用されません。 WSLは独自のカーネルを提供します。 （少なくともWSL2では）標準のカーネルソースから独自のカーネルを構築して置き換えることができますが、Windows / WSLシステムにインストールされているすべてのディストリビューション間で単一のカーネルが共有されます。 WSL1 では、Linux から Windows へのシステムコールの変換に使用される擬似カーネルです。 WSL2では本当です。Linuxホストされている（つまり、通常は表示、アクセス、変更はできません）、Hyper-V仮想マシンで実行されているカーネル。
WSLは、WSL / LinuxとWindows層間の相互運用性（ネットワーク、Windowsバイナリ実行機能
binfmt_misc、WSLg起動など）を処理する独自の初期化システムも提供します。WSLはそうではないため、問題が発生する可能性があります。いいえほとんどのLinuxディストリビューションの標準初期化を実行します。たとえば、Ubuntu / Debian / Arch（一部のニッチディストリビューションを除くほとんどすべて）はSystemdを実行しますが、WSLはこれらの「ディストリビューション」のいずれかを実行しても有効にしません。私の説明を見てくださいここそしてここ。
もちろん、Systemdは支配的なinitシステムですが、WSLのinitとSystemdの両方がPID1のために戦っているので、WSLの他のほとんどのinitシステムよりも多くの問題があります。 SystemdはPID1以外の実行を絶対に拒否します（そして、WSL2は回避策として名前空間を使用しない限りそれを許可しません）。他の一部の初期化/プロセスマネージャはPID1以外で実行できるため、WSLでの使用に適しています（IMHO）。例えば、私はArtixとDinitを通して大きな成功を収めました。一般プロセスマネージャとして、監督ほとんどのディストリビューションで合理的にうまく機能します。
WSL「配布」とは、インポートされたパッケージから生成された「インスタンス」または「コンテナ」を意味することもあります。実行すると、
wsl -l -vシステムにインストールされているディストリビューションが一覧表示されます。少なくともWSL2でこれらのうちの1つを実行すると、実行されるのは本質的にインポートされたパッケージのコンテナ（分離された名前空間）です。
Linuxディストリビューションには通常、デフォルトのデスクトップ環境（Gnome、KDE Plasma、Xfceなど）と（言及したように）テーマも付属しています。 WSLディストリビューションでデスクトップ環境を実行できますが、これは標準的な手順ではありません。 Windows 11では、WSLはWSLg機能を使用してLinux GUIアプリケーションを実行できますが、これはWindows 11に統合された単一のLinuxアプリケーションを実行する場合にのみ適用されます。Windowsデスクトップ。
Linuxデスクトップ環境の実行できる（サードパーティのXサーバー、WSLgフルスクリーンWeston / Xwayland、またはXRDPを介して）実行できますが（XRDPを除く）、Windowsの組み込みで傍受されないように、Alt+などのキーバインディングを変更する必要があります。Tab特徴。