【Bash】Windows Subsystem for Linux【WSL】3
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>849
あとは /dev/ttyS1 のパーミッションが 644 ではなくて 664 なら使うユーザを所有しているグループに入れるという解決も考えられたかなあ。 ああ。その、 /dev/ttyS1 というのは特殊なファイルで、
停止するときには消去され、起動するたびに新しく作成されています。
なので、パーミッションを保存しているのでは?
というのは当てはまらないケース。 >>850-852
ありがとうございます。
ttyは起動する度に生成されるんですね。
と言うことはrc.localの編集がよさそうですね。 >> 849
ごめん、根本的にどこやっつければいいのかみつけた。
`/lib/udev/rules.d/50-udev-default.rules` というのがあるんだけど
そのうちの
`KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"`
この行の末尾に `MODE="0666"` にすると
たぶん起動されるたびに 666 で生成される。
ただ、緩める方向の変更なのでファイルの役割について
理解して作業することをオススメします。
# 理由があって先人の考えた規定値が 644 なんで。 >>884
> windowsが提供するAPI側の問題だからアプリだけでとうなるものでもないんじゃないかな
おいおい。WSLはWindowsで提供されてるAPIを使用して動いてるんだぞ。
APIに問題があるわけ無いだろ >>854
ありがとうございます。
これの場合、シリアルに繋がってる例えばUPSなんかが乗っ取られて勝手にダウンさせられるかもしれないですね。
うちは学習用のマイコンを繋ぐだけですが、ちょっと怖いので
どちらにするか考えて決めようと思います。 >>857
MODE="0664" にして、キャラクターデバイスを使う
ユーザのグルーブを増やすという選択肢もあるよ。 >>844
CreateFileのhTemplateFileに指定するだけで拡張ファイル属性を自動でコピーしてくれんのにWindows API側のどこに問題があんだよ 家に帰ってきたので試してみました。
最近のubuntuは/etc/rc.localがなくなっているようなので
スクリプトを作ってサービスに登録しましたが、パーミッションは変わりませんでした。
sudo chmod 666 /dev/ttyS1
でもダメで、おそらく初めてsudoコマンドを使うとパスワードが求められるのがネックになってるような気がしました。
仕方ないので、>>854が紹介してくれた方法で
#KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"
KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout", MODE="0666"
こんな感じに変更してみました(#〜の行が元あった設定)。
ですが、はやり反映されません。
MODE設定の書き方が間違ってるのでしょうか? ? なんの話をしてるんだ?
ここWSLのスレだろ?
rc.localとかLinux起動時に行われる処理がWSLで動くわけ無いだろ
WSLではすでにLinuxに相当するWindowsが起動してるんだから udevもOSのサポートが必須でパッケージ入れれば使えるようなもんじゃないから
まだ実装されてないんじゃないのか? > ユーザのグルーブを増やすという選択肢もあるよ。
これが一番正しい解決方法だろ
セキュリティの理由もあるのでパーミッションを緩めてはだめだ
/dev/ttyS1はデフォルトで正しいパーミッションになってるんだから
ttyS1を使えるグループにユーザーを追加するだけ >>861
なるほど、できないのですか
ならばどうしたらいいでしょうか? 自己レス
> セキュリティの理由もあるのでパーミッションを緩めてはだめだ
一応念の為。WSLの中で見えるパーミッションは所詮WSLの世界から見える
架空のパーミッションでしか無いので、WSLの世界でrootになったからといって
本当にWindowsのAdministrator権限を持っているわけじゃないので
ユーザーができることしかできない
セキュリティ云々は考え方としての話な。
誰でも触れることを意図する変更はやったらだめということ >>863
ユーザーをrootにするということですか?
グループのパーミッションは現状4です。 >>866
ユーザーをdialoutグループに追加しろって話だ
Linuxの基本やで >>867
今は/dev/ttyS1のパーミッションは660になってる 1803だとownerはrootだけど1809だとdialoutになってる? sudo gpasswd -a `whoami` dialout
でいいのか? 1809なら多分それでいいんだろうけど1803だとこんなんだから
crw-r----- 1 root root 4, 64 Oct 29 22:21 /dev/ttyS0
起動時にNOPASSWDなsudoでchmodやchownするスクリプト走らせるみたいな方法しか思いつかんわ コマンドの挙動、よく分からなくてこわいから vigr するわ。オレなら。 https://twitter.com/0xbadfca11/status/1053802978656702464
X410 ってやつの割引期間終わっても次の割引期間が始まるよって書き込みあったけど本当やんけ。場所が場所なら景品表示法で怒られるやつ。
https://twitter.com/5chan_nel (5ch newer account) >>873
> 起動時にNOPASSWDなsudoでchmodやchownするスクリプト走らせるみたいな方法しか思いつかんわ
WSLに限って言えば、WSL環境内でsudo使っても、実際にはWSLを実行している
ユーザー権限で動いているわけでセキュリティ的にはなんの問題もない気がする
setuidしたコマンドを実行するとか? setuidは知ってはいたが意識して使ったこと無いのでやってみたわ
まずsetuidはバイナリじゃないと有効にならないのでシェルスクリプト
とかではなくC言語などのバイナリ吐ける言語で作る必要がある
例えば以下の内容のファイルを作って、gcc ファイル名.c とかでコンパイルする
(gccは適当に入れろな)
#include <sys/stat.h>
int main()
{
chmod("/dev/ttyS1", 0666);
}
a.out(適当名前に変更どうぞ)が作られるから、
sudo chown root:root a.out
sudo chmod +s a.out
あとはsudoとか使わなくてもroot権限(ファイルの所有者)で
動いてくれるので.bashrcとかに書いて実行すればよかろう
ちなみに、/dev/ttyS1 決め打ちなのは手抜きというより引数で自由なパスを
指定できるようにすると、セキュリティ的に問題があるのであえてそうしている
つまりこのコマンドはどう実行しても /dev/ttyS1 しか変えられんというわけだ
自分専用のツールならこの程度で十分だろう 日経Linux 11月号の付録
WSL 特集、100 ページの冊子
DVD は、Ubuntu 18.04.1 LTS 日本語 Remix, 64bit, ブータブル、
Mint 19 Cinnamon v2, 64bit, ブータブル/ISO、
Lubuntu 18.04.1 LTS, 64bit, ISO 100ページも特集することあるのかね。
Linuxのコマンドリファレンスかも。 linuxは既にデュアルブートで動かしてるからdvdはいいけど100ページのってのは気になる 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を変換しようとする猛者か レス数が950を超えています。1000を超えると書き込みができなくなります。