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

>>752
> rsyncやSFTPの時代にファイルの属性で困るわけないでしょ。

Windowsで編集すると、Windowsには実行属性がないので
それがLinuxに反映されることがない

ということも知らないのかな？やっぱり使ったことなさそうｗ

>>754
それがレンタルサーバーで困った話を検索したと言ってんの。

まあ、Linux板だから、VS使ってる人もWSL使ってる人も少ないだろうけど。
わかってる人が居たら、ちょっと恥ずかしいだろね。
使ったことないんだなってすぐわかるから。

> それがレンタルサーバーで困った話を検索したと言ってんの。

レンタルサーバー（Linuxマシン）で困るなら、
普通のLinuxでも困りますよねｗ

>>756
>>697 を実際にやってみれば良いのでは？

>>697以外の例では困るから
>>697限定にしてるんですよねｗ

exeに実行権限付ければLinux上で起動できると思ってるらしい。

>>759
別の話をするんですか？
それでは、Linuxマシンを使って、Linux上でexeを起動するにはどうしたらいいのでしょう？


念の為、WSLの方が楽々になるという話をしています。

>>739へのレスです
> むしろWSLで何が楽々になるんだよ？

使ったことないのが丸見えだったのだが。
最初からそう言ってるのに。

>>760
まったく別の話じゃないだろ。
やっと気が付いた？
それで恥ずかしくなって誤魔化そうとしてるのかな？かな？

さて、VSは何処でバイナリをこさえるでしょうか？

また質問に答えませんでしたねｗ

つまりWSLの方が楽々なんです。

では、それを踏まえたうえで、なにに困ってたのでしょうか？
そもそもコイツ、Microsoftがなぜ不安定なrsyncにこだわったのかさえ分かっていなさそうだな。
なにに困るのかわからないみたいだし。

>>764
で、半年くらいすると、「実行権限は問題ないと言ったのは俺だ！」と書き込むんだろ？

困っていたといい出したのはお前であって
WSLの方が楽だって言ってるんだが？
話すり替えるなよ

まあ言っときますが、WSLはやめておけ、まだ時期が早い。

>>767
ほお、じゃあ困っていなかったんだな？笑

困っていなかったんだって。
この子使ってないわ。ｗ

> そもそもコイツ、Microsoftがなぜ不安定なrsyncにこだわったのかさえ分かっていなさそうだな。

MicrosoftはWSLでrsync使ってませんよ？

>>769
「困ることが有る」と「WSLの方が楽」は両立します

例 仕事は楽だけど給料が少なくて困る

>>770
VSでrsync使ってたんだよね。
さて、WSL関係なくLinux使いなら常識ですが、Microsoftはなぜrsyncにこだわったのでしょうか？

>>772
> Microsoftはなぜrsyncにこだわったのでしょうか？

過去の話で、当時はそれが最善の手段だったからだろうなｗ
その後でWSLが登場した。だからといってすぐに古いものを切り捨てたりはしないが

はあ、馬鹿だねえ。
rsyncも知らないのか。

得意の検索してこい。

rsyncは○○です。と答えたら
なにか状況が変わるんですか？ｗ

あなたが好きな言葉を当てはめてください。
そして、それに対して自分でレスしてください。

ハッキリ言ってWSLはやめとけ、いまはまだ時期が早い。

Microsoft製品はバージョン3になってから買えって言うだろ？

お前は時期が早いを何一つ答えてないんだがねｗ
いくつ質問したっけ？一つも答えてないよね

時期が早いの理由を

ウェブ開発者はWSL使っても良いこと無いので、WSLを試す時間があったら、コードの一行でも書くほうが良いと思います。

使えるようになったら使え。
今はまだ早い。

> ウェブ開発者はWSL使っても良いこと無いので、

この人は、

1. 良いことがないの理由を一つも言っていません
2. WSLの方が楽々です。に反論していません

>>777
俺は答えないよ。
俺が問題を出してお前が答える。
これからはこの方式だ。

おまえ、俺の書き込みを自分のセリフって事にしちゃうだろ。
だからもう、情報は与えない。

質問に答えられないお前を馬鹿にするだけにする。

はい、にげた（笑）

こういうこと。俺が答えてもこいつは何も反論しない

>>782
実行権限は？どうなった？理解したか？

>>783
Linuxマシンを使うと、設定が何もされてないので
簡単に実行権限が消えてしまいます。
WSLの方が楽々な理由の一つです。はい答えました。反論がないのは知ってますｗ

デザイン班はマック、コーディング班はLinuxで良いだろ。
それが一番便利。

>>784
それ、Windows使うとダメな理由になってねえか？

最初からLinux使えばええやろって話では？？

やっば、教えてしまった。笑

>>786
WSLだと、Windowsと相互運用設定が完了しているWSLを使うのでその問題が解決します。

> 最初からLinux使えばええやろって話では？？

LinuxではWindowsアプリが動きません。
だからmacOSを使うしWindowsを使うのです。

実機にSSHで接続するのが一番楽ちんちん。

1. WSLのインストール vs Linuxのインストール

WSLのインストールの方が簡単で時間も短く
設定項目はLinux用のアカウント名とパスワードだけです。
Linuxの場合、パーティションの設定など多くの作業が必要です。

勝者：WSL

2. ターミナル起動 vs SSH

ターミナル（Ubuntu）はスタートメニューのボタンをクリックするだけです。
SSHの場合、コマンドプロンプトを起動しSSHで接続しますが
パスワードを聞かれて面倒なので秘密鍵を作る作業はほぼ必須でしょう

勝者：WSL

3. WSLからexe実行 vs Linuxでexe実行

Linuxでexe実行しても動きません。LinuxからWindows用のコマンドを実行できません。
LinuxからWindows用のコマンドを実行するにはWindows側にもSSHサーバーをインストールする必要があるでしょう

勝者：WSL

いや、俺もWSL使ってるんだよ？
使ってるだけに、これはまだ製品のレベルに達してないから、他人には勧められないなって。

こんなもん他人に勧めるバカはなんだと思う？
愉快犯でしょうが。

> 使ってるだけに、これはまだ製品のレベルに達してないから、他人には勧められないなって。

なぜそこだけ「他人に勧められますか？」って質問しないんですか？

答えは言わないっていいましたよね？
なんで自分で勧められないって答えを言ったんですか？

https://mao.5ch.net/test/read.cgi/linux/1608010142/l50

このスレに来てアンケートに答えてくれないなら、もうお前とは話さない。
絶交だよ！

でも、来てくれたらイイネするよ。

Web開発にWSL2使ってる開発者知り合いにそこそこいるわ
なんならWSL2のおかげでMac or LinuxからWindowsに完全に移行したってやつも

>>727
>GUIは対応してません

GPU仮想化機能を使ってWaylandをnativeに動かせるようにするんだけど？
ただの仮想化ソフトには出来ない芸当。

>>797
GUIとGPUでは意味が違う

あとGUIに対応しないって主張していたのは初期の話ね
将来的にはGUIアプリにも対応することになったようだが、デスクトップ環境には対応しないだろう
つまりWindows上でGUIアプリを動かす。相互運用を考慮した実装。その時点でLinuxマシンと違う

>>796
オレも、もうWSLが無いWindowsは考えられないほど依存している。あとKeyhacにも。

>>798
戦略ミスだろな。
完ぺきにLinuxが動けば、Linuxユーザーが増え、Linuxへの移行パスとなり得る。
したがってMicrosoftは、いずれかの時点で戦略ミスに気付き、完ぺきに動かない程度に維持するはず。

WSL使えないって言ってるやつ、Linuxまともに使えない能無しだな。

>>800
Linuxユーザーは増えないよ。Windowsの一つの機能になるだけ。

Windows用ソフトウェアはWindowsでしか動かない。
Linux用ソフトウェアはWSLがあるのでWindowsでも動く。

すると、ソフトウェアベンダーはLinux用のソフトしか作らなくなるのでは？
Linux用ソフトしかなくなった世界で、Windowsはどうなるだろう？

やはり戦略ミスだわ。

無能が的中して良かった

Linuxってサーバーで圧倒的に使われている技術なんだけど。その開発のためにもWSLが使われている。クライアントとサーバーを区別できてない奴多すぎ。

>>803
Windows用ソフトウェアもLinux用ソフトウェアも動かせるWindowsこそ最強ってなるだけだな
ソフトウェアベンダーがLinux用のソフトしか作らなくなるとしても既存のWindowsアプリが消えてなくなるわけじゃなし

>>803
Linuxで動く様な商用ソフトって、ほとんど無いような。
あってもATOKみたいにdisconになる。
依存地獄のサポートなんてしたくないよな。

>>803
ソフト作ったことないだろ
WindowsでもLinuxでも動くように作るのは面倒だし何より商用ソフトはテストの手間がバカにならん
Windowsのシェアが半減しない限り普通のソフト屋はWindows専用で行く

>>800
> 完ぺきにLinuxが動けば、Linuxユーザーが増え、Linuxへの移行パスとなり得る。

完ぺきにLinuxが動けば、Linuxに移動する理由がないよ
だってLinuxは完璧に動かない。Windowsアプリが

WindowsアプリとLinuxアプリが完璧に動くWindows vs Linuxアプリしか動かないLinux
結果は火を見るよりも明らか

>>803
> すると、ソフトウェアベンダーはLinux用のソフトしか作らなくなるのでは？
> Linux用ソフトしかなくなった世界で、Windowsはどうなるだろう？

そのLinux用ソフトをWindowsで使うのでは？ｗ
だってLinuxじゃWindows用ソフト動かないでしょｗｗｗ

WindowsがLinuxに侵食されるのを心配するより、chrome osに侵食されるのを心配したほうが良い。chrome osは管理が楽でAndroidアプリが動いて、最近学校に大量に導入されている。

Microsoft「だからクラウドにビジネスの主体を移動して
Windows 10の無料アップデートを実現したんだよ
普通に考えればOSの利益が減って損すると思うだろうが
MicrosoftのビジネスにとってWindowsはすでに重要ではない。
いつから計画して、いつ実現したのかわかるかな？」

やりがいのないLinuxプラットホームでソフトウェアベンダーがアプリをリリースする事は殆どないんだよなあ
ここは現実とかけ離れておかしくなっている奴が多いのか？ｗ

依存地獄がなんてやってたら、常用環境がおかしくなったわ。
アプリ設定画面からリセットかけても初期化されないので削除するしか無かった。
再DLめんどくせーな。

Flatpak, Snap, AppImageとかElectron, PWAなんかでリリースすれば依存地獄なくなるんじゃね

>>815
毎回フルパッケージでリリースって要領が悪すぎる
というかそれ以前の問題なんだよ

>>816
あ、はい。手元にあるファイルとの差分だけを
ダウンロードする仕組みを作れってことですね

>>817
ちなみにnix*とかはそうしてる。

>>727
すでにGUI（GPUはもうとっくに動いてる）動かすっていう話
が出てるんだよなぁ。

情報更新して，どうぞ
https://devblogs.microsoft.com/commandline/whats-new-in-the-windows-subsystem-for-linux-september-2020/

GUIに対応しないと言っても、WSL1の初期からXVNCでも何でも好きな鯖入れて使えてたし
音が出ないも自分でPulseAudio入れてホスト(Windowsでも、他のLinuxホストでも)にリダイレクトするだけだったし

対応しない ではなく お前にはできない だっただけ。

なんちゃってユーザーだろ。
使ったこと無いと思う。

遊んでるだけ

WSLはまだ使い物にならないから、なんちゃってユーザーが多い。

いやふつうに開発で使ってるって
ほんまこいつずっと何言ってんだ？

WSLが使える道具だってわかったら困るんだろ？
志賀なんとかスレで荒らしてるやつが
ここにも来てるみたいだし

「ぼくの書いた記事を読んだのだろうけどあれでは使えない、なぜなのかはお前が書け」
「ぼくがデスクトップ画像を貼ったらピタッと止まった」
「彼らには使えているはずがない」

これ追い出さないとダメな奴

単に自分のものさしでしか物事を測れないってだけだと思う。実機に勝ものなしっていう、ものさし。

実機だとドライバ周りやらグラボまわりやらで要らねえトラブルおこるから、Linuxアプリ使うだけならWSLのが手軽まである。

Emacsを通してしかLinux使ってないから、WSLで十分なんだよな。VcXsrvでWindowsの一画面として動くし。
デスクトップ環境なんて必要ないから、かえってスッキリしていい。起動しているプロセスも数えれるほど。

>>829
ちょっとだけLinux使いたいって人には最適解ですね。特にWSL1はね。
mingwでうまく動かないときに使ってる。

WSLの前はCygwinでgnupack使ってたんだけど、遅かった。特にmagitは使い物にならないくらいに。forkエラーも時々出て途方に暮れた。WSLでそれらがみんな解決した。

>>830
ちょっとだけでなくガッツリ使ってるよ。

Linuxアプリが動くだけじゃなくて、環境が標準化されてるっていうのがいい
WSLという形で、仕様が決まってるから
アプリも対応しやすくなる

さっき作ったシェルスクリプトは、外部コマンドとしてあるバイナリを
内部で呼び出すんだけど、Windows用バイナリでもLinux用バイナリでも動くようにできた
Windowsメインで使ってる人は、exeをダウンロードするだろう、そしてそれを使える
WSLメインで使ってる人は、Linux用をダウンロードするだろう、それも使える
どちらでもよい

WSLはGNU/Linuxのディストリビューションが使えるのがいい。MacなどのBSD系のUNIXはコマンドのオプションが微妙に異なっていて、作ったスクリプトなんかをLinuxサーバーに転用できない。DockerもLinuxをベースとした技術だし。

だから Mac用にWSL2を作らないかな？完全互換で
仮想マシンだから作れるやろ？

>>835
異なるオプションを持つ同じ名称のコマンドが混在して混乱しそう。WSLはUNIX系のOSじゃないWindowsで動くからいいのかも。

>>836
Mac版のコマンドは全て使えなくすればOK
つーかすでにLinuxのコマンドと混乱してる
すべてGNU版のコマンドに入れ替えればいいのに

Windows 10XでWSLは動くんだろうか。
https://gigazine.net/news/20210115-microsoft-windows-10x-leaked/
あとKeyhacが動くかが気になる。

>>837
出来るってよ
https://i-beam.org/2012/09/17/110914/

>>839
知ってる。GNU版のコマンドに入れ替えても問題なく使える。

だからWSL2と同じようにLinuxカーネルを動かす仮想マシンであらゆるディストリを
複数同居できるようにして、デフォルトでmacOS側のファイルシステムをマウントし
Linux側からmacOSのコマンドを実行できるようにすれば、macOS版のWSLが出来るはずなんだ

真のLinuxカーネルで真のLinuxディストリを動かしつつ
そのLinuxからmacOSを制御したい

>>838
今の所
https://i.imgur.com/jaRWrzv.jpg

>>840
それ意味ある？

>>842
Linuxのコマンドと信頼性が高いUbuntuのパッケージが使える
macは/bin/shが古いbashなのも気に入らない

>>841
動くんだ

>>843
bashが古いなら自分でソース取ってきてmakeすればいいじゃん

どうもこのスレにいるやつはレベル低いな

>>843
なんとなく思ったんだけど、MacでもDockerが動くんだよね。ということはLinuxカーネルは動かせる。
以下を読むとWSL2的に動いているようにも見える。
https://www.it-swarm-ja.tech/ja/linux/docker%E3%81%AFmacos%E3%83%9B%E3%82%B9%E3%83%88%E3%81%A7linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%92%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%BE%E3%81%99%E3%81%8B%EF%BC%9F/831105280/
なのでやろうと思えば出来ることのような。
そもそもDockerのコンテナ使えばある程度のことはできるのかも。

あった。multipass。
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0590
https://hnakamur.github.io/blog/2019/10/17/multipass-on-windows-and-macos/

>>845
シェルスクリプトの一行目には#!/bin/shって書くのが普通なんだよ
そして/bin/shは入れ替え不可能になってる

>>847
> なんとなく思ったんだけど、MacでもDockerが動くんだよね。ということはLinuxカーネルは動かせる。
依存関係が逆。DockerがLinuxカーネルを使ってる。DockerにはLinuxカーネル含まれてないし、動かす仕組みもない
Linuxカーネルが動くから、Dockerが動くんだよ

勘違いしてそうだけど、MacでDockerを動かす仕組みはWindowsでDockerを動かす仕組みと一緒。
macOSもWindowsも「Linuxではない」からLinuxカーネルの機能はない。
だから仮想マシンの上でDocker独自の軽量ディストリでLinuxカーネルを動かしてる。
macOSでも仮想マシンを使ってるんだよ。


一応補足するとWindowsにはLinuxカーネルの機能はないと言ったが、
WS1では仮想マシンを使わずに、Linuxカーネル互換機能を提供するものだから
完璧ではないが今のWindowsにはLinuxカーネルの機能があると言える。

そして仮想マシンを使うWSL2ではDocker独自の軽量ディストリの代わりに
MSが作ったWindows公式の軽量ディストリを使うようになった
WSLでは複数のディストリを同時に動かせるが、WSL2で使うLinuxカーネルは一つしかない
共通のLinuxカーネルの上でDockerを含めた複数のディストリを動かすから起動も速くメモリ効率もいい

>>850
長々書いてくれたけどDockerがLinuxのカーネルを使うことは分かっているよ。847のリンクの中の図がそうなってるよ。

>>851
そこがわかってるならDocker持ち出す必要ないだろ

Macでも仮想マシン使えるんだよね。ということはMacでも
Linuxを仮想マシンにインストールして使うことが出来る。

といえば済むだろ

MacでもDockerが動くならMacでもLinuxのカーネルが動かせると書いたんだよ。分かりづらくてごめんよ。