【Bash】Windows Subsystem for Linux【WSL】6
■ このスレッドは過去ログ倉庫に格納されています
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】5 https://mao.5ch.net/test/read.cgi/linux/1553100855/ Windowsで(おそらく)実績がない9pではなく NFSとかCIFSとかあるだろう procfsやsysfsも公開できるからって話が前にスレで出てたような >>640 それただのネットワークファイル共有プロトコルじゃん 9pはネットワーク共有プロトコルだぞ? https://ja.wikipedia.org/wiki/9P > 9P (または Plan 9 Filesystem Protocol または Styx) https://www.atmarkit.co.jp/ait/articles/1903/01/news043.html > WSL$は、9Pと呼ばれるファイル共有プロトコルを利用する。 9PはNFSとかよりも抽象的なファイルも扱えるんだろ >>644 >9PはNFSとは異なり、キャッシュや、仮想ファイル(例えば、プロセスを表現する/proc)の提供も補助する。 >9Pが選ばれたのは、/procファイルシステムなどの疑似ファイルシステムを扱えるのが大きな理由だと考えられる。 なんでそれぞれの文章の直後にこう書かれているのにそこは無視するわけ? 単にネットワークファイルシステムだぞ 642が意味不明だ >>648 9pはvirtfsで使われているので「ただのネットワークファイル共有プロトコル」ではないが >>646 その記事を書いた人の考えてることを根拠にされても困るんだがw WindowsからWSLの/procを参照できることがなんで重要なの? virtfsで使われてるただのネットワークファイル共有プロトコルだぞw >>649 意味がわからない 「ただの」になんかすごい深遠な概念が含まれてるのかも知れんが俺は脳を共有してないので説明されないとわからん 1. 9pはネットワーク共有プロトコルである 2. だがvirtfsで使うと、そのネットワーク共有プロトコルをネットワークを介さないで使うことができる 3. つまり9pはネットワーク共有プロトコルではない 4. だからvirfsを使わなくても9pはネットワーク共有プロトコルでなくなるのだ! こういう発想かねぇ? バカだな >>654 ホストとゲストでファイルシステムを共有するプロトコルの話でなかったらなんの話なの? >>656 ホストとゲストでファイルシステムを共有できるプロトコルには NFSやCIFSなどがありますって話だろ >>657 NFSやCIFSはネットワーク越しにファイル共有するためのプロトコルでそういう実装しかないんじゃないの? なんだこいつ?そんなんパッチ当てれば済むだろ。 virtfsだってパッチ当てたんだろうし 実績ってまさかvirtfsの話? WSLはvirtfsじゃないってさっき言ったよね? まさか関係ないものが実績になると思ってんの? qemu/kvmでlinuxゲストホスト間のファイルシステム共有プロトコルとして使われている9pがwslに無関係なら ネットワークファイル共有でしか使われてないNFS、CIFSなんかもっと関係ないが? Windows Subsystem for Linux 2のメモリ管理を詳しく見る https://ascii.jp/elem/000/001/981/1981180/ いい加減そろそろ1つくらい、SMに走らないレズ陵辱ゲーがほしいわ 暴力方向や、わざとらしい首輪つけてペット化とかしなくていいんだよ よくある男女の陵辱物みたいに、弱みを握ったり、立場を利用したりする感じで、 ノンケのヒロインたちを犯して肉体関係を持ち続けるような作品がほしい ヤるシーンだけの関係じゃなくて、ヒロイン達の日常生活に侵食していったりすると尚良し WindowsユーザーやLinuxユーザーにとって WSLなんてレイプ以外の何物でもない 俺には文句言うくせに >>664 はお咎めなしかよ ダブスタだな お咎めなしじゃねーだろ >665で速攻つっこまれてんじゃん ごめん >>665-666 にも突っ込めって意味ね 客観的には >>664 が一番悪い 二番目は >>666-667 三番目はおまいらが無駄レスしていること同じ罪 10スレも消費するようなことじゃない そこで「お前ら」じゃなくて「俺ら」って言えてればまあ説得力もあるんだがな まほうのことば rm -f / でたのしいなかまがポポポポーン dd if=/dev/zero of=「流石に伏せ字」 ぐらいいかないと 失礼しました。 >>678 を "まほうのことば rm -rf / でたのしいなかまがポポポポーン" に訂正いたします。 onedrive上に構築したwslを同期した他のpcで lxrunoffline register すれば同じ環境に なりますか? 今のバージョンならlxrunoffline使わずexportしてimportで良いやろ \\wsl$\ってsymlink対応してないのか? Preztoを入れた環境で.zshrcや.zpreztorcにアクセスできず.zprezto/runcomsからたどる必要がある \\wsl$からfuseでマウントしたディレクトリに入れないな WSL 2、実はWSLからパフォーマンス向上ほとんどなし? 2019/12/16 10:23 後藤大地 https://news.mynavi.jp/article/20191216-938538/ Phoronixは12月11日(米国時間)、「Windows Subsystem For Linux Performance At The End Of 2019 - Phoronix」において、開発段階にあるWindows 10のWSLWindows Subsystem for Linux 2と、 すでに出荷されているWindows 10のWSLのパフォーマンスなどの比較結果を伝えた。WSL 2はWSL よりもファイルシステム性能が大幅に向上すると考えられているが、ベンチマーク結果からはそれほどの 性能向上が計測されなかったようだ。(中略) ベンチマークは多方面にわたって実施されている。それぞれのベンチマーク結果のポイントとして、以下が 紹介されている。 ・Windows 10 Build 19008は、Windows 10 Build 18362よりも概ね優れた性能を示している ・Windows 10 Build 18362 WSLとWindows 10 Build 19008 WSLにはほとんど性能差が見られない ・Windows 10 Build 19008 WSL 2は、WSLよりも少しだけ性能が良くなっている。特に高負荷I/Oと ネットワークアクティビティが引っ張る形で性能を引き上げている MicrosoftはWSL 2はWSLよりも高いファイルシステム性能を実現するとしていた。しかし、実際に計測 されたベンチマークでは、ファイルシステムI/Oの特定のマイクロベンチマークで性能の向上が確認されて いるだけで、全体的に見るとそれほど性能の向上が確認できない状態になっている。 WSLはWindowsでLinuxバイナリを実行するための技術。WSLはレイヤ技術およびコンテナ技術を使って おり、WSL 2はHyper-Vによる仮想環境技術を使っている。MicrosoftがWSL 2でWSLとまったく異なる アプローチを採用した理由は不透明。その理由の1つとして、ファイルシステムの性能向上があったが、 当初言われていたほどファイルシステム性能は向上しない可能性が出てきた。 WSL 2は2020年5月または6月に公開が予定されている次のWindows 10フィーチャーアップデート での導入が予定されている。 >>692 > ・Windows 10 Build 19008 WSL 2は、WSLよりも少しだけ性能が良くなっている。特に高負荷I/Oと > ネットワークアクティビティが引っ張る形で性能を引き上げている だから性能が良くなってるんじゃねーの? 結論はそれだろ? なんで反対の結論になってるんだ? >>694 読んでないのに言うのはなんですが、 I/Oについては、高負荷時でなく、通常時も遅いことが問題視されていたのですから、そこのところが含まれていなければ、期待はずれということになります 負荷が低いときのI/Oとかどうでもいいわw 必要なときに重いもの(ボトルネック)が軽くなってる。それが重要でしょう? 言うほど性能上がってなかったって話を まるで以前より性能が低下したかのように思わせる WSLにパフォーマンスは期待してないんだよな ただIOが遅すぎるとパッケージをインストールやアップデートするのにも時間がかかって煩わしさがあった パフォーマンスに期待しないと言いながら遅いのは嫌だと言う 自己矛盾に気が付かないない阿呆 >>701 「遅いのは嫌い」=「パフォーマンスに期待してる」ってことなのか? 例えば「まずいのは嫌い」=「天下一品の味でなければいけない」 そういう意味だと思う? パフォーマンスに期待 は 最高レベルを望む という意味ではない ファイルシステムのI/Oに関しては9pプロトコルの登場で WSL2の登場を待たずして解決したようなもんだと思ってるんだけどな Windowsとのファイル共有で使っていたDrvFSは遅いけどVolFSは速いわけでしょ? そのVolFSにWindowsからアクセスできるようになったんだから Windows上高いパフォーマンスが必要ならDrvFSを使う Linux上で高いパフォーマンスが必要ならVolFSを使う この使い分けだと思うけどね WSL2はLinuxの互換性の向上とDocker Desktop for WSL2に期待してる Docker Desktop for WSL2はWSL2の機能を使って実装されてるから 起動速度アップとメモリ使用量の低下が期待できる。 必要なときに必要なだけ確保するから、仮想マシンにメモリを 大量に割り当てておくという必要がなくなるからね これは普通の仮想マシンを使ってるmacOSにはないメリット 9pを採用したWSL2がそれほど早くなかったって内容じゃないのか そもそもVMのIOが遅いのは分かってるのでWSL1よりどの程度改善されるかなんだよ >>706 9pプロトコルはwindowsとのやりとりの話で 今回の話とは関係ないんじゃないのか こんなの見つけた。やっぱりWSL2+ext4はnative linuxに近い速度なんだな https://vxlabs.com/2019/12/06/wsl2-io-measurements/ WSL1 lxfs を WSL2 ext4 に変えても2倍の速度になったりしないよ。 なぜならnative linuxに変えても2倍の速度にはならないんだから(笑) lxfsは元から速かったが、WSL2でほぼLinuxの速度になった macOS Catalinaで2月3日以降、野良アプリが動かなくなるらしい Homebrewで入れるアプリも対象だろうから ますますWSLに移行する人が増えそう スレ違いの上に動かなくならないぞ Appleにアプリ提出する時のチェックが厳しくなるだけ wsl1 がらみで申し訳ないが、 wsltty の 3.0.5以降、最新の 3.1.0.2まで、 コンテキストメニューでディレクトリから呼び出した時、PATH の先頭に $HOME/bin が反映されない。 もともとの WSL のコンソールをコンテキストメニューで呼び出すと反映される。 3.0.2.3 だと、問題ない。 コンテキストメニューからの呼び出し(コマンドライン)は "%LOCALAPPDATA%\wsltty\bin\mintty.exe" ^ -i "%LOCALAPPDATA%\wsltty\wsl.ico" --WSL= ^ --configdir="%APPDATA%\wsltty" ここで立ち上がった wsltty 上で、 echo $PATH うちの環境だけなのかな? $HOMEという環境変数使わず、/home/hoge/binとかにするとどうなる? >>713 レスありがとう。 それを最初に直接 .bashrc でエクスポートしたんだけど、 今度はもとからのWSLコンソールで、二重にPATHが設定されてしまった。 原因自体は、ログインシェルが起動できていないためじゃないかと目星をつけて、 調べていたら、対処方法もわかった。 結論から言うと、wsltty(mintty)の仕様変更があったようで、 ログインシェルにするのに別途新たにオプション "-" を付けることが必要になったようだ。 "%LOCALAPPDATA%\wsltty\bin\mintty.exe" ^ -i "%LOCALAPPDATA%\wsltty\wsl.ico" --WSL= ^ --configdir="%APPDATA%\wsltty" - 同梱のコンテキストメニューを追加するスクリプトはそれに合わせて変更されているんだけど、 自分は以前のオプションのまま、改めてスクリプトを実行していなかったので、 ログインシェルが起動せず、ユーザー環境が反映されていなかった、ということだった。 とはいえ、アップデートのたびにコンテキストメニューのことまでは考えないよなぁ。 ちなみに、wsltty-3.1.0.2 の config-distros.sh、229行目に変更箇所がある。 > bridgeargs=" -" # now used to request login mode wsl2はパフォーマンス向上よりも互換性の改善がメインの目的だから別にいいのでは wsl2だとNICの帯域制限も出来るんだっけ? WSL1はdevice io がサポートしていなかった >Our top requests from the WSL community have been to increase the file system performance, >and make more apps work inside of WSL (i.e: introduce better system call compatibility). >We have heard your feedback, and are glad to announce that WSL 2 helps solve these issues. パフォーマンスの改善も互換性の改善も両方同列 怒らないで教えて欲しいんだが 何でお前らMacにしないの? >>720 もうUnixの時代じゃないからだよ。Linuxの時代。 UnixはFreeBSDかOpenBSDがわずかに生き残ってるだけ macOSで何ができるかって言ったらそのBSDのマネごと しかもBSDとして使うと遅い 世の中がLinux(とWindows)の世界なのに 今更BSDを使う意味がない。Homebrewでごまかしてきたけど WSLに逆転された。WSL2登場でますますWindowsが有利になる。 WSL2の仮想マシンを使うからDockerは起動は速くなり、 WSL2が不要なメモリを解放するからメモリ使用量も大きく減る。 WSL2はDockerとの相性が抜群。 それにたいしてmacOSのDockerは仮想マシンに数GBのメモリを 割り当てないといけない。使わなくても割り当てる必要がある。 メモリ搭載量の少ないノートでは致命的 >>723 が完膚なきまでに論破しててワロタ そう、Dockerのこと考えたらMacはないんだよな iOSの開発という苦行をやらざるを得ない人以外にはMacを買う理由がなくなった ※スタバどや除く 2010年までのMacBookなら、メモリ増設も ストレージ増設も簡単。 タイムマシンで外付けHDDに待避すれば 機種変更するのも簡単。 今の機種は、メモリもストレージも増設不可。OSも旧機種には入れさせない。 最後のキラーアプリNiktoがWSLで動けば、 Mac持ち歩く理由がない 俺はMacのParallels上のWin10でWSL動かしてるわw WSL2の方が速いけどメモリ喰う。 Wineが動いた時はワラタw Dockerもそこで動くけど、今まで通り普通にMacのCLIで叩いた方が楽。 OSどころかハードまで囲い込みされたくない macOSを使ってほしいなら以前のように互換機を認めろっとことさ >>729 では聞きたいが MBP/MBAより優れているハード iPadより優れているハード iPhoneより優れているハードが 現実に存在するかね? >>730 MBPは優れたハードだと思うけど個人的には高過ぎて選択肢にならんな 16インチメモリとSSD換装できるなら買うんだけどなぁ Apple製品興味ないから知らんけど 高くて性能良くて融通効かない純正より 安くて性能そこそこで痒いところに手が届くリーズナブルな互換機使いたい層もいるんでないの? Apple純正品に興味ないから知らんけど CDNやってる企業は今もBSD使ってるよね ネットワーク周りでLinuxに対して優位性があるのかな スループットにおいてはBSDの方が有利と言われてる。 スケジューラの実装がLinuxとはまた違うから。 YAMAHAのルーターとかはBSDやね nmapでスキャンすると癖が出る。 Macはタイマーの精度がAT互換機より 高いので、DAW系でProTools使う人には 有利なんて話は聞いた事がある。 メモリ32GBぐらいは積めるノートを安価に 且つ最低10年使えれば需要はあるかも BSDは軽くてCLIベースならいいけど、 macOSはBSDをベースにしてるってだけでBSDじゃないからね 自称UnixのくせにCLI環境はCygwinなみに遅い BSD使ってたのはライセンスの理由がでかかったと思うわ カーネルもいじりやすかった 性能はもう関係ないと思う ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる