
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 --import
WSLディストリビューションでパッケージ化できます。 Microsoft StoreからWSLにインストールできる便利でテスト済みのディストリビューションがいくつかありますが、最終的にinstall.tar.gz
はそれからWSLにインストールします。WSL のパッケージングには、次の追加の利点があります。本物Dockerイメージを含むすべてのソフトウェアをWSL "Deployment"に簡単に変換できます。ただ
docker pull ...
、、、docker run ...
そしてdocker export ...
タールボールを作成してください。 Microsoft StoreにないRed Hatイメージが必要な場合は、そのDockerイメージをインポートしてください。忙しい箱?同じ。など。ただし、「ブータブル」ディストリビューションになるには、少なくとも次のものが必要です。
/etc/passwd
1人以上のユーザーと。- デフォルトのエントリポイントとなるデフォルトユーザー用に定義されたシェル。
- ユーザーでない場合は、デフォルトユーザーを定義する必要が
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特徴。
答え2
私の理解は、Linuxディストリビューションがオペレーティングシステムのスキンを意味するということです。オペレーティングシステムのコアの上にあるUI階層。
これは正確ではありません。 Linuxディストリビューションは、GUIの外観と感覚を超えたいくつかの基本的な点で異なります。
- バージョンのカーネルとさまざまなカスタマイズ(最新のカーネルと最先端のソフトウェアが必要ですか?Fedoraを使用してください。安定性が欲しいですか?RHELを使用してください)
- さまざまなハードウェアデバイスのサポート
- パッケージマネージャ(RHELには
rpm
、、、、yum
があり、dnf
Debianには、dpkg
があり、apt
ArchLinuxにはpacman
;などがあります。) - ソフトウェアパッケージとツール(たとえば、Debianのデフォルトリポジトリには無料のオープンソースソフトウェアのみが含まれています)
- 更新とバグ修正のスケジュールが異なるリポジトリ
しかし、主な用途がいくつかのBashスクリプトを書くことであれば、どのディストリビューションを使用しても経験はほぼ同じです。
答え3
広く見ると、分布の違いは肌の違いです。さまざまなグラフィックインターフェースは単なる特別なケースです。まず、2つの割り当て関数の間に2つの主な違いがあります。
- リポジトリに何が含まれていて含まれていないか。
- デフォルトツールのデフォルト値は何ですか?
最初の例は、ライブラリまたはアプリケーションのバージョンです。開発者が新しいバージョンを作成したら、ディストリビューション管理者はそれをダウンロードしてコンパイルしてリポジトリに公開する必要があります。管理者(実際の人)がアプリケーションの新しいバージョンに多くのバグがあると予想している場合は、そのバージョンをスキップできます。ただし、他のディストリビューションの管理者はディストリビューションをそのままリリースし、一般ユーザーが開発者に直接バグについて苦情を提起できるようにします。
2番目:Ubuntuはグループに許可された使用があることをsudo
確認します。 Fedoraでは、グループ名はです。この違いは、デフォルトのツールの1つとしてリポジトリに保存される前にコンパイル中にツールに組み込まれます。wheel
sudo
sudo
sudo
ターミナルもUIという事実を忘れないでください。グラフィックではありません。そして違いもあるかもしれません。例:Ubuntuはapt
リポジトリから新しいアプリケーションをインストールするために使用しますが、Fedoraはdnf
同じ操作を実行するために使用します。これは他のUI選択として見ることができます。彼らは同じ目的を持ち、ほぼ同じ機能と制限を持っています。他のコマンドラインキーセットとは異なる構造化パッケージが処理されるだけです。
オペレーティングシステムの構造を理解すると、インストールしたディストリビューションを無視してさまざまな方法でディストリビューションを混在させることができます。sudo
これを直接再コンパイルして特別なグループ(たとえば)を定義できますadmins
。または、dnf
Ubuntu(またはapt
Fedora)にインストールし、両方のリポジトリからアプリをダウンロードすることもできます。後でダウンロードしたアプリの一部の設定を調整する必要があるかもしれませんが、可能です。もちろん、いつでもいくつかのアプリケーション/ライブラリをソースコードにダウンロードして、直接コンパイルしてコンパイルされたバージョンを共有できます。これがあなただけのディストリビューションになります。
これは、オペレーティングシステムの一般設定とWSLオペレーティングシステムの両方に適用されます。
答え4
これがあなたの質問に対する「最良の」答えであるかどうかはわかりませんが、ディストリビューションごとにカーネル要件が特定の時点で異なる可能性があるため、WSL1互換性はディストリビューションによって異なる可能性があります。
実際の例として、Arch Linuxは次のような困難を抱えています。「カーネルが古すぎる」問題しばらくの間glibc-2.33-4の変更のため、Ubuntuはそうではありませんでした。
しかし、この問題はCentOSのアーチコンテナも登場しました。したがって、WSL1自体に限定されません。しかし、実際には、WSL1 で Arch を実行するのが難しいことを意味します。