【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/

>>359
Linuxのカーネル機能だから
そういう事はあるだろうね

商用じゃないと信用できんし

本当に求められてるものは軽くて速いフル仮想マシンなんだよね

それかLXCね
Windows起動時に仮想マシンをバックグラウンドで動かしてWSLはLXCのインターフェース、としとけばもっと実用的だった

カーネルだけ共用するメリットが今ひとつわからんなあ。
メモリはどのみちインスタンス毎に食うわけだろうからそんなにリソースの節約になるのかね。

>>363
こんな所に書かずにMSに提案すればいいのでは

>>359
dockerもコンテナ仮想化も全否定だね
非効率で時代遅れ

>>358
そうですね，今の状態で下手に
便利にしようとするより
仕組みを学んでからのほうがいいと思うので，
背景起動はとりあえず後回しにします。

恐らく，仰るところの「仮想マシンを起動する」という動作を
Windows OSと同時に行うことができれば（それも背景で），
私がしたいと思ってることを一番理想的に行える気がする。

>>367
だからWindows起動時とかログイン時に
少なくともWSL上のLinuxコマンドをなにか実行したらかってに起動するでしょ？

>>364
メリットっていうか複数のカーネルが動いたら不自然なだけだよ

WSLというのは本来Windowsカーネル上でLinuxアプリが
動くというもの、その場合Windowsカーネルは当然一つ

WSL2でもそれを踏まえてLinuxカーネルこそ使うが
それはWindowsカーネルの一部として同居しているようなもの
理想的には裏でWindowsカーネルとLinuxカーネルが情報をやり取りして
どちらからでも同一の情報を参照できるのが一番

WSL1ではそれを実現しやすくて、WSL2ではLinuxカーネルをそのまま使うから
Linuxとの互換性は上がるが、カーネルの情報が分離してしまうというデメリットが有る
そのデメリットはしょうがないにしろアーキテクチャ上は、1つのWindowsカーネルの
サブシステムとして1つのLinuxカーネルがあるほうが適切

どっちもデメリットが目立つな
やっぱLinux使えばいいじゃんってなる

スタートアップにWSL入れとけばすむ話し？

>>367
Windows初心者っぽいけど、いったい何がしたいんだ？

ログインしなくてもOSが立ち上がった状態で
他のマシンからアクセスできるということならサービス化なんだけど
WSLでできるかどうかは知らない

そこはcygwinのサービス化でw

でも、WSLなら本物のGNUが使えるぞ。

一週間待ってください
本物のGNUを食わせてあげますよ

Cygwinはパチモンやったわ。
これからは本物使わせてもらいますわ。

BoWはパチモンやったわ。
これからは本物使わせてもらいますわ。

Bash on Windowsやない、BSD on Windowsやで。

>>378
BOWはCYGWINと違ってBSD実行ファイルをちゃんと動かせるシミュレーターみたいなものだよ

>>380
Cygwin以上のパチモンやったわ。

>>372
wsl.exeを実行したときのウィンドウを立ち上がらせない状態で，
Linuxカーネルを起動して
それ以降にwsl.exeを実行したときのオーバーヘッド
（コンテナを立ち上げるより前にLinuxカーネルを起動するという）
を無くしたいと思っています。

>>370
Linux使うといちいち同期を取らないといけないのがめんどくさい
WindowsいったりLinuxいったり、
ファイル共有の設定したりSSHログインしたり
OSのアップデートとかしたり

ID:tZdYKzq9 はWindowsもCygwin使ったことないニワカだねｗ
自己破産しちゃうような貧乏人なんだろうねぇｗｗ
あえて名前は上げないけどｗｗｗ

>>382
だから起動時にスタートアップか何かで
コマンド実行すればいいだけでしょ？
たったそんだけ

適当に作っても一瞬黒い画面が出る程度で終わる
ちゃんと作ればそれもでなくなるだろうけど

たったそんだけの話をしてるんだよね？

スタートアップにショートカット放り込んで、そのショートカットのプロパティ弄ればいいだけのことなんだけどね。
こんだけ粘着するのってまるで志賀みたいでｷﾓいわーｗ

そもそも初回の起動時間ってどのくらいなん？
パソコンつけっぱなしで再起動したくないからわからんのだわｗ

wsl -l -v でVERSION 2とでてるUbuntuを
wsl -t Ubuntuで停止させた状態で
Ubuntuを起動すると2〜3秒ぐらい

UbuntuのSTATEがRunningになった状態から
Ubuntuを起動すると一瞬。1秒未満

WSL2がこれより遅いことって有るんか？

ん？もしかしてWSL2の仮想マシンって2〜3秒で起動してる？
こりゃはえーわｗ

>>383
ん？Windows使わなきゃいいじゃん

Windows使わないと仕事にならんだろｗ
OfficeとかMSの開発ツールとか

>>390
？？？
Officeはオンラインで動くよ？

>>391
Linux使っても、結局Microsoft製品使うんですねｗ

LinuxユーザーってWindowsが嫌いなくせにWineでWindowsアプリ使ってるんだよな
だったら最初からOSをWindowsにすればいいだろ

結論としてはどうせMicrosoft製品使うんだから
Windows使えばいいじゃんことになる
GUIはWindowsの方が使いやすいんだからさ
どちらか一方ならWindows選ぶよってだけの話

>>392
そりゃ使うでしょ？
Windowsは要らんけど

>>394
揃える必要はない
GUIもLinuxのほうがシンプルで良い

> シンプルで良い
LinuxのGUIの何がいいの？って何度も聞くんだが
答えが出たことってないんだよなｗ

>>397
シンプル

本物のGNUツールが使えることです。

GNU is Not Unix そして Linux Is Not UniX です。
素晴らしいですね。

Windowsではないということ、それ自身が価値となる。

-- Dang Kogai.

>>398
どこが「シンプル」かを一言も言ってないと言ってる

>>400
それ自身には価値がないってことですか？って言ってやれｗ

Linux は人類の共有財産。
水や空気のようなもの。

Windowsがなくなってもあまり困らないけどLinuxなくなったら人類規模で大混乱が巻き起こるだろうなぁ

Windowsがなくなってもあまり困らないなんて思ってる人がいるのか？
人類滅亡まではしないだろうが（それはLinuxも同じ）
大混乱間違いなしやろ

人類の定義が違うんでしょ

windows上でlinuxが使える事が便利なんだからそうじゃないなら使わなければいいのに

× windows上でlinuxが使える事が便利
○ windows上でlinuxコマンドが、Windowsのファイルやexeコマンドと組み合わせて使えることが便利

単にLinuxを使うだけならLinuxマシン使えばいいだけなので仮想マシンですでにできていた。
WSLが便利なのは、仮想マシンという隔離された環境のLinuxではなく
本当の意味でWindows上でLinuxコマンドが使えること

WinのプログラムとLinuxのプログラムでパイプ通して使えるんだっけか、しかも相互で

>>409
そうそう。しかもちゃんとUnicode対応

もともとWindowsはUTF-16に対応していてテキストモードがUnicodeモードだと
Unicodeで出力されるんだが、当然それはUTF-16で出力される
だけどそれの出力をWSLでみるとUTF-8に変換されてる。

WSL上でこんな事してみるとしてみるとちゃんと日本語が文字化けせずに見れるのがわかると思う
cmd．exe /c dir '%USERPROFILE%\Documents' | less

突然書けなくなった？！？

登 録 コ ー ド って書き込もうとしてるやろ？

>>410
面白いなー

pathの変換コマンドも面白いと思ってて、
.bat 書くよりWSL上のコマンドを駆使してshell script 書く方が、
書くのは圧倒的に効率的で早いし、Windowsバイナリを
shell script の中で起動できるからこりゃいけるわ！と歓喜した.

しかし、実行したWindowsバイナリは、Windows側からみた
pathにしかデータを吐けないから、データはWindowsファイルシステム上に置かれてしまう.
そのデータを同じshell scriptの中でWSLから触ると、死ぬほど遅いという罠.
あと、WSLから起動したwindowsバイナリがWSLのメモリを食い潰して、Windows自体のメモリを圧迫するという罠.
メモリの話は解決努力がなされてるみたいだけど、現状は実用には耐えないかと.

>>412
いや，すまん．
説明のなかで， cmd. exe をスペース空けずに書いてたんだが，それを削除したら書けた．

> そのデータを同じshell scriptの中でWSLから触ると、死ぬほど遅いという罠.

え？どれくらい遅いの？
遅いのはファイルを開くときであって
普通に読み込むときの速度は変わらないけど？

> あと、WSLから起動したwindowsバイナリがWSLのメモリを食い潰して、

WSLのメモリってなに？
WindowsバイナリがLinux環境で動くわけないんだけど

なんかてきとーなうそついてんなーｗ

> しかし、実行したWindowsバイナリは、Windows側からみた
> pathにしかデータを吐けないから、

これも嘘だな。UNCパス、つまりネットワーク共有フォルダを読み書きできるなら
WSLの中にも書き込める

>>416
ごめん，　vmmem

> あと、WSLから起動したwindowsバイナリがWSLのメモリを食い潰して、

Windows バイナリを WSL 側から起動したとき，
vmmem がどんどん肥大化することを言いたかった．

>>418
WSLに samba 走らせて，同じPCの Windows 側から高速に読み書きできるってことですか？

ちなみに， PC1 のWSLの中からWindowsバイナリ起動 -> NAS(UNCパス)　に書き込んで，
PC1の WSL の同じ shell script から /mnt/z に mount した NAS にアクセスすることは試したが，糞遅い．死ぬほど遅い．

>>415
Shell Script を走らせて，その中で
Windows バイナリが　Windows ファイルシステムに書き込んでから，
同じ Shell スクリプト の中で100MB のファイルを 100個開いて処理して，少しだけけデータを保存する作業

を
1. Cygwin 上で走らせたとき
2. WSL2 上で走らせたとき

で比べて，２〜３倍遅い．

>>420
この，「糞遅い，死ぬほど遅い」というのは， >>421 の2,〜3倍のこと．

wsl1使うと少し早い。

>>418
デフォルトでWindowsホームにファイル吐き出すツールがあるんだけど
これをWSLホームにファイル吐き出すにはどうすればいいの？

>>419
> Windows バイナリを WSL 側から起動したとき，
> vmmem がどんどん肥大化することを言いたかった．

Windows バイナリを WSL 側から起動したって
実行されてる場所はWSLとは無関係なんだから
Windowsから実行したのと同じだって

>>420
> WSLに samba 走らせて，同じPCの Windows 側から高速に読み書きできるってことですか？
sambaの方が遅いだろ

>>424
> デフォルトでWindowsホームにファイル吐き出すツールがあるんだけど
まずはそのツールがUNCパスに対応してるかどうかだ
そのツールの問題だ

>>425
>まずはそのツールがUNCパスに対応してるかどうかだ
>そのツールの問題だ
え、対応してないツールは使えないの、ゴミじゃん
WSLから実行した時は特殊フォルダを置き換える、ぐらいしてくれないと使い物にならんじゃん

アプリの出力先は、そのアプリが決めた業務条件だから、
勝手に変えたら、ダメ！

そのアプリか、そのアプリの使用者の意図で変えるべき、業務条件。
責任範囲が全く異なる

>>426
> え、対応してないツールは使えないの、ゴミじゃん

UNCパスに対応してないツールは
昔からネットワーク共有フォルダに対応してねーだろ？
それがツールの問題じゃなくて何なの？

まあネットワーク共有フォルダに対応してないなら
ネットワーク共有フォルダをドライブに割りあげるだけで使えるけどな

ツールの問題をWindowsは解決してくれる。
ツールがゴミでもWindowsは素晴らしいなぁｗ

> WSLから実行した時は特殊フォルダを置き換える、ぐらいしてくれないと使い物にならんじゃん

意味不ｗ エアプだから何が問題なのかわかってないんだろうなｗｗｗ

>>428
あー、ちがうそうじゃない
UNCじゃなくてホームフォルダとか特殊フォルダのことね
WSLでホームに出力って処理したのにWindowsのホームに出力されたら糞でしょ

WSLとWindowsでホームが2つあるからもうめちゃくちゃだ

ネットワーク共有対応してないと使えないってのもおかしな話だよな
スタンドアロンのWindowsで動かしてんのになんでネットワーク対応せなあかんねん

何言ってんだこの馬鹿

>>431
いや分かれてた方が無難だろ・・・。

>>434
なんでターミナル使いたいだけなのにホームが複数あんだよ？

これが仮想マシンだっつーならわかるよ
でもターミナルなんだろWSLは？
なんでターミナルごとにわざわざホームを切り替えなきゃいかんのだ
shもbashもashもzshもホームは1つ
それが当たり前だ

>>430
> UNCじゃなくてホームフォルダとか特殊フォルダのことね
ホームフォルダは実際にはただのパスでしかない

UNCの意味がわかってないようだが、これはWindowsが対応しているネットワークのパスであり
メモ帳などちゃんと作られてるアプリは、ネットワークのパスを参照できる
WindowsからWSL上のファイルを参照するときも、このUNCパス

> WSLでホームに出力って処理したのにWindowsのホームに出力されたら糞でしょ

そんなことにならないよｗ
ちゃんとWSLのホームとWindowsのホームは別れている

>>431
> WSLとWindowsでホームが2つあるからもうめちゃくちゃだ
代わりに仮想マシン使っても分かれるじゃんｗ
シンボリックリンクでリンクできるんだからめちゃくちゃにはならない

>>432
> ネットワーク共有対応してないと使えないってのもおかしな話だよな
普通のアプリはちゃんと対応している
ネットワークドライブから直接、動画ファイルや音楽ファイルを直接開けないなんてことあると思うか？

お前が作ったクソツールならありえるだろうなって話しかしてない

>>436
> なんでターミナルごとにわざわざホームを切り替えなきゃいかんのだ

WSLではUbuntuとFedoraとOpenSUSEとみたいに
複数のディストリをインストールすることが出来るからだよ

ディストリが違うのにかってに共有されたら困る
自分で必要なものだけを共有すればいいだけ

Windows上で複数のLinuxディストリが使えるというのは
実はLinuxでもできないことなんだよな

Ubuntuをインストールしたら、使えるのはUbuntuだけ
もちろん仮想マシンを使えば使えるけどねｗ

WSLだとUbuntuの最新版と一つ前を同時に実行してテストするなんてこともできちゃう
ターミナルごとに使うディストリを変えることが出来る

>>436
ターミナルって端末のことなんだが

>>437
仮想マシン使ったら分かれる
当たり前だ別のインスタンスだもの
しかしターミナル使うだけでホーム別れたらおかしい

>>438
仮想マシンなら別れていい
ターミナルなら1つであるべき

>>442
ディストリ使ってるんだから別れてる
当たり前だ別のディストリだもの

異なるディストリのターミナルなんだから
ディストリ毎に違うのは当たり前

仮想マシンだけが、ディストリを分ける手段じゃないんだよｗ

つまり結局のところWSLはターミナルではなく仮想マシンということだな
WSLをターミナルのように考えるとおかしくなる

だからターミナルって端末のことだって

違うディレクトリを使うからホームが分かれるとかまじで意味不明
インスタンスが違うからホームが分かれてるんだよ

>>445
WSL2であっても仮想マシンは一つしか起動してない
複数のディストリがあっても仮想マシンは一つ

お前は仮想マシンごとにホームが有るのはおかしくないと
言うつもりなんだろうが、仮想マシンはひとつなんだよ

矛盾してるのは、ホームを分ける手段が仮想マシンしかないと思いこんでるから。
WSLは複数のディストリを入れて、それぞれにホームを分ける手段を提供している
設定でホームを変えれば簡単にWindowsのホームと同じにすることは出来るが
そっちのほうが不便だろう

WSLは複数のディストリを同時に動かすことが出来る
だからターミナルもディストリごとに分かれている
ターミナルはターミナルだが、複数のディストリが存在している

>>447
そうそう。WSLの中でUbuntuとFedoraとOpenSUSEのように
インスタンスが違うからホームが別れているんだよ

ちなみに仮想マシンだと、LinuxからWindowsのexeが実行できないので
明らかにWSLは仮想マシンではない

>>448
もうめちゃくちゃでわけわからんな
仮想マシンならホームは別れてて当たり前
ターミナルならホームは1つじゃないとおかしい
なんでこんな複雑でわかりにくい糞仕様しちゃったんだWSL？

>>449
つまりWSLは仮想マシンってことだろ
先日WSLはターミナルとか言ってたバカはなんだったんだ？

>>450
仕組みを作ればできるだろ

WSLがターミナルだとしたらWindowsとWSLでユーザー違うのもおかしな話だ
WSLはただの仮想マシンでありターミナルではない

あぶねえ
WSLはターミナルとか言う変なやつに騙されるところだった
やっぱりWSLはターミナルじゃなくて仮想マシンだった
普通に考えりゃ当たり前だけどな

>>451
> もうめちゃくちゃでわけわからんな

ん？お前が馬鹿なんじゃね？
ディストリが異なるから、ホームが別れていて当たり前
これがわからんのでしょ？

>>452
> つまりWSLは仮想マシンってことだろ

ただし複数のディストリがあっても
仮想マシンは一つしか起動してない

仮想マシンは一つなのにディストリごとにホームがある
ボームはディストリ事にあるべきものだからだ

WSL1は仮想マシンなんか無いぞ

>>456
ディストリが別れてるからじゃなく別のインスタンスだからだろ
別のインスタンスが同じディストリだろうが異なるディストリだろうが関係ない
WSLはただの仮想マシンだからホーム(とユーザー)が分かれてる
もしターミナルだったら別れないはずなのでWSLはターミナルではない