【Bash】Windows Subsystem for Linux【WSL】9

ついに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】8
https://mao.5ch.net/test/read.cgi/linux/1590742701/

んだんだ、WSLが急に出てきたとか思ってるニワカだし、スルーでいいかとw

古いCPUはWSL2を使えない。

WSL フォーエバーさんやで。

MSはWSL1を先に作ってよかったと思う
WSL2を先に作ってたら多分WSL1は作らなかった

WSL1の開発は大変だから、WSL1のメリットである
Windowsとのファイル共有が速いとか
古いCPU対応とかは切り捨てるという対応をとっただろう
Homeエディションへの対応もしなかったかもな

アホすぎる、WSLってぽっとでてきた技術じゃねーよ
20年以上前からSFUとかでやってる

WSL1が本家のWSLであってWSL2はおもてたんと違う!
https://qiita.com/yugo-yamamoto/items/ac31bbd00f6b88e05793

外部からWSL2のネットワークにアクセスするの面倒なんだよねぇ

>>206
外部だけでなくホストのWindowsからもアクセスしにくい。SSHトンネルはwsl1で開けてるよ

SFUはフリーソフトに負け
WSL1で仕事につながらず
docker頼みで接続可能でないWSL2を作った
version1version2じゃなくtype1type2だ

> SFUはフリーソフトに負け
MSも積極的に開発してなかったしな
なにより対応パッケージが少ないし、どう考えてもパッケージの提供が大変すぎる
多くのオープンソースがあってアップデートのたびに正しく動くか検証しなきゃいけない
それをやってるUbuntuとかのディストリビューターは大変だと思うよ

WSLの成功はそこをUbuntuに丸投げできたのが大きい
だからMS独自のLinuxディストリ（＝パッケージの提供）は今後も作らないだろうな

> WSL1で仕事につながらず
> docker頼みで接続可能でないWSL2を作った
どういうこと？

docker頼み＝dockerが使えるなら仕事になる＝WSL1からdocker使えるよね？

>>206
WSL2のネットワークという考え方はすじが良くない
WSL2はWSL1と同じでホストOS上でアプリが直接動いているという体なんだから
ポートの開放＝ホスト上のポートとWSL2上のポートのマッピング機能と考えるべきだろう
HyperV的にはできたはずだけど、WSL2ではまだ対応してないの？

WSLのアンチは適材適所って言葉を知らないのか？
それともただのバカ？

>>210
WSL2のネットワークは外部からは見えないので
Windows側でportproxyなどで中継しないとアクセス出来ない

>>212
内部の実装はそれでいいんだよ

portproxyみたいなのを自動的にやってくれる機能は
まだWSL2に搭載されてないの？って話

第一段階は、手動でポートとディストリをマッピングするコマンドを実行
第二段階は、WSL2でポートを開いたら、カーネルが検知してコマンドを自動実行

とかね

使ったこともないのに偉そうに語らないでくれ

Windows 10 Home 版に、WSL2, Docker を入れた

CPU-i3, 8GB メモリで、Windows の連続アップデートに、3時間掛かった

その後、WSL1 から、WSL2への変更。
Dockerのインストール自体は簡単だった

これで、Windows10 プロ版じゃなくても、Dockerを使える。
Kubernetes も入っていた

Ubuntu 長期版も入れて、日本語化する

今は、ここまで出来る開発者が求められている！
Linux の運用構築も、開発者の最低ラインになった。
Mac みたいに、Linuxを知らない香具師は、むしろ、Windowsよりも遅れることになったw

1. Windows 10の連続更新
2. WSL1から、WSL2への変更
3. Dockerのインストール
4. Ubuntu 長期版の日本語化

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0.0
は気持ち悪いよね・・・・。なんでもっとスマートに出来ないかな。

カッコの中をシェルスクリプトにすれば?

バーチャルマシンだからWindowsと別ネットワーク
スマートな解決ってソフトLANカードだな
virtualboxみたいな

>>216
> なんでもっとスマートに出来ないかな。
お前の頭の悪さをつぶやかれても困るんだがｗ

awk使ってるのに、awkのパターンマッチング使わずgrepを使う。
ファイル読み込みすりゃいいのに、わざわざcatを使う
動くからヨシで基本を勉強してないだろ

export DISPLAY=$(awk '/nameserver/{print $2":0.0";exit}' /etc/resolv.conf)

あとオレのマシンだと3行返ってきたから1行だけにしておいたぞ

UNIX哲学を踏まえると最初のほうがそれっぽいけど

UNIX哲学の独自解釈はやめたまえ

あと有名なUUOCのことを知るんだな

https://ja.wikipedia.org/wiki/Cat_(UNIX)#cat%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%A8UUOC
UUOCは「無駄なcatの使用（Useless Use of cat）」の略である。 Usenetのcomp.unix.shellに投稿された賢者の観察によると，
catの役割はファイルを連結することである。もしファイルが1つしかないのであれば、何かと連結しようとするのは時間と手間の無駄でしかない 。
にも関わらず、次のような使用をよく見かける。

https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat

猫の無駄な使い方
cat（UUOC）の無用な使用は、ユーザーに便利な機能のみを提供するコマンドライン構造の
一般的なUnix専門用語です。[5] これは「猫の虐待」とも呼ばれます。UUOCのインスタンスを
修正するアクティビティは、デモギフィケーションと呼ばれることもあります。[6]一般的なcat虐待の例は、賞に記載されています。

>>219
そういうことを言ってるんじゃないと思うぞw
理系の頭の善し悪しはともかく対人関係のIQ低そう・・・。

中の人が言ってるんだね
https://github.com/microsoft/WSL/issues/4106#issuecomment-501868870

またロクに使ってないやつが偉そうに暴れてるのか

grep の引数に、対象ファイル名を渡せないの？

touch なんか、ほとんどのプロ中のプロが、ファイルを作るために使っているw

>>216
WSL2にssh serverを入れてssh clientでX11-forwardingするように接続すると、
DISPLAYを設定しなくてもX clientを表示出来るよ。
外部からssh出来るようにすれば、外部のX serverにもX clientを表示出来る。

スレの話の流れ的に

export DISPLAY=localhost:0.0
か
export DISPLAY=:0.0
で動いて欲しいよねって話じゃないのか？

というか出力先がネームサーバーというところじゃ

>>229
公式がそうしろと言ってるからね…
https://docs.microsoft.com/ja-jp/windows/wsl/compare-versions

>>4
Windows のファイルシステムにアクセスさせる場合は，
全く実用にならない．いろいろ調べたが，2倍〜3倍以上遅い．

Windows 共有フォルダのNASとか使ってる場合，
WSL は， まともに mount できないから，
WSL2 しか選択肢はないが，全く使えない遅さ．

python, perl, shell script で小回りの利くスクリプトで，
例えば5分でスクリプト作って，100MBのログ100本読んで
処理するときとか3倍とか時間かかってホント使えない．

実用になると思ってる人，何に使ってるのかかさっぱりわからん．

アプリ開発だろ

アプリで100MBのログ100本読むとかしないからな

だいたい3倍かかるというのなら、30MBのログか
30本のログにデータ量を減らせばいいわけだ

WSLで作業してるぐらいなら、メインはWindowsだし
デバグ中にみるログのサイズなんてたかが知れてるからなぁ。
Windows側のファイルへのアクセスが多少遅くても問題にならんわなー、普通の人なら。

接続先サーバーがクラウドだったら、クラウドサービスのログビューワー使うだろうし
オンプレとかならリモートのLinuxにログインして見るから関係ない

100MBのログ100本をクライアントのWSLにダウンロードして見るわけないし
と考えると100MBのログが100本あるような場合ってどんな場合だよ？となる
3倍かかって使えないなら、1/3の時間なら使えるわけだ

さてみんなのログサイズはどれくらい？ｗ

もちろん100MB×100本＝10GBのログを見ることが皆無とは言わんけどなｗ

ファイル処理が遅いのは小さなストレスだね
チリも積もると山となる

期待はずれというのが正当な評価

× 期待はずれというのが正当な評価
○ 馬鹿が勝手に見当違いな期待してただけ

しかも後付で「期待」を作り出しただろｗ

ファイルシステムがLinuxと同じぐらい速いと
期待してたのにーって、遅いと知ってから言い出す。

それ以外の本当の期待は全て満たしてるので
ファイルシステムが遅いぐらいしか言うことがないｗ

実機で10ミリ秒のところがWSLで30ミリ秒なので使い物にならないんですw
って事なんだろうなぁw

いや…別に
WSLファンクラブか？！ｗ

速度が必要なファイルはext4に置けば良いのでは

特定の場合に遅いという話だけを聞いて
使ってもみずに文句を言ってるだけだから
解決法があるなんて知らないと思うし、知りたくもないと思うよｗ

解決法とか面倒なこと考えずに最初から速いのがあるならそっちのがいいだろう
つまりLinuxを使えばいい

大前提としてLinuxでは別の問題があって解決できないから
WSLを使うんだよ

Windowsはクラウドでいいかな

ぷっｗ

>>245
だからext4は早いって。素のLinux使うのと一緒だろう。

Linuxの方のボリュームに落けばいいだけなのに何か不都合でもあるわけ？ファイラーからも見れるよ？

仮想マシンとWSL両方にウブンツ入れてフォルダ共有かけてる俺は勝ち組だな！

なんに勝ってるかしらんけどw

果たしてUbuntuマシン使っているのに、仮想マシンにUbuntu入れて使うなんてことするだろうか？

>>249
一緒なら素のLinux使うわ

>>250
WindowsのホームとWSLのホームが位置も構造も違うのはめんどくせえなあと思った
Linux使っときゃ1つ管理すりゃいいのに
WindowsでWSLっていう回りくどい環境だと管理も2倍以上の面倒くささ

ネットワーク絡みの開発がしたいときとか

>>253
前提としてWindowsも使う必要があるんだが

>>254
WSL2だとホームの構造は同じ
あとシンボリックリンクは便利だぞｗ

もし知らなかったら可哀想なので説明してあげると
シンボリックリンクというのは別の場所にあるファイルやディレクトリに対して
自由なパスでアクセスできるLinuxの機能だよ

コマンド一つで例えばLinuxのホームディレクトリの下に
Windowsのディレクトリを持ってこれる
これでホームの位置の構造の問題は直ぐに解決できる
便利だから覚えておいたほうがいいぞ！Linuxの基本だがなｗ

>>257
WindowsホームとLinuxのホームは別物では？
WSLが常に起動してるわけじゃないからリンクも張りたくない

>>254
たかがその構造がめんどくさいという理由でLinuxを母艦にしたいとは思わないね。

あくまでも開発用途で必要なだけだし、Linuxじゃできないことが多すぎる

Windows+WSLなら大体のことができてしまうからこれで十分

そもそもLinuxで満足してるならこのスレになんで来るんだい？

>>259
> WSLが常に起動してるわけじゃないからリンクも張りたくない

なんかこの一言で、お前が使ってないのバレちゃってるよｗ

あえて聞くね。答えてね。

「WSLが常に起動してる」ことと「リンクを張ること」に
一体何の関係があるの？WSLが起動してなくても問題なにもないじゃないｗ

>>258
素LinuxとWSLでホーム構造が違うよ

素Linuxだと
~/.foo → ~/dotfiles/foo

WSLだと
~/.foo → Windowsホーム/dotfiles/foo
Windowsホーム/.foo → Windowsホーム/dotfiles/foo

>>261
WindowsからWSL方向のリンクを張れないってことだけど言われなきゃわからないのかな

>>259
予め起動させておけば？

>>263
貼れるだろｗ　あほやなぁ
試してからいえや

>>262
だからシンボリックリンクを使いましょう

>>262
そういう使い方をしたい場面がよくわからない
dotfilesとか置いてるけどそれはLinuxのホームディレクトリにおいてればいいだろ

>>265
張れない時は張れないよ
WSLディレクトリの有無に依存するんだから

>>267
WSLが常にあるわけじゃないんだよ

>>268
起動している時に貼ればいいだけだろｗ
まさかWSLが停止するとシンボリックリンクが勝手に消えるとか思ってんのかｗｗｗ
だーかーら、使ってないってバレバレなんだよ

WSLから見てWindowsは常に存在してるが逆は成り立たない
なのでWindowsからWSLにリンク貼るなどWSLに依存する構造はよろしくない

WSLへのリンクはUNCパスへのリンクに過ぎない
これは今までもごく当たり前にリモートサーバーへのリンクとして使われていた
なにをいってんだろうなｗ

>>272
で、リンク切れで困ると

問題はLinux用のdotfileとWSL用のdotfileが異なることだな
管理対象が無駄に増えて面倒だ

>>273
リンクじゃなかったら困らないんですか？
それはなんでですか？ｗｗｗ

これ、もうお前が答えられない質問な

>>274
> 問題はLinux用のdotfileとWSL用のdotfileが異なることだな

異なる部分だけ吸収すればいいだけ
シンボリックリンク使えば吸収できるし
使わなくても一行程度で終わる話

>>275
素Linuxなら困らんよ
そもそもwindowsへの/からのリンクなんて貼らないからな
素Linuxのホームは1つのホームで完結してる
WSLは無駄にホームを分裂増殖させてるから管理が2倍めんどう

>>276
めんどくせぇー
わざわざWSLを使うことによってめんどうを呼び込んでるじゃねえか
素Linux使えばそんな面倒なことしなくていいのに

ID:vj+7dSvOが言いたいことと反論のまとめｗ

アホ「WSLが停止するとシンボリックリンククリックしてもアクセスできないニダ！」
オレ「WSLが停止してるなら、シンボリックリンクじゃなくてもアクセスできねーだろアホ」
オレ「アクセスできないだけでシンボリックリンクはそのまま残ってるだろ、どアホ」


アホ「アクセスできないと困るニダ！」
オレ「アクセスできないと困るのは、シンボリックリンクと関係ない話だろ」

>>278
面倒の内容が「シンボリックリンクを一つ貼れば終わり」だって言ってるんだが
そこは認めるんだよな？ｗ

うわネトウヨか

>>280
物によるだろ

>>282
どんなものが解決できねーんだよ
具体例をいえ

>>283
たとえばdockerの設定とかだなー
winとlinuxでインストール方法、ファイルの置き場から中身まで構造が違うから個別に用意しなきゃならん

>>284
dockerの設定って何？
具体例をいえといったのに
なぜ何も言わない

ちなみにDockerのLinuxでのインストール方法

CentOS版
https://docs.docker.com/engine/install/centos/

Debian版
https://docs.docker.com/engine/install/debian/

Fedora版
https://docs.docker.com/engine/install/fedora/

Ubuntu版
https://docs.docker.com/engine/install/ubuntu/

winとlinuxでインストール方法が違うのではなく
Linuxディストリごとにインストール方法が違っている
Windowsの問題じゃねーんだわｗ

>>285
そんくらいググれ
ファイルの場所も内容も違うからな

>>286
せいぜいそんくらいだろ
設定は使い回せる

> ファイルの場所も内容も違うからな
全部同じだよ

> 設定は使い回せる
Docker for Windowsは結局の所Linuxで動いてる
Dockerだから設定ファイルとやらはそのまま使える
お前の言う設定ファイルが何なのか知らんがなｗ

>>286
WSL内にDocker入れるのに、windows側にも両方入れるの？
君ガイジじゃない？

>>291
Dockerはクライアントサーバー型って知ってるか？
WSL側に入れるのはクライアント
Windows側に入れるのはサーバー
役目が違ってる。
ほんと恥ずかしいよお前ｗ

んで、設定とは何だ？ｗ

WSL使わないならこのスレ来るなよ。ここはWSL使いが盛り上がればいいんだよ。きっと目の上のたんこぶで気になるんだろうな。オレはWSLからexeの起動とかWindows側にあるファイルをLinuxコマンドで操作したりとか、WSLが無くてはならないものになってるよ。

>>292
ん？クライアントサーバ逆になってる上にWSL側にもクライアント入るけど大丈夫か？

こいつはWSLとWindows側両方にDockerサーバー入れて設定ファイルを別々に管理するのが気持ち悪いだとか言ってるけど、サーバーはWSL側にしか入らないし、設定ファイルをまとめて管理したい意図が全然理解できなかったわ

今日からWSL2を使い始めてる(これまではWSL1だった)んですが、Windowsで実行する各種Gitクライアントはwsl$配下で起きているGit管理ファイルの変更をリアルタイムに検出してくれないようです
これを同一ファイルシステムの時と同じように検出させる方法はありますか？

Gitがネットワーク上のファイル変更をリアルタイムに監視しないんだろう、というのは想像が付いてます
ネットワークドライブの割り当てをしても同じでした

また使ったことないやつが暴れてんのかよ
ていうか相手してるやつもウザい

>>290
使えんよ