【Bash】Windows Subsystem for Linux【WSL】4

Install the Windows Subsystem for Linux
https://docs.microsoft.com/en-us/windows/wsl/install-win10

前スレ
【Bash】Windows Subsystem for Linux【Ubuntu】3
http://mao.2ch.net/test/read.cgi/linux/1528141781/

貼れと言われた気がした

【田】Windows10のダメな点

・個人情報を勝手にネットに垂れ流す
・診断データと使用状況データをMicrosoftに送信する機能をレジストリでオフにしてもなお8時間で4000回、93つの異なるIPのMicrosoftサーバへデータが送信されている
・エロファイルを持っている場合はそれも全て晒される
・間違ってロリファイルを持っていた場合はネットに繋いでいるだけで警察が来る
・死ぬほどUIがダサく異様に使いづらい
・ダサい上に抑揚のないフラットデザインのため、どのウィンドゥが手前で奥なのかわからない
・かつてあった多くの機能の半分以上をカットし、使わない機能をてんこ盛りにしたデブOS
・起動が超遅い。見かけ上早く起動したように見えるだけでほとんどのソフトを読み込んでいない
・スリープ復帰速度はほとんど変わらず
・ファイル圧縮・解凍速度も遅いまま。フリーウェアの圧縮・解凍ツール使ったほうが200％以上高速化する
・ファイルコピー速度が壊滅的に遅い。フリーウェアの高速コピーツール使ったほうが400％は速い
・メモリ使用量が馬鹿みたいに多い。初期は少なく見えるが使えば使うほど多くなる
・タブレットでも動くように設計されているが、利便性もデザインもiPadの足元にも及ばないゴミ
・標準ブラウザにEdgeとかいうゴミを採用。機能が少なすぎる上におそろしく遅くて使い物にならない
・無料のセキュリティソフトと称する重いウィルスソフトが多数憑依している
・仮想デスクトップと称するゴミを搭載。フリーウェアの仮想デスクトップソフトの半分の利便性もない。
・Win８で削除したスタートボタンを恥を忍んで復活させた
・しかしスタートメニューにまつたくいらんメトロや宣伝がゴチャゴチャついて無駄に肥大化、邪魔。機能性がない
・非アクティブウィンドウもスクロール可とかいう、昔からできるような機能を大げさに宣伝
・タッチパネルとして使いやすいUIとして喧伝しているが、デスクトップPCで画面の汚れるタッチ操作を行うのはよほどの馬鹿だけ
・ダサくて見づらいゴミフォント「游書体」がデフォルト設定
・ほとんど反応しないゴミ丸出しの音声認識アシスタントCortana搭載。画面に向かって話しかけているぼっち野郎の姿はバカそのものｗｗｗｗ

IME連携はMicrosoftが仕事したらいいんじゃないの。

日本マイクロソフトに何を期待しろと

>>586
たったとShiftJISをデフォルトから捨てて、UTF-8に変更しろっていう話。

ソート順が変わって大騒ぎになる。に一票

5ch(2ch)がUTF-8に対応するのが先か
どっちにしても過去と決別だな

MsDOSがs-jisに依存している以上難しいだろ
filesystem関係、kernel関係とか、マルチプラットフォームへのバグフィックス諸々考えると絶対やらないわ。少なくともやりたくないわ

64ビットじゃ16ビットのDOSなんてもう動かないぞ？
DOSはDOSで放置でいいだろ。何言ってんの？

AndroidのFuchsiaみたいに既存路線を捨てて新しいOSになるしかないんじゃないかな。

今更感あるけどとりあえず日本語(UTF-8)みたいなロケールを追加して人柱募ればいいのに
まあUTF-16LEでUnicode系APIを整備しちゃったのが悪いんだろうけど

.NETはUnicode前提で実装されてたんだよな。もう20年前か・・・
だからMSは何もしなかったわけでもない。

いくらテストしたってもこれ以上弄り回すとまたバグ祭りになるに決まってる。

おっと調べたら既にあるのねhttps://i.imgur.com/knbAPYN.png

>>591
業務用のシステムではLinuxですらSJISでなんとかしろと言われて
各社苦労してんのに、WindowsがSJIS捨てたら少なくともMSKK消滅だろ

>>595
それもDOSやWindowsのせいだろ。

SJISは改元後の合字に対応しないとMSは言ってるね

>>596
韓国人じゃあるまいし、誰が悪いかを言いつのったって現状は変わらないよ？

>>594
これでシステムはUTF-8になる
アプリのLive5chとかはunicodeサポートされてないのでメニューとかが文字化けした
ChromeやFirefoxは問題なかった

>>598
じゃあどうする？
代案も示さないようじゃ反論にもならない。

>>600
SJIS続行。

Windowsと関係ないやん。
Windowsなんてとっくにネイティブ文字コードがUnicodeになってるのに
アプリが無理やりレガシーな文字コード使ってるだけだろ

地域の設定にutf-8を使用というチェックボックスがあったんだけど、いつからかutf-8がデフォになって、ユニコード対応でないプログラムの言語という設定が出来てる。
メモ帳のデフォがutf-8になったあたりかもしれない。

C++20でchar8_tが入るので、utf-8サポートを標準に従った状態でサポートできるようになるよ。
なんでここまで引っ張ったんだろな。

いまやってるsjisの話がwslにどうつながるんですか

つなげてみせようホトトギス。

>>605
wslので叩くwinAPIのフレーバーが増えるんじゃない？
ネイティブ互換性が増えるとか

GNU Octave をubuntu 18.04 (wsl)とVcXsrvで使っていて、qt + opengl のグラフィックスが動作しなかったが、-wglから-nowgl にして、LIBGL_ALWAYS _INDIRECT を設定しないようにしたら、表示するようになった。
しかし、他のソフトウェア(gnuplot のwxt terminal )でwarning がでるようになった。
でも、warning だから、我慢しよう。

>>605
強引にこじつけるとWindowsとWSLで協調動作を行うプロセス間にWindowsサブシステム側の言語設定を無理無く馴染ませる事が出来るかという話
当然だがWSL上で動くプロセスはあくまでLinuxそのままだから言語設定はLANGかロカール系環境変数に依存するという部分は変えられない

ありがとう。
Windows でもMsys2入れて、winptyコンソールアプリをつかっている私にはあんまり関係ないことだということがわかりました。

そもそもLinuxはASCII互換の文字コードしか扱えないので
SJISやUTF-16などに対応するのは事実上無理だよ。
これはLinux側（カーネル及びアプリ）の制限

ほとんど使われないけどwcharなPOSIX関数はある
Windowsは逆にこっちを明示的に使うようにして従来のAPIはロケール依存のまま残したんだけど

>>611
日本語にSHIFT_JISを採用したUNIX系でOSもあったしSHIFT_JISについてはアプリが頑張ればいいだけでLinuxカーネルの問題は無いだろう

たしか、Solarisは日本語ロケールがSJISだったはず。

Solarisの日本語デフォはEUCじゃなかったっけ？
HP-UXはSJISだったね

Linuxこんな理由らしい
ttp://www.ossforum.jp/jossfiles/Linux_SJIS_Support.pdf

>新しい技術への挑戦を尊ぶLinuxの開発技術者

蓄積されたデータを継承・発展させていくことだって、新しい技術への挑戦だろうになあ。
当時のOSS界隈はマイクロソフトをFUDを多用するとか言ってたけど、
おまえらのやってることも同じじゃねーかという。

>>616
FUDを多用するというFUDだろ。

こんなとこでケチをつけてるだけの人生よりよっぽど有意義だな

>>615
カタカナの長音記号もまともに扱えていない文書を堂々と掲げられる心意気に敬服

私の環境では、X サーバーを-nowglで立ち上げないとグラフィックスで不具合が生じることがあった。たぶん、環境依存たと思う。

環境依存てすか。

-wgl はwindowsのopenglのハードウェアアクセラレーションを使うのでそう書いた。でも、確証はないので、多分をつけた。

Windows 2000ぐらいに小さくて軽いWindows 10に
WSLだけ入れたいわ。
それ以外の付属モノは、全部要らん。

WinPEとか？

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
> テキストをテキストのまま色付けや段落分けできる構造化エディタだったんだよなあ

無理やで？
勝手に色がつくことは可能だが、
ユーザーが自由自在に色を付けることはできない

>>631
rtfがそんな感じ

そりゃテキストにメタ情報入れればできるやろな

絵文字には色を付けられるのに
変なの

文句はアンテナ○○○に言っとくれ♪

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の問題などを回避できる余地がある

ってところかな

What’s new for WSL in Windows 10 version 1903?
https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/

>>640
Microsoft本気だな
Macに移ったユーザを取り戻せる

>>641
そんなことは気にしてない。

MS「Mac？ああ、マクドのことやな。」

Macに移ったのってWeb系のスクリプター連中が主でしょ
あのへんの層は大して金にならないからMSはそれほど重視してないだろう
とはいえこのままだとWinがクラウド開発に向かないゴミのレッテルを貼られて稼ぎ頭のエンタープライズまで逃げる恐れがあったから、
そうなる前に開発者離れを食い止めたいんだろうな

Msをクラウドにシフトさせた現CEOも優秀だし、オープンソースの徹底化も英断だったんだなって。

いやAzureだけは擁護できないわ
MSの客層的にWinのVMさえちゃんと動けば儲かるのはわかるけど、
マネージドサービスの品質があまりにも低すぎる
真面目にやる気ないんならお願いだからホスティング以外は全部撤退して開発環境だけ作っててほしい

>>646
お前が擁護しようがしまいが、
AzureではLinuxも動くし、AWSの次に使われてる
クラウドであることは否定できない

https://japan.zdnet.com/article/35123218/

うちはまだ1809だな。

>>640
この兼ね合いでバックグラウンドプロセスが無い状態でWSLコンソール全部閉じてもkill -9 -- -1してもinitが終了しなくなったんでwsl.conf弄るときはwsl --terminateするなり忘れずにな

今はwslのフォルダにあるファイルを作るとアクセス権限が000のファイルになってしまうけど、Windows 10 version 1903で変更されるんだろうか。

そういうわけじゃない
9Pサーバ使ってアクセスするかたち

直で触るんじゃないんだろう。
串を経由するようなもんだ

なるほどSambaみたいなもんかね。

fuseじゃねえの

FTPだろ

NFSだろ

DOKANだろ

この仕組は俺も前に考えたんだよね。
実装大変そうだからやらなかったけど。

そんとき、こういうアイデアはあるけど
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がデバイスを直接管理したりしてないの