【Bash】Windows Subsystem for Linux【WSL】3
レス数が950を超えています。1000を超えると書き込みができなくなります。
mecab用の最新辞書からデータベースファイルをコンパイルする目的でWSLを使ってる。
Windowsのmecab.exeでも同じデータベースファイルを使えるからだけど。 WSLのdebian日本語化(locale,man)だけで
http://www.atmarkit.co.jp/ait/articles/1810/26/news035.html
これだけ書けるんだから、水増しはいくらでもできるだろうけど、
いちおうlinux専門誌だから、どんな視点で記事を依頼してるかだね
linuxユーザから見たら、10倍以上遅いlinuxもどきだろうし、
dbだとさらに差がつくし > linuxユーザから見たら、10倍以上遅いlinuxもどきだろうし、
そんなに遅く感じることはない npm/yarnで開発環境準備すると、
linux on 10年前のcore2duoラップトップ
のほうが
wsl on 第7世代core-i5&SSDラップトップ
よりも早く終わるわ
あと、sqliteがやたら遅くなるのが解せない Linuxの人ってインストールだけして喜んでる人多いよね
セットアップ時間が短縮した!とか言って喜んでるの
そこしか判断できないからなんだろうけど >>888
vscodeの裏で走るnpmも遅いけど、wsl上のvscodeはたまに
windows側からもkillできない死に方しちゃってこっちのほうが面倒。
windowsのvscode使って、開発支援は各language server経由ってのが
増えそうだけど、そうなるとhyper-V上のdockerのほうが良くなるような SQLiteが遅いのはファイルシステムのせいだろう。
WSLのファイルアクセスが遅いから足引っ張ってる。 kill出来ないなら1809からだけど、wslconfig /terminateで再起動しちゃえば良いのでは 何度も言うけど、I/Oが遅いのは、MicrosoftがさっさとNTFSを捨てないから。
さっさと、NTFSなんか捨てるべき。 >>892
1809より前でもwslサービス停止させればkillできたけど、
書き込み処理中でも強引に全体を終了させるからファイル
破損すると被害大きかった https://www.sqlite.org/download.html
から
SQLiteの公式バイナリ落として、WindowsネイティブとLinux on WSLとでどれくらい違いがあるんだろうか?
単純なSQLでベンチマーク取ってみると10倍くらい差が出そう。 NTFSが原因ではないでしょ。WindowsネイティブとLinux on WSLはともにNTFSなのだから。 >>895
たとえば、
openbenchmarkにある、同じマシンでのsqliteへのinsertionテストで
ubuntuだと2.27秒の処理がwindows binaryだと24秒で十倍くらい
さらに同じマシンで
ubuntu:2.62秒、Ubuntu@wslで60秒
となってる
このベンチ取った人はopenbenchmarkの中の人
test suite見るとwindowsのsqliteは32bit版みたい
https://openbenchmarking.org/system/1810126-SK-WSLWINDOW35/Windows%2010%20October%20WSL >>898
いくら32bitのEXEでも遅すぎる・・・ワロタww 遅いのはマジでNTFSのせいかもしれんな。
>>893を疑ったけどその通りみたいだw 前スレで自分がそもそもNTFSが遅いんじゃないかと書いたらボロクソに叩かれたのを思い出したわw
http://mao.5ch.net/test/read.cgi/linux/1468149353/715-721n
しかしNTFSってWindows Serverとかでも使われてるわけで、もしNTFSが原因で一桁遅いんだったら、IISとかSQL Serverとか遅くて製品として成り立たなくなっちゃうと思うんだけど、そういう話は聞いたことないしなあ。 >>898
NTFSが原因ってことは、
それがexFATにしたら10倍になるってこと?
exFATはえーなw >>902
> 前スレで自分がそもそもNTFSが遅いんじゃないかと書いたらボロクソに叩かれたのを思い出したわw
そりゃそうだな。
NTFSが遅いと仮定するならば、NTFSから変更すれば
Windowsは爆速になると言っているようなもんだ
少し考えばありえないってことぐらいわかるだろう Linux on VirtualBox on Windows はバリバリ速いよ。
NTFS上の1ファイルにファイルシステムがあるから?
やはりDefenderとかが悪さしているのかも。調べてみるか。 >>898
10倍っていうのはforkの遅さと一致するんだわ
俺の計測だと、Linuxではfork1回で0.2ミリ秒だがWSLだと2.5ミリ秒になる
たった10000回forkしただけでLinuxで2秒がWSLで25秒になるわけだ >>905
> NTFS上の1ファイルにファイルシステムがあるから?
1ファイルだろうが、アクセスはブロック単位だろw
ほれみろ、Linux on VirtualBox on Windows がバリバリ速いことからも
NTFSに原因がないってことは明らかじゃねーかw ちなみにSQLiteも1データベース=1ファイルなので
1ファイルだと速いことは否定される >>902
WSLで遅い
WindowsはNTFSだ
この2つになんの関連も示せてないのに、NTFS使ってるから遅いんだって
言ってるから馬鹿にされるわけで
例えばNTFSだと遅いならば他の条件を同じにして
NTFSからexFATに変えるとかして検証ができるはず >>906
これでテストしてみた。
while :; do date; done | uniq -c
Hyper-V動かしているUbuntuとの比較だけど、こんなに違うんだよな。
・Hyper-V
1598 2018年 10月 31日 水曜日 18:36:16 JST
・WSL
48 2018年 10月 31日 水曜日 18:35:47 JST
Disk I/O の話ではなくなってるけど。 上記のテストは、ウイルススキャンの影響も受けるようです。
47 2018年 10月 31日 水曜日 19:18:07 JST
47 2018年 10月 31日 水曜日 19:18:08 JST
47 2018年 10月 31日 水曜日 19:18:09 JST
47 2018年 10月 31日 水曜日 19:18:10 JST
136 2018年 10月 31日 水曜日 19:18:11 JST ← McAfee VirusScan のオンラインスキャンを手動停止
167 2018年 10月 31日 水曜日 19:18:12 JST
162 2018年 10月 31日 水曜日 19:18:13 JST
129 2018年 10月 31日 水曜日 19:18:14 JST
153 2018年 10月 31日 水曜日 19:18:15 JST
152 2018年 10月 31日 水曜日 19:18:16 JST
153 2018年 10月 31日 水曜日 19:18:17 JST
151 2018年 10月 31日 水曜日 19:18:18 JST
36 2018年 10月 31日 水曜日 19:18:19 JST ← しばらくすると 停止していた Window Defender が動き出す
27 2018年 10月 31日 水曜日 19:18:20 JST
26 2018年 10月 31日 水曜日 19:18:21 JST
27 2018年 10月 31日 水曜日 19:18:22 JST
24 2018年 10月 31日 水曜日 19:18:23 JST >>991
おお、すげぇ。確かに速くなった。
とある処理を各シェル実行してるんだが、だいたい速くなった
一つkshだけ殆ど変わらなかったが、このシェルの特徴として他のシェルでは
サブシェル(forkが行われる)で実行する所をサブシェル使わずに
高速化してるのでこの結果は納得がいく所
参考 http://magicant.txt-nifty.com/main/2007/12/post_b430.html
プロセス起動時のメモリチェックでも時間がかかってるんだな 日経Linux11月号の特別付録Windows版Linuxのすべてがわかる本、
買ってみたけどこれいらんなぁ
100ページとあるが、半分以上はLinuxのコマンド集とかになってるし、
今時点の記事なのにApril2018Updateに関わる事しか言ってないし
tmux書いてるなら罫線が乱れることも書けばよいのに(設定で直るけど 雑誌は安いが失った時間は高くつく
Windows Subsystem for GNUの速度測定をしてる君たちの着地点はどこなんだい? >>914
もう着地してる。遅い原因はわかったので、その機能を減らすことで
速度を上げることに成功した。WSLでも快適なツールに仕上がったよ 日経Linux 11月号の付録の、WSL 特集、100 ページの冊子
コマンドの説明も、Windows のpowershell で処理して、Linux でgrep するとか、
powershell.exe 何々 | grep
Linuxのls を、Windowsのクリップボードに入れるとか、
ただし、改行がLF だけになるけど、
ls | clip.exe
Windows, Linux双方のコマンドが入り乱れて、なかなか面白い >>917
めんどくせーな。
WSLでDebianパッケージのFFmpeg使ってたのに。 新機能試したいならInsider Preview使うしかない。
WindowsごとHyper-Vに入れとけばいい。 >>919
>>920
とりあえず春まで待つことにします… 18272のWSLは残念なことになってるけどエクスプローラーに突如現れたWSLって名前のフォルダは何だろうな(こちらに同じように何も機能していない) >>920
> 新機能試したいならInsider Preview使うしかない。
WSLはもう新機能じゃないじゃん。
安定版WSLが提供されてるのに、あえて開発版を使う必要はない WSLにも新機能出てくるから、
新機能試したいならInsider Preview使うしかないってのは別に間違いでもないでしょ
そういうのに興味ないなら別に追随しなくて良い しかしIPの最新ビルドではWSLが動作しないのであった 既存のWSLは実用的だけど、まだ伸びしろもある。
たとえば、wslpathは作りかけっぽいし、OpenGLはなんか変。
デーモンを自動実行する上品な方法もあったらいいなと思う。 >>927
人それぞれだろうからリリースノートに気になるのがあったらじゃないのかねぇ
https://docs.microsoft.com/en-us/windows/wsl/release-notes
1803や1809では機能的に変わった所があったからな 最近だとdockerに必要なMS_SLAVEの
サポートがあった LinuxカーネルのAPIとの互換性を高くすればDockerが動くのは必然
Dockerが動くのを視野に入れてると思うが、
Dockerを個別にサポートしているのではなく、
Dockerが使用しているカーネルのプロセス分離とか
そういったAPIがWindows上に搭載された結果だろう 日経Linux 11月号に載っている、
端末上で動く、CUI のファイラー、ranger は、Ubuntu 16.04 で動きますか?
他には、LXD (Linux Containers)も動きますか? Ubuntu 16.04 で、ranger をインストールできた
sudo apt install ranger
設定ファイルをコピーする。
ranger --copy-config=all デフォルトの改行コードもLFでいい。
Macもとっくの昔にそうなってるし、テキストデータオンリーならそれで困らないと思う。 >>936
> ついに、メモ帳がLFに対応するのか…
もう対応してる。
rsyncを使ってバックアップで、改行コードがLFで
出してるのがあったんだが、サクッと確認するのが楽になった。 最新の安定バージョンでついに対応と言った936に対してもう対応してるとかアスペかよ >>940
>>936が言ったのは、「ついに対応した」ではなくて
「ついに対応するのか」だからな。
つまり>>936は未来の話をしてる。
だから、もうみんなに公開されている安定版の
October 2018 Update ですでに対応していると言った。
理解できた?本物のアスペさん 1809にした人は知ってる事だから、そいつが無知だったんだろ 分割されたバイナリファイルをmsysのcat.exeで結合したら暗黙で改行コード変換されたことに気づけず苦しむところまでが遠足です。 >>938
Windows 10のInsider PreviewでシステムロケールをUTF-8にするオプションが追加される
https://srad.jp/story/17/11/14/0640253/ >>943
catがテキストモードで開いてるわけねーだろ
変換なんかしねーよ。 日経Linux 11月号には、
端末上で動く、CUI のファイラー、ranger の他にも、
mc というファイラーも載っている
ただし、どのバージョンのOS で動くかは、書いていないけど
sudo apt install mc Windows のExplorer では、BOM 付きUTF-8 じゃないと、sjis と区別できないから、文字列検索できない
ただし、BOM付きにするとバグるアプリがあるから、漏れは、BOMなしにしている。
それで文字列検索は、WSL 側のgrep を使う >>946
midnight commanderかな?
懐かしいね iconvは入力文字のコードがUTF8前提で、最初7ビットアスキーの範囲で途中からSJIS交じりのファイルを変換させると字化けしまくるバグ(ばぐ?しよう?)があるからキライ。 > iconvは入力文字のコードがUTF8前提で、
入力文字コードの指定ぐらいしろ
本当にアホ iconvで-f指定しないでCP932を変換しようとする猛者か わかってねえのはてめえらだ!
天才は何をしても許されるんだぞ〜! ウェブページのHTMLを、ウインドーズのメモ帳で開くと、ダーーーーーーーーーーっと全部一行に表示されたことありますよね?
その現象が、ウインドズーを他のオペレーティングシステムと連携させて使用する上での最大の問題点の見える化です。
この問題は一見簡単に解決できそうですが、実際は今の人類のIT技術では解決不可能です。
格段にAIが進歩すれば、あるいはギリギリ解決できるかできないか、それぐらい難しいテーマです。
この問題を解決できる究極アルゴリズムを発明できる人なら、次のgoogleになれます。 意訳「メモ帳が改行コードLFに対応したんだよ」というレスをしてください。お願いします。 >>954
10/3 から正常にメモ帳で参照できるようになりました。不思議です。 >>957
究極アルゴリズム、完成していたのか…! すげえマジレスするけど、一度スプリットして再度改行コード入れるだけやで。
エディタの改行コードを選べれば解決なんやで。
windowsの問題はsjisと改行コード。これをスッキリ解決してくれたらネイティブで使えるし、
bashの連携もうまくいくねん。Bashだとすんなりうまくいくcurlのコマンドもwindowsネイティブなら
sjisで日本語送るからサーバーではねられて死ぬ。 >>959
日本語専用の文字コードであるsjisが
日本以外の世界中のWindowsで使われるわけ無いだろw
こう突っ込むと、sjisとか言ってたやつは逃げるんだよなw >>960
世界規模で考えてるとはご苦労だな。俺もコンソールやコマンドプロンプトに日本語は打ちたくないけども
日本人だし、curlでアクセスしたいサイトは日本語のサイトなんだ。
俺は快適にPCを使うのに母国語が使えるっていうのは大きなポイントでね。
あとアジア圏には全く同じ問題がつきまとうんでそのへんの理解を頼むわ。英語が母国語の地域は少ないんだぞ。 > 世界規模で考えてるとはご苦労だな。
そりゃOSなんだから世界規模で考えてるだろ
で、いつからWindowsはSJISを世界規模で
使うようになったんだ?
いい加減嘘つくのやめろよ >>962
煽るのは自由にしてくれたらいいんだが、展開が早すぎないか?
「windowsの問題がsjisと改行コード」の文節が「WindowsはSJISを世界規模で使う」になったんだ?
今回は人を嘘つきにするのが早いな。嘘つきくんと呼ぼうか。
ローカルな話と理解してくれるならローカルな問題だとわかりそうなもんだが、う〜ん、なにか別の意図があるに違いない。
僕の知らないグローバルななにかが。
あと、世界規模の話すると、海外PCから日本語見ると文字化けするんだよね。あれはグローバルな問題じゃない? そういや、AIXのデフォルトってまだSJISなん?とっくに変わった? >>963
そりゃ日本以外ではSJIS使ってないんだから、
SJISに問題はないってことになるからねw SJIS時代の比較関数はUnicode対応された今でも世界中のWindowsで静かに生きている。
これは、Windows95とWindowsNTで同じソート結果が必要だったことによる。 >>965
EUCだよ
SJISにも設定出来るけどな >>957
メモ帳以外の普通のエディタは、文字コード・改行変換できる
Windows10 October 2018 Update(1809)では、WSL・Windows の自動変換ができるようになったのかも?
漏れのは、1803 だから、Ubuntu 16.04.5 だけど、未だに、Ctrl+C, Ctrl+V でコピペできない
winver というコマンドで、OS バージョンでも見てみれば? 1809は改行なおしに力いてれきたのな
まだ3だがうp知こない
はや来ぼんぬ Linux の端末では、コントロールキーはシグナルに使われるから、
ショートカットを使えないようにしているのか
Ctrl+Shift+C, Ctrl+Shift+V で、コピペ出来るようになるのかも Announcing Windows 10 Insider Preview Build 18277
https://blogs.windows.com/windowsexperience/2018/11/07/announcing-windows-10-insider-preview-build-18277/
> We fixed the issue causing WSL to not work in Build 18272. Thanks for your patience. Microsoft Storeにて2種類のLinuxディストロが配信開始
https://pc.watch.impress.co.jp/docs/news/1152338.html
Windows 10上でのLinuxの動作をサポートする「Windows Subsystem for Linux(WSL)」機能への追加Linuxディストリビューションの配信をMicrosoft Storeで開始した
配信が開始されたのはWLinux、OpenSUSE 15/SLES 15の2種類。
WLinuxに関しては有償での配布で価格は2,350円となっているが、現在期間限定で1,150円で販売されている。
このほか、ARM版Windows 10上のWSLにおけるUbuntu 18.04の動作が新たにサポートされ、
エクスプローラ上のコンテキストメニューからLinuxシェルが開けるようになったり、コンソール上でのコピーアンドペーストが使えるようになったりと、細かな機能追加もされている。 WLinuxなら自分で入れれば良いと思うんだけどな
githubで公開されてるんだから
特別なものでもなく中身Debianだし 何言ってんだも何も無料で入れられるって言ってるんだが? 「何言ってっだ」という東北なまり?に微妙に心が安らぐ。 WLinuxが記事になってる時、東南アジアにいて、Windowsの国と地域の設定を東南アジアの国にしてたせいか、WLinuxが100%割引になってたんよね
それで買った -OyomiオプションつきでWSL版mecabで開いた状態だと、Windows版mecabで同じ辞書フォルダを開けない。
Windows側でCreateFile()の共有指定をFILE_SHARE_READからFILE_SHARE_READ | FILE_SHARE_WRITEに変更して再ビルドすることで回避できた。
同じ問題が、いろんなアプリで起きそうな予感。
WSLで読み取りで開いているファイルにアクセスできないWindowsアプリとか潜在的に多そう。
ちなみにMSのCライブラリだとfopen(filename, "r") でFILE_SHARE_READ | FILE_SHARE_WRITEが指定されるので大丈夫。
CreateFile()というWindows固有のWin32APIを直接呼び出すコードで問題が起きる可能性がある。
読み取りで開くからといって共有指定をILE_SHARE_READ | FILE_SHARE_WRITE ではなくFILE_SHARE_READだけにするとハマる。 レス数が950を超えています。1000を超えると書き込みができなくなります。