【Bash】Windows Subsystem for Linux【WSL】5

Install the Windows Subsystem for Linux
https://docs.microsoft.com/en-us/windows/wsl/install-win10

前スレ
【Bash】Windows Subsystem for Linux【WSL】4
http://mao.5ch.net/test/read.cgi/linux/1541747008/

マイクロカーネルとLinuxエグゼクティブの間のオーバーヘッドじゃないの？

https://ja.m.wikipedia.org/wiki/マイクロカーネル

そもそもスマホはトルクかキャタピラの二択
落としたら画面壊れるようなのはゴミ
メインはPCだから性能とか関係ねーし

githubでMS技術者がissueで回答してるから見てくれば？
数か月前に話題になったっけ？

wslはforkがcygwinよりましだが、大分遅い。そもそもwindowsにはforkの概念がない。これが少なくともcofigureとかが遅い原因だと聞いている。

前にも話題となったけど、ウイルス対策ソフトの影響も結構ある

>>211
> マイクロカーネルとLinuxエグゼクティブの間のオーバーヘッドじゃないの？

そこはタスクマネージャーのCPU時間に含まれない領域なの？って話です。

>>213
それI/Oが遅いとかいう話でしょ？
でも俺のツール、そんなにI/Oがあるわけじゃないんだよ

>>214
うん。forkが遅いっていうのはわかってる。
でもそれはCPU時間に現れても良いんじゃない？という話です。

>>211
あとLinuxエグゼクティブってあんたが作った造語？
そんな言葉、無いよね？

>>218
だからWSLがマイクロカーネルのエグゼクティブとして実装されてるのかな知らん言うとるがな。
マイクロカーネル上でOSの「いわゆるカーネル」として動作してメモリ管理や入出力管理、システムコールなどのAPIを提供する「エグゼクティブ」として実装されているのであれば

ごめん、飽きた。
あとはテメエで勉強してくれ。
俺はお前の母ちゃんじゃない。
甘える相手を間違えてる。

> マイクロカーネルとLinuxエグゼクティブの間のオーバーヘッドじゃないの？
> だからWSLがマイクロカーネルのエグゼクティブとして実装されてるのかな知らん言うとるがな。

「Linuxエグゼクティブ」とかいうから何のことかと思えば、
やっぱり造語じゃねーかｗ テメーがへんな言葉を使いだすから誰にも理解出来ない言葉になってんだよ。

https://www.atmarkit.co.jp/fwin2k/special/win9xorwin2k/win2kknlover_2.html

WSLは↑にあるPOSIXサブシステムなどと同じレイヤーのサブシステム。
Windows "Subsystem" for Linuxの略だろ

ちょっとさぁ、勉強してないなら、俺俺用語を作り出して話をしないでくれませんかね？

わかった上で改めて読むと

> WSLってマイクロカーネル上で動くエグゼクティブとして実装されてるのかな？
> だとしたら遅くて当然。

Windowsのカーネルモードコンポーネントは、すべてマイクロカーネル上で
動くエグゼクティブとして実装されてるので、WSLだけが遅くて当然というのはおかしいということになる。

さらにWSLはサブシステムなのだからエグゼクティブとして実装されてすらいない。

言いわすれてた

> マイクロカーネルとLinuxエグゼクティブの間のオーバーヘッドじゃないの？

Linuxエグゼクティブなんてものは存在しない

.exe をエグゼクティブと読んだのか。。。

MSYS2で良いのにWSL使ってる奴

msys2はいやだよ。あれLinuxじゃないし、
パッケージ管理もオリジナルだし、msys2のことをいちいち覚えないといけない。
WSLならLinuxの知識と殆ど変わらない

archwslが公式で出たらwslに移行するかも

>>209 >>219
ttps://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
ttps://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/
ttps://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/
ttps://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

>>224 >>225
msys2は私は以下で使用。
sshでlinuxサーバーとの接続。
windowsのアプリケーションのbashのシェル環境での実行。
メインは、msys2が提供するgcc、autotools、ライブラリなどを利用して、windows nativeのgnuplotのビルド。

WSLとVcXSrvの組み合わせで幸せになれますか？
（日本語表示とか日本語入力とか）

幸せになれるかしらんが日本語表示、入力は出来るよ
個人的にはリモデでアクセスした方が幸せなんじゃとか思うけど

>>229
X410 使ってるけどgnome-terminal動くからできるよ。

>>228
うん。そのgnuplotのリポジトリを見てみよう
mingwやcygwinのMakefileがあるだろう？
https://github.com/gnuplot/gnuplot/tree/master/config

これがだめなんだよ。msys2はLinuxじゃない。
他のLinux/Unixとは違う互換性が完璧ではない専用のOS扱い

つまり何が言いたいかっていうと、他人が作ったものでも自分が作ったものでも
msys2に対応させなければいけないし、対応していないものは動かないかもしれない
そのせいで全てのパッケージがmsys2で使えるわけじゃない。

特定のOSに対応させるためってならまだわかるけど、
そのOSで動く小さな環境のためにメンテナンスとかしたくない
もうWSLでいいよ。WSLの方が優れてるのにmsys2とか使う意味ない

>>228
クロスコンパイルでよくない？

デメリット並べ立ててもwsl来る以前に環境整えたてたら移行めんどいとかあるんだろうし
どっちかに統一しなくてもその時その時で使い分けでもいいんでないの
まあ今更>224の言い分は理解できんけど

個人的にはaptが普通に使えるのが一番のメリットかな

>>232

msys2でコンパイルするメリットはできた.exeファイルは
wslのない環境にもっていっても動くこと。
32bitのOSでも動くようにできるし。

Linuxエグゼクティブという新しい造語が生まれた瞬間に立ち会えた幸せ

msys2よりはWSL上のmingwの方がいいかな
どっちも遅いからVMに逃げたくなるけど

フィードバックあげるのでもなければ無理して作りかけのWSLに付き合う必要ないんじゃ

colinuxの64bit版はいつ出ますか？

ntkernel道連れに落ちるような子は要りません

>>239
これ
どこまでもWSLって途中なんだよな

load averageが適当なのは直さないのか？
無理だって話らしいが・・・

MSYS2 は、日本語でバグル

https://www.scriptlife.jp/contents/programming/2016/09/14/post-1766/#VirtualBoxGPGPU
>　というわけで、どれもダメな感じでした…
>　TensorFlow、Windows版が正式に出てくれたらそれでって感じですけど…あんまり出る雰囲気じゃない(し、Windowsで運用したいというのもあんまりない)よなあ。

gpuは動きましぇん！
うんわかってた

>>232
私はgnuplotのwindows版のパッケージャーだ。
msys2でいまsourceforgeで配布されているgnuplotをビルドしている。
開発版も常にビルドして試験している。

msys2にはmingw64とmingw32のwindows nativeの豊富なライブラリ群があって
それでmsys2に依存しないwindows nativeのlinux由来のソフトのビルドができるのだ，
これだけのmingwのライブラリをそろえるは大変だし，その手間を省くのがmsys2だ。
Cygwinやｗｓｌと根本的に目的が違う。

>>246
mingw64とmingw32
これは厳密ではなかった。mingw64のw64とw32のが正しい。

ヤバイな、全然伝わってなさそうで

>>248
まあ，それぞれ考え方が違うんだしいいんじゃない。

いや…、まぁ良いか
人それぞれだし

>>250
君らには無縁な話だから

>>232
gnuplotのconfig/cygwinのMakefileはCywin用のバイナリ作成用ではない。
これはCygwinのMinGWコンパイル環境を使って，Windows Nativeのgnuplotをビルドするものだ。
Cygwin用のバイナリはlinuxと同じでにconfigureとmakeでビルドする。
CygwinのQtにはバグがあってQtにパッチをあてないqtターミナルが動かない。

あぁ、わかるよいいたいことは。

だがそんな面倒なこと、もうやめて良いんだよってこと
普通にLinuxバイナリを使えば良いんだから

>>253
個人ては、自分もそうなりつつある。でも、wslなんて使うwindowsユーザーがどれくらいいる？
gnuplotのユーザーの大半はwindows native版のユーザーだ。native版のパッケージジャーとしてmsys2は捨てられない。私がいいたいのはそういうことだ。

> wslなんて使うwindowsユーザーがどれくらいいる？

cygwinやmsys2を使うユーザーは少ない。
cygwinやmsys2を使うユーザーぐらいはWSLを入れるだろう。

> gnuplotのユーザーの大半はwindows native版のユーザーだ。
gnuplotの開発者がmsys2を使ってビルドするのは良いだろう。
そして開発者はそれを配布する。使う方はmsys2でビルドされているかなんかどうでもいい。
msys2単体で使う必要はない。

俺もGit for Windowsをインストールしていて、あれはmsys2のようだが、
Git for Windowsとして使っているのであって、そこに追加でパッケージを入れたり
なにかをビルドしたりしようなんて思ってない。ただのWindows用のgit環境として使ってる。
Git for Windowsとして完成された環境というわけだ。
（もっともGit for Windowsはとりあえず入れてるだけで使う機会はほとんどないけどね）

232で言ってることと随分ずれてる

ハンドルの管理が面倒いのかのう？
巨大なハッシュ表がいるだろうし

msys2の話は、もういい。
私としては、wslでflatpakでGNU Octaveが入れられないのが痛い。まあ、自分はビルドできるのでいいけど。
wsl上のflatpakの状況がわかる人教えてください。

普通にWindows版バイナリあるじゃん

https://www.gnu.org/software/octave/#install

必死だな

意味がわからないだけ。

WSLは相互運用するためのツールなのに
なんでWSL上だけで完結させようとするのか？

普通にWindows用のツールと組み合わあせて使えばいいのに

>>220
WSLはすべてがユーザーモードで動いてるようなそんな単純な実装じゃない
https://msdnshared.blob.core.windows.net/media/2016/05/picoProcess.png
https://msdnshared.blob.core.windows.net/media/2016/06/file-system-graphic.png
https://i.imgur.com/vVPQgxj.png
http://www.alex-ionescu.com/publications/BlueHat/bluehat2016.pdf

>>262
その中にもLinuxエグゼクティブなんて書かれてないですが
どれのことですか？やっぱり造語なんですか？

>>263
？
Linuxエグゼクティブとやらの話なんてしてないけど？

>>259
octaveのwindows native版があるのは当然知ってる。でも、linux版のほうがgui版見た目がいいw。
あと、日本語pathは5.1.0ては通るけど、まだなんかおかしい。
shellコマンドと併用するときはlinux版がいいのよ。
linuxでつかっているのそのまま使える。

linuxで使っている環境をそのままもちこみたい。ただ、それだけ。

https://winaero.com/blog/flatpak-coming-wsl-windows-10/
てのがあった。早く対応しないかな。

What’s new for WSL in Windows 10 version 1903?
https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/

>>268
ありがとうございました。

個人的にはブロックデバイスへのアクセスとfuseに対応して欲しい

ループバックデバイス(losetupやkpartx)が使えるとうれしい。
VMや実機使えば、WSLでもラズパイ環境作れたけど、公式のイメージ展開するときにここで詰まる。

要望がどんどん高くなっていくのは分かるけど、WSLってLinux環境をつくるものじゃなくてELFなアプリが動けばいいなぐらいのものじゃなかったのか？

それは手段であって目的ではない

Who is WSL for?
https://docs.microsoft.com/ja-jp/windows/wsl/faq#who-is-wsl-for

This is primarily a tool for developers -- especially web developers
and those who work on or with open source projects.
This allows those who want/need to use Bash, common Linux tools (sed, awk, etc.)
and many Linux-first tools (Ruby, Python, etc.) to use their toolchain on Windows.

ウェブ開発者でもブロックデバイスやfuseにアクセスすることはあるから必要なんだよ

>>275

そういう人は実機やvmでいいんじゃないの？

マシンを切り替えるのが面倒。それが仮想マシンであってもだ。

>>274
ありがとうございました。

EncFSとかSSHFSのfuseはWindows側でマウントしてWSL側で
mount --bindしてやれば無理矢理使えないわけでもない。
WSLだけで完結してほしいけど。

>>277
まったく意味がわからん。

なんか追加でソフトを入れようとするとexeを台帳登録する手続きがクソめんどい
Windows標準機能ならそれを回避できる
aptで入るパッケージはexeじゃないから自由に使える
っていうクソ環境にいる人たちのためにもWSLの機能向上を頑張ってほしい

>>280
同一マシンであれば、ファイルは普通に共有されてるし
ネットワークも同じネットワークだ

仮想マシンだと別のマシンがネットワーク上に有るのと一緒
ファイルを共有したければ、そういう設定をしないといけない
（仮想）マシンの環境整備をしないといけないんだよ

>>305

説明は >>232用で他の人がわからんでも仕方ない。gnuplotのMakefileを、よんだ人しかわからない。

>>282
1時間もあればできるんだが。

>>283ですが、>>280向けでした。すいません。

>>284
1時間でできるかどうかじゃない。
その後、事ある毎にメンテナンスするのが面倒なんだよ
VirtualBoxが動かなくなったりな

LinuxとWindowの併用ユーザは、シームレスに両方のアプリが使える環境を欲するものだとおもう。
CentOS＋wineだったけどWin10+WSLに移行した俺が言うんだから、間違いじゃない。

仮想だとしてもPC2台を同時に使うのは不便というより「面倒くさい」から。

>>286
ま、能力がない人は大変ですね。

>>287
で、wslは遅いとか、いろいろできないことが多いとか
大変ですね。

ちゃんとした開発をやるなら仮想化の方が同じ環境をすぐに作れたりして便利だと思うが
事務とかやるPCでテキストファイルをちょっと操作したいとかいう時にWSLがあると心強い

VM使うほどでもない用途で使えばいいのであってVMと比較するのはナンセンス
VMだけでいいならクライアントHyper-vあるのにわざわざWSLなんか作る必要ないだろ

メモリ32GB程度積んでいれば、16GBのメモリ割り当てたVMをheadlessで起動しておけば、
WSLよりずっと快適。
でも、一台あたり2万円の追加投資すらしてくれない会社がほとんどじゃないかな。
hyper-vでこれをやると、常時16GBのメモリ確保されるのでおすすめしないけど。

ノートPCユーザな俺だとメモリの制限があるから、ヘッドレスなLinux使うぐらいならWSLで済ます、になるなぁ。
そっちのが手軽だし、WSLでダメならDEありでフルフルなLinuxをインストールしてある実機を（リモートになるけど）使えばいいだけだし。

何でもかんでもWSLで済ます、なんて無謀なことをする奴はいないだろ、さすがに。

BOM 無しUTF-8(UTF-8N) では、Windows 側で、文字コードが判別できないから、エクスプローラで検索できない。
BOM 付きなら、sjis と区別できるけど

そういう場合に、WSL からgrep するのが速い

検索できるよ

おれはクライアント（窓）で文字列編集とか扱うとき慣れている犬コマンド（wsl）を使って、鯖（犬）にファイルを整理してホストしてるな。
んで、一応xrdp打ち込んでリモート貼れるようにはしたけど。
それとは別にdev鯖立ててVMとかDockerで管理すりゃあいい。
クライアントとdevは消しておいて、ファイル鯖を踏み台にしてWakeさせりゃあいいし。

スマンちょっと真面目に答えてほしいんだが、MSYS2にしろWSLにしろ、開 発 途 中 な も ん を わ ざ わ ざ 使 う 必 要 あ る か ？

実機か仮想環境でLinux用意した方が大抵の場合良いんじゃないのか？

開発に寄与したい方が人柱をやるのは大変立派なことだし、尊いことだ
でもな、末端のユーザーよ。本当に自分に必要なのは何なのか、もういっぺん考えてもいいんじゃないか

> 開 発 途 中 な も ん を わ ざ わ ざ 使 う 必 要 あ る か ？

世の中すべてのものが開発途中だろ
awkだって開発中でついこの間5.0でたしな

> 本当に自分に必要なのは何なのか
自分の仕事ができることだろ。

完璧な道具がほしいんじゃない。
道具はどんなものでもいいが、なるべく便利で
それで仕事が楽にこなせればいい。

お前よく考えてこの結論に達したか？

>>298
あのさぁ〜〜〜
awkなんか引き合いに出してる時点で終わってんぜ、お前さん

枯れ切ったawkと開発途上も途上のWSLを同じステージで語るとはｗ
しかもその根拠が「最近新しいバージョンが出たから」とはｗ
恥ずかしくないのか
もう二度とポストするなよ

開発の途上でも実用に耐えられるからあちこちに文献が転がっててスレも勃ってんだろ
むしろ開発途中のベータってよりベースの完成品に機能を追加してる段階だろう
ReactOSどころかwine辺りと比較しても周囲の反応でその辺は明らかだろう

> 実機か仮想環境でLinux用意した方が大抵の場合良いんじゃないのか？

これがすべてに当てはまるとか決めつけないでほしいな。
ネットワーク経由で実機使うより、無駄にリソース浪費して仮想環境使うより、軽快に動くWSL使うことが便利なケースではWSL使うだけのことだし。

実用レベルでいったらWSLも生Linuxも似たようなもの。
「開発中」って言葉はWSLを使わない理由にはならないな。
開発中と言っちゃったらLinuxそのものが開発中になっちゃうしね。

>299
WSLがダメってことにしたいみたいだけど、Win10+WSLはLinux＋wineより使えるよ。
どうしてもWin10で動かない古いWinアプリ使いたいんでもなければね。

>>300-301
wineはありえないです
wineを使うくらいならWSLの方が良いです

「実機か仮想環境で」と言ってるのになんでwineとか言い出したのかマジで分からないしビビるのですが、それくらい答えに窮してるってことですか？

>>302
開発途上ってとこに突っ込んでんだよ
表向きのフェーズが開発の途中だろうと何だろうと使えるか使えないかが全て

WSLでWineを一応動かしてる。
最近WSLでも32ビットEXEを動かせることを知った。qemuかますから遅いけど・・・

WSLでLinuxバイナリを作っています。
WSLがあればC++でウェブ開発という選択肢が出来ます。
Visual studioはやはり素晴らしいです。

>>297
目的を達せるなら開発中のものかは問わないですね。効率よく使えるものを使うというだけです。
EWS-UX でコードを書いていた時は私物PC に BSD on Windows を、HP-UX の時は Cygnus windows を入れて使用していました。

よくわからん争いになっているが、端的にいえば「探究心」のパッションがあって追い求める覚悟があるってのは技術屋じゃあ常識だろ。
ソレが単純に企業お抱えか単なるギークかの違いだ。コミュニティやプログラムに参加すれば色々絵られる部分もあるしソウイウモノに突っ込んでくハングリー・チャレンジ精神は大事だと思う

>>299
> awkなんか引き合いに出してる時点で終わってんぜ、お前さん

あのね。わざと枯れてると思われてるものを持ってきてるの。
枯れてると思われてるものでも、未だに開発中だってこと

すべて開発中と言っても良い

永遠のベータ、2019ロードショー。

君たち、低俗な諍いはやめたまえ
すべての原因は君たちがmacを選択しなかったことにあるんだ