X
トップページ⇒Linux
1002コメント348KB
【Bash】Windows Subsystem for Linux【WSL】5
■ このスレッドは過去ログ倉庫に格納されています
0491login:Penguin
垢版 |
2019/05/07(火) 23:23:11.60ID:ITEXxCds
>>485
詐欺に加担している広告業界が健全なわけねーじゃん
0492login:Penguin
垢版 |
2019/05/08(水) 08:05:39.47ID:xAWOG2G2
朝日新聞「今だから作れる祖母の味　キムさんのスープ」
https://hayabusa9.5ch.net/test/read.cgi/news/1557220519/
　
　
今だから作れる祖母の味　「キムさんのスープ」

　祖母の愛情も、自分のルーツも、素直に受け入れられなかった少女が大人になり、生まれ育った長崎市でカフェを開いている。
いまだからこそつくれるスープに自身のアイデンティティーを重ねながら、お客さんたちを元気にしている。

　長崎市江戸町にあるカフェ「Ｎｏｂｉｓｔｅｒ（ノビスタ）」。４月中旬のお昼どき、１０席の小さな店に常連客が次々と訪れる。
オーナーの金海伸子さん（４３）がつくるこの日の日替わりスープは「キムズスープ」。
ニンジンや大根などの根菜に、調味料はみそとコチュジャン、ごま油。
「おいしい」「この味好き」と言いながら、心と体をあたためて、午後の仕事に戻っていく。

　日本人の母と在日韓国人２世の父との間に生まれた伸子さん。長崎市で育ち、話す言葉も日本語だったが、食卓は周りの家とは違った。
母がつくるハンバーグなどのおかずに、父方の祖母、金（キム）西運（セイウン）さんがつくるキムチやナムルが並んだ。

https://www.asahi.com/articles/ASM4Q66FDM4QTOLB00Z.html
https://www.asahicom.jp/articles/images/AS20190506001187_comm.jpg
0495login:Penguin
垢版 |
2019/05/08(水) 17:34:36.30ID:qVU7ncMt
Interixの互換レイヤー使ってた頃に比べると雲泥の差で今のほうがいいんだけどね。
0496login:Penguin
垢版 |
2019/05/09(木) 00:07:23.11ID:oWnxUloD
ギフハフにソースコードあるけど誰もビルドしてないんです？
Windows Terminal Beta
0497login:Penguin
垢版 |
2019/05/09(木) 00:55:44.99ID:WSOTv708
ちょっと使ったけど文字が綺麗
wsl用ならもうこれでいい
0498login:Penguin
垢版 |
2019/05/09(木) 00:56:12.06ID:ECSW2kDh
Canonical、Ubuntuの「WSL 2」対応を発表　2019/05/08 23:01　後藤大地
https://news.mynavi.jp/article/20190508-820096/

Canonicalは5月6日(米国時間)、「Canonical announces support for Ubuntu on Windows
Subsystem for Linux 2｜Ubuntu blog」において、同日にMicrosoftが発表した新たな技術
「WSL 2 (Windows Subsystem for Linux 2)に対応すると発表した。

UbuntuがWSL 2で動作するようになると、従来よりもファイルシステム性能の向上を期待
できるほか、これまで利用できなかった機能も利用できるようになると見られる。

WSL 2は、LinuxシステムコールをWindowsカーネルのシステムコールに差し替えることで
Linuxバイナリを実行するWSLとは異なり、仮想マシンを利用することでLinuxカーネルを
動作させることでLinuxバイナリを実行するというアプローチを採用している。Microsoftは
この技術によってWSLが抱えているファイルシステム性能の低さが改善されると説明している。

MicrosoftはWSL 2は通常のアップデートの中で提供し、WSLとWSL 2の共存も可能だとしている。
アップデートに関して、ユーザーが明示的に作業する必要はないと考えられているが、すでに
WSLで動作するUbuntuをインストールしているユーザーが実際にどのような作業をすべきかに
ついて明らかにされていない。

WSLからWSL 2にアップグレードすることでファイルシステム性能が向上することが期待
されるが、具体的にどのような変化が見られるのかは現段階ではわかっておらず、今後の
詳細な発表が待たれる。
0499login:Penguin
垢版 |
2019/05/09(木) 01:01:48.61ID:Tj0RIc1X
>>494
試したけど神だぞこれ
もうVSCodeのUIをWSL側で動かすようなアホな真似は必要ない
0500login:Penguin
垢版 |
2019/05/09(木) 08:13:43.32ID:QdeAzV/w
新しいやつはグラフィック画面搭載されるの？
0501login:Penguin
垢版 |
2019/05/09(木) 08:18:41.59ID:FNaILRwM
結局、MS は、Vagrant, Chef などで、仮想マシン上に、Linux を構築する手間を省いた

つまり最初から、仮想マシン上に、Linuxを用意してくれる
0502login:Penguin
垢版 |
2019/05/09(木) 08:20:34.88ID:WXPuc6WC
別に今でもGUI表示出来るし
0504login:Penguin
垢版 |
2019/05/09(木) 11:21:53.36ID:nF5xXod/
>>501
それだけじゃないぞ。
今のWSLと同等の使い勝手を提供するって言ってるんだから、
仮想マシン上のLinuxにsambaなんか入れなくても
Windows上のテキストエディタから自由にファイルを触れるようになるはず。

俺が以前Vagrantで開発用の仮想マシン（samba等込）を作っていたやり方に
近いがそれよりもWindowsと統合された物ができるのは確実

あとはメモリ管理がホストと共通になっていればゆうことなし。
仮想マシンにメモリを分配するのはいやなんだよ。
Linuxカーネルに手を入れるみたいだから期待はできる。
0505login:Penguin
垢版 |
2019/05/09(木) 11:45:37.35ID:FBMVNEps
専用のハイパーバイザで動くんだろうけど、今までの使い勝手が変わってしまうのはちょっと嫌だな。
フレームバッファも実装されて画面もLinux管理下になったら普通にVMと変わらないし。
スクショを見るとターミナルは独自のものっぽいが・・・
0506login:Penguin
垢版 |
2019/05/09(木) 12:04:46.11ID:nF5xXod/
>>505
今までの使い勝手は変わらないはずだよ。

普通のVMと違うのは、普通のVMよりはるかに使いやすいってこと
例えば（今までどおり）Windowsから直接コマンドを実行できる
Windowsからファイルの変更ができる
起動が遥かに高速

今までだったらWSLは遅いから自分でVM作るって言ってたけど、
もう自分でVMを使う理由すらなくなるよね。
0507login:Penguin
垢版 |
2019/05/09(木) 12:11:01.05ID:O87sEPbk
まあ判断するのはWSL2の現物が出てからにしようぜ。
つうか元のWSLだって、速度も互換性もネイティブ並みという触れ込みだったんだぞ、忘れたか？
0509login:Penguin
垢版 |
2019/05/09(木) 12:22:17.88ID:nF5xXod/
>>507
最初に登場したときは、ベータ版で
ネイティブ並みなんて触れ込みはしてないはずだが？
ちょっとどこで言ったのか探してきてくれないか？
0511login:Penguin
垢版 |
2019/05/09(木) 12:50:02.24ID:FkGuWnSS
ファイルシステムってどうなるの？
0512login:Penguin
垢版 |
2019/05/09(木) 12:55:42.83ID:FBMVNEps
VMみたいにイメージファイルにもろもろ突っ込んでしまうではなかろうか？
じゃないと散々苦しんだこの問題は解決しないと思う。
今まで通り、C:は/mnt/cとして、WSL側もUNCパスを参照できるだろう。
0513login:Penguin
垢版 |
2019/05/09(木) 13:06:08.27ID:nF5xXod/
>>510
それは「速度も互換性もネイティブ並み」なんて
一言も書いてないって証拠ですか？ｗ
0514login:Penguin
垢版 |
2019/05/09(木) 13:08:56.21ID:uBc0v/pJ
WSLってディストリの概念があるのが凄い気持ち悪いんだが

SlackwareとかGentooとかArchみたいな、ミニマルな構成だけ提供すれば良いのに
0516login:Penguin
垢版 |
2019/05/09(木) 13:10:19.36ID:FkGuWnSS
>>512
それならWindows側からの参照するのにsamba相当のものが必要になるよね
0517login:Penguin
垢版 |
2019/05/09(木) 13:15:09.08ID:nF5xXod/
>>512
おそらくそうだろうね。Windows上のファイルである限り、
ファイルごとにセキュリティソフトが反応してしまう
セキュリティソフトの検閲を回避するには1ファイルにするしか無いｗ

ま、それをやったとしても、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プロトコルサーバーを動かすほうが楽なわけだ。
0518login:Penguin
垢版 |
2019/05/09(木) 13:17:37.55ID:nF5xXod/
>>514
> WSLってディストリの概念があるのが凄い気持ち悪いんだが

それはWSLのせいじゃない。Linuxがそもそもディストリの概念があって
Linuxカーネルと、そのカーネルで動く各種アプリ・コマンドが
分かれて提供されてるのが原因

まあそのおかげでMicrosoftは最小限のLinuxカーネル部分だけを提供すれば
あとは既存のディストリの成果をそのまま使えるわけなんだが
0519login:Penguin
垢版 |
2019/05/09(木) 13:19:07.52ID:nF5xXod/
>>516
> それならWindows側からの参照するのにsamba相当のものが必要になるよね

それがWindows 10 19H1でリリースされる9Pプロトコルのファイルサーバー
samba相当のものが内蔵されてるから、自分で仮想マシン作って構築するより使い勝手が良い
0520login:Penguin
垢版 |
2019/05/09(木) 13:21:23.41ID:uBc0v/pJ
>>518
WSL from scratch があっても良くない？
0521login:Penguin
垢版 |
2019/05/09(木) 13:24:06.55ID:Lf2YpPgU
何でNFSじゃなくてわざわざ9Pを実装してるんだろうね？
Win側のNFSクライアントの使い勝手が悪いんだろうか
0522login:Penguin
垢版 |
2019/05/09(木) 13:24:30.66ID:nF5xXod/
>>520
マイクロソフト「いいんじゃね？そういうディストリも普通に作っていいよ。
ただし我々は、Linuxカーネル相当のものを提供するだけではなく
開発者にとって便利なように、完成されたLinuxディストリを提供する。
その一つとしてUbuntuだ。だが君がfrom scratchを作ることに否定はしない」
0523login:Penguin
垢版 |
2019/05/09(木) 13:24:57.09ID:vTKLnMxn
Microsoft Linuxが出れば解決
0524login:Penguin
垢版 |
2019/05/09(木) 13:26:23.72ID:nF5xXod/
>>521
WindowsじゃなくてNFS自体の問題

https://ja.wikipedia.org/wiki/9P

> ファイルはウィンドウ、ネットワークの接続、プロセスや、その他オペレーティングシステムで
> 利用可能なほとんどのものを表現している。 9PはNFSとは異なり、
> キャッシュや、仮想ファイル(例えば、プロセスを表現する/proc)の提供も補助する。
0525login:Penguin
垢版 |
2019/05/09(木) 13:30:21.57ID:nF5xXod/
ここにも書いてあるな

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に実装された機能だ。このときには、何に使うのかが見えていなかったが、
>実はこうした用途が想定されていたというわけだ。

いろいろつながってるよね。
0526login:Penguin
垢版 |
2019/05/09(木) 13:35:28.09ID:Lf2YpPgU
>>525
サンクス、なるほどね
仮想マシンに移行するならWin側から/procや/sysは触れる方が良さそうだね
0527login:Penguin
垢版 |
2019/05/09(木) 13:42:48.84ID:FBMVNEps
今更WinSockがUNIXソケットに対応して何が嬉しいのかわからんかったけど、なるほどそういうことだったのか・・・

DockerやFUSEが動いてCoderでVSCodeも使える。
それまでの開発ツールを一つの場所に集約できる。
インポート・エクスポートもできて環境のバックアップや以降も簡単にできる。

いいことずくでこれからWSL使う人増えるんじゃないか？
0528login:Penguin
垢版 |
2019/05/09(木) 13:49:04.31ID:nF5xXod/
/procなんか、一部はWindows側の情報を見せるんじゃないかね？
cpuinfoとかmeminfoとか。

そうするとWSL側から、Windowsのプロセスを見れたりするかもしれないな。
これはただの仮想マシンじゃ無理な所でLinuxカーネルを最適化するっていうのは
こういうところなのかもしれない。

/procを通してWindows側と連携できるとなると、
分離されたシステム空間で動かすVMとは仕組みが全然違ってくるな。
0529login:Penguin
垢版 |
2019/05/09(木) 13:50:47.92ID:FkGuWnSS
なるほど
なんか一気に使いやすくなりそうだね
0530login:Penguin
垢版 |
2019/05/09(木) 14:23:19.06ID:+NNjGFTb
>>527
残念ながらCoderは VSCode Remote Development と Visual Studio Online が発表されたため一ヶ月以内には終了すると思われる
0532login:Penguin
垢版 |
2019/05/09(木) 16:55:43.80ID:023cyoaJ
方針転換していちいち反応が必死すぎる
0533login:Penguin
垢版 |
2019/05/09(木) 21:17:16.77ID:UDxbmnjg
いまやMS WindowsのソフトすらもLinux上で開発する奴が増えたからMSがこれはやばいよとなって
MSの物ならPC系Linux、組み込みも簡単に開発出来るんだにしようと必死しているからな
VSCode Remote Development、 Visual Studio OnlineとかさすがMSだよな
まぁ、開発をしない普通のLinuxユーザー(ただクレ乞食)をMSに取り込む気はないだろうが、開発をやっている連中は
取り込みたいよな。
0534login:Penguin
垢版 |
2019/05/09(木) 21:30:58.77ID:mWOCBsvs
Windows用アプリケーションをLinuxで開発するってなんかの罰ゲームか
マルチプラットフォームでLinuxがメインターゲットの場合だってWin固有のコードはWinで開発するだろ
0535login:Penguin
垢版 |
2019/05/09(木) 21:43:22.93ID:6mW9DL3O
windowsやlらinuxやらって大変だね
素直にmacにすればいいのに
0536login:Penguin
垢版 |
2019/05/09(木) 21:45:54.65ID:eRAsguLm
仕事でMacとか使わないからなぁ
0537login:Penguin
垢版 |
2019/05/09(木) 22:04:06.35ID:bmJxDBYf
>>535
世の中から引きこもりたくないし。
0538login:Penguin
垢版 |
2019/05/09(木) 22:05:43.83ID:6h5TDM3n
うちは庶民なのでMacは遠慮しときますわ
0539login:Penguin
垢版 |
2019/05/09(木) 22:05:59.76ID:ZM3HPgxE
>>533
＞いまやMS WindowsのソフトすらもLinux上で開発する奴が増えたから

へー、そんな事出来るんだ初耳
因みにどんなソフトがあるんだよ低能
0540login:Penguin
垢版 |
2019/05/09(木) 22:26:07.89ID:nF5xXod/
>>533
> いまやMS WindowsのソフトすらもLinux上で開発する奴が増えたから

聞いたこと無いな。だって無理じゃん？VisualStudioとかさ

逆にLinuxのソフトをWindowsで開発するって話は多く聞いていて、
WSLでそれがさらに加速する
0542login:Penguin
垢版 |
2019/05/09(木) 22:58:40.61ID:Zy3jJotr
>>533
一例だけでもいいから具体例はよ
0543login:Penguin
垢版 |
2019/05/09(木) 23:11:42.40ID:GyQqPAUu
>>542
OSSだけど、VLC
ttps://wiki.videolan.org/Win32Compile/

Winでのビルドは頑張ってねとか書かれてる
0544login:Penguin
垢版 |
2019/05/09(木) 23:14:52.71ID:FBMVNEps
10年ぐらい前にChromiumのWin版をビルドしたことがあるけど、
準備がすごいめんど臭くてさらにコードをいじらないとビルドできなかったな。
LinuxとMacはそれに比べて簡単だった。
0545login:Penguin
垢版 |
2019/05/09(木) 23:23:49.57ID:Tj0RIc1X
MSのLinux開発への擦り寄りは最終的には「Azureを売る」へ繋がるわけだけど、肝心のLinux on Azureは散々な有様だよね
十中八九、あと3年くらいしたら今の路線はピボットを迫られるだろうけど、そのときWSLはどうなるんだろうね
0546login:Penguin
垢版 |
2019/05/09(木) 23:28:06.85ID:nF5xXod/
> 肝心のLinux on Azureは散々な有様だよね

大ヒットしてるよ
0547login:Penguin
垢版 |
2019/05/10(金) 01:10:54.15ID:1ytzxSkQ
>>543
そんなん使ってるのVLCみたいなマルチプラットホーム向けの極一部だけだぞ
0548login:Penguin
垢版 |
2019/05/10(金) 02:16:01.63ID:j9HFyirv
Macは大学で導入してるところが多いが
就職したあとどうするんだろ
0550login:Penguin
垢版 |
2019/05/10(金) 09:26:25.37ID:Wm/jGSzK
>>549
困るのは就職できないほうだろｗ
0551login:Penguin
垢版 |
2019/05/10(金) 09:43:14.46ID:zm2wJ1Zy
>>548
winユーザーってこんなにバカなの？
0552login:Penguin
垢版 |
2019/05/10(金) 09:52:23.67ID:Wm/jGSzK
ほらみろーｗ Windowsユーザーにするやつが釣れただろーｗ
0553login:Penguin
垢版 |
2019/05/10(金) 13:00:06.42ID:zm2wJ1Zy
ハハハ、やっぱりwinユーザーってバカなんだね
0554login:Penguin
垢版 |
2019/05/10(金) 13:53:02.63ID:EJ+mbNeR
winユーザーはマカーはmac以外使いこなせないと思ってる
ってことでバカ呼ばわりはまあわかるのだが
>548が犬厨な可能性は考慮してないのだろうか
0555login:Penguin
垢版 |
2019/05/10(金) 14:03:13.70ID:1ytzxSkQ
俺的にはFUSEに期待だな
Winの似た様なライブラリとかドライバとかの類はライセンス的にすんげぇ使い辛いからなぁ
標準でマイナーな書庫の直接マウントとかできる様になると色々と有難い
0556login:Penguin
垢版 |
2019/05/10(金) 14:18:19.24ID:LiOa/NnR
犬もドザもバカーも所詮どんぐりの背比べ
使いやすさデスクトップ編
System7.1以降X未満>>>>>WinXP以降>>>超えられない壁>>>>X以降>>犬
サーバー編
犬>>>>>>>>>>>>Windowsserver>>>>>>超えられない圧倒的な壁>>>>>>>>macOS Server
0557login:Penguin
垢版 |
2019/05/10(金) 14:26:46.61ID:6Bd68FQ/
俺はMacのParallels(VM)でWindows10動かしてその中でWSLを使ってる。
もともとWin10以外にUbuntuもVMがあったけど、WSLだけでどうにかなるからそうなった。UbuntuのVMは捨てた。
0558login:Penguin
垢版 |
2019/05/10(金) 19:48:15.81ID:VrVafN5z
>>557
Mac でコンソールは使わないのですか？（まぁ他の UNIX が細々としていますのでアレですが）
0559login:Penguin
垢版 |
2019/05/10(金) 19:55:51.26ID:6Bd68FQ/
>>558
使ってるよ。
Linux(WSL)が欲しいのはラズパイのクロスコンパイル環境を用意したいから。
0560login:Penguin
垢版 |
2019/05/10(金) 20:02:52.05ID:2zeC/CTQ
>>494
VSCodeをWSL側で動かすことを全力を出した全俺に謝れ

くっそぉ・・・orz
0561login:Penguin
垢版 |
2019/05/10(金) 21:04:22.77ID:2i/BB1PT
>>560
ん？
WSLでVSCode動かしたかったからそういう意味のないことをしたんだろ？
うまくできてよかったじゃん
君以外の誰にも役に立たないことだったけど

まぁ、趣味なんてそんなもんだよ
0562login:Penguin
垢版 |
2019/05/10(金) 21:14:26.73ID:6KEM/fgw
AndroidのAOSPがWSLの半分以下の時間でコンパイルできるならWSL2入れてもいいかなぁ。
CTS動かないと意味ないけど。
0563login:Penguin
垢版 |
2019/05/10(金) 21:15:00.26ID:b7GzZDU+
WindowsにLinuxカーネルをのせるんだったら、次はDockerが生で動いてくれたらいいのにね
0564login:Penguin
垢版 |
2019/05/10(金) 21:15:23.36ID:eyDJVaW1
GNU Octave のwindows 版がlinux上でのビルドです。
0565login:Penguin
垢版 |
2019/05/10(金) 22:30:35.11ID:aG1ZxCIe
>>560
歪んだハックはいずれ正道によって駆逐されるものだ
勉強になったね
0566login:Penguin
垢版 |
2019/05/10(金) 22:53:47.38ID:Wm/jGSzK
>>565
まじそれな。Vagrantやったの無駄だった。
0567login:Penguin
垢版 |
2019/05/11(土) 05:39:58.18ID:23e7vvE0
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だけでも問題なさそうだけど
0569login:Penguin
垢版 |
2019/05/11(土) 06:56:23.90ID:aALNFQnP
>>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の上で
動かしてくださいと（何もメリット無いだろうけどなｗ）
0570login:Penguin
垢版 |
2019/05/11(土) 08:13:34.40ID:b8w0H16P
>>569
docker on windowsはHyperV上のLinuxで動いてるだけだろ
0571login:Penguin
垢版 |
2019/05/11(土) 10:03:00.47ID:hB8UFSoc
>>567
WSL2上のdockerへRemote-Containerで直結すればいいだろ
Dockerがクラサバ型なの知らないのかな
0572login:Penguin
垢版 |
2019/05/11(土) 15:04:08.06ID:aALNFQnP
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と共有して使えれば楽なんだが
0573login:Penguin
垢版 |
2019/05/11(土) 15:19:03.89ID:3QLvWbX5
DockerのハイパーバイザーをHyper-Vで、クライアント側はWSLで動かす例を見たな。
0574login:Penguin
垢版 |
2019/05/11(土) 16:24:41.52ID:1R5w3n2t
WindowsコンテナでWSLのプロセスを動かすのは出来るのかな？

…Hyper-V使わないコンテナはWin10では動かないのね
さすがにイメージは無いようだから作らなきゃならんか
0575login:Penguin
垢版 |
2019/05/11(土) 18:33:08.22ID:aALNFQnP
>>573-574
何を言ってるのかさっぱりわからんｗ

> DockerのハイパーバイザーをHyper-Vで、クライアント側はWSLで動かす例を見たな。
Dockerのハイパーバイザーってなんだ？Dockerは仮想マシンとは
全く関係ない仮想化技術だからハイパーバイザーなんてでてこない。
Dockerはハイパーバイザーを使う必要はないから
「Dockerのハイパーバイザー」という言葉は意味不明

> WindowsコンテナでWSLのプロセスを動かすのは出来るのかな？
WSLのプロセスってなんだ？ （今の）WSLはAPIを変換するレイヤーなんだから
WSLのプロセスなんかいない。WSL2の話だとしても、仮想マシンに乗ってるLinuxカーネルのことだぞ
WindowsコンテナでLinuxカーネルがはいった仮想マシンを動かすって言ってるのか？
0576login:Penguin
垢版 |
2019/05/12(日) 06:15:19.68ID:qt7GlmFj
手違いでgpuパススルー提供してくれればいいのに
0578login:Penguin
垢版 |
2019/05/12(日) 10:16:53.56ID:CHrIvu7I
>>577
開発者のScott Xuってどういう人？
0579login:Penguin
垢版 |
2019/05/12(日) 11:02:36.48ID:LHseVdEZ
名字が中華っぽいなら
0580login:Penguin
垢版 |
2019/05/12(日) 13:00:28.82ID:Qq5nJiWO
スマン>>578だがArchスレで聞いた方が良いな
移動します
0581login:Penguin
垢版 |
2019/05/12(日) 22:13:23.25ID:zdwItqPT
自分で入れるarchとなんか違う所あるのかな
0582login:Penguin
垢版 |
2019/05/12(日) 22:34:57.13ID:+k7oRJxc
>>581
公式がサポートしているなら、the arch way に則っていることの一つの基準になる

が、Archスレでも言われてるようにこれはどうやら非公式で、公式でarch on wslを出すかという問題については、メーリングリストでとっくの昔（2018/3）に NO で決着がついていて、>>577は時間の問題でストアから消えるようだ
0583login:Penguin
垢版 |
2019/05/12(日) 22:59:49.31ID:H7sQm3Wm
>>582
オープンソースで自由なのに消えるわけ無いだろｗ
0585login:Penguin
垢版 |
2019/05/13(月) 00:42:40.92ID:kfH6729w
その中国系の奴のスパイウェア扱いされてんのなw
0587login:Penguin
垢版 |
2019/05/13(月) 01:02:17.53ID:7EQTzBan
いやスペルが一文字違うのか
Scottxuだもんな
0588login:Penguin
垢版 |
2019/05/13(月) 02:26:48.87ID:xcN6a4i7
Arch Linuxの商標等を無断使用してArch Linuxのオフィシャルのものと錯誤させるような現状はアウトだけど
Arch Linuxからのforkである事を明記して、別の名前にしてArch Linuxのクローンと自称すれば、それだけでは止める理由は無くなるよね
0589login:Penguin
垢版 |
2019/05/13(月) 06:12:53.18ID:7DTjxB+l
>>583
自由なソフトウェアｗｗｗｗｗｗｗ
江添亮かよテメェは（中指ﾋﾟｰﾝ
0591login:Penguin
垢版 |
2019/05/13(月) 11:16:23.69ID:wQhZ/CcM
>>590

> さらにWSL2の環境毎にVMを立ち上げるのではなくLinuxカーネルは一つだけ立ち上げて、
> それぞれのWSL環境はコンテナで仕切っている様です。

すごいな。仮想マシンとは全く違う仕組みじゃないか
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況