【Bash】Windows Subsystem for Linux【WSL】3
■ このスレッドは過去ログ倉庫に格納されています
なんでWSLがあるのかよく考えろ
PSのメリットを語っても意味ない >>245
そういうレベルじゃない、スクリプト内で.NETのインスタンスを生成してゴリゴリできる
http://www.atmarkit.co.jp/ait/articles/0607/26/news118_3.html
>>246
Win上でもWSL上でもPowerShellだけで動くだろ? じゃあPS使い続けてWSL使う必要もないし、ここでレスする必要もない。 >>247
PowerShellが移植されていることと
PowerShellで書かれた同じプログラムが
期待したと通りに動くどうかは別問題 >>241
マウスの移動とクリックやメニュー操作ならできるよ。
面倒だからマウスでするけどね。 >>251
それはどんなプログラムにも言えるし。移植されていることがまずは重要。 WSLで書いたWebサービスをPSでブラウザテストするやつなんていない。 パーフェクトソルジャーの介入によりスレがおかしな方向に PowerShell最強でも何でもいいけど
それをWSLスレでわめき散らしてもいいという法はない
linuxに移植されてるつってもわざわざwinのWSL上でPowerShell使ったりしないんだし
WSL外で動かすPowerShellの話はスレ違いだろ
ここは最強を決めるスレじゃなくWSLについて語るところ >>257
いや別にいいだろ。
それPSでできるよみたいなのがあっても。
過剰な宣伝は御免被るけど。 その理屈だと、C言語、Per、Ruby、Python、etcでできるよ。もOKになるけど? >>259
もちろんおkですよ。
過剰な宣伝は御免被るけど。 はい、それじゃこのスレではおkということに決まりましたので。 WSLのスレだから多少の脱線はともかくWSLに関連した話題にしてほしいもんだが
PowerShell絡めてWSL使うような話ならともかく
PowerShellの利用方法語るスレじゃないのよ WSL(Bash)からPS呼び出していいことってある?
単にWindowsから使えよ。 自分としては、今のWSLより *** 使ったほうが楽、という例はどんどん書いてほしい。
*** に入るのはなんでも構わん。 PowerShell でも Vagrant+VirtualBox でも Cygwin でも。 WSLより素のLinuxのほうが便利だし、楽なんだけど、Windows+WSLだから便利な感じ。
WSLだから便利なことといえば、WSL側でサーバーを立てて、Windowsからブラウザ経由で使うとか。
そういう用途だと思う。 >>269
その用途だったらVMのほうがいい。WSLでサーバーは無理。 サーバーなら素直にVMやDockerの領分だろうね
Docker CE入れてDocker for Windows操作すると捗るよ 自分用のサービスを起動時に立ち上げるのは便利だと思うけどな。VMやdockerだと環境構築の手間や、リソースを割り当てないといけないから。
WSLは事前にリソース割当しなくていいからエコ。 >>276
そんな者がいるとでも?
皆等しく自己愛性ゆとり >>275
エコだし柔軟だ。頭打ちになるような処理でもCPUフルで使える。 >>279
何を持ってライトと言ってるのかわからないけど、例えば重い処理する場合に、例えば動画のエンコードとか、VMよりWSLのほうがいい。
リソースを上限まで使えるから。エコっていうのは効率的って意味で、貧乏って意味じゃない。
物事には向き不向きがあるんで、向いてるものを使うのが当たり前。 >>280
WSLはi/oが遅すぎてライトユースにしか向かない。
VMのほうが圧倒的に早い。リソース以前にいかんともしがたい事実。 >>280
WSLは逆にリソースを制限するのが困難なんだよね。VMなら使うコア数指定できるけど
WSLはできるのかな?やり方知ってたら教えて。 Dockerもnamespaceやcgroupで制限分離できるしね
WSLはwslconfigで見れるディストリビューション名単位での管理しかできないと思ってるけど
細かく分離して管理可能なんだろうか WSLってパフォーマンスとLinux互換性の向上したCygwinみたいなもんで、現時点でできることはCygwinとほとんど同じ。
つうか半年ぐらい前に試したときは、パフォーマンス、互換性とも大して向上してなかった。
Cygwinは長年かけて移植された大量のソフトウェア群を抱えているわけで、実用的にはWSLへ乗り換える理由はないと思った。
今は少しは改善されたんだろうか?果たしてWSLがCygwinを遠く引き離すほど進化する日は来るんだろうか? 確かにFFmpegはWindowsよりLinuxの方がビルドしやすいな。
依存関係のものは手っ取り早くパッケージでインスコしてソースを展開してconfigure && make
で終わる。コンパイルはVMより遅いけど・・・ >>285
Windowsバイナリをクロスコンパイルすればいいよ。
ffmpegぐらいになるとWSLはちょっとつらいね。 >>284
cygwinは今後廃れていくんじゃないかな。
ソースコード修正する必要があることが多いし
cygwinのほうが優れているのはdllさえあれば他の環境でも動くことぐらい。 >>282
VMは仮想化だけど、WSLはWindowsの実装の一つだからリソースを制限するとかじゃないよ。
基本的なことがわかってなさそうに見えるレス。 タスクマネージャー見ればどうなってるのかわかる話。 サーバーの話だからリソース制限する話出てるのでは
基本的なことって何のこと言ってるのかよく分からないけど >WSLは逆にリソースを制限するのが困難なんだよね。VMなら使うコア数指定できるけど
>WSLはできるのかな
WSLは仮想化してるわけじゃないので、制限する必要がない。Windowsアプリと同じようにアプリ側で制御すればいい。 >>284
WSLとcygwinの仕組みはよくにてるし、使い慣れた環境のほうが手には馴染むかも知れないけど、
WSLのほうが実装がWindowsなんで将来性があるかも。あとインストールとアンインストールは絶対的に楽。
過去の資産に関しては、ubuntuのaptパッケージがそのまま使えるのでcygwinより動くソフトは多いかもね。
でもcygwinはXも起動できるし、xfce4のデスクトップ環境なんかも完動するから、そのへんはcygwinなんじゃないか? > WSLとcygwinの仕組みはよくにてるし
ぜんぜん違う。
まずcygwinでは既存のLinux用のバイナリは動かない。
ソースコードの互換性も完璧ではなく、
cygwin用にソースコードを修正して
コンパイルしなければいけない。
WSLがすごいのはLinuxのUbuntu用のバイナリをコピーしてきて
WSLのUbuntu上で動かせるってこと
cygwinは不完全なソースコード互換性しかなく
WSLはバイナリ互換性がある >>293
使用感はぜんぜん違うかもね、仕組みはよくにてる。
どちらも*nixのシステムコールとWindowsのAPIを互換して動かしてる。
cygwinは開発が古いので、Unixのシステムコールをベースにしてる。バイナリが動くかどうかは仕組み上別の話。 Windows ServerでLinuxウェブアプリ。 >>294
全然似てない。
WSLはMicrosoft Linux、Cygwinはゴミみたいな移植。 >>294
> 使用感はぜんぜん違うかもね、仕組みはよくにてる。
> どちらも*nixのシステムコールとWindowsのAPIを互換して動かしてる。
残念ながらそれは間違ってる。WSLはWindowsのAPIは利用していない。
そもそもWindowsのAPIっていうのは、カーネルのネイティブAPIを使ってる実装されてる。
OSに直接実装されてるのはネイティブAPIであって、WindowsのAPIではない。
WSLではWindowsのAPIを使うこと無くネイティブのAPIを呼び出している。
Windows API → ネイティブAPI → OS
Linux互換API → ネイティブAPI → OS
ということ
Cygwinだと
Linux互換API → Windows API → ネイティブAPI → OS
となってるので仕組み自体が違っている >>298
cygwinがただのアプリでWSLがサブシステムって話だろ。WindowsAPIとネイティブAPIを区別してなかったわ。にてる理由を書くには十分だったから。 >>300
そこを区別しないと駄目。
なぜなら、Windows APIを使ってる限り
CygwinはWindows APIの制限から逃れることはできない
WSLはWindows APIの制限に引っかからないので
Windowsでできないことが可能になる > Windowsアプリと同じようにアプリ側で制御すればいい。
ってかいてあるじゃん。
書いてあることぐらいちゃんと読めよ >>293
POSIX実装をしようとするところは似ている。アプローチが違うだけ。 間抜けすぎてあまりにも可愛そうだから
Windowsでアプリのコア数制限する方法教えてやるわ
https://pc-karuma.net/windows-10-process-cpu-core/
Windowsアプリ全てに適用する話だから
WSL上のプロセスだけでなく、Windowsアプリ全般に使える
http://ascii.jp/elem/000/001/250/1250797/
> 実は、このinitも/bin/bashも、Windowsのプロセスとして管理されている。
>タスクマネージャには、initもbashもちゃんとプロセスとして表示される。
>つまり、WSLのプロセスは、コードはLinuxのバイナリだが、プロセスとしては、
>Windowsのカーネル側で正式なプロセスとして扱われている。
>メモリ管理やスケジューリングもWindows カーネルが行っている。 >>307
> POSIX実装をしようとするところは似ている。アプローチが違うだけ。
アプローチが違うって、それ仕組みが違うって言ってるのと同じ意味じゃんw NT系でカーネルとかAPIとか分離させまくったおかげだな
wslだけでなくWin32のソフトウェアとかも
サブシステムとして動いてるし
Windows on ARMも同じ理屈 cygwinの良さはwindowsのコマンドとlinuxコマンドを一緒に使えるとこだと思ってるけど
俺にとってはバイナリがどうとか仕組みがこうだとかどうでもいいな MINGWとcygwinは違うobjを出すから混ぜるとリンク出来ん >>308
>>310
windowsってすごいですね。 cygwinはmicro動かなくてガッカリしたな
昔から使ってる人は過去の資産があるんだろうけど
linux童貞のwinユーザーがゼロから触る場合
学習コストはWSLのほうが少なくて済むと感じた XilinxのFPGA開発用ツールがそのまま動いたのにはびっくり。
x11は別途必要だったけど。 >>311
バイナリが動くことがどういうことかを理解してもらわないとw
要するにcygwinとは違って、cygwin用にソースコードを
修正しなくていいってことなんだよ
例えば、gitのソースコード。これだけ(今日時点で75箇所)cygwin用にコードが含まれてる
https://github.com/git/git/search?q=cygwin&unscoped_q=cygwin linuxユーザーがwindows始める場合もwslは良い
cygwinは過去の遺物と言うか老害のこだわりと言うか >>308
開発環境から本番環境にデプロイするのに、毎回その手順やるなら話にならないと思う
毎回topで表示されるプロセス一つ一つに全部手動で割り当てすることになるよ
CPU分離設定が移行しやすく管理されてるのかっていう話ね >>310
逆だよ。
いろんなサブシステムを動かすために分離したんだよ。 ほんと、あたまがよわくてかわいそう(w
コマンドラインから変更できるに決まってるじゃんか
話にならないね。
http://www.atmarkit.co.jp/ait/articles/0703/16/news151.html
> ●Windows VistaではStartコマンドでも指定可能
> Windows Vistaでは、コマンド・プロンプトからSTARTコマンドで
> 起動する際にアフィニティ・マスクを指定できるようになっている
> (Windows XP以前のOSでは使用不可)。
>
> C:\>start /affinity 1 MySampApp.exe >>320
Linuxでは真似の出来ない柔軟性ですね。 >>321は>>319あてね。
CPUのコア数はコマンドラインから変更できる >>321
wslで
/usr/local/bin/foo.sh
をcpuのコア10,12,15の3つを使って起動するコマンド教えて。
簡単にできる? >>324
お前が言ってるのは、 "Linux" に
CPUのコア数を指定する命令は存在するのか?
って聞いてるのと同じだぞw
Linuxを馬鹿にするのか?w
https://qiita.com/nakat-t/items/4542e84c4b72b78740e8
> コマンドによるCPUアフィニティの設定方法
> tasksetというコマンドでプロセスのCPUアフィニティを設定できます。
>
> # taskset -p mask pid ちなみに、仮想マシンだとプロセスごとに
コア数を指定することはできない
仮想マシン単位でしか指定することができない
だからWSLの方が良い >>320
因果律があるわけじゃない、どっちでもいい、マイクロカーネル実装しただけ。 >>325
じゃあ、早く教えてあげたら?
ググるのは得意だけど、実践できないタイプに見えるなぁ。 >>328
書いてあんだろ
おめめついてますかー?
ないのはあたまですかー? >>328
真面目に答えると、シェルスクリプトはシングルプロセスが多いからマルチコアを当てるには工夫がいる。
foo.shの中身によるってこと。
だけど、元の話題はVMのほうがリソース制限できるって話みたいだから、VMでやるとOS一つ起動する分とfoo.shのプロセス分を消費するので、おかしいだろって話だよ。 >>330
実践したことがなさそうな彼への
引っ掛けだったのに。
ところでwslの中からtasksetってできるのかな?いま環
境にないし誰か
試せない?もしできたら便利かも。
いちいちaffinityとかでWindowsから制御するのは実用的じゃないし。 >>331
実践したことないのはお前の方だって
はっきりしましたなwww >>330
> 真面目に答えると、シェルスクリプトはシングルプロセスが多いからマルチコアを当てるには工夫がいる。
ブロックさせないように、パイプでつなげればマルチプロセスで動くよ
ま、実践したことないあいつには
思いつかないでしょうなーw >>316
「俺にとってはどうでもいい」って言っているんだから、彼にとってはどうでもいいんだよ。 >>320
それまでのWindowsはソフトウェアのエラーで
OSごと落ちるのが当たり前だったのでサーバ用途に使えなかった
Windows Meとかひどかったでしょ
NT系のマイクロカーネル化はその対策
結果的にサブシステムが作りやすくなったのよ ファイルを開いたまま移動できなかったり、NT系OSがUNIX系OSより特段に優れてるとは思えないな。 >>336
それはOSの問題じゃなくてアプリケーションのつくり方の問題。メモ帳でテキスト開いた
ファイルを移動してみたらわかるよ。 NTカーネルはマイクロカーネルを標榜してたんで、(厳密にマイクロカーネルってわけではない。)
高度に抽象化されたカーネルが土台にあって、その上にサブシステムと呼ばれるUI(この辺は大雑把に)が置かれる。
NT系OSの良いところはカーネルAPIが優秀なところ。WSLもカーネルが優秀だからできる。
ちなみにLinuxは強力なコマンド群が強みだけど、カーネルはモノリシックで時代遅れなんだ。
Macもマイクロカーネル化してる。Linuxが生き残れてるのはオープンソースだから。
このUIの部分をOSと呼ぶか、アプリケーションと呼ぶかは単に個人の趣向だったり、パッケージだったりするから誤解するな。
WindowsはvistaからNTカーネルにはほとんど手を入れない。だからVista以降のWindowsOSの評価はUIとマシンスペックの評価ってこと。 >ちなみにLinuxは強力なコマンド群が強みだけど、カーネルはモノリシックで時代遅れなんだ。
>Macもマイクロカーネル化してる。Linuxが生き残れてるのはオープンソースだから。
Linuxが出てきた頃に戻ったような気分だよ 20年前よりWSLでマイクロカーネルを実感してるわ。 Machで盛り上がった時代があったな。OSF/1とか。 MINIXというかタネンバウムだね
関係ないけど、コンピュータネットワーク(通称タネンバウム本)は読んどくように。 ■ このスレッドは過去ログ倉庫に格納されています