17 ポイント 投稿者 GN⁺ 2025-05-20 | 6件のコメント | WhatsAppで共有
  • MicrosoftはWSL全体をオープンソース化したと発表。これは、Microsoft/WSLリポジトリの最初のIssueだった「オープンソースになりますか?」への回答でもある
  • GitHubのMicrosoft/WSLからソースをダウンロードして自分でビルドしたり、機能追加やバグ修正を行ったりできる
  • 公開されたコードには、コマンドラインツール、サービス、Linux向けデーモン、Plan9ベースのファイル共有サーバーまで含まれる
  • WSLはWindows側の実行部分と、Linux仮想マシン(VM)内で動作する複数のコンポーネントで構成される
    • CLIツール: wsl.exe, wslconfig.exe, wslg.exe
    • WSLサービス: VMの起動、ディストリビューションの実行、ファイル共有などを担う wslservice.exe
    • Linuxデーモン: init, gns, localhost など、ネットワークやポートフォワーディング機能を担当
    • Plan9サーバー: WindowsとLinux間のファイル共有を担う
  • 以前からオープンソースとして公開されていた構成要素
    • WSLg: WaylandおよびXサーバーをサポートするグラフィカル環境関連コンポーネント
    • WSL2-Linux-Kernel: Linuxカーネルのソース
  • まだ公開されていない構成要素
    • Lxcore.sys: WSL1の中核ドライバー
    • P9rdr.sys, p9np.dll: Windowsで \\wsl.localhost パスをサポートするファイルリダイレクトシステム

オープンソース化の背景とWSLの歴史

  • WSLは2016年のBUILDで初めて発表され、Windows 10 Anniversary Updateに含まれた
  • WSL1は、Windowsカーネル内でLinuxのsyscallを処理する lxcore.sys ベースの構造だった
  • WSL2は2019年に初めて発表され、実際のLinuxカーネルを活用して互換性と機能を改善した
  • その後、GPUサポート、GUIアプリ実行(wslg)、systemd サポートなどの機能が追加されながら進化してきた
  • 2021年からはWindowsから分離された独立パッケージとして、Microsoft Store経由で提供されている
    • 最初のリリースは0.47.1(プレビュー)で、その後2022年の1.0.0でWindows 10までサポートが拡大
  • Windows 11 24H2からは、従来の内蔵WSLから新しいパッケージベースのWSLへ移行している
    • wsl.exe はそのまま残し、ユーザーの移行を支援する

最新バージョンと機能

  • 最新リリースはWSL 2.5.7で、4年間にわたり約9ページ分のGitHubリリースノートを通じて改善が続けられてきた
  • 主な改善点には、ミラーネットワーキング、DNSトンネリング、Session 0、プロキシ/ファイアウォール対応などが含まれる

コミュニティの貢献

  • 長年にわたりコミュニティは、バグ報告、機能提案、非公式な分析などを通じてWSLの改善に貢献してきた
  • ソースコード公開以前から実質的な貢献は活発だったが、これで直接的なコード貢献も可能になった
  • Microsoftはこのコミュニティの支援に感謝しており、今後もWSLの発展により大きな相乗効果を期待している

貢献方法

  • ソース構造や機能実装に関心がある、あるいは改善したい点があるなら
    • microsoft/WSL リポジトリで参加できる
    • 自分でビルドする、PRを送る、Issueを報告するなど、さまざまな形で貢献可能

6件のコメント

 
ing03201 2025-05-27

Endeavour + lustre / Windows 11 + WSL + WSA を使う立場からすると
後者のほうが使い勝手はいいです
ただし、パフォーマンスは前者のほうが上です

 
iolothebard 2025-05-21

WSLチームも今回かなり削減されたみたいですね……

 
forgotdonkey456 2025-05-21

人手が足りないと、「community driven」という名目でオープンソース化してしまう最近のMSの動きw..

 
zihado 2025-05-21

在庫処分ですね

 
ksb9770 2025-05-20

WSL1はクロス開発環境として最高のマシンです。IOも速く、Linuxベースのコマンドもすぐに実行できます。WSL2は1よりクロスコンパイルが遅いです。

 
GN⁺ 2025-05-20
Hacker Newsの意見
  • 自分はHacker NewsでWSLを褒めるコメントをするたびに、カルマ税を払っているような気分になる立場だ。WSLは1台のコンピュータで複数のLinuxバージョンを同時にとても簡単に動かせるので、Linuxそのものより強力だという印象がある。dockerのようなデバイス対応、ローカルストレージ、ネットワークマッピングなども特別なスクリプトなしで、デスクトップやノートPCですぐ使える点が本当に大きな魅力だと思う。たとえば、あるプロジェクトはUbuntu22、別のプロジェクトはUbuntu24が必要でも、OSアップデートの心配に縛られなくていいのがうれしい

    • 「Linuxより強力だ」というのは誇張で、実際のところWSLは仮想マシンだ。WSLの主な強みは、各種便利機能を自動化して提供してくれることにある。ただ、本当により便利な環境とは、そもそも仮想マシンが不要な環境だと主張する。Distroboxやtoolbxのようなツールも似た機能を提供するし、NixOSでも一般的なLinux環境を手軽にテストできる。しかも、ハードウェアアクセラレーションが使え、GUIアプリもそのまま動き、遅い9pブリッジの問題もなく、VMのメモリバルーンのような問題も起きない。WindowsユーザーにとってWSLが革新的なのは確かだが、LinuxユーザーにはそうしたVM自体が不要だという意見だ

    • LinuxでもDistroboxで同じことは実現できるが、Windows + WSLを併用できる点は確かに魅力的だと認める。もしMicrosoftが不要なソフトウェアや広告、Copilot、過剰なテレメトリなどを減らしたDevエディションを出し、MacBookのようなハードウェアを提供するなら、Appleを離れる開発者を十分呼び戻せると思う。個人的にはMacとLinux環境を行き来しているが、使い勝手の面ではWindows + WSLの組み合わせのほうを好む部分があると明かす。PowerToys、WSL、PowerShell、そしてPowerShell + Winget DSCによるPCセットアップ自動化などは本当に優秀だが、Windowsのユーザー不親切さと長すぎるアップデート時間はどうしても耐えられないという悩みを説明している。macOSのようにイミュータブルなベースにイメージベースのアップデートを導入すればもっとよいという提案だ。M4 Pro級ノートPCの性能がない点も、Windows側の残念な理由として挙げている

    • 「WSLがLinuxより強力だ」という主張は、カルマが減ってもおかしくない発言だと思う。WSLは良いし毎日使っているが、対応ハードウェア上でLinuxを実行したほうが体験として優れているのは事実だ。VMがネイティブと同じだけ良くなれないのと同様に、WindowsソフトウェアもWindows上でより良く動く。比較するとWSLはI/Oが遅く、グラフィックスにも遅延や不具合があり、ときにはクラッシュ、非効率なメモリ管理、ネットワーク異常などさまざまな問題が起きると経験している。非常に強力なコンピュータでCLI中心に使うならWSLは便利かもしれないが、実際には人それぞれ必要な環境次第だと強調する

    • WSLは実際のところLinuxだ。特にWSL2からは完全にVM構造になっており、WSL1はWindowsカーネル上で動く方式だったので、それはそれで見事だったと評価する。ただしNTFSファイルシステムが遅いことと、Windows自体を扱わなければならない点には強い不満がある。カルマの数字はただの数字だと思っているので気にしない、というコメント

    • 自分にとってWSLはかなり不安定で、コンピュータがスリープから復帰するたびにVMとホスト間のネットワーク問題で再起動が必須になる。Windowsのユーザーディレクトリで作業すると、ファイルシステムドライバが遅いためgitコマンドに何秒もかかり、結局2つのホームディレクトリを管理する面倒が生じる。セットアップの過程でも、複雑なDNS、VPN、ネットワーク優先順位の誤り、時刻同期の不一致など、解決すべき不可解な問題が多かった。結局毎回Windowsを再起動する日常になってしまった。自分は複数のOSを使う必要がなく、会社でも大半のツールはLinux VMで動いていて、その方式だけが唯一合理的だ。表のOSはむしろ問題を増やすだけで、2つのOSの相互作用によって必要以上に複雑な作業を強いられるという見解だ

  • 自分はWSLが最初に登場したとき、とてもうれしかった。ゲームと開発を1台のWindows PCで統合して使うという夢が現実になったように感じた。しかし時間がたつにつれ、パッケージインストールの問題やOS間の境界にまつわる問題など、細かなトラブルが増え、次第に使い心地が粗くなっていった。ValveのProtonや最近のLinuxゲーム対応が向上したことで、UbuntuとNixOSに完全移行した。今ではゲーム面では少し不便さがあるものの、開発環境はむしろずっと快適になったと満足している。一部のAAAゲームが動かない点を除けば、Windows + WSLより良い体験だと思う

    • 自分も似た経験をしており、今ではLinuxのインストールのほうがむしろ簡単になった立場だ。Windowsのスパイウェア的な機能のせいで、使う理由はますます減っていると思う

    • ただし、Nvidiaのグラフィックカードを使う場合は例外だと考える

    • どのゲームで問題があったのか気になる、という質問

    • ほとんどの人がこういう経験をしたことがあると思う。今のWindowsはゲーム(GPU)がなければ存在感が薄かっただろうし、過去のプロジェクトではmsvccygwinmsys2などでビルド環境を切り替えながら混乱していた過程も振り返る。今ではWSLでもある程度簡単にビルドできるが、環境変数を1つ変える作業にまで疲れを覚え、二度とこんなやり方を繰り返したくないと語る

  • 自分はむしろ、Linux上でWindowsを仮想マシンとして使う方法を勧める。WindowsでLinuxを使いたくなるなら、いっそLinuxへ移行してしまえばよく、振り返ることはないという信念だ。この15年間、Windowsに戻ったことはない。今のWindowsの現実を考えると、VMの中でさえ使うのをためらうレベルだ

    • GPU関連の作業(ゲーム、Adobe suiteなど)では、VMでWindowsを動かすなら別のGPUをVMにパススルーしなければならず、それがないユーザーはアクセラレーションなしの環境を受け入れるしかないので、VM方式は簡単ではないという立場だ。PhotoshopをQEMU QXLドライバで動かすと性能がひどく、VirGLはそもそもWindowsゲストをサポートしていない。VMWareやVirtualBoxは少しマシだが、それでもネイティブには及ばない

    • たいていのWindows関連スレッドでは、生産性アプリのためにWindowsが必須な人たちと、そうでない人たちの明確な断絶があると認識しているという。自分のようにGPU関連の生産性アプリを使う場合、VMでは不可能で、結局Windowsをネイティブで使うしかないという主張だ。軽いアプリだけを使うユーザーなら仮想マシンでも十分だが、CADやゲームのような本格的な作業には向かないと判断している

    • 何年もLinuxだけを使ったあとWindowsに戻り、その後またMacに戻った立場だ。wineの互換性問題、完成度の低い代替ソフトウェア(例: GIMPはPhotoshopの代わりにならない)、QtとGTKアプリが混在することでデスクトップの見た目が崩れることなどを挙げ、Linuxは万能ではないと指摘する

    • 反論として、Valve IndexのようなVR機器は、こうした環境(つまりLinux上でWindows VMを動かす構成)ではまったくまともに動かないという経験ベースの意見だ。子どものころからLinuxのハードコアユーザーだったが、こうした特殊な例外もあるので、無条件に一般化するのは難しいという立場だ

    • 関連情報として、Windowsを評価版VMイメージとして配布している公式リンクを紹介し、評価期間が切れるとデスクトップが黒くなり、PCが1時間ごとにシャットダウンするなどの制約があると知らせる。最新の評価版イメージは6か月以上更新されておらず、登録すればISOは提供されるという案内だ

  • 名前がWindows subsystem for Linuxなので、いつも紛らわしい。一見するとWineの公式版のようにも見えるし、実際にはLinuxのためのWindowsサブシステムという意味にも取れる。まるでMicrosoftがLinuxに機能を与えているように聞こえて不快だ

    • Microsoftはプロジェクト名をLinuxで始められないので、結局WSLという名前になったのだと述べる

    • 昔のWindows Subsystem for Unixというプロジェクトに由来する命名だ。名前はいつも期待とは逆の動きをしてきたという

    • WindowsのLinux用サブシステム、という両義性のある改善案を機知に富んだ形で提案する

    • WindowsでLinuxを動かすためのサブシステムなのに、命名がややこしい点には同意する

  • 自分はここ数年、ときどきWSLで開発してきた。うまく動いているときは最高だが、ひとたびこじれると本当に悪夢だ。ネットワーク、VPN、XServer、Windowsのスケーリング、ハードウェアアクセラレーション付きグラフィックスなどで絶え間ない問題があった。実際に開発している時間より、問題解決に費やした時間のほうが多かった気がするし、改善されたこともなかった。WSLは速くて強力だが、日常的に使うには自分にはつらすぎる環境だ。代わりにMSYS2を主力で使っているが、速度は遅くても少なくとも安定している点が最大の利点だ

    • 自分はいまだにWSLベータ版を使っていて、更新すると今うまく動いている環境が壊れるのではないかと思い、アップグレードもできない状態だ
  • 先週、記録的な業績発表のあとにもMicrosoftで大規模なレイオフがあったが、こうした動きはその副作用なのか気になる

    • 大企業で3%規模のレイオフは、会社全体あるいは何らかのプロジェクトを丸ごと消す場合でもない限り、実質的にはほとんど影響がない水準だと思う。むしろ大企業には人員過剰がよくあるので、この程度は大したことではないと断言する

    • こうした大企業のオープンソース化の決定、準備、実行は、絶対に1〜2週間で進むような小規模なものではない

    • 今回のBuildイベントや関連ニュースについて、今の全体的な空気の中では手放しで肯定的には見づらいという懸念を示す

    • 発表どおりなら長期間準備してきた結果なので、最近のレイオフとは無関係だという説明に同意する

  • WSL 1を動かしている主体であるkernel side driver lxcore.sysは、今回のオープンソース化の対象には含まれないと知らせる。そしてWSL 1がいまだにサポートされていることに驚いており、メンテナンスモードだろうと予想している

    • 自分が本当に関心があるのはlxcore.sysだけだ。自分はいまだにWSL1しか使っておらず、ABIをまたいだり、WindowsをLinuxユーザースペースへトンネリングしたりする独特なハックも試したことがある。オープンソースになればもっと扱いやすくなることを期待している

    • 実際にはWSL1もWSL2もどちらも完全にサポートされていると聞いている。数字の違いから受ける印象とは違う

  • ライセンスや詳細の確認が必要だ。前向きな話かもしれないが、Microsoftが開発者を解雇したあとで、無料の助力を求める口実かもしれないと疑っている

    • ライセンスはMITだと案内する
  • 自分はWindowsユーザーではないが、WSLは素晴らしいと評価している。ただ、多くのWindowsユーザーがLinuxを批判する最大の理由は「Windowsのように見えない」ことであり、Linuxユーザーの立場では、むしろLinuxがWindowsのように見えないからこそ良い。Windowsユーザーが無料で広告のないWindowsを欲しがるあまり、LinuxをWindows化しないでほしい。WSLがWindowsユーザーをWindowsに留める効果を持つなら、むしろ歓迎だ

    • 自分はWindowsユーザーではないが、WSLそのものは嫌いだ。Microsoftが開発者の世代をLinuxに奪われるのを恐れて、OSの中にLinuxを組み込んだ戦略に見える。開発者が自分でカーネルを再コンパイルして体験する楽しさを失わせたのではないかと残念に思う
  • WSLの中でWindowsファイルシステムを扱うときに起きるバグが、今からでも早く修正されてほしいと願っている

    • Microsoftもきっとそう願っていると思う