【Bash】Windows Subsystem for Linux【WSL】5
■ このスレッドは過去ログ倉庫に格納されています
>>509 とりあえずこの辺かな。 http://hayabusa6.5ch.net/test/read.cgi/linux/1459317475/538 > いくつかのベンチマークの結果、WSLは同じハードウェアで直接実行したときに近い結果をたたき出し、WSLはよい結果を出したとThomas氏は言う。 VMみたいにイメージファイルにもろもろ突っ込んでしまうではなかろうか? じゃないと散々苦しんだこの問題は解決しないと思う。 今まで通り、C:は/mnt/cとして、WSL側もUNCパスを参照できるだろう。 >>510 それは「速度も互換性もネイティブ並み」なんて 一言も書いてないって証拠ですか?w WSLってディストリの概念があるのが凄い気持ち悪いんだが SlackwareとかGentooとかArchみたいな、ミニマルな構成だけ提供すれば良いのに >>512 それならWindows側からの参照するのにsamba相当のものが必要になるよね >>512 おそらくそうだろうね。Windows上のファイルである限り、 ファイルごとにセキュリティソフトが反応してしまう セキュリティソフトの検閲を回避するには1ファイルにするしか無いw ま、それをやったとしても、Windowsのエクスプローラーから Linux内にあるファイルを参照できるようになりますからね。 WindowsからLinuxファイルへのアクセスが可能に 〜「Windows 10 19H1」におけるWSLの改善 https://forest.watch.impress.co.jp/docs/news/1170221.html 正直↑のリンク先に書いてある > この機能は「WSL」を初期化する際に「9P」プロトコルのファイルサーバーを起動し、 > それを介してファイルを扱うことで実現されている。そのため、Windowsからアクセスできるのは > 現在のところ、動作中のWSL/Linuxディストリビューションのみとなる。 この制限が腑に落ちなかったんだよね。なぜならWindows上にファイルは有るわけで 動作中のWSL/Linuxディストリビューションに限る必要はないはず。 またWSL上で9Pプロトコルサーバーを動かす必要もないはず。 (だってWindows上から直接参照できるのだもの) WSL2の発表でその理由がわかった。WSL2のLinuxカーネルにデバイスファイルとして マウントさせる仕組みにも使うから、WSL上で9Pプロトコルサーバーを動かすほうが楽なわけだ。 >>514 > WSLってディストリの概念があるのが凄い気持ち悪いんだが それはWSLのせいじゃない。Linuxがそもそもディストリの概念があって Linuxカーネルと、そのカーネルで動く各種アプリ・コマンドが 分かれて提供されてるのが原因 まあそのおかげでMicrosoftは最小限のLinuxカーネル部分だけを提供すれば あとは既存のディストリの成果をそのまま使えるわけなんだが >>516 > それならWindows側からの参照するのにsamba相当のものが必要になるよね それがWindows 10 19H1でリリースされる9Pプロトコルのファイルサーバー samba相当のものが内蔵されてるから、自分で仮想マシン作って構築するより使い勝手が良い >>518 WSL from scratch があっても良くない? 何でNFSじゃなくてわざわざ9Pを実装してるんだろうね? Win側のNFSクライアントの使い勝手が悪いんだろうか >>520 マイクロソフト「いいんじゃね?そういうディストリも普通に作っていいよ。 ただし我々は、Linuxカーネル相当のものを提供するだけではなく 開発者にとって便利なように、完成されたLinuxディストリを提供する。 その一つとしてUbuntuだ。だが君がfrom scratchを作ることに否定はしない」 >>521 WindowsじゃなくてNFS自体の問題 https://ja.wikipedia.org/wiki/9P > ファイルはウィンドウ、ネットワークの接続、プロセスや、その他オペレーティングシステムで > 利用可能なほとんどのものを表現している。 9PはNFSとは異なり、 > キャッシュや、仮想ファイル(例えば、プロセスを表現する/proc)の提供も補助する。 ここにも書いてあるな https://ascii.jp/elem/000/001/818/1818008/index-2.html > Linux/Unixで一般的なNFSを使わなかったのは、9Pが >疑似ファイルシステムなどもサポートできたこと、 >ファイル共有プロトコルとしては軽量だったことが理由と考えられる。 > そのソースコードの由来はともかく、マイクロソフトはWSLで > 9Pプロトコルを扱えるようにした。また、/initプロセスで > 9Pファイルサーバーを動作させるように改良した。これにより、 > WSL側は、VolFs(ルートディレクトリ以下)や/proc、/sysなどの > 特殊ファイルシステムを含めて、Win32側からアクセスを可能にした。 このリンク先に有る図の構成は、おそらくWSL2でも近い形で流用されるのだろう。 この9Pサーバーを実現したことが、WSL2での開発の流れにつながってるのだろう。 > Win32側は、9Pプロトコルのクライアントをリダイレクタードライバーとして実装した。 >これは、C:\windows\system32\driversにある「p9rdr.sys」が対応している。 >このp9rdr.sysは、リダイレクタードライバーとして組み込まれ、ネットワークフォルダーに「wsl$」ホストを見せるようになっている。 > > p9rdr.sysと/init(9Pサーバー)の間は、AF_UNIXによるプロセス間通信を使う。AF_UNIXは、 >ソケット(バークレーソケット)を使う場合に同一マシン内のプロセス間通信に使う >「アドレスファミリー(Address Family)」である。これは、Windows 10 Ver.1803(RS4)で >Windows側とWSLに実装された機能だ。このときには、何に使うのかが見えていなかったが、 >実はこうした用途が想定されていたというわけだ。 いろいろつながってるよね。 >>525 サンクス、なるほどね 仮想マシンに移行するならWin側から/procや/sysは触れる方が良さそうだね 今更WinSockがUNIXソケットに対応して何が嬉しいのかわからんかったけど、なるほどそういうことだったのか・・・ DockerやFUSEが動いてCoderでVSCodeも使える。 それまでの開発ツールを一つの場所に集約できる。 インポート・エクスポートもできて環境のバックアップや以降も簡単にできる。 いいことずくでこれからWSL使う人増えるんじゃないか? /procなんか、一部はWindows側の情報を見せるんじゃないかね? cpuinfoとかmeminfoとか。 そうするとWSL側から、Windowsのプロセスを見れたりするかもしれないな。 これはただの仮想マシンじゃ無理な所でLinuxカーネルを最適化するっていうのは こういうところなのかもしれない。 /procを通してWindows側と連携できるとなると、 分離されたシステム空間で動かすVMとは仕組みが全然違ってくるな。 >>527 残念ながらCoderは VSCode Remote Development と Visual Studio Online が発表されたため一ヶ月以内には終了すると思われる いまやMS WindowsのソフトすらもLinux上で開発する奴が増えたからMSがこれはやばいよとなって MSの物ならPC系Linux、組み込みも簡単に開発出来るんだにしようと必死しているからな VSCode Remote Development、 Visual Studio OnlineとかさすがMSだよな まぁ、開発をしない普通のLinuxユーザー(ただクレ乞食)をMSに取り込む気はないだろうが、開発をやっている連中は 取り込みたいよな。 Windows用アプリケーションをLinuxで開発するってなんかの罰ゲームか マルチプラットフォームでLinuxがメインターゲットの場合だってWin固有のコードはWinで開発するだろ windowsやlらinuxやらって大変だね 素直にmacにすればいいのに >>533 >いまやMS WindowsのソフトすらもLinux上で開発する奴が増えたから へー、そんな事出来るんだ初耳 因みにどんなソフトがあるんだよ低能 >>533 > いまやMS WindowsのソフトすらもLinux上で開発する奴が増えたから 聞いたこと無いな。だって無理じゃん?VisualStudioとかさ 逆にLinuxのソフトをWindowsで開発するって話は多く聞いていて、 WSLでそれがさらに加速する >>542 OSSだけど、VLC ttps://wiki.videolan.org/Win32Compile/ Winでのビルドは頑張ってねとか書かれてる 10年ぐらい前にChromiumのWin版をビルドしたことがあるけど、 準備がすごいめんど臭くてさらにコードをいじらないとビルドできなかったな。 LinuxとMacはそれに比べて簡単だった。 MSのLinux開発への擦り寄りは最終的には「Azureを売る」へ繋がるわけだけど、肝心のLinux on Azureは散々な有様だよね 十中八九、あと3年くらいしたら今の路線はピボットを迫られるだろうけど、そのときWSLはどうなるんだろうね > 肝心のLinux on Azureは散々な有様だよね 大ヒットしてるよ >>543 そんなん使ってるのVLCみたいなマルチプラットホーム向けの極一部だけだぞ Macは大学で導入してるところが多いが 就職したあとどうするんだろ ほらみろーw Windowsユーザーにするやつが釣れただろーw winユーザーはマカーはmac以外使いこなせないと思ってる ってことでバカ呼ばわりはまあわかるのだが >548が犬厨な可能性は考慮してないのだろうか 俺的にはFUSEに期待だな Winの似た様なライブラリとかドライバとかの類はライセンス的にすんげぇ使い辛いからなぁ 標準でマイナーな書庫の直接マウントとかできる様になると色々と有難い 犬もドザもバカーも所詮どんぐりの背比べ 使いやすさデスクトップ編 System7.1以降X未満>>>>>WinXP以降>>>超えられない壁>>>>X以降>>犬 サーバー編 犬>>>>>>>>>>>>Windowsserver>>>>>>超えられない圧倒的な壁>>>>>>>>macOS Server 俺はMacのParallels(VM)でWindows10動かしてその中でWSLを使ってる。 もともとWin10以外にUbuntuもVMがあったけど、WSLだけでどうにかなるからそうなった。UbuntuのVMは捨てた。 >>557 Mac でコンソールは使わないのですか?(まぁ他の UNIX が細々としていますのでアレですが) >>558 使ってるよ。 Linux(WSL)が欲しいのはラズパイのクロスコンパイル環境を用意したいから。 >>494 VSCodeをWSL側で動かすことを全力を出した全俺に謝れ くっそぉ・・・orz >>560 ん? WSLでVSCode動かしたかったからそういう意味のないことをしたんだろ? うまくできてよかったじゃん 君以外の誰にも役に立たないことだったけど まぁ、趣味なんてそんなもんだよ AndroidのAOSPがWSLの半分以下の時間でコンパイルできるならWSL2入れてもいいかなぁ。 CTS動かないと意味ないけど。 WindowsにLinuxカーネルをのせるんだったら、次はDockerが生で動いてくれたらいいのにね GNU Octave のwindows 版がlinux上でのビルドです。 >>560 歪んだハックはいずれ正道によって駆逐されるものだ 勉強になったね >>565 まじそれな。Vagrantやったの無駄だった。 vscodeをwsl側で動かすだけなら全力だすほどの作業じゃないような remote-wsl,sshは、remote-wsl,sshしたあと、そこから remote-containerができないみたいだから、wsl2内でdocker 使うなら、また全力出す機会はあるかも 新vmが本当に小リソースなら、docker for windowsも対応させて ぱっとしないhyper-v捨ててほしい ここらへんのできがよければ、vscode利用者なら、wsl2使わずに remote-containerとdocker for windowsだけでも問題なさそうだけど >>567 何を言っとるんや?お前 docker for windowsはHyper-Vを使ってるんだぞ? まずなCPUには仮想化支援機能っていうのが有る。 その仮想化支援機能は、OSもしくは特定のアプリが専有する必要がある。 だからHyperV もしくは VirtualBox のどちらかしか動かすことができない(という状態が続いていた。) そこでWindowsにはOS標準のHypervisor Platformという機能が追加された。 この機能は他のアプリから利用できるようになってる。 今のHyperVはHypervisor Platformを利用する。 VirtualBoxも6.0でHypervisor Platformを利用するようになってる。(はずだがまともに動いていない) まあこれにより、Hypervisor Platformの上でHyperVやVirtualBoxが動くわけだ。 WSL2もHypervisor Platformで動く1アプリとなるのだろう 通常のDockerは、WSL2 on Hypervisor Platformで動く docker for windows は HyperV on Hypervisor Platform で動く docker for windowsはWindowsが対応するようなものではない。 そういうことはDockerに言え。HyperVを使わずに Hypervisor Platformの上で 動かしてくださいと(何もメリット無いだろうけどなw) >>569 docker on windowsはHyperV上のLinuxで動いてるだけだろ >>567 WSL2上のdockerへRemote-Containerで直結すればいいだろ Dockerがクラサバ型なの知らないのかな Docker on MobyLinux(Docker専用Linux) on HyperV(重量VM) on Windows と Docker on Ubuntu(フル機能Linux) on WSL2(軽量VM) on Windows って どっちが良いんだろうな? Dockerだけを使いたい人は前者、Linuxを使いたい人は後者? MobyLinuxはDocker専用だから機能が限られてる分起動が速い・・・ように思えるけど 実際はUbuntuの方が速い気がする。WSLと同じ感じならLinuxが起動するのではなく カーネルのみ起動してコンテナを作るような感じになるはずだから ファイルアクセスの速度に関してはどちらも同じだろうし、 Docker for Windowsはもう出番なし? メモリ管理がどうなってるのか気になるな。 仮想マシンに一定のメモリを割り当てる方式(Docker for Windows)ではなく ホストOSと共有して使えれば楽なんだが DockerのハイパーバイザーをHyper-Vで、クライアント側はWSLで動かす例を見たな。 WindowsコンテナでWSLのプロセスを動かすのは出来るのかな? …Hyper-V使わないコンテナはWin10では動かないのね さすがにイメージは無いようだから作らなきゃならんか >>573-574 何を言ってるのかさっぱりわからんw > DockerのハイパーバイザーをHyper-Vで、クライアント側はWSLで動かす例を見たな。 Dockerのハイパーバイザーってなんだ?Dockerは仮想マシンとは 全く関係ない仮想化技術だからハイパーバイザーなんてでてこない。 Dockerはハイパーバイザーを使う必要はないから 「Dockerのハイパーバイザー」という言葉は意味不明 > WindowsコンテナでWSLのプロセスを動かすのは出来るのかな? WSLのプロセスってなんだ? (今の)WSLはAPIを変換するレイヤーなんだから WSLのプロセスなんかいない。WSL2の話だとしても、仮想マシンに乗ってるLinuxカーネルのことだぞ WindowsコンテナでLinuxカーネルがはいった仮想マシンを動かすって言ってるのか? >>577 開発者のScott Xuってどういう人? スマン>>578 だがArchスレで聞いた方が良いな 移動します >>581 公式がサポートしているなら、the arch way に則っていることの一つの基準になる が、Archスレでも言われてるようにこれはどうやら非公式で、公式でarch on wslを出すかという問題については、メーリングリストでとっくの昔(2018/3)に NO で決着がついていて、>>577 は時間の問題でストアから消えるようだ >>582 オープンソースで自由なのに消えるわけ無いだろw >>578 https://twitter.com/scottgu https://en.wikipedia.org/wiki/Scott_Guthrie Scott Guthrie is an Executive Vice President of the Cloud and Enterprise group in Microsoft. だから、>>577 は変なものではなさそうだけどね 権利的にどうこうな話はFedoraの件もあったから分からんが https://twitter.com/5chan_nel (5ch newer account) いやスペルが一文字違うのか Scottxuだもんな Arch Linuxの商標等を無断使用してArch Linuxのオフィシャルのものと錯誤させるような現状はアウトだけど Arch Linuxからのforkである事を明記して、別の名前にしてArch Linuxのクローンと自称すれば、それだけでは止める理由は無くなるよね >>583 自由なソフトウェアwwwwwww 江添亮かよテメェは(中指ピーン >>590 > さらにWSL2の環境毎にVMを立ち上げるのではなくLinuxカーネルは一つだけ立ち上げて、 > それぞれのWSL環境はコンテナで仕切っている様です。 すごいな。仮想マシンとは全く違う仕組みじゃないか >Windows UpdateでLinuxカーネルがバージョンアップされる アップデートの履歴にも Linux〜 Linux〜 って文字が羅列されるんだな。胸熱だわw WSL2はHyperVに似た仕組みを使っているのだろうけどHyperVはWindows homeでは使えないのよね WSL2もWindows homeで使えないのだろうか Homeで開発用にPC使うってのが間違い。 開発者でないユーザーにWSLは不要。Linux使いたかったら普通にPCにLinux入れりゃいいだけ。 門外漢が横から申し訳ないけど、それはどうだろう。 今よりさらにWindowsのネイティブアプリに近づくなら使ってみたい俺みたいなのもいるかも。 主に単純な作業の自動化の用途で開発とは無縁なんだけどね。 >>596 門外壊と予防線はってて申し訳ないけど頓珍漢な物言いはご容赦願いたいです。 正しくはネイティブアプリと使用感が変わらないくらい相互のやりとりが簡単になるということでしょうか。 自分でもよく分かってないのでこれでやめときます。話に水を差して申し訳ありませんでした。 >>599 何が面白いのか分からないんで解説お願い >>597 頓珍漢な物言いはあなたの方だと思いますよ >>594 Windows 10 HomeにVisualStudioをインストールして使った場合にどのような問題が生じるか、具体的に説明して。 ちなみにマイクロソフトが公式に上げているシステム要件には次の記載がある。 > Windows 10 バージョン 1703 以降:Home、 > Professional、Education、および Enterprise > (LTSC および S はサポートされていません) マイクロソフトが嘘をついている仰ってる? そもそも動かない と サポートする気がない は別物なんです。 Windows TerminalとWSL 2はOSS版Windows 10の布石か? - 阿久津良和のWindows Weekly Report 2019/05/13 15:25 https://news.mynavi.jp/article/20190513-822501/ (前略)蛇足だが公式ブログのコメント欄を見ると、かのRichard M Stallman氏がかみついて いる。コメントを投稿したのが本物のStallman氏なのか確認する術を持っていないが、 筆者は冗長な文章がメーリングリストなどで見かける文面に類似しているように感じた。 真偽は読者諸氏のご判断にお任せするが、WSL 2は本年6月からWindows Insider Preview、 2019年末に一般向けプレビューの提供を予定している。 ---- Stallmanを名乗る人物の直下に "I don't think rms browse Microsoft websites :)" と コメントがついているが… >>602 このページの話をしてるの? https://docs.microsoft.com/ja-jp/visualstudio/releases/2019/system-requirements > HYPER-V エミュレーターのサポートを得るには、「サポート対象の」 64 ビット オペレーティング システムが必要です。 > クライアント Hyper-V および第 2 レベルのアドレス変換 (SLAT) をサポートするプロセッサも必要です。 「サポート対象の」のリンク先 Windows 10 Hyper-V のシステム要件 https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-requirements > Hyper-V のロールは、次のバージョンの Windows 10 で有効にすることができます。 > > Windows 10 Enterprise > Windows 10 Pro > Windows 10 Education Visual Studioを使えることと。Visual Studioの全機能を使えることは意味が違うよね? windows homeでも利用できるよと中の人が言ってるのに、何開発者どうたらの言い合いしてるのやら >>604 https://devblogs.microsoft.com/commandline/announcing-wsl-2/ > 前略)蛇足だが公式ブログのコメント欄を見ると、かのRichard M Stallman氏がかみついて > いる。コメントを投稿したのが本物のStallman氏なのか確認する術を持っていないが、 うん。ワロタw > ちょっと差し止めたいのですが。あなたがWindowsと呼んでいるのは、 > 実際にはGNU / kWindows、あるいは私が最近それを呼んだことにしたように、GNU + Windowsカーネルです。 >>606 Windowsの機能の有効化と無効化を見てみると、 Hyper-V と Vitual Machine Platform と Windows Hypervisor Platform に分かれてるもんね Proしか対応してないのは、Hyper-V、仮想マシンの管理ツールで それ以外の機能は使える(ようになる)のでしょう。 もしかしたら、WSL2限定かもしれないけど ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる