【Bash】Windows Subsystem for Linux【Ubuntu】2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>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上で動かした方が良いですよね? >>291
適当なことを言うな
The name Wine initially was an abbreviation for Windows Emulator.[14] The phrase
"Wine Is Not an Emulator" is a reference to the fact that no code emulation or virtualization
occurs when running a Windows application under Wine.[15] "Emulation" usually refers
to the execution of compiled code intended for one processor (such as x86) by
interpreting/recompiling software running on a different processor (such as PowerPC).
Its meaning later shifted to the recursive acronym Wine Is Not an Emulator in order to
differentiate the software from CPU emulators.[16] While the name sometimes appears
in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.[17]
Wineという名前は、最初はWindows Emulatorの略語でした。 「ワインはエミュレータではありません」
というフレーズは、ワインの下でWindowsアプリケーションを実行するときにコードエミュレーションや
仮想化が発生しないという事実への参照です。[15] 「エミュレーション」とは通常、
異なるプロセッサ(PowerPCなど)で実行されているソフトウェアを解釈/再コンパイルすることによって、
1つのプロセッサ(x86など)用のコンパイル済みコードの実行を指します。 その意味は後で
CPUエミュレータとソフトウェアを区別するために再帰的頭字語であるWine Is Not Emulatorに移行しました。
この名前はワインとワインの形で時々現れるが、プロジェクト開発者はワインの形で標準化することに同意した[17]。 POSIXなんて言葉は全く出てこない
https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_seems_to_be_disagreement
1.3 Is Wine an emulator? There seems to be disagreement
There is a lot of confusion about this, particularly caused by people getting
Wine's name wrong and calling it WINdows Emulator.
When users think of an emulator, they tend to think of things like game console
emulators or virtualization software. However, Wine is a compatibility layer -
it runs Windows applications in much the same way Windows does. There is no
inherent loss of speed due to "emulation" when using Wine, nor is there a need to open Wine before running your application.
That said, Wine can be thought of as a Windows emulator in much the same way that
Windows Vista can be thought of as a Windows XP emulator: both allow you to run
the same applications by translating system calls in much the same way. Setting
Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode.
A few things make Wine more than just an emulator:
Sections of Wine can be used on Windows. Some virtual machines use Wine's
OpenGL-based implementation of Direct3D on Windows rather than truly emulate 3D hardware.
Winelib can be used for porting Windows application source code to other operating
systems that Wine supports to run on any processor, even processors that Windows itself does not support.
"Wine is not just an emulator" is more accurate. Thinking of Wine as just an
emulator is really forgetting about the other things it is. Wine's "emulator" is really
just a binary loader that allows Windows applications to interface with the Wine API replacement. >>292
用途がわからないからなんとも言えないけど
パフォーマンスが出ればいいならWindows側のほうがいいよ >>294
俺が喩えるならと前置きした上でPOSIXと書いただけだから出てこなくて当然だ
日本語難しかったの? >>296
それをいうことで何が言いたかったの?
WineはもともとWindows Emulatorと言われていたように
Windowsのエミュレータではあるんだよ。
だけど>>290がいうようにエミュレータと言ってしまうと
ハードウェア仮想化を行うPCのエミュレータと勘違いするから
Wine Is Not an (PCの) Emulator っていうようになったんだけど? ctrl+c失敗したらどうしたらいいですか?
local閉じないんですが… >>299
そうなんですよ。開いたportが閉じなくて、コマンドに戻れないし、bashウィンドウも閉じれない…bash複数起動もできない…ベータ版だからかと思ってはいるのですが、プロセスも切れんとは…Win側から強制終了の仕方が知りたいです。 ユーザーフォルダ以下を操作しようとするとフリーズしてwindows再起するまでbash死ぬけど同じような状態かな? >>301
え?mnt/c/user以下でlocalhost開いちゃダメなのでしょうか? >>302
「local閉じないんですが」 や 「localhost開いちゃ」っとかの文の意味がよく分からないかも
localhost (127.0.0.1) のIPアドレスのポート開いてSocketでLISTENする様なプログラムを組んだとか?
そうではなくて、ローカルHDD上のテキストファイルを vi で開いたら固まったとかなら >>258 >>265 の件かもね おまえら、lineなら以前からあっただろ
https://sourceforge.net/projects/line/
LINE Is Not an Emulator. LINE executes unmodified Linux applications on Windows by intercepting Linux system calls.
使い物には…… >>303
申し訳ないですorz
・python(anaconda)でローカルサーバーport8080開いた
・閉じようと思いctrl+c無反応、^Cが入力されるだけでウインドウもが閉じれない
・別のbashウィンドウも開けず
・windows側のプロセスを切ろうと思っても権限なし
・cmdでportを確認したらclose_waitのまま
・困ってpc再起動したらbash起動できず壊れた
次にあったらと思うと怖い((( ;゚Д゚))) >>192
linux同士ですら実現できないことをできるわけないだろ
>そしてLinux用バイナリがそのまま動くから、Cygwin/MSYS用に
>ビルドするという作業が要らなくなる
>つまり世の中に配布されているLinux用バイナリがそのまま使える。
>インストール手順などもUbuntuのものがそのまま使える >>306
linux同士なら依存するライブラリ込みでバイナリを放り込むだけで動くものは多いし
ごっそり丸ごと放り込めば殆ど動く
互換性が無かったらコンテナとか流行ってない pythonのインタプリタの終了はctrl cじゃなくてctrl dじゃなかったか?
あとexit()とか ■ このスレッドは過去ログ倉庫に格納されています