【Bash】Windows Subsystem for Linux【Ubuntu】2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
なんでそんな昔のものを取ってくるんだ? Creators Update入れればいいのに。 ちなみに今のFastリングのInsider Preview は16184。 >>182 もう少し詳しく頼む。 login shellになるとユーザ名とパスワードが必要になるのか? スタートアップファイルって.profileとかのことか? >>187 ログイン時に実行されるスクリプトが違うだけ やっぱりサーバー用途のニーズも高かったんだな。 Bashだけの口じゃCygwinやMSYSと使い勝手が変わらない。 >>191 > Bashだけの口じゃCygwinやMSYSと使い勝手が変わらない。 それDebianでもCentOSでもCygwinでも使い勝手は変わらないと 言ってるようなもんだよ。 パッケージ周りが違うからCygwinやMSYSとはぜんぜん違う。 CygwinやMSYSは別のディストリだがBash on Ubuntu on WindowsはUbuntu そしてLinux用バイナリがそのまま動くから、Cygwin/MSYS用に ビルドするという作業が要らなくなる つまり世の中に配布されているLinux用バイナリがそのまま使える。 インストール手順などもUbuntuのものがそのまま使える 最初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が動いてほしいが ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる