【Bash】Windows Subsystem for Linux【WSL】3
■ このスレッドは過去ログ倉庫に格納されています
変換ミス
バーチャルボックスね
ってかversionboxってあったんだな いやいや、半角入力で変換ミスはないだろw
暑さでやられてる? ミスぐらい自由にミスらせてあげればいいのに。ミスなんだし。 WSL自体がコンテナみたいなものなのにさらにその中にコンテナを作るのか >>712
システムコンテナとアプリケーションコンテナという考え方がある
システムコンテナはコンテナ技術を用いてシステムを作るもの
システムコンテナは仮想マシンに近くOSに相当するシステムを作り出し
作業者はこのシステム上にログインして作業する。
WSL(正確に言えばbashでログインした状態)はこれに近い
それに対してDockerはアプリケーションコンテナ
アプリケーション実行に必要な外部ライブラリをパッケージング
しただけで、アプリケーションをそのまま実行するのと意味的には等しい
作業者はデバッグのためにDockerコンテナに入ることはあるが
通常はDockerコンテナの上で作業したりはしない 実際dockerで配布されてるアプリケーションもあるしな。
でもWSLで動かないものがWSLのdockerで動くわけじゃないし、通常はWSLにアプリケーションをインストールすればいいと思うよ。 >>713
wslのシステムコンテナの本体はどこにあるの? >>716
コンテナはプロセスだよ。隔離された空間にあるだけのプロセス
だから本体は実行時にメモリに現れ終了したらなくなる
コンテナを作るためのUbuntuのイメージファイルって話なら
C:\Users\USERNAME\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc
とかみたいだけど、これはWSLじゃなくて、Ubuntuのイメージファイルか
WSL(Windows Subsystem for Linux)自体はサブシステムであってコンテナじゃない。
サブシステムを提供するためのファイルはC:\Windows以下の何処かにあるだろうけど、
やっぱりWSLで作られるLinux環境はプロセスとしか言いようがないな >>717
ってかドッカーやらのコンテナって仮想マシンとは違うとかよくいわれるけど
windowsとmacで動いてるやつは裏で仮想マシンまわってるだけだろ? >>718
DockerはLinuxカーネルで動くものです。
WindowsとMacのことは一旦忘れましょう。
Dockerは仮想マシンではありません。
実際に仮想マシンは使いません >>720
グロ
死体画像
うpってんじゃねーぞゴミカス! WSLはサーバーサイドアプリをインストールして使えるのが最大の強みだと思うわ。
もちろんlocalhostでだけど。
Windows立ち上げてるときだけ使えるサーバー環境。
gitbucket、ampache、cloud9、等々 サーバー環境作るならdocker でない?
WSLはフロントエンド環境。 >>724
開発するならdockerがいい。サーバーアプリをただつかうだけならWSLで十分、常駐させても問題ないレベル。 I/O周りが遅すぎて開発に使うのやめてプレゼン用に使ってたけど、
先日npm installでセットアップ中にカレントディレクトリ以下のファイルの
90%ほどをぶっ壊してくれて、上位にあった~/.zsh_historyの一部まで
バイナリで書き込まれる惨事
dockerへ出戻り Dockerを開発環境に使ってるの?
あれ開発環境にはいまいちじゃない?
パッケージングにはいいと思うけど IDEとかの開発環境をまとめたdockerなら全然あるし、使える。 >>730
IDEでDocker使うんか?
Vagrantみたいに? やったことないけどCloud9をWSLで使うこともできるらしい。
Dockerでやったほうがいいけど。 >>732
横からだけど、例えばWeb開発なら開発からテスト配布まで、dockerでできる。cloud9とかを入れておいて、ブラウザから開発する。 >>734
Cloud9をサービスとして起動できるDockerを使ってローカルで開発と言うこと?
最近はそんな感じなのか
Cloud9使ったことないけど便利なのかなぁ
その組み合わせの利便性によってはDockerを見る目がまた変わるわ 仮想化も組み合わせによって色々面白いことできるねぇ
ブラウザから使えるideかぁ
ちょっと興味出てきた わざわざローカルにcloud9入れて使ってるやついるのか?
名前の通りクラウドで使うためのものやろあれ 俺WSLにcloud9入れて使ってるけど、単純にsshクライアントもいらなくなるし、Windowsのubuntu窓使わずに済むし幸せ。 >>735
遅レスだけど、gitとweb環境とcloud9入りのdockerで開発するってこと。
別にエディタはcloud9じゃなくてもいいけど、1つの窓でエラーログ見るコマンドも打てるし便利でしょ。
特に少数複数人で開発する時にPCが違ってもgitリポジトリを紐づけたdockerファイルを共有して、ブランチをpullすれば開発環境が整う。キモはcloud9じゃなくてgitなんだけど、cloud9ならブラウザ動けばみんな同じコーディングができるので。
基本的にローカルは汚さずに、万一dockerが壊れてもgit最新に戻せる。
開発からテスト、dockerファイルをいじって、配布まで、できる。
むしろ現場でdockerが流行るのはこのおかげ。
データベースも小さいのならgitに入れちゃえ。 WSLにcloud9入れるのはマシンスペックが足りないPC向け。
dockerをWindowsで動かすには結局仮想化するので、スペックを分けなきゃいけない。これができないからWSLが不完全でも使う層が出てくる。docker動かせるならそっちのほうがいい。 環境を汚してもいい鯖持ってるならWSLもdockerもなくていい。
dockerはあってもいい。 WSL、forkの速度あがらないかなー
OSの基本部分に関わるところだから、
forkの機能を備えてないNTカーネルでは
エミュレートに時間がかかるんだろうけど
それでも10倍はひどすぎる。
おかげでforkさせないシェルスクリプトの
プログラミングノウハウが溜まっていくwww 愕然とする事実発覚。WSLはパイプを使うだけでも遅すぎる
これもforkが遅いからか?
[test1.sh]
foo() { :; }
i=0
while [ $i -lt 1000 ]; do
foo | foo
i=$((i+1))
done
--------
time ./test1.sh
real 0m8.005s
user 0m0.047s
sys 0m3.391s
[test2.sh]
foo() { :; }
i=0
while [ $i -lt 1000 ]; do
foo
foo # fooの呼び出し回数を合わせるため
i=$((i+1))
done
--------
time ./test2.sh
real 0m0.027s (殆どが起動時間)
user 0m0.000s
sys 0m0.000s ちなみにLinuxで同じことをやったら
[test1.sh]
real 0m0.281s
user 0m0.285s
sys 0m0.157s
[test2.sh]
real 0m0.006s
user 0m0.006s
sys 0m0.000s
WSLはLinuxの28倍
でもLinuxでも遅いっちゃー遅いな coLinuxならどうなんだろうね。WSLより速いのか? 速いんじゃないの? coLinuxのLinuxアプリはWindowsとは
隔離された空間で動いているんでしょ?
NTカーネル上でLinuxアプリを実行してるんじゃなくて、
NTカーネル上に作ったLinux空間でLinuxアプリを動かしてる
WSLはLinuxアプリは、NTカーネルから見たとき1つのアプリに見えるけど
coLinuxはNTカーネルから見たときcoLinuxアプリしか見えない。という認識 着実にチューニングが進んでいるw
上のベンチマークじゃなくて今作ってるやつだけど
パイプをなくしたら200msから100msに二倍になった
もう一箇所、サブプロセス作ってる所があるのでそこを直すと60msぐらいになりそう
大した差はないように思えるけど、コマンドの実行で300msかかると
つっかかりを感じて、200msだと実行結果が表示開始されるまで一瞬の待ちを感じて
100msだと実行したと同時に1行ずつ出力されいく感じになる。
50msだと結果全てが一瞬で表示される感じになる
使い方によっても何度も実行する部分だからできる限り早くしておきたい。
Linuxだったこれがパイプ使っていても17ms
なくしたら8msなんだけどな >>747
ksh で約2倍高速化(bash比)w >>752
やる処理によって大きく代わるよね
dash(ash)が多くの場合速い。bashとzshがその次。
kshはたいてい遅いんだけど、時たま早い処理があるって感じ 一方ロシアは(速度の必要な処理は)VMとクラウドを使った。 >>754
うーん?基本的にPOSIXの範囲でしかやってないからなぁ
それも時々動くか実行してみただけの感想でちゃんと計測してないし
気が向いたらベンチしてみたほうが良いかもなって思ってるけど多分やらないw kshの変数は長さ情報を持ってるな
${#str} が何文字か調べるときstrに入っている文字列が
長いほど時間が掛かるが、kshだけは長くても短くても同じだった 複雑な処理は、プログラム言語でやれば?
Windows10・WSL・Ubuntu16 で、デフォルトで、python3, perl は入っている。
Ruby は入っていない
which python3
=> /usr/bin/python3
ll /usr/bin/python3
=> python3.5 >>760
またお前か
プログラム言語が入ってない。入れられない環境も
視野に入れてるからダメだって言ってるだろ wslはforkが遅いって話しじゃあなかったのか? >>760
他人ですが >>747 を python でやるとどのくらい時間がかかりますか? >>762
他の言語はforkをシェルスクリプトほど使ってはいない
だから他の言語で書くとforkの遅さの影響を受けにくい
シェルスクリプト内部的にforkが使用されてる例
( echo test ) # 丸括弧によるサブプロセス実行
a=$(printf '%s' hoge) # $(・・・) による標準出力の変数代入
echo test | while read -r line; do # パイプの処理
/bin/echo # 外部プログラム呼び出し
知らずに書くと普通に使ってしまうものばかり
ちなみにevalはforkが行われないし実行速度にほとんど影響が出ない
一応言っておくと、実際にforkが呼ばれてるのを確認したわけじゃないけどね
プログラムの挙動とか遅くなってる原因を調べた結果
できればfork呼び出し回数を数値で見たい
straceを使えばわかるのかな? >>751で書いた「今作ってるやつ」(何かは言わないけど)は
バグとか仕様追加もあって最終的に70msぐらいになった
なにもしないプログラムが20msぐらいなので実質50msぐらいだな
処理内容はwhileループとcaseとevalと変数操作のオンパレード
ついでに各シェルでのおよその実行時間
kshが一番速かったw yashと勘違いしていたかな?
・ksh 60ms
・dash 70ms
・posh 70ms
・mksh 75ms
・bash 110ms
・yash 130ms
・zsh 140ms
ベンチマークに興味がある人は、こちらのyash開発者のサイトが参考になるかも
http://magicant.txt-nifty.com/main/2008/09/post-aecc.html
http://magicant.txt-nifty.com/main/2009/09/yash-2-135-2-03.html forkはプロセスのcloneを調べれば良さそう
こんな感じで実行すれば意図したとおりの結果が出てきた
strace -T -tt -f -F ./test.sh 2>&1 | grep clone
ついでに減らせそうなところが見つかったのでやってみたら
cloneの数を7個減らして、dashの70msが40msまで減ったw
残り3個。0個にするのは不可能なんだけど、1個にはできるかもしれないな できたw
fork(clone)1個。30msになった。
元が200msなので7倍近く高速化
fork 1個で5msって感じかな
今回は処理内容が増えるとその分fork数も増える可能性があったから
頑張ったけど、fork数が固定数であればそこまで頑張らなくてもいいだろうな >>766からforkを10個から1個に減らして再計測
概ね2倍ぐらいの速度になった(dashが一番になったイェーイw)
・dash 30ms (233%)
・posh 30ms (233%)
・mksh 35ms (214%)
・ksh 55ms (109%)
・bash 50ms (220%)
・yash 70ms (186%)
・zsh 85ms (165%)
前回トップだったkshはあまり速度改善はしなかった。
さすがにおかしいと思って調べてみたら、
kshだけ(forkが10個ときのコードでも)forkが1個も存在しなかった
少し適当にだが調べてみるとこんな感じだった
・( echo a ) ・・・ ksh:fork0回、他:fork1回
・a=$(printf) ・・・ ksh:fork0回、他:fork1回
・echo a | read line
・・・ ksh:fork1回、zsh:fork1回、他:fork3回
・echo a | cat ・・・ksh:fork2回、zsh:fork2回、他:fork3回
・/bin/echo ok ・・・ ksh:fork2回、他:fork1回
kshは外部コマンド実行以外はforkを行わないか少ないようだ
逆に外部コマンドを実行する場合はkshは他よりもforkが多い
俺がkshは遅いと感じていたのは、これより前に作っていたプログラムでは
外部コマンドの実行の方を多用していたからだと思う 変なところで改行入ってしまったが
・( echo a ) ・・・ ksh:fork0回、他:fork1回
・a=$(printf) ・・・ ksh:fork0回、他:fork1回
・echo a | read line・・・ ksh:fork1回、zsh:fork1回、他:fork3回
・echo a | cat ・・・ksh:fork2回、zsh:fork2回、他:fork3回
・/bin/echo ok ・・・ ksh:fork2回、他:fork1回 くっそ、poshとmkshがprintfがビルトインじゃない
forkが遅すぎるwww Windows 10に最適化されたLinuxディストロ「WLinux」が爆誕
https://www.softantenna.com/wp/windows/wlinux/
誰か試した人いる? DockerにおけるAlpine Linuxみたいなものかな 今日日、Git for Windowsを標準インストールするだけでbash、awk、perlもインストールされるわけだが。 gnuplotをwslとcygwinでwxtとqtをつけてビルドした。make checkで連続でプロットがでるが
cygwinの方がかなり速い。これはxserverとの接続の問題かもしれん。 WLinux試したけど、build-essentialが入らない。
パッケージの依存関係が壊れてるっぽい。 Chromeが動かないって話だが、fonts-noto-cjkを入れてロケールを日本語にしたら起動した。 >>777
776 は実行時のPCで別プロセスが動いていたことが,原因だった。 >>780
途中でおくった。
やり直したところ,wxtではほぼ同じ。
qt ではcygwinの方が大分速い。
それだけでなくqtは多くのプロットで表示がおかしい。
NativeのUbuntuではqtは表示の問題は起こさない。
ご質問のファイルに書き出しはwslの方がかなり速い。
色んな要因があるので一概に言えないwxtの方が好きなので,
wslではGNUTERM環境変数をwxtにして,wxtデフォにしている。
gnuplotは基本windows Native版を使うけど,他のツールと一緒に使うときは
これまでcygiwn版をつかってきた。しかしこれkら,wslに乗り換えようかなと
思っている。
Cygwinはwin 7のPCで使うだけになると思う。 まだ開発中という感じ
将来性はともかく今はわざわざ金を出して使う必要性はわからん まあ、割引中で安いし伸び代あるなら今のうちに買ってしまうのもアリだけどね。 WLinux、元はDebianだしgithubにも公開されてるしな
ストアの金額はサポート料金らしいし、
普通の人は公式から自分の好きなdistro無料で落とせばよいんじゃね
別にXserverの設定とか簡単なんだし WlinuxとX410を購入してみたけど面白ろい
セットアップした後は素早くX Windowでアプリを使える
ただターミナルからの起動なので
wlinux -c "application"
みたいなbatを書いたけど 787だけど
wlinux -c "application"
でscriptの実行だったら動くけどguiアプリケーションだと接続拒否権されるなターミナルに直接的入力だとx410に接続できるけど Remediating the October 2018 Git Security Vulnerability
https://blogs.msdn.microsoft.com/devops/2018/10/05/remediating-the-october-2018-git-security-vulnerability/
This includes Git clients on Unix platforms (including Linux and macOS) are vulnerable,
including git running in a Linux distribution inside Windows Subsystem for Linux.
Git on Cygwin is also vulnerable.
Git for Windows is uniquely not vulnerable to this security issue 1809でwslconfigにterminateが追加されてることは知ってたんですが、
その他にupgradeってのが追加されてるんですけど、これは何か知ってる人います?
説明文通りファイルシステム形式をアップグレードするんだろうけども
/upgrade <ディストリビューション名>
ディストリビューションを WslFs ファイル システム形式にアップグレードします。 書いてある通りwslfs形式に移行させます
lxfs -> wslfs
ファイルシステム関連のattributesの扱いが少し変更されていますが、
パフォーマンスとかは変わらず、あいかわらず遅いです
新しい不具合を発生させたりもしたので、ごく一部の人で実験してもらう段階じゃないかな
あと、変換自体とても時間かかります パフォーマンスが早くなったりはしないのね
ありがとう 私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
平 和は、勝ち取るものです。拡散も含め、お願い致します。 wslでubuntuを入れましたが、
sudo apt update が失敗します。
ググると
wget -O - https://gist.githubusercontent.com/Zenexer/10bc12fa5c99848b4b2150184f6beee5/raw/ubuntu-fix.sh | sh -s
このコマンドでイケるよと言われてますが、イケないので相談に来ました。
こんな感じです。
hoge@hoge:~$ wget -O - https://gist.githubusercontent.com/Zenexer/10bc12fa5c99848b4b2150184f6beee5/raw/ubuntu-fix.sh | sh -s
--2018-10-17 19:27:53-- https://gist.githubusercontent.com/Zenexer/10bc12fa5c99848b4b2150184f6beee5/raw/ubuntu-fix.sh
Resolving gist.githubusercontent.com (gist.githubusercontent.com)... 151.101.88.133
Connecting to gist.githubusercontent.com (gist.githubusercontent.com)|151.101.88.133|:443... connected.
Unable to establish SSL connection.
どうすればアップデートできるのでしょうか? >>798
wget に –no-check-certificate でも付けて試せばいけるかもな。
てか、WSLなんか、アレな環境なんか、さっさと捨てなさいな。 >>799
ありがとうございます。
しかし、うまくいきません。
$ wget --no-check-certificate https://gist.githubusercontent.com/Zenexer/10bc12fa5c99848b4b2150184f6beee5
/raw/ubuntu-fix.sh | sh -s
--2018-10-17 19:52:29-- https://gist.githubusercontent.com/Zenexer/10bc12fa5c99848b4b2150184f6beee5/raw/ubuntu-fix.sh
Resolving gist.githubusercontent.com (gist.githubusercontent.com)... 151.101.88.133
Connecting to gist.githubusercontent.com (gist.githubusercontent.com)|151.101.88.133|:443... connected.
Unable to establish SSL connection. >>801
具体的にはどうすればいいのでしょうか?
wslのホームまで落として実行してみましたが、こんな感じです。(hoge.shがそれです)
$ ./hoge.sh | sh -s
./hoge.sh: 2: set: Illegal option - ■ このスレッドは過去ログ倉庫に格納されています