【Bash】Windows Subsystem for Linux【WSL】3
■ このスレッドは過去ログ倉庫に格納されています
>>397
だからなんだと。お前書いていて理解してないだろ?
クラッシュするのはGPU自体のバグなんだからWebGLに限らずOpenGLでも発生する問題
だから、OpenGLはずいぶん前からサポートされてるって話をしている
落ちるからサポートしていなかったわけじゃない
Cross-Origin Resource Sharingなんかは完全にWebGLの仕様の問題で
GPUドライバの不具合とは一切関係ない
お前はこの二つをごっちゃにしてCross-Origin Resource Sharingを使うと
GPUにバグがなくてもクラッシュさせられるとか思ってるんだろ?
ほんと馬鹿らしい ID:DbiQ98jc = ID:2J7dm43q か
別IDからID被り設定は流石に草 wikipediaの文章、中途半端な気がしたから少し詳細調べてみたが、
結論としてはやっぱりwikipediaは当てにならんってことだな
http://d.hatena.ne.jp/nakamura001/20110617/1308293128
> そして、今回のMozilla JapanブログではContext Information Security社から
> 報告(DoS攻撃が可能)についての話なので「WebGL仕様の問題では無く、
> Firefoxの問題です」と書かれているようです。
DoS攻撃に関してはFirefoxの問題
クロスドメイン画像盗取に関しては仕様の問題
( http://d.hatena.ne.jp/atsushieno/20110511/p1 )
GPUにバグが有る場合クラッシュするっていうのは
完全にこれ書いた人に想像だろ?
(ドライバにバグがあればクラッシュするのはWebGLに限らず
当たり前でWebGLの問題とする必要もない) >>404
そのブログ的なものが正しいという証拠を示さないとねぇ。 >>405
リンク先を見ればいいだけ
ほら、勉強してこいw リンク先がMozillaじゃねーかw
開発者がFirefoxの問題だって書いてるじゃねーか
ひぇ〜って今頃気づいた頃かな? >>406
リンク先も正しいとは限らないのがね。
査読つき論文になってるようなものじゃないから。 おやおや、開発元が言ってることにまでいちゃもんつけだしたよw
ホントこいつなにも考えてないんだなーw >>409
第3者が言ってるならいいんだけど、開発元でしょ? 開発者が自分のミスですって認めてるのに、
第三者がいーや、お前のミスではないっていって
信じるの?wなんで?w >>411
あそ、バカに付き合って遊んだだけだから
気にしないでね。 IDかぶりしてないよ。仕事行ってただけ、”ドライバが落ちる”=”ドライバがバグる”ではないでしょ。って話。そもそも言いがかりなんだからまともに相手してられん。 >>414
ドライバが悪いと落ちてしまうと死んでしまうモノリシックなカーネルを使ってるLinuxより
切り離せるマイクロカーネルを採用したWindowsのほうが優れているってことですね。
幸いなことにドライバの対応が少ないLinuxだとその欠点はおおっぴらに
なってないから勘違いして「Linuxはフリーなのに、しゅごい!、マンセー」なひとが
多いね。 windowsのコマンドシェルをディスるつもりやないけど、マルチピリオドを含むファイル名を一括リネームしようとしたらエラー出てできひんかった
Explorerで一つずつならできるんで、いろいろ表記変えて試したけどあかんかった
ひょっとしてWSLでmvしたら、と試したら全然問題ないやん
役に立ったわWSL >>414
落ちる=バグる ではない?
じゃあ落ちるってどういう意味?
まず最初に自分の発言を訂正しなよ。
↓
357 返信:login:Penguin[sage] 投稿日:2018/06/22(金) 17:32:37.40 ID:DbiQ98jc [12/16]
GPUドライバ落ちてもモノリシックのLinuxは落ちないし。 >>416
> ドライバが悪いと落ちてしまうと死んでしまうモノリシックなカーネルを使ってるLinuxより
落ちる=バグるじゃないらしいよw >>420
でもロードされてない状態のことを指すらしいよw 落ちる=停止させる だと
↓これが意味不明になるんだよね
> GPUドライバ落ちてもモノリシックのLinuxは落ちないし。
GPUドライバ停止しても、モノリシックのLinuxは停止しないし。
なんでそこでモノリシックが関係するの?
GPUドライバがバグで落ちた時、モノリシックのLinuxは
カーネルパニックを起こす。でもマイクロカーネルのWindowsは
そんなことにはならない。問題なく動き続けるって話をしていたのに
落ちる=停止だとその話に噛み合わない な割にはアップデートしたら再起動要求してくるのはなんで 1803にしてからlxssのサービスの立ち上がりがなんか安定しない >>423
OSのアップデートだからでしょ?
定義ファイルやストアアプリのアップデートで
再起動要求してくることはないよ >>426
この例と同じだよ
GHOST: glibc 脆弱性 (CVE-2015-0235)
https://access.redhat.com/ja/articles/1333303
> 2. システム、または影響を受けるサービスを再起動します。
> 脆弱性が、システムのアプリケーションの多くに影響するため、すべてのアプリケーションが
> アップデートした glibc パッケージを使用するようにする最も安全で推奨される方法は、システムを再起動することです。
>
> アップデートの適用後システム全体を再起動できない場合は、以下のコマンドを実行して、glibc の古い
> 「メモリ上」のバージョンを使用して実行中のすべてのプロセス (サービスではない) を表示します。
>
> lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t
>
> 結果リストから、公開しているサービスを特定して再起動します。このプロセスは一時的な回避策として有効な場合もありますが、
> 問題が発生しても Red Hat ではサポートされていないため、トラブルシューティングの前にシステムを再起動する必要があります。
理論上は更新があったモジュールを使用しているプロセスを再起動すれば良いんだけど、
プロセス名を言われても普通のユーザはよくわからないでしょ?
アップデートで更新されるモジュールは一つとは限らない。
画面がないプロセスとか普段意識してないサービスとかの多数の名前を画面に出されてもわからない。
起動していたアプリが落ちることもあるから、自動的に勝手に再起動できないし。
実は再起動が必要なアップデートは、必ず再起動が必要になるわけじゃない。
更新があるモジュールを読み込んでいなければ再起動なしに更新できる
だからよく「再起動が必要になる"場合が" あります」って書いてあるわけさ
再起動が必要なのは、更新があったモジュールが使われている場合で、
そのときに、ユーザーがわかりにくいプロセス名を表示してユーザーの操作を待つ方針をとるか
再起動すれば万事OKという方針を取るかで、後者を取るのは仕方ないと思うよ
もっといい方法があれば良いんだけどね I/Oが本当に遅いんだけど…
でもこれでMacいらなくなった
WSLの中のファイルいじる時はsshでsftpで良いの?直接Windowsからファイル操作すると壊れるって
逆は/mnt/cで可なんだよね >>428
wslのファイルはwindowsからいじれないけど、wslでいじらないのはなぜ? viとかemacsとか
そうしないのならwslの意義がほとんどなさそうなのだか >>431
Windows上のEditorのほうが使いやすいと思うからじゃないの?
コンパイルはWSLで、編集は秀丸とかさくらエディタでとか。
将来的には改善されるんじゃないかな。 linuxだとコンソールから編集するけど、Windowsのターミナルエミュレーターがしんどいからcloud9入れてる。便利よ。 >>431
だったらはじめからLinux使っとけよ >>434
Linuxだけでがんばるのもいいし、Windowsだけで済ませるのもいいけど、
Windows、Linuxのそれぞれのいいところを生かせるのがWSL。 >>432
ファイルの編集をwin側でということなら、win側でファイルを用意してwslからは直接とかリンクを張ってとかで利用するのがいいですね 俺もLinux側のファイルをWindows上で
直接編集できるようにならないかなーって思って、
仕組みだけは考えてみたんだよ。
一番の問題はWindows上のテキストエディタが
WSL上の所有者やパーミッションを適切に設定しないこと
だから直接ファイルを参照するのではなく変換レイヤーをかます
その変換レイヤーをエクスプローラのエクステンションとして作成する。
そしてWSL上のファイルを仮想的なファイルシステムとして
エクスプローラ上にマウントする
あとは所有者やパーミッションはWSL上からしか変更できない
ってすれば概ねいけるんじゃないかなーと
ファイルを上書き保存するときに、内部的に別名で作成して
古いのを削除してリネームするタイプはちょっとこまるけどさ
誰か作ってくんねーかなー >>436
なんとなくだけど、
VolFs(WSL上のファイルシステム)は相互運用を考えられておらず
Linuxで使われてるファイルシステムの機能を実現できるように作られており
/mnt/c以下のDrvFsの方で相互運用できるような感じで開発されてる気がする
例えば最近だと所有者やパーミッションをうまく扱えるようになった
WSLの開発チームとしてはDrvFsの方でデータ作成してほしんじゃないかなーって思う >>437
>>438
1803でパーミッション関係改善されたらしいけど、どうなんでしょうか。
当方の環境ではメモリがふんだんにあるんで8GBのramdiskをOSFmountで
作ってそこにWindowsとWSLの作業フォルダ作ってるんで、問題にはなっていません。
秀丸とかさくらエディタとかちょっとした修正には便利なんでやめられません。 >>437
dokan + win-sshfsみたいな >>437
問題の最大の原因が
>ファイルを上書き保存するときに、内部的に別名で作成して
>古いのを削除してリネームするタイプ
である以上そこを一番に対処しないのは片手落ちどころかZ武 そういやwinsshfsのドライブはdrvfsでマウントできないな
WSLでfuseが動いてくれればなあ 反応されてないからこれっきりにするけど、WSLにcloud9入れれば解決するよ。
cloud9はブラウザから使えるIDEでエディタもコンソールも付いてるし、もちろん日本語も使える。
コピー&ドラッグでファイル交換もできる。
linux鯖に入れたりもするけど、qiitaに記事があるから見てくれ。
https://qiita.com/naniwaKun/items/b7b45a6e6ed33ce81eb9 >>443
fuseは要望は多いみたいだし、可能性はあるね。 >>444
面白そうだから家に買ったらやってみる。 fuseは遅くてもいいから欲しいな
それとデバイス直接触れるようになればかなりいい >>449
デバイスは難しいんじゃないかなぁ。GPUとか使いたいって言う
人はいるようですね。そこまでするなら実機でいいような気がするけど。 wslで出来ないこと探すのに躍起になってるだけかと。 >>451
もうOSとかそんな時代じゃないんだけどね。それをわかっているのがMS
わかってないのがLinuxやMac信者。 できないこと探すってよりWSLは万能ツールじゃないからさ
得意なこと不得意なことあるのは当たり前かと
MSもそのあたり分かってるからHyper-VのEnhanced Session Mode作りながら
WSLは別物として開発してるわけでね >>450
あ、いやデバイスというかhddとかusbメモリとか
ext4とかのhddとかwindowsで扱いたいときあるじゃん Windowずから操作しても、大抵はファイル壊れないよ Windowsユーザーが気付いていない未来の落とし穴
1. スケーリング問題が未解決
2. HiDPI(Retina、仮想解像度)をサポートしていない
3. MacとLinuxに引き離される
4. フルHDモニターしか使えない
5. 巨大画面56インチ4KモニターでWindowsを使う日がもうすぐやってくる
>>454
loopback deviceとかdevice mapperとかもあるといいなあ
まあ要求しだすと結局「素のLinuxか仮想マシン使え」になってしまうんだけど
せめてWin10のHyper-VがUSBメモリブートできれば… リナックスx86系は日本人C,C++本物のマは数える程しかいないの知ってる
なぜならいざ配布となるとlibcとか互換性問題めんどいからな
妙に上げてるのは似非マのうぶんちゅうかもしくわぱいそんぱいそんいってるパイカスだけだろ?
MSも商売だから大変ね WSLでfuseが動いたらext4やbtrfsをマウントできるようになるのか? >>461
え、嘘だろとか思いながら今パピーで即席でfuseのチェックはずしてbzImageコンパイルしたけど普通にext4のrootfsマウントできたぞ
俺の10分返せ >>462
ここはLinux板だけど、WSLのスレッドだからカーネルはWindowsだよ。 >>465
WSLのカーネルコンパイルできたら面白いね。 >>465
いやLinuxカーネルの例えであってるよ、ext4がfuseに依存してるかどうかの話だから
難しい話じゃないと思うんだけどね >>467
依存してるかどうかの話は君しかしてないんじゃない?
WSLのカーネルを自分でコンパイルできるなら方法を教えてほしい。 >>467
ext4がfuseに依存してるかどうかの話ではないよ
fuse版のext4(あるいはbtrfs)ドライバが存在するか、もしくは>>461が作れるかどうかの話だよ >>468
釣りかな?
>>461がその話をしだしたんだが
あとWSLはWindowzのサブシステムだからカーネルはNTカーネルでしょ
興味ないから見てないけど >>470
WSLでfuse動かすことできたんですか?
それだけの問題なんだが。
YesかNoでよろしく。 >>469
あ、そういうことかわかったスレ汚しゴメンね >>465
>今パピーで即席でfuseのチェックはずしてbzImageコンパイルした
このパピーのマシンは素のパピーLinux?それともWSL?
コンパイルはできると思うけど、カーネルはロードできないんじゃないか?
試したことさえないんだけど、そもそもWSLにLinuxのカーネルがのってないから。
仮にWSLで自前カーネルで起動?できるなら、コンパイルもAPIレベルでエミュレート(厳密には違うけど)できてることになるからワクワクするぞ!
手順を教えてくれ。 >>472
勘違いはあるよね、俺もはじめWSLは仮想化だと思ってたよ。>>473は気にしないでくれ。 >>473
書き込みから、そう思って期待したんだけど
>>472
のようにそういう意図じゃなかったようです。
自前カーネル起動するなら普通に考えたら実機かVMですよね・・。 >>476
あなたがいい人だということはわかりました。 WSLは全然よゆーで不完全なんだけど、ただの仮想化じゃないから夢のある話で期待したくなる魅力があるんで、そのへんの啓蒙にはなったんじゃないか? >>478
昔からある技術をLinux互換にしたんで興味持つ人が増えているのかも。
MSの英断としかいいようがないですね。 MS CEOのナデラならでわの営団だな
ナデラならでわ でもwslでできなくてLinuxディストリでできることって殆ど無くない? >>483
Windowsでできてしまうことが悔しいですか? WSLはLinuxデスクトップが無くなる一助になると思いますが、Linuxそのものは広まると思いますよ。
WindowsユーザーもWSLを通してLinuxを使うようになりますから。
LinuxもWindowsの一部になったと考えればありがたみが分かるのではないでしょうか。 Windowsの機能の一つとして認知される以上、メモ帳のようにいつまでもWindowsに在り続けると思います。
そういった意味でもWSLは安心して使えるんじゃないでしょうかね。 >>487
普通のWindowsユーザーはメモ帳は使うかもしれないけどWSLは使わない。 Hyper-VはProでないと使えないし
Homeでも使えるWSLはありがたい WSLはバッテリーを余分に消費しないので、そういった点もありがたいですね。 WSLでビルドして大量のファイルを作ったり消したりしてると
no such fileとか言われることある?
/mnt/cのほうで起きるんだけど >>474
仮想化じゃなくWinカーネルでGNUを動かすだからな
MSがWinにLinuxカーネルを入れるなんて大敗北だろうからな >>494
理解してるし、レスの流れを読んでくれると助かる。 >>494
と、いうかLinuxにとってWindowsに取り込まれて内包されてしまうほうが
敗北なんだけどね。協力したCanonicalがバッシング受けてるとか。 Windows ServerならWSLでサーバー機能を提供しても、
ライセンス的に問題ないという理解で良い? ■ このスレッドは過去ログ倉庫に格納されています