【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と共有したいからそうしてるんだろ? ext4ドライブに移したら意味なくね? >>746 windows store使わないという意味ならできる What’s new in the Windows Subsystem for Linux - September 2020 https://devblogs.microsoft.com/commandline/whats-new-in-the-windows-subsystem-for-linux-september-2020/ GUI app support in WSL is becoming a reality! We are getting closer to an initial preview and happy to announce a preview release for Windows Insiders within the next couple of months. Below is an early look at an internal build running GUI apps in WSL! You can see that WSL will support many different types of applications, including IDEs running fully in a Linux environment. We have included lots of fit and finish details, such as showing the icons for Linux apps in the task bar and support for audio with your microphone (and yes, that really is the Linux version of Microsoft Teams running in WSL). https://devblogs.microsoft.com/commandline/wp-content/uploads/sites/33/2020/09/gif3.gif Stay tuned for more details about this feature coming soon. $ sleep 1 がいつの間にか動くようになってた 直ったのかな? wsl2 scp でファイル転送するとエラーになるときがある。 wsl1 では問題なし。 もうしばらく様子見かな。 Windows側のOpenSSH(scp.exe)をWSLで呼び出すとどうなる? いや、どうだったんだよw scp.exeで転送出来ないのか? 善きこと まあ自分でセットアップすれば同じ事は既にできるが、 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側でお仕着せの統一的なデスクトップを表示するための環境が用意してあって そこにソケット通信するだけだから そのソケット通信をディストリ側が実装なりなんなりしないとあかんのちゃいますん? >>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 お前バカだろw 環境変数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が1つ作って ディストリ上で動くアプリは環境変数DISPLAYで指定された、そのMSが準備した仮想マシンにソケット接続するだけ あとはMSが作った仮想マシンとWindowsホストとのやり取りで ウインドウを表示するだけだな >>782 > だからそれは一体どこの誰が用意して設定してくれるの? 書いただろ。ディストリ起動するときに実行されるinitが環境変数を用意する。 それは今も行われてる。WSL使ったことないの? WSLのbashを起動したら、環境変数 WSL_DISTRO_NAME=Ubuntu-18.04 とか見えてるんだがw > WSL環境なら接続先はlocalhostなんじゃね(鼻くそほじりながら) それはWindowsホスト、つまりコマンドプロンプトから WSL上で動いているサービスに接続する時の話 なーんもしらんのかw 「おれはインストールイメージファイルを利用しているのでインストーラーが走ることはない、はい論破」レベルのアホかと思ったが、 それ以前の馬鹿だった。 低レベルの話ができる奴なのかと思ったが全くの論外で、誰かのお仕着せのふしぎな仕組みをブラックボックスのまま使うだけの猿だった いや狂犬か 訂正 それはWindowsホスト、つまりコマンドプロンプト"等"な Windows上のブラウザから、WSLのサービスに接続する時もlocalhost Windows上で直接動かしているように見せかけるのがWSLだからね >>785 ほら。お前のレスが証拠。俺のレスの内容へのコメントがなくなったねw 環境変数DISPLAYも知らないレベルが相手だったのかねw ゲスト側が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 不思議でもなんでもないなw 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の仮想マシンはたった1つだけで、複数のディストリから たった1つの仮想マシン上のLinuxを共有している WSLGもそのたった1つのLinuxで動作する 各ディストリの各アプリは、そのたった1つのLinuxにソケット接続する その妄想とやらに反論がないなら、正しかったことで 終わりってことでいいんじゃない?w >>792 自分でWSL用ディストリを作ったことのない馬鹿の妄言 ___ / ⌒ ⌒\ / (⌒) (⌒)\ / ///(__人__)///\ 2万円のおせち料理が半額だったお | u. `Y⌒y'´ | これでお正月はばっちりだおww \ ゙ー ′ ,/ / __|___ | l.. /l ハワイアン`l ヽ 丶-.,/ |__ おせち _| /`ー、_ノ /  ̄ ̄ ̄/ ________________ |\ ‖ /| | ( ̄肉)_/ ̄V ̄ヽ_ ‖_____∠ | | ( ̄肉) | ,ォ ≠ミ .‖ i\チーズ| | | |`ー´ .|〃 yr=ミ:、‖-ー、\.\ /l | | |( ̄肉) iイ {_ヒri}゙‖ ハム ) \l/l .| | | `ー´ ヾ」^ヽノ‖ヽ_ノ .|__| |\ ̄ ̄ ̄ ̄ ̄ ̄ ̄‖ ̄ ̄ ̄ ̄ ̄ ./| | ┌/⌒⌒⌒⌒ヽ.‖ ̄ ̄ ̄ ̄ ̄ ̄| | | ( {ニニニィ )‖ l⌒l| | | |\ ∨ }/‖ .ィ ≠ミ、| | | | ヽ ゙こ三/ ノ‖ く`ヽ、!/行ミt)| | | | ヘ ノ |‖ .\ ゙.ヒrリ.》 | | ┼ヽ -|r‐、. レ | | | `ー^ー'‖ `ヽノ  ̄Y | . d⌒) ./| _ノ __ノ wsl2 20211で起動しなかったから20206で更新止めてた なんか20206でも起動しなくなった 20226で治ったとか見たから更新したけどやっぱ起動しない 助けて wsl1に戻すと一応起動はしたしフォルダアクセスできたから中身は回収したとしてなんか挙動が変だからwls2に戻したい もうイライラしてwsl自体嫌になってきた助けて 入れ直せってことか 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 アホかw NTFSの方が速いのにext4にしたって意味ないだろw 遅いのはネットワーク通信してるから 速度早くしたいならWindowsのパスをマウントしないようにすればいいだけの話 >>812 容量がほしんでないの? あと、NTFS側には大抵ウイルス対策ソフトが入っているから、その影響で結構遅い。 ガチウイルスソフトなんて入れる奴が悪い。 プライベートでならDefenderで十分だ。 Defenderであろうがファイルシステムにフィルタかましてるのは一緒 なぜLinuxサーバはアンチウィルスが不要なのか? https://web.archive.org/web/20150219021906/http ://www.tepa.jp/technical_abc/linux_anti_virus-01.do 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なんかも 2005年ごろってLinuxカーネル2.6だったな。 3.0になるまで長かった。 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が並んでるんだけどこれって非表示とかに出来ないの? Windowsのデスクトップ上に Windowsのファイルは勿論 Ubuntuのファイルも開くようにした この方がデスクトップ切り替えなくても良いから便利 今更ながら気付いた Canonicalのエンジニア曰く、WindowsがLinuxカーネルベースになる日は来ないだろうし、そうなるべきでもない https://linux.srad.jp/story/20/10/18/0828242/ MS純正のWineみたいなのは作れないってことか? >>839 .NET Coreに期待かな まだGUIアプリは対応していないけどコマンドラインアプリは持ってきてそのまま動くよ >>841 まだってWPFにWIndows以外で対応する予定自体ないでしょ >>838 当たり前の話だよなw WindowsがLinuxカーネルになるとか言ってるやつがアホなだけで LinuxがWindowsカーネルベースになる日はいつ来そうですかね >>846 linuxがカーネルだから、それはlinuxではない >>838 esrの名前久しぶりに見たわ お元気そうで何より >>847 WSL1はこれからも開発が続くって言ってるよ WSL1がそれになるはずだったではなく WSL1がまさにLinux(ディストリ)をWindowsカーネルで動かしたもの ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる