【Bash】Windows Subsystem for Linux【WSL】4
■ このスレッドは過去ログ倉庫に格納されています
-wgl はwindowsのopenglのハードウェアアクセラレーションを使うのでそう書いた。でも、確証はないので、多分をつけた。 Windows 2000ぐらいに小さくて軽いWindows 10に
WSLだけ入れたいわ。
それ以外の付属モノは、全部要らん。 Hyper-V Server 2019とかいいんじゃね?
WSL有効に出来るよ http://www.aoky.net/articles/david_pogue/david_pogue_says_simplicity_sells.htm
Microsoft Word が単なるワープロだったのはアイゼンハワー大統領の時代(50 年代)にまでさかのぼります。(笑)
しかし代わりに何があるでしょう? Microsoft は実際試したことがあります。
「みんな機能を追加しすぎだと不平を言っている。ワープロだけのソフトを作ってやろうじゃないか。
シンプルで純粋な、Web ページ作成やデータベースのないやつを」。
それが現れました。Microsoft Write です。みなさんご存じないでしょう。大失敗でした。誰も買いませんでした。
私はこれを「SUVの原理」と呼んでいます。みんな必要もないパワーに取り囲まれているのが好きなんです。
データベースやWeb ページ作成機能なんて必要ないのに、こう言うのです。
「アップグレードしておこう。そのうち必要になるかもしれないからね!」 それならもう普通にLinuxインストールすればいいだろ。 >>626
ワードパッドやろwin使いなら誰でも知ってるで
でも欲しいのはバイナリのリッチテキストじゃなくて
テキストをテキストのまま色付けや段落分けできる構造化エディタだったんだよなあ
htmlやcssがもっと手軽に扱えたら良かったんだろうけど >>629
3.1まではwrite、95からはwordpadだっけ(以降もスタブのwrite.exeはあるけど) >>629
> テキストをテキストのまま色付けや段落分けできる構造化エディタだったんだよなあ
無理やで?
勝手に色がつくことは可能だが、
ユーザーが自由自在に色を付けることはできない Skip Aheadで\\wsl$\登録名\のUNCパスで各ディストリのrootfsにアクセスできる機能が追加されたがchmodし直しは変わらんしWSL内のmountも正しく反映される、浅いパスぐらいしか利点を感じない どうやってそんなの見つけるん?と思ったらエクスプローラーにペンギンがいやがった >>636
お、マジか。どういう実装なんだろう?
俺が前思っていたのはWindowsからはそうやってアクセスできる
内部的には(WSLレイヤーを介さずに)sambaプロトコルで
アクセスしているかのように見せかけるって方法で、
chmodに関しても設定でsamba相当の事ができるようにすれば
Windowsからsamba経由でアクセスしてるのと変わらない
実用性になるだろうって思ってた >>636
一応言っておくと、
利点は遅くてLinuxファイルシステムと完全な互換性がないdrvfsではなく
速くて互換性が高いlxfsに置いたファイルをWindows上から直接修正できること
drvfsとは違い、ディスク上のファイルを直接参照するのではなく
\\wslという仮想的なファイルシステム経由でアクセスするので
Windows上からのアクセスは遅くなるものの、
設計的にはchmodの問題などを回避できる余地がある
ってところかな >>640
Microsoft本気だな
Macに移ったユーザを取り戻せる Macに移ったのってWeb系のスクリプター連中が主でしょ
あのへんの層は大して金にならないからMSはそれほど重視してないだろう
とはいえこのままだとWinがクラウド開発に向かないゴミのレッテルを貼られて稼ぎ頭のエンタープライズまで逃げる恐れがあったから、
そうなる前に開発者離れを食い止めたいんだろうな Msをクラウドにシフトさせた現CEOも優秀だし、オープンソースの徹底化も英断だったんだなって。 いやAzureだけは擁護できないわ
MSの客層的にWinのVMさえちゃんと動けば儲かるのはわかるけど、
マネージドサービスの品質があまりにも低すぎる
真面目にやる気ないんならお願いだからホスティング以外は全部撤退して開発環境だけ作っててほしい >>646
お前が擁護しようがしまいが、
AzureではLinuxも動くし、AWSの次に使われてる
クラウドであることは否定できない
https://japan.zdnet.com/article/35123218/ >>640
この兼ね合いでバックグラウンドプロセスが無い状態でWSLコンソール全部閉じてもkill -9 -- -1してもinitが終了しなくなったんでwsl.conf弄るときはwsl --terminateするなり忘れずにな 今はwslのフォルダにあるファイルを作るとアクセス権限が000のファイルになってしまうけど、Windows 10 version 1903で変更されるんだろうか。 そういうわけじゃない
9Pサーバ使ってアクセスするかたち 直で触るんじゃないんだろう。
串を経由するようなもんだ この仕組は俺も前に考えたんだよね。
実装大変そうだからやらなかったけど。
そんとき、こういうアイデアはあるけど
MSは実装しないだろうなって思ってた。
だからやったたこと驚いた。
最近のMSはすごいよ
正しいことをちゃんとやる 俺はなんとも思わんが
そのチョイと癇に触るような上からの物言いはやめたほうがいいと思うぞ いるいる
後出しジャンケンであーこれ俺が考えてたやつだわーって言う奴 本当に考えていたならギフハブに12H以内に公開してみたまえ アイディアだけならだれでも思いつく。責任ある立場の人が相応のコストをかけて実現できるかどうかに意味がある。 別に、そのアイデアの実装が複数できていてもいい。
OSSならば、どちらかが淘汰されるか、
どちらも良くて、途中で方向性が変われば、
また違うソフトウェアとして、生き延びていくだけ。
要するに、アイデアを実際に実装するかどうかだ。
実装しなければ、なにもない。 そもそもWindows上にLinuxを共存させようと思った時点でファイルの見せ方について検討して当たり前でしょ。
「自分が最初に思いついた」とか、ネタなら面白くないし、本気ならヤバイ。心の病気だよ。 >>667
NT4の時代からService for Unix があったから
今から20年前にMicrosoftは実装してたんだけどね
(Linux互換ではなかったけど)。
>>658
の彼はいつ考え付いたんだろうね。 あー、SFU限定でファイルパスの大文字小文字を別物扱いできるようにするにはレジストリをいじるとかなんとかあったの思い出した。なつい。 >>669
ですね。ただ、大文字小文字で別物扱いがいいのか今でもよくわかりません。
昔は日本語ファイル名なんて考えられなかったし。 FUSEの逆をやるのかと思ったが、それも違うのか。
読み書き自体はブリッジ経由で稼動中のWSLにやらせるので、動作していないWSLのファイルは読み書きできない。
逆に、WSL側が関知しない形で配下のファイルを読み書きされる事もないから、OS非稼動時に他の環境からパーティションを勝手に読み書きされた時に発生するような不具合も原理上ない、と。
多少のオーバーヘッドは発生するにせよ、利便性と安全性を両立できるなら歓迎だな。グッジョブと言わざるを得ない。 ファイル自体はWSLでもOSが管理してるわけだし、
Linuxでも別プロセスが勝手に書き換えることはあるんだから
WSL稼働時しか修正できない理由はないと思うけどね WSL環境から読み書きするファイルも最終的にはWindowsの管理下にあるが、これまではWindows側からWSL配下のファイルを読み書きした際はWSL上で動作するLinux環境側が関知できないまま書き換わり、最悪では破損する危険があった。
ブリッジを介し、WSL自身を経由してWindows側から安全に読み書きできる手段が構築されたのが今回。以前と同じではない。 AppDataにあるものを直接書き換えるのはNGのままだよ。 >>673
> WSL上で動作するLinux環境側が関知できないまま書き換わり
どういうこと? WSLはOSじゃないんだけど?
OSはWindowsそのもの。Linux環境なんてものはない。
これまで壊れていたのは、Windowsアプリが、WSL用に追加している
ファイルのメタ情報を考慮してないからだよ。保存した時に抜け落ちる。
9Pサーバー経由にすることでメタ情報を上手く保護している 「Linuxでも別プロセスが勝手に書き換えることはある」(=それで支障が発生する)とか眠い事言ってる奴が、他人を詰問する滑稽さ。 そのメタ情報は、WSL上のLinuxカーネル相当分とファイルサブシステムを経由することで、適切に保持される。
そのためのブリッジを設えたのが今回。
あと「WSLはOSじゃない」の下りとかまあ何もかも浅くてデタラメなので、小学校からやり直せ。 よくわかんないんだけど、Windows側のテキストエディタ使ってLinux側のファイルをガンガン変更してもOKになったりしたって事? >>678
\\wsl$\ディストリ名\〜 というUNCパスでアクセスすればね。
users\appdata以下を直で弄ったら、これまでと同様にぶっ壊れる Windows側からの操作は動作中のWSL(Linux)環境経由で読み書きするので、Linux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱いとなり、
オフライン中に別環境からパーティションを半端に弄られたり、あるいは動作中に介入されるような不味い事にはならない。
まあ「WSL稼働時しか修正できない理由はないと思うけどね」とか言い切っちゃってるアホには、ちょっと難しかったかな。 とりあえず、ダブスラのSambaみてえなパス構成でアクセスすりゃあサブシステム側のお目通りかなって安心安全な改変ができるってことやろぉ よく分からんがWSLはOSじゃないっていいたいだけちゃうんかと
毎回、WSLはOSじゃないけどWSL上で動作するLinuxプログラムの実行環境が〜
とか言わないといかんのか? >>676
お前理解してないんじゃね?
Linuxでも別プロセスがファイルを書き換えることはあるよ。当たり前。
それでアプリレベルで支障が出たとしても、ファイルシステムが壊れるわけじゃないんだよ。
支障のレベルをお前わかってないね。 >>680
> オフライン中に別環境からパーティションを半端に弄られたり、あるいは動作中に介入されるような不味い事にはならない。
オフライン中に別環境からパーティションを半端に弄られると
Linuxは壊れるんか?
つまり別ディスクから起動して書き換えるってことに相当するんだが
それでファイルシステムが壊れることはないだろ
だいたいWSLでは「パーティションをいじる」ことはできない。
パーティションを管理してるのはOS(Windows)なんだから
すこしWSLのファイル管理を勉強したほうが良いよ。
LinuxじゃないんだからWSLがデバイスを直接管理したりしてないの >>682
> 毎回、WSLはOSじゃないけどWSL上で動作するLinuxプログラムの実行環境が〜
Linuxプログラムの実行環境なんてのも存在しない。仮想マシンじゃあるまいし。
単にLinuxのシステムコールをWindowsのカーネルAPIに置き換えてるだけ
カーネルから見れば、LinuxアプリもWindowsアプリも同じ環境で動作しているように見える。 連投粘着ウザいよ
そんなに言いたいならTripでもつけてやってよ
別に論破する必要ないから、本屋でも行って1000年ROMってろ(ハナホジーでいいし >>684
>オフライン中に別環境からパーティションを半端に弄られると
>Linuxは壊れるんか?
オンライン中に別システムからちょっかい出されたら壊れるだろそりゃ
壊れないケースもあるだろうけどさ 編集でなくてrobocopyとかxcopyで
%userprofile% を別のディスクにバックアップしても壊れるんやろか? WSL では、Windows 側のsjis のファイル名が、
Linux 側で見ると、自動的に、UTF-8 に変換されるのが、すごい! もともとNTFSはUTF-16で、api使うときにシステムロケールに変換してるから、その延長でしょう。 >>689
> オンライン中に別システムからちょっかい出されたら壊れるだろそりゃ
だから別システムってなんだよ?
WSLのアプリはNTカーネル上の1プロセス。
単なる別プロセスでしかないんだが。
えとさぁ、WSL用の別のOSがいて、そっちがWindowsの制御外から
デバイスごと管理してるわけじゃないんだぞ?わかってんのか? >>691
Windowsはファイル名をUTF-16で管理してるのだから
UTF-8と相互変換するのは簡単 改行と引用ウザイ
引用マウントしたいならふたばでも行ってくれ
其れかいっそブログでも書いてここに貼っとけばエエやん。論争大好きマンなの? はい。論争大好きここでマウント取りたいマンですよ? しかし考えてみたら凄いことだよな。
Windowsで普通にLinuxソフトが動くもんな。 ExplorerでShell芸が輝くわぁ…
ネイティブでウィンドウシステムサポートしたら、ユーティリティ系でもなければデスクトップ環境系のLinuxの需要下がるよな
まあそれでもxubuntuとかお古PCに入れるんだろうけど。 >>693
別システムは別システムだよ
なんでWindows配下のプロセスの話になるんだよ >>701
やっぱりWSLが別システムだって思ってんのか?
同じシステム上で動いていて、単に使ってるAPIが違うだけだぞ
その証拠にタスクマネージャーで見ると、WSLで動いているプロセスが
Windowsプロセスと同じように見える
ファイルはWindows(というかNTカーネル)が管理していて
どちらからロックを掛けても、同じようにロックが掛かる
WSLにドライバは存在せず、Windowsと同じドライバが管理してる
ファイルシステムだってそう。WindowsだろうがWSLだろうが
共通のドライバによって管理されてる。
だからどちらからどのタイミングで使ってもファイルシステムが壊れることはない
Windowsから触って壊れるのはファイルシステムではなくWSL上のメタデータが保存されないってだけ
ファイルシステムからみれば壊れているわけじゃない WSLとか関係なくない
DBとかでもデータファイル直でいじらんだろ >>702
なんでWSLの話だと思い込んでるのかなあ。 >>703
それは全く別の話。
WSL起動中でないと書き込みができないから安全とか
意味不明なことを言ってるやつがいる。
(WSLが別システムだから?意味不明w)
こっちは書き込みの安全性についてWSL起動中かどうかは関係ないといってる。
直接弄った時の安全性は、WSLの起動とは関係ないだろ? WSL起動中でないと書き込みができないのは
ファイルが壊れるとか別システム(笑)とかじゃなくて、
ストアアプリでファイルはそのアプリ用に隔離されてるから
直接ファイルを弄ることはセキュリティポリシーに反するからだろう
ファイル自体は同じOSが管理してるんだから壊れることはない >>680の何が間違ってるのか理解できてないようだから書いておくと
> Windows側からの操作は動作中のWSL(Linux)環境経由で読み書きするので、・・・(1)
> Linux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱いとなり、・・・(2)
この(1)が全く関係ない。
(2)のLinux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱い
になるのは、WSL(Linuxではない)環境経由だろうが、WSL環境以外だろうが同じ。
WSL環境以外から書き込んでも、(2)と同じ扱いになる。
だから(1)は全く関係ない。 WSL側はWindows側の挙動を知りようがないから、appdata以下を直で弄られてもWSL上のLinux環境からは察知できず、メタ情報にも齟齬が発生する。
NTFS上のファイルとしては無事でも、WSL上のLinux環境からは破綻してしまっていたのがこれまで。
19H1ではWindows側にブリッジを作り、\\wsl$〜というUNCパスを使えば書き込み処理が起動中のWSL経由で行われ、WSL上のLinux環境からも関知される。
「実際の読み書きは土台のWindowsがやっているのだからファイルやメタ情報が壊れる訳がない」と繰り返しているアホは、この構造を理解できていない。
構造を理解できていないために、支障なくアクセスするためにはWSL環境が起動していなければならない理由もできていない訳だ。
無知で無能なくせに、やたらと攻撃的でマウント気質。まあ控え目に言ってクズ野郎ですな。
こちらとしても手加減する理由がないので、思う存分叩き伏せられる。 環境とかシステムって単語使うとまた噛みつかれるで
厳密君の言葉尻チェックうるさすぎ >>709
なんでいちいち関係ない話を付け加えるんだ?
> WSL側はWindows側の挙動を知りようがないから、appdata以下を直で弄られてもWSL上のLinux環境からは察知できず
さも検知できれば大丈夫みたいな言い方をしてるけど、検知の有無は関係ない
そもそも(ファイル更新検知のためのAPIを使わない限り)ファイルの更新なんか検知しないのが普通
> メタ情報にも齟齬が発生する。
最初からこれが原因だって言ってる。Windowsアプリから保存すると、
(WSL用のメタデータを考慮してないほぼすべてのアプリは)
ファイル保存時にメタ情報が抜け落ちる。それだけでいい話
> 「実際の読み書きは土台のWindowsがやっているのだからファイルやメタ情報が壊れる訳がない」と繰り返しているアホは
誰もそんなこと言ってない。お前が
> オフライン中に別環境からパーティションを半端に弄られたり、
とか意味不明なことを言ってるんだろ。パーティション関係ない。オフライン関係ない。別環境なんてものはない
俺は>>675の時点でちゃんと以下のように言ってる。
> これまで壊れていたのは、Windowsアプリが、WSL用に追加している
> ファイルのメタ情報を考慮してないからだよ。保存した時に抜け落ちる。
> 支障なくアクセスするためにはWSL環境が起動していなければならない理由もできていない訳だ。
WSL環境が起動してないなければならない理由をお前は何も言ってない。
メタデータを保存するだけならば、WSL経由にする必要はない。 WSLのシンボリックリンクをデスクトップアプリのテキストエディタなどで開けばただのテキストファイルだし。 >>714
ディレクトリ配下を再帰検索する野良アプリを使っている人は要注意かも。
名前がドットから始まるターゲットをディレクトリ扱いする間違った実装してたらアウト。 なんでWindowsからいじっただけでEAまで飛ぶのかよくわからんのだが >>717
Linux側のi-nodeに同期させる仕組みがないからでしょ。パフォーマンスが犠牲になる実装を避けるのは当然。 >>717
メモ帳みたいに同じファイルに上書きするんなら消えない
VSCodeとか上書き操作しても実際には別ファイルへの書き出し→元ファイルと入れ替えってやるから消える
>>716
今までエクスプローラー以外から作れなかったわけじゃないのにそんな馬鹿な実装アプリ使ってたら既に問題出てるでしょ >>717
保存する時に、別名で作成→古いファイルを消す→名前を変更する
ということをやってるから。
一応安全な手段ではあるんだよ。
これだと途中でエラーが起きてもデータが消える可能性少ない
データ保存に比べて一瞬で終わる名前の変更だけできればいいからね Linux側のi-node(笑)
またLinux側とかありもしないものを持ち出してる
知識が浅いと駄目だね ■ このスレッドは過去ログ倉庫に格納されています