【Bash】Windows Subsystem for Linux【Ubuntu】2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
最初Cygwin/MSYSの代わりになると思ってたんだけど全然違うんだよな
結局サブシステムの中で完結しててだったら不通にVMでいいじゃんってなってる >>193
> 最初Cygwin/MSYSの代わりになると思ってたんだけど全然違うんだよな
Ubuntuに代わり(というかそのもの)だからねw
VMでUbuntu使うぐらいなら、Bash on Ubuntu on Windowsでいい。
Cygwin/MSYSは残念ながら、Ubuntuのノウハウは使えない。
apt-getは使えないし、ビルドの方法も特殊
普段CentOS使ってる人だとまた少し違うけど、
UbuntuやDebian系を使ってる人は、そのノウハウがそのまま使える。
ここまでくるとMacOSもbrewという独自の方法を辞めて欲しくなるよ。
そうすれば全てUbuntuのやり方で統一できるのにって思ってる。
> 結局サブシステムの中で完結しててだったら不通にVMでいいじゃんってなってる
え? どうみてもWSLはサブシステムの中で完結してないよな?
WSLで起動したプロセスはタスクマネージャーから見えるし、
メモリ空間は共有しているしネットワークも共有で別にIPアドレスが割り当てられることもない
ファイルシステムもマウントポイントが特殊なだけでサブシステムの中に
Windowsのドライブが割り当てられてる。
あらゆる証拠がWSLがWindowsと強調して動いてることを示している。 New distro’s coming to Bash/WSL via Windows Store
https://blogs.msdn.microsoft.com/commandline/2017/05/11/new-distros-coming-to-bashwsl-via-windows-store/
We are also working with the great teams at SUSE and Fedora to bring their Linux distro’s to the Windows Store & Windows Subsystem for Linux (WSL) WSLがサブシステム内で完結してるっていうならCygwinがCygwinの世界で完結してないところなんて実デバイスに触れるところしかないと思うが >>196
すまん。あんたの日本語がわからん。
つまり、
本当はWSLはサブシステム内で完結していない(これは事実)
だからその点ではCygwinと変わらないということであってるよな 横からで悪いが「サブシステム内で完結」ってどういう意味?
環境サブシステムを仮想マシンか何かだとでも思ってるの? > 環境サブシステムを仮想マシンか何かだとでも思ってるの?
そう思ってるんだろ?
だから間違いだって突っ込まれてるんだよ。
LinxuサブシステムもWindowsサブシステムも理屈上は対等の存在で
同じNTカーネルの元で動いているものなんだからサブシステムで「完結」するわけがない
根本的な知識が欠落してる それはどうでもいいとして、もっといいニュースが出たね。
WSLで動くディストリが本物のUbuntuだけじゃなくて
本物のFedoraや本物のOpenSUSEまで動くようになった。
これでLinuxの大部分のノウハウはWindowsで
そのまま使えるようになる。
MacOSみたいなBSD系の独自の1ディストリとは訳が違う。
MacOSはbrewコマンドを始めとする独自の知識が必要になるが、
Windowsの場合はサーバーで動かすOS(=多くがLinux)と
全く同じディストリを内包している。 ストア経由でUbuntu、openSUSE、fedoraもWindows 10上で動作可能に
〜SpotifyやAutodesk SketchBookなども続々提供
http://pc.watch.impress.co.jp/docs/news/event/1059426.html すまん完結っていう表現はいまいちだったな
よく理解してないから教えてほしいけど
俺が知りたいのはVMでできないことでWSLできることはあるのかってこと
もちろんそれがないとしてもWSLにもメリットがあることはわかる > 俺が知りたいのはVMでできないことでWSLできることはあるのかってこと
何度も言ってるじゃん。
メモリ空間の共有
プロセス空間の共有
ファイル空間の共有
ネットワーク空間の共有
VMは起動時間が遅い。別のカーネルが動いてる。
メモリ食う。ディスクも別に割当容量を食う
違うことだらけなんだが? 仮想OSは、OSが2つあるけど、
Dockerは、OSが1つで、コンテナが2つ以上ある。
OSが2つある方が、資源を食うし、電気代も高い
WSLは、Dockerに似ているのかな?
subsystemとは、単なる別のモジュールというだけだろ >>207
dockerはプロセスが仮想化されてるから、
chrootの方が近いだろうな。
新しい(WSL用の)ファイルシステムをルートに
違うディストリを起動する。
でもプロセスの分離がされているわけじゃないから
一つのOS上で動いているように見えるしリソースも共有している。 >VMでできないことでWSLできること
こんなのはどうよ
WindowsとBashの相互運用
ttps://kledgeb.blogspot.jp/2016/11/wsl-53-windowsbash.html msys2の代わりになるかと思ってたけど、Winアプリ用にはmingwのライブラリが揃ってなさ過ぎて
割と基本的なUNIX系コマンドすら、なかなかビルド出来ないので全然代わりにならなかった
必要なライブラリも全部自前ビルドすれば出来そうだが、さすがにそこまで時間無いし
やはりこれはmsysやcygwinの代わりでなくてubuntuなんだと納得 > 割と基本的なUNIX系コマンドすら、なかなかビルド出来ないので全然代わりにならなかった
これってemacsみたいにコンテナ上だとビルドエラーになる問題と同種の話?
BuildRequireが揃えられないって話ならスレ違いだが。 >>210ってcygwinの話でしょw
Bash on Ubuntu on Windowsは
その名の通り、Ubuntuだから、
Ubuntuにあるライブラリは全部使える >>205
あーいや”技術的に”できることでなくて実際の使用用途の話
>>209
そうそう
そういうこと >>213
> あーいや”技術的に”できることでなくて実際の使用用途の話
何を聞いているのか?さっぱりわからん。
実際に仕様用途とは、WindowsはLinuxができること
全てができるという話か? >>213
つーかさ、メモリ空間が共有ってことは
VMに膨大なメモリを持っていかれることもないし、
ネットワーク空間が共有ってことは
同じIPアドレスが使えることだってわからないのかな? 今はInsider Previewじゃないとできないけど、Windows側でマウントされたドライブを
drvfs経由でWSL側でもマウントできるので、Windows使わないと読み込めないディスクでも
WSLなら扱える。
Linux単独やVMでは無理なケース。 今もWindows使わないと読み込めないディスクってあるの?
ntfsもexfatもLinuxでマウントできるようになったけど > 今もWindows使わないと読み込めないディスクってあるの?
Windowsで現在マウントしているディスク(システムドライブなど)は、
仮想マシンからマウントして読み込めない
だから共有フォルダを使えるように仮想マシンに
Guest Additionsとか入れなきゃいけない >>217
BitLockerで暗号化したドライブはWindowsじゃないと扱えない。 ReFS (Resilient File System) はWindows Server 2012で導入されたファイルシステムである。開発コードはProtogon。
https://ja.wikipedia.org/wiki/ReFS >>211
BuildRequiresの話に近いけど、ubuntuのライブラリにはmsys2に有るようなWin用クロスコンパイルmingw環境が
超基本セット以外無かった(例えば libintl libiconv も無い)ので、msys2の代わりは出来ないと思った話
後で考えると当たり前だと納得しているけど、msys2やcygwinの代わりになるみたいな記事に乗せられて期待してしまい、
今さら>>18,19 辺りのことを実感している > 後で考えると当たり前だと納得しているけど、msys2やcygwinの代わりになるみたいな記事に乗せられて期待してしまい、
なんかお前ずれてね?
msys2やcygwinがそもそもLinuxの代わりにならなかったんだが?
msys2やcygwinはできれば捨て去りたいものだろ?
WindowsでLinux関連のツールが使えないから
msys2やcygwinを使って ”ごまかす"
でもWSLができてから本物のLinux関連のツールが使えるようになったから
msys2やcygwinはもういらない
Linuxとはぜんぜん違う変な仕組みのmsys2やcygwinはもういらない WSLだとLinuxのバイナリがそのまま動くから、
"Windows用にクロスコンパイル" する必要がなくなったんだよ
Linux用にコンパイルすれば、それがそのままWindowsで動く
Linuxで生成したバイナリをコピーして持ってくれば動く >>209
普通、そんな相互運用がWDLで出来るって期待するよな
>>223-224
俺が一番WSLで良いなと思ったのはまさにLinuxのバイナリが動くってこと
そして、そのおかげでLinuxの良いソフトをmsys2とかを使って動くようにする必要がなくなった
てのは大きいよな これAndroid用バイナリも同じことできないのかなぁ。Xみたいな表示の仕組みは要りそうだけどw >>227
もうWindows Bridge for Android (Project Astoria)のことは忘れるんだ! 許すまじ
strings -el /mnt/c/Windows/System32/drivers/lx* | grep -i android >>230
少なくともマイクロソフトは何も問題はないな。
問題があるとしたらUbuntuだし >>232
読んでないけど、開発者モードを有効にすることで使えるようになるWSLが
Windows 10 Sで動くか?っていう質問はWindows 10 Sでソフトウェア開発を
するのか?って質問と同じだと思う。
いや・・・しないだろ? >>232
>Windows 10 S does not run command-line applications, nor the Windows Console, Cmd / PowerShell, or Linux/Bash/WSL instances
>since command-line apps run outside the safe environment that protects Windows 10 S from malicious / misbehaving software:
WSLだけじゃなくて普通のコマンドプロンプトも動かないのか、結構思い切ったんだね ここまで来ると10 SはiOSに近い仕様だな。
AndroidさえターミナルでCUIを扱えるのに。 iOSも脱獄すればターミナル扱えるのに
10 Sもいずれハックされるんだろうか ハックも何も脆弱性なんか利用しなくてもシステムに書けるんだからいくらでもできるだろ やっぱりIO速度が全然出ないねえ
Androidのsdcardfsみたいな感じで高速化されないだろうか ゲイツの法則に象徴されるWindowsでパフォーマンスを求めることが間違い そうやって技術力を認めず、無関係な人を使って文句を言う CygwinやMSYSなんかよりはマシとは言えconfigureするだけで遅...てなるよね CPU速度はLinuxネイティブと同じくらいの速度が出せているだけに残念だな ファイルシステムのエミュレートのコストが高いのか知らないけど、ちょっと改善してほしいところ。 forkはそこそこ速いけどexecが遅いらしいね。これはまあ構造上厳しそう
だと思う。 >>244
CPU速度って?
WSL上ではLinuxよりCPU周波数が低速になるの?
それともキャッシュの利きが悪くなるとか? NTFSを捨てられれば、IO速度問題も解決すると思う。 Windowsのほうが詳しくないんだけど
Windows10でbashが使えると思ったんだけど
今1607だけどどうやったら使えるようになるの?
情報がごちゃごちゃしてわけわからん あ、この記事もCreaters Update向けに更新済みか
機能の有効化・開発者モードの有効化だけした後
コマンドプロンプトを起動して bash って入力すればそれで良いと思う、多分 >>252
> 今1607だけどどうやったら使えるようになるの?
そういう人は、WSLがベータじゃなくなってから使ったほうが良い
すでに修正済みの問題まで、文句つけそうだから 今時v1607でUbuntu on Windows使うとか罰ゲームか拷問か何か?
最低でもCurrent Branchで使ってないと使い物にならねえよこれ vi(vim)を起動するとキー入力受け付けなくなった
何がおこっとんのや >>258
おま環:-)
vimで日本語も使えるよ >>260
マジか? シンボリックリンク作成解禁は開発者モード限定じゃなくなるのか >>265
私の方はCreators Updateに導入したけど普通に動いてるけどな >>265
だからそれがおま環なんじゃないの?
100%再現性があるわけじゃないだろう? vim使うだけのためにわざわざWindows Subsystem for Linux入れるのか? >>268
udevが使えるようになると面白いけどね >>269
参考までにudevが使えるとどんな感じに面白くなりそうなの?
usbとかの実ハードの挿抜が検出できる様になる的な? 今更この時代にBashでどういう方面で利用するかねえWindows上で…
俺なら、データベースソフト使ってクエリ作りまくるけどな。
Bashはたしかにコンパクトなソフトだよ。
但し、多桁演算には耐えられない。 >>272
まだ勘違いしてるの?
BashだけじゃなくてWindowsでLinux用のアプリの
多くが動くようになったんだよ そうなんだよね
ふつーにBash on Windowsでビルドしたx64バイナリをlinuxサーバーに持っていって問題なく動くよ
逆もほぼOK
epoll以外はね Ubuntu on Windowsとか普通にUbuntu(or Linux)を全面に出したらいいのに何でbashを全面に出したのか謎
そりゃみんな誤解するわ そりゃ何も考えずにGUIが使えないからでしょ
Ubuntu使っててもXサーバーの概念知ってる奴少なそうだし そういえばXのフォワーディングできるようになったんだよな
俺の動かしたいソフトバンク動かなかったけど とりあえず動かすテストレベルならMacOSで問題ないし、本格開発ならVMだしそんなにメリット感じないなぁ。 atomがWSL対応したらしいな
個人的にはVScodeが動いてほしいが WineならぬLineが実現するとはちょっと前まで想像できなかったな…
これのおかげで犬厨を卒業できそうだ
手頃なunix環境として定評あるMacを潰しにかかってるのか >>284
LINEってグループチャットアプリのLINE? 意味がよくわからないわ Wineって、Wine Is Not an Emulator の略だったよね。 Lineだと、Linux Is Not an Emulator ってことか
たしかにカーネルにLinux互換のサブシステムが追加されており
エミュレータではない ああそういう・・・WSLって言わばLINuxEmulatorだよねって意味だったのね・・ PC(ハードウェア)のエミュレータなのか
Linux(OS)のエミュレータなのかってことだな。
Wine Is Not an Emulator の場合、PCのエミュレータという意味でEmulatorと言ってる。
WineはPCエミュレータではない。これは正しい。
だけどWineはWindows Emulator略だとする説もある。
この場合はWindowsのエミュレータという意味だから、これも間違いではない
この世界では単にエミュレータと言ってしまうと
PCエミュレータの意味となってしまうからそれを避けたんだろうな
つまりWSLはLinuxのエミュレータではあるが、PCのエミュレータではない。 >>290
全然違う
Wine Is Not an Emulator は文字通りエミュレータではないと言っている
これは喩えるならPOSIXの仕様に従ったOSが複数あるように
それぞれがお互いのエミュレータでは無いという意味と同じ
少なくてもそういう建て前になっている Windows機でnode-red(node.js)を動かすのにUbuntuOnWinでやるメリットって在りますか?
パフォーマンスはファイルシステムの差でWIndows上で動かした方が良いですよね? ■ このスレッドは過去ログ倉庫に格納されています