【Bash】Windows Subsystem for Linux【WSL】8

ついにWSL2が登場したぜー。こりゃ完全にLinuxだ。ヒャッハー！WSL最高！開発にLinuxは使わねぇー。Windowsで開発してLinuxは動かすだけや！

WSL2アーキテクチャ
https://www.atmarkit.co.jp/ait/articles/1906/14/news019.html

WSL 2では、仮想マシン環境が起動し、bashがコマンドを受け付けるまで2秒程度という速度で起動できる。
このため、コマンドプロンプトなどからwsl.exeなどを使ってbashコマンドを処理する時間は、
現在のWSL 1とほとんど変わらない。また、本物のLinux実行環境であるため、
これまで正しく動作できなかったアプリケーション、例えばコンテナシステム（Dockerなど）や
ユーザーファイルシステム（FUSEなど）も動作させることができる。その上で、現在のWSL 1と同等の機能と使い勝手を実現するという。

WSL 2はWSL 1を置き換えずに併存する
　WSL 2が登場したからといって、WSL 1は廃止になるわけではなく、引き続き利用可能である。

ファイル共有プロトコル「9P」でWSL 1との互換性を確保
　このように、WSL 2とWin32環境の間のファイル共有は、どちらも9Pを使うことになる。
　また、WSLからWin32プログラムを起動する「Win32相互運用性」では、最初にWSL側で、
実行ファイルを判別する必要がある。具体的には、実行ファイル先頭のマジックナンバー
（Win32ではMZ）を見て、LinuxのELF64か、Win32の実行ファイルなのかを判断する。

【Bash】Windows Subsystem for Linux【WSL】7
https://mao.5ch.net/test/read.cgi/linux/1579395785/

Windowsから起動したのと何も変わらない

いや、どうだったんだよw
scp.exeで転送出来ないのか？

自分でやればいいだろ

Linux GUIアプリがWindows 10で動く日 - 阿久津良和のWindows Weekly Report
https://news.mynavi.jp/article/20200927-windows10report/
https://news.mynavi.jp/article/20200927-windows10report/images/001l.jpg

善きこと

まあ自分でセットアップすれば同じ事は既にできるが、
WSL側で標準的な実装を提供してくれるなら、それこそバカチョン化できる
よほど思想的にアンチMSを拗らせているようなディストリ以外は、インストーラー側でWSL環境も考慮するようになるだろう

Windowsの機能(の一部)としてLinuxを取り込めるなら、拒絶する理由は無い

> インストーラー側でWSL環境も考慮するようになるだろう
その必要はないんだよなぁ

もともとLinuxはGUIがない環境（つまりWSLと同じ）にも対応しているし
WSLは本質的にはLinux用バイナリを起動する機能だから
必要なのはそこにファイルがあることだけ
それもchrootなどの機能で昔からLinuxは対応してる

chrootというのは指定したディレクトリ上にOSのファイルを置いて
そのディレクトリをルートディレクトリとしてバイナリを動かすこと
chrootで起動するためのディレクトリを作る機能がそのままWSLに応用できるわけよ

WSLにインストールされる環境でいちいちchrootなんか使っていないし
WSL環境に固有の設定はインストーラ側で対応だし
何言ってんのコイツ

WSLのchrootとqemu-user-staticでラズパイのエミュレーション環境を作ったけど？
ARMのバイナリをコンパイルするだけでなく、そのまま動作させることもできた。

>>763
chrootしたことある？
どうやってchrootするためのディレクトリ作るよ？
なんかのツール使ってしかやったことなさそうだね

やり方は簡単。
/procや/devといった特殊なもの以外を特定のディレクトリにコピーする
/procや/devはバインドマウントするだけ

たったこれだけで新しい環境でバイナリが起動できるんだよ
Linuxはそういう事ができるように作られてる

WSLでやるのはこの環境を作るだけ。Linux側の対応は既に出来てるから不要

chrootおじさんはchrootで時代が止まってそう

なんでそう思うんだ？普通にDockerも使ってるが？
Docker（コンテナ）も根底にはchrootと同等の技術が使われてる

コンテナはchrootの発展だからな。ディレクトリの分離だけでなく
リソースの分離まで行うのがコンテナ技術

温故知新っていうやつだな

chrootの使い方なんか誰も聞いていない

現状のWSLでもxrdp経由でグラフィカル環境を実現することは可能だが(君には難しくて無理ということだが)、
WSL側でお仕着せの統一的な環境が容易されるようになれば、ディストリ側のインストーラーが対応することでこれまで自力では設定できなかった馬鹿な奴ら(君のことだよ)でもグラフィカル環境を扱うことができるようになるだろう
それは善い事なので、妨げるまでもない…という話に、なぜchroot?

頭おかしいだろ

Androidタブレットにchrootで既存のディストリ環境を導入するアプリは利用していてそれなりに便利に使ってはいるが、
それはAndroidでARMだからという環境に強いられた、消極的な理由でしか無いしなあ…
x86ならdockerでいい(dockerの方がいい)
Windowsと言わず、chromebookですらそうだ

>>769
> ディストリ側のインストーラーが対応することで
だからそんな必要がないという話

WSLはディストリ側から見れば単にファイルを置いてるだけに過ぎない
Linuxは単に実行ファイルを置くだけで動くように作られてるんだよ。

ここに仕組みが書いてあるな

https://news.mynavi.jp/article/20200927-windows10report/
> WSLGは隔離されたコンテナのように動作し、Linuxディストリビューションとはソケットによる通信を行う。

Linuxディストリビューション（のデスクトップアプリ）はソケット通信するだけ
だからディストリ側のインストーラーがやることなんてなにもない

WSLG、これはMSが用意するWSL上で動くコンテナ。
ディストリで提供されるデスクトップ用実行ファイルは
ソケット通信でこの用意済みのWSLGコンテナと通信するだけ

>>769
お前Linuxでデスクトップ表示する仕組みを知らんだろ？
その仕組に則ればディストリ側は何もすることがないんだよ

WSL側でお仕着せの統一的なデスクトップを表示するための環境が用意してあって
そこにソケット通信するだけだから

そのWSLGはいつ出るんだろうな

そのソケット通信をディストリ側が実装なりなんなりしないとあかんのちゃいますん？

>>774
5月に発表があった時、年内に進捗を報告する見通しって言ってたじゃん。まだまだよ。
https://www.publickey1.jp/blog/20/wsl_2linuxguimicrosoft_build_2020.html

と言ってもWSLも発表されて数年で実装されたし
WSL2も発表されて数年で実装されたし、
今までの実績からいって何年もかかるってことはないだろ
それぐらいMSの開発スピードは速い

>>775
それは既にアプリに実装済みで、その仕組を使ってLinuxのデスクトップは表示されてる。
ソケット通信の先をMSが作るだけ

>>771
実行ファイルに通信先のソケットのポートやプロトコルを教えてやる設定はどこに置いて、その設定は結局誰が書くんです？

トンチンカンな問答を吹っ掛けられても、読まされるこっちが頭おかしくなりそうなのでアンカー飛ばして来ないでもらえますかね、キチガイ。

ゲストOSからrdp鯖やpulse鯖に見えるWSLGをこれからMSが用意するので
ゲストOSのディストリビューターはWSL環境にインストールされた際にこれらを利用する設定を作らないと、
(僕は自力で設定できるが)馬鹿な君らには「WSLでは、グラフィックが使えない。」という状況が変わらない。

ゲストOSやアプリからは既存のプロトコル互換に見えても、それらを利用する設定はユーザーなりディストリなりが明示しなければ、当然使えない訳だが。
ラズパイをヘッドレス運用する際にxrdp入れて使う設定だって、ディストリがxrdpの設定スクリプトや雛型を用意してくれているからバカチョンでできる訳でな
無かったら全部自分で用意することになる。俺はできるが、お前らは無理なんだろ。

>>778
お前バカだろｗ
環境変数DISPLAYで渡されてるのしらんの？

Linuxのデスクトップアプリはこの環境変数に設定されてる
IPアドレスに接続するだけなの

だからあとはWSLのinitでこの環境変数を提供して
接続先を用意するだけ

>>779
> ゲストOSからrdp鯖やpulse鯖に見えるWSLGをこれからMSが用意するので
> ゲストOSのディストリビューターはWSL環境にインストールされた際にこれらを利用する設定を作らないと、

不要。「これらを利用する設定」＝環境変数DISPLAYとXDG_SESSION_TYPE を準備するだけ
各ディストリのアプリはGUIを表示する時、DISPLAYに接続するように作られてる
それがもともとのLinuxデスクトップアプリの仕様だから
環境変数DISPLAYとXDG_SESSION_TYPEを用意するのはWSL（のinit）で実現できる

>環境変数DISPLAYで渡されてるのしらんの？
だからそれは一体どこの誰が用意して設定してくれるの？
お前が知らんうちに勝手に設定されていると思っているものは、誰かが検出して反映(するように設定)してくれたものだ
それは誰で、どこで、いつ設定しているの？

>Linuxのデスクトップアプリはこの環境変数に設定されてる
>IPアドレスに接続するだけなの

WSL環境なら接続先はlocalhostなんじゃね(鼻くそほじりながら)
もちろんLAN越しや、なんならWAN越しでだって設定はできますがね(君には無理かもしれないが)
IPアドレス(笑)よりもポートの方が問題だろ。どこで検出してどうやって伝達して環境変数に反映するんだよ

>だからあとはWSLのinitでこの環境変数を提供して
>接続先を用意するだけ

なんかもっと高度な話の可能性がミリくらい残っているかなと思ったが、とんだ買い被りだったようだ
やはりただ煽りたいだけの無知キチガイで結論。もう俺にアンカー飛ばして来るな

> ラズパイをヘッドレス運用する際にxrdp入れて使う設定だって

だからそれを全部MSが用意するって話なんだが
ディストリとは別に、RDP周りの設定が全て準備されてる仮想マシンをMSが１つ作って
ディストリ上で動くアプリは環境変数DISPLAYで指定された、そのMSが準備した仮想マシンにソケット接続するだけ

あとはMSが作った仮想マシンとWindowsホストとのやり取りで
ウインドウを表示するだけだな

>>782
> だからそれは一体どこの誰が用意して設定してくれるの？

書いただろ。ディストリ起動するときに実行されるinitが環境変数を用意する。
それは今も行われてる。WSL使ったことないの？
WSLのbashを起動したら、環境変数 WSL_DISTRO_NAME=Ubuntu-18.04 とか見えてるんだがｗ

> WSL環境なら接続先はlocalhostなんじゃね(鼻くそほじりながら)
それはWindowsホスト、つまりコマンドプロンプトから
WSL上で動いているサービスに接続する時の話
なーんもしらんのかｗ

「おれはインストールイメージファイルを利用しているのでインストーラーが走ることはない、はい論破」レベルのアホかと思ったが、
それ以前の馬鹿だった。

低レベルの話ができる奴なのかと思ったが全くの論外で、誰かのお仕着せのふしぎな仕組みをブラックボックスのまま使うだけの猿だった
いや狂犬か

訂正

それはWindowsホスト、つまりコマンドプロンプト"等"な
Windows上のブラウザから、WSLのサービスに接続する時もlocalhost
Windows上で直接動かしているように見せかけるのがWSLだからね

>>785
ほら。お前のレスが証拠。俺のレスの内容へのコメントがなくなったねｗ

環境変数DISPLAYも知らないレベルが相手だったのかねｗ

ゲスト側がWSL環境を想定していなくても誰かが勝手に適切なポートとアドレスを設定してくれるDISPLAY環境変数があるらしい
ふしぎだね！

馬鹿か

ああ、そうか、ディストリ上のGUIアプリと仮想マシンとの接続はソケット接続って書いてあるな
環境変数DISPLAYの値はlocalhost:0.0じゃなくてDISPLAY:0.0とかなんだろう
これならポート番号もいらんな。

Docker Desktop for WSL2のWSL2インテグレーションと近い仕組みかもしれないな
Docker Desktop for WSL2ではWSL1のときに必要だったDOCKER_HOST環境変数が不要になってる
どうやってWSL2上のDocker仮想マシンに接続しているかと言うと

ディストリの中でdocker-desktop-proxyというプロセスが動いていてソケット接続で待ち受けてる。
あとはディストリ内のDockerクライアントがソケット接続でdocker-desktop-proxyにつないで
それがDockerの仮想マシンにプロキシしている。
このdocker-desktop-proxyが必要なのはDockerだからであって
MSが作るなら9pプロトコルと同じようにinit自体に内蔵するだろう

つまり見た目上ディストリの中では特別なにかが動いているようには見えないが
ソケット接続で待ち受けていて、ディストリ上のアプリはそのソケットに接続するだけ

>>789
不思議でもなんでもないなｗ
WSLで起動するPID番号1のinitはMSが作ったinit
ディストリを起動するときに最初に起動するのがMSのinitなんだから
環境変数の準備なんて普通にできるよ

「MSが作ったinit」も、ディストリ側でそれを利用する設定でないとそもそも活かされない(WSLと協調できない環境がブートする)だけなんだよなあ
ファイルを置くだけでどうにかできる、環境変数が勝手に自動で最適な設定で入っている前提のボクちゃんには想像もつかないだろうが

>>792
MSが作ったinitは、WSLの各ディストリの（標準の /sbin/int ではなく） /init にコピーされて現在使われてるんですが？
ディストリ側で利用する設定になってなくても「WSL登場の最初から使われてる」んですが？

MSが作った /init は今現在、すでに使わてるんですが何を言ってるんですか？

>>792
ディストリの中身は気にしなくていいんだよ
rootfsを作ってインポートするだけでいい
妄想じゃなくて試したら？

WSLの特徴は仮想マシン上にディストリを"インストール"してないこと

もしこれが一般的な仮想マシンのようのディストリをインストールしていたら
インストーラーが起動して、各サービスも起動して・・・
でもそれらはWSLにとっては不要だから無効にしてと
ディストリのインストーラーに対していろんな調整が必要になる

WSL1は単にLinuxバイナリを起動するだけ
WSL2は仮想マシンこそ使われてるがWSL専用の軽量Linuxが動いていて
Ubuntuなどのディストリはコンテナ技術を使って起動するから
こちらもディストリのインストーラーは使われない
WSLの仮想マシンはたった１つだけで、複数のディストリから
たった１つの仮想マシン上のLinuxを共有している

WSLGもそのたった1つのLinuxで動作する
各ディストリの各アプリは、そのたった1つのLinuxにソケット接続する

妄想独演会は終わったかい？

その妄想とやらに反論がないなら、正しかったことで
終わりってことでいいんじゃない？ｗ

>>792
自分でWSL用ディストリを作ったことのない馬鹿の妄言

wsl2
20211で起動しなかったから20206で更新止めてた
なんか20206でも起動しなくなった
20226で治ったとか見たから更新したけどやっぱ起動しない
助けて

初期化しよう

初期化って何の初期化ですの

wsl1に戻すと一応起動はしたしフォルダアクセスできたから中身は回収したとしてなんか挙動が変だからwls2に戻したい
もうイライラしてwsl自体嫌になってきた助けて

https://www.atmarkit.co.jp/ait/spv/1807/06/news028.html

入れ直せってことか
20206ならwsl2で立ち上がるのもあるし駄目なのもあるから入れ直すのはありかもしれんけど
20226は全部無理だから多分入れ直しても無理ですわ
週末までにfixされなかったら20206でやり直すか…

RPCが失敗とかいうメッセージが出て起動しない件なら、20206からの問題のはずだからそのビルドに戻すのは悪手なんでは？

その他なら「起動しない」だけではエスパー出来ん

The Windows Subsystem for Linux instance has terminated.
ってメッセージできて起動できなかったんだけどlsxxmanager起動し直したら20226で起動したわ
wsl-terminal使ってたけどそっちからはwsl2起動できないわwsl1はできるけど
でもまあそれ使う必要ないから一応使える状態なったわ

wsl-terminalの方は付属のwslbridge2が古いからっぽいね
20226上でwsl-terminal 0.9.2 + wslbridge2 0.6(別途入手してファイルを上書き)はWSL2に接続できたよ
確かにwsl-terminal 0.9.2だけだとWSL2には接続できない

↑情報ありがとう

Dドライブをまるごとext4に出来るのは次の大型アップデートで来るの？
早くしてくれ
今はWindowsのパスそのままマウントしてるけど遅すぎて使えんわ

>>810
Build 20211 で使えるようになってるようなので、次の Update には入るのでは？

>>810
アホかｗ NTFSの方が速いのにext4にしたって意味ないだろｗ
遅いのはネットワーク通信してるから
速度早くしたいならWindowsのパスをマウントしないようにすればいいだけの話

>>812
容量がほしんでないの？ あと、NTFS側には大抵ウイルス対策ソフトが入っているから、その影響で結構遅い。

ガチウイルスソフトなんて入れる奴が悪い。
プライベートでならDefenderで十分だ。

誤検知多すぎてな

Defenderであろうがファイルシステムにフィルタかましてるのは一緒

なぜLinuxサーバはアンチウィルスが不要なのか？
https://web.archive.org/web/20150219021906/http://www.tepa.jp/technical_abc/linux_anti_virus-01.do

OSSなんてマルウェアだらけじゃないの

流石に2008年の記事は情報が古いんじゃない？

Windowsユーザばかりが、ウィルスを取っていくなんて狡い。
Linuxユーザだって少しは楽しんでもいいではないかと私は思うのである。それだからというわけではなかろうが、　Wineプロジェクトに携わる人たちのお陰で、
Linuxユーザも「ウィルスを捕まえる」ことができるようになった――とはいっても、
ささやかなものではあるが。

ことウィルスに関する限り、Linuxはユーザ・フレンドリでは全くない。
何せ、ウィルスを探し出して動かす必要があるのだ。Windowsなら、ウィルスが勝手に動いてくれるというのにだ。
GNU/Linuxの開発に携わる者は、この歴然たる落差を埋めるべく善処すべきである。

しかし、ウィルスを集めている我が友人たちを煩わせる必要はなかった。
bogofilterで選り分けたメールの分厚い束をひっくり返すと、ウィルスが大量に見つかったからだ。
そこで、APTで手に入れたClamAVに私の「スパムやら何やら、
読みたくもないゴミ・メール」コレクションを料理させ、6つのウィルスをつまみ出した。
いずれもWindows専用だが、その「専用」ぶりを、これから確かめようというのである。

https://mag.osdn.jp/05/01/31/0346216

なぜLinuxサーバはアンチウィルスが不要なのか？
https://web.archive.org/web/20150219021906/http://www.tepa.jp/technical_abc/linux_anti_virus-01.do

なぜLinuxサーバはアンチウィルスが不要なのでしょうか？
それはサーバーだからです。
サーバーでは未知のソフトを動かすことはほぼありません
予め決めたソフト（例えばサーバーソフト）を動かすだけです。

そのためサーバーに必要なのはアンチウイルスではなく
動かしているソフトに脆弱性がないか調べたり
新たに脆弱性が見つかった場合いち早く更新するという作業が必要になります
それの作業がアンチウイルスソフトと同等のものになります。

bashの脆弱性何年か前に見つかったなぁバッシュショック
phpやperlなんかも

「LinuxよりもWindowsは安全」なのか
https://enterprise.watch.impress.co.jp/cda/infostand/2005/04/04/4978.html
LinuxデスクトップはWindows 10より安全性が低い？
https://kledgeb.blogspot.com/2017/02/linux-5-linuxwindows-10.html
2019年、WindowsはLinuxよりも脆弱性が少ないOSだった。
https://wpteq.org/windows/post-57208/

なんか古臭い記事だな…と思ったら、2005年かよ

2005年ごろってLinuxカーネル2.6だったな。
3.0になるまで長かった。

wsl2でXmonadかi3使えますか？

WSL2を導入してから、Windows上で使用していたメッセンジャアプリが
使用できなくなり困っています。具体的には、vEthernetに割当てられる
IPアドレスのためメッセンジャアプリが同一LAN内のメンバーを見つけ
られないという現象です。メッセンジャ側の複数IP対応の問題かとは思う
のですが、今後アップデートも望み薄で、WSL2(vEthernet)側の設定で
何とかならないかと思い相談させて頂きました。ちなみにメッセンジャは
LightLine2というアプリです。

Windows上で使用するものならWSL2関係ないじゃん

>vEthernetに割当てられるIPアドレスのため

の意味がわからん
なんか競合してるってこと？

>>827
複数IP対応はしているようだけど Windows10は多分サポート外
作者に問い合わせればいいのでは？それかソフトウェア板へ

ネットワークメインのアプリでバインドするIPアドレス
NICが指定できないものがあったとしたら捨てたほうが良い

別のVPNアプリを入れててそっちのほうの問題だったり？

>>827
そもそも10対応してないじゃん

https://www.snowwind.net/application/lightline2/download.php

「LightLine 2」は以下のOS上で実行することができます。

・Windows 7
・Windows Vista
・Windows XP
・Windows 2000 (Ver2.30以下まで)
・Windows Me (Ver2.30以下まで)
・Windows 98SE (Ver2.30以下まで)

※64bit版でも動作する可能性はありますがサポート外になります。

WSL(て言うかhyper-v？)入れてからタスクマネージャーに大量のvEthernetが並んでるんだけどこれって非表示とかに出来ないの？

Even 2020 cannot bring forth the Year of Linux on the Desktop
https://www.theregister.com/2020/10/15/even_2020_cannot_bring_forth/

>>834
おま環

Windowsのデスクトップ上に
Windowsのファイルは勿論
Ubuntuのファイルも開くようにした
この方がデスクトップ切り替えなくても良いから便利
今更ながら気付いた

Canonicalのエンジニア曰く、WindowsがLinuxカーネルベースになる日は来ないだろうし、そうなるべきでもない
https://linux.srad.jp/story/20/10/18/0828242/

MS純正のWineみたいなのは作れないってことか？

hyper-vでやるか

>>839
.NET Coreに期待かな
まだGUIアプリは対応していないけどコマンドラインアプリは持ってきてそのまま動くよ

Monoでよくね？

>>841
まだってWPFにWIndows以外で対応する予定自体ないでしょ

Introducing .NET Multi-platform App UI
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/
マイクロソフト、新UIフレームワーク「.NET Multi-platform App UI」(.NET MAUI)発表。単一コードでマルチプラットフォーム対応。Microsoft Build 2020
https://www.publickey1.jp/blog/20/uinet_multi-platform_app_uinet_mauimicrosoft_build_2020.html

>>838
当たり前の話だよなｗ
WindowsがLinuxカーネルになるとか言ってるやつがアホなだけで

LinuxがWindowsカーネルベースになる日はいつ来そうですかね

WSL 1がそれになるはずだった

>>846
linuxがカーネルだから、それはlinuxではない

>>838
esrの名前久しぶりに見たわ
お元気そうで何より

>>847
WSL1はこれからも開発が続くって言ってるよ
WSL1がそれになるはずだったではなく
WSL1がまさにLinux（ディストリ）をWindowsカーネルで動かしたもの

Windowsのデスクトップ上でUbuntuのターミナルを開いたりファイルマネージャーを開いたり又Exelを開いたりしてるけどUbuntuのスクリーンショットで見るとUbuntuのデスクトップにはターミナルやファイルマネージャーだけ開いて見えるのな
でも実際にUbuntuのデスクトップに切り替えると何もない
つまりWindowsの仮想デスクトップに反映されているということで良いの？

>>851
どういう環境で何をやってんのか全くわからないからなんとも言えないよ

>>851
よう、ポルナレフ

>>147
自決。
vimを自コンパイルして8.2にしたら解決しました。
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 22 2020 02:34:54)

早まるな

早丸