[過去ログ] 【Bash】Windows Subsystem for Linux【WSL】5 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
854
(1): 2019/06/14(金)07:36 ID:SFGaLfty(1/3) AAS
>>852
遅くなってるけど検討中
外部リンク:docs.microsoft.com
855
(1): 2019/06/14(金)08:40 ID:NaM43hJg(1/5) AAS
WSL1同様、systemdとかサービスの仕組みはないな。
まだinitが初めに動く感じになってる。
856
(1): 2019/06/14(金)09:50 ID:LDJUclfk(1/5) AAS
>>855
いい加減、設計思想を理解したほうが良いぞ
WindowsというOSでLinux用バイナリを動かすのがWSLだ
OSはあくまでWindows。
systemdに相当するものはWindowsのサービスだよ
できるのかしらんが、そこに登録すれば形になるだろう。
WSLはカーネル相当のものしか提供しないんだからsystemdが含まれることはない
857
(1): 2019/06/14(金)10:35 ID:eE+2hc0n(1) AAS
>>854
ありがとう、やはり無印のWSLより遅くなってるか。

自分の懸念点は、以前に書いた >>686 にまとまってる。
要するに、OS間のやり取りが遅いなら、通常のVMに比べてほとんどメリットがないし、
逆にやり取りが速いなら、そのソケットを通常のVMに導入したほうが良いというもの。

まあしばらくは様子見だな。
858: 2019/06/14(金)11:18 ID:LDJUclfk(2/5) AAS
>>857
OS間のファイルアクセスが遅くなることで
どういう問題があると思ってる?
859: 2019/06/14(金)11:53 ID:LDJUclfk(3/5) AAS
> 要するに、OS間のやり取りが遅いなら、通常のVMに比べてほとんどメリットがないし、

VMでLinuxを動かすのに比べて、Windowsと統合されているとうのがメリット
WSL独自のinitプロセスに9Pサーバーが組み込まれており、どんなディストリであっても
設定不要でOS間のファイルアクセスが可能になってる。

これと同じことをしたいなら、
「あなたが自分でVM上のLinuxにsamba等をセットアップしてWindowsと統合させてください」という話

> 逆にやり取りが速いなら、そのソケットを通常のVMに導入したほうが良いというもの。

もともとVMのLinuxはUNIXソケットを使用できていた。WindowsがUNIXソケットに対応したので
「ソケットを通常のVMに導入したほうが良い」はすでに実現されている。
省9
860: 2019/06/14(金)11:53 ID:LDJUclfk(4/5) AAS
× それにWindowsでsambaが動いてるのでWSLでsambaを動かすと競合する。
○それにWindowsでsambaが動いてるのでVMのLinuxでsambaを動かすと競合する。
861: 2019/06/14(金)11:59 ID:LDJUclfk(5/5) AAS
WSL2と同じことをVMでやるならば、

1. Linux用の9Pサーバー、もしくは(samba以外の)ファイル共有サーバーを用意する
2. WindowsからUNCでアクセスできるようなドライバを作成する
3. Linux上のファイル共有サーバーとWindowsを連携させる

最低でもこの3つが必要
862: 2019/06/14(金)12:09 ID:/zZ9P1yP(1/2) AAS
WSL2を使った場合とVMを使った場合

・パフォーマンス・・・どちらでも変わらない
・利便性・・WSL2の方が良い(セットアップ不要、エクスプローラと統合、コマンドを直接実行できる)

であれば、WSL2を使ったほうが良いってことにならんか?常識で考えて
863: 2019/06/14(金)12:10 ID:/zZ9P1yP(2/2) AAS
WSL1ではVMを使ったほうがパフォーマンスが高いから
VMを使ったほうが良いというユーザーが一定数いるけど
864
(2): 2019/06/14(金)12:32 ID:3/ZJQfp2(1/2) AAS
WSLの機能しか入ってないinitだからかinittabも見てないっぽいしなぁ
自動起動は.bash_profileからSUID付けたシェルスクリプトでも叩くのがシンプルなのかな
865: 2019/06/14(金)12:37 ID:Hc+IuMb9(1/26) AAS
>>864
VMじゃなくて、WindowsにLinuxが統合されたと考えるのが正しいんだよ。
866: 2019/06/14(金)12:38 ID:Hc+IuMb9(2/26) AAS
Windows起動 = Linux起動
だから自動起動はWindowsの起動時にWindowsの機能を使って行う。
867: 2019/06/14(金)12:39 ID:J8C5ipsR(1/25) AAS
正直あまりメリットを見いだせないなこれ…
使い勝手はWSLとそう違いがあるわけでないのだけど仮想化するなら意味ない気がする
Docker動くのもHyperV上では既にネイティブとは言えなくなってしまったしssh経由の操作と変わらない
ポータビリティ考慮するならむしろVMの方がいいとすら言える
868
(1): 2019/06/14(金)12:43 ID:Hc+IuMb9(3/26) AAS
WSLの目的は利便性だから
どうも実装に目が行ってる人ばかりいるけど、
MacでBSDコマンドが実行できるのと同じ感覚で
WindowsでLinuxコマンドが実行できるという事実が重要
869
(1): 2019/06/14(金)12:45 ID:J8C5ipsR(2/25) AAS
Cygwinとか使ってる人のための機能としては文句なしだろうけど
Linuxの利点殺してるよねこの汎用性のなさは
RDPサーバー目当てで環境変えようと思ったけどLinuxの代替えにはちょっと辛そう
870
(1): 2019/06/14(金)12:45 ID:Hc+IuMb9(4/26) AAS
そうか。WSL2では、SSHも利用せずにLinuxの環境にアクセスできるんだな
871
(1): 2019/06/14(金)12:46 ID:J8C5ipsR(3/25) AAS
>>868
Windows側を直接操作できるわけじゃないから全然ちゃうと思う
872: 2019/06/14(金)12:46 ID:Hc+IuMb9(5/26) AAS
>>869
macOSの代替って考えたほうが良いよ。
macOSでもX使ってないからね。
X使う人は少数
873: 2019/06/14(金)12:48 ID:J8C5ipsR(4/25) AAS
>>870
ターミナルがWindowsで動くのは大した利点ではないよ
GUIまで統合できるなら話は別だけど
874
(1): 2019/06/14(金)12:48 ID:k9Ur5WIJ(1) AAS
>>856
そりゃそうだけど
ディストリ側が提供してくれんとsystemdに依存してるソフトもあるんだから無いと困るだろ
875
(1): 2019/06/14(金)12:49 ID:Hc+IuMb9(6/26) AAS
>>871
Windowsのコマンドを実行できるんだから、
Windowsのコマンドでできることは、WSLからでも実行できるよ

あんたが言ってることは、
「コマンドプロンプトからWindows側を直接操作できるわけじゃない」と
言ってるのとほぼ同義でしょ?
876: 2019/06/14(金)12:49 ID:Hc+IuMb9(7/26) AAS
>>874
> ディストリ側が提供してくれんとsystemdに依存してるソフトもあるんだから無いと困るだろ

systemdに依存してるソフトってなに?
877
(1): 2019/06/14(金)12:50 ID:rLtj6Yk3(1) AAS
WSLならともかくWSL2がmacOSの代替とか片腹痛いわ
878: 2019/06/14(金)12:50 ID:Hc+IuMb9(8/26) AAS
>>877
理由を書かないとか、片腹痛いわw
879
(1): 2019/06/14(金)12:52 ID:Hc+IuMb9(9/26) AAS
WSLもしくはWSL2によって
WindowsがmacOSやLinuxのターミナル相当の機能を実現したってことなんだよね。
GUIに関しては、もとからmacOSやLinux相当のGUI機能を持ってるわけなんだから

足りなかったターミナル相当の機能が強化された
880
(1): 2019/06/14(金)12:54 ID:J8C5ipsR(5/25) AAS
>>875
いや逆ができないでしょ…
881
(1): 2019/06/14(金)12:57 ID:Hc+IuMb9(10/26) AAS
>>880
コマンドプロンプトからWSL上のLinuxのコマンドを実行できるし、
WSL上のLinuxからWindows上コマンドを実行できる

Windows 10のコマンドプロンプトからWSL上のLinuxコマンドを呼び出す(バージョン1803対応版)
外部リンク[html]:www.atmarkit.co.jp

Windows 10のLinux互換環境WSLからコマンドプロンプトのプログラムを呼び出す(バージョン1803対応版)
外部リンク[html]:www.atmarkit.co.jp
882: 2019/06/14(金)12:58 ID:J8C5ipsR(6/25) AAS
>>879
GUIを言うならターミナルだけ実現しても意味ないよ
せめてOSXみたいにXぐらい統合しないと
そもそもssh程度で十分なものを実装してもメリットになってないよ
883
(1): 2019/06/14(金)12:59 ID:Hc+IuMb9(11/26) AAS
> GUIを言うならターミナルだけ実現しても意味ないよ
> せめてOSXみたいにXぐらい統合しないと

OSXってXと統合されてないぞw
884
(1): 2019/06/14(金)13:00 ID:J8C5ipsR(7/25) AAS
>>881
だからこれじゃcygwinと変わらないよ…
何を言ってるんだこの人は
885: 2019/06/14(金)13:00 ID:JmlKQfIU(1) AAS
GUIの使用まで考えるなら、対応toolbox入れたVMのほうが描画速いから既存のVMに利点見出す人もいるだろうね
emacs程度の描画なら変わらないけど、vscodeくらいのリッチさだと表示のもたつきがわかっちゃう
hyper-vでもxrdp使うスクリプト提供(元はユーザ作成)してるだけだったし、toolbox相当作ってくれるなんて期待できないか

windows版vscodeのremote-containersがwindows版docker依存なので、WSL2側にdocker入れても
remote-ssh経由して使わないといけないのがとても面倒
886
(1): 2019/06/14(金)13:01 ID:J8C5ipsR(8/25) AAS
>>883

OSXのXserverはMacのGUIでX操作できるよ
887: 2019/06/14(金)13:04 ID:J8C5ipsR(9/25) AAS
WSL2に相当に期待してるのはわかったけども
普段Unix環境使ってる人からすると常用はちょっと無理じゃないかな
少なくともDocker以外はMacのがまだマシに見えるし

Dockerについてはパフォーマンス見る限りかなり良いみたいだけど
これもLinux実装を仮想化して動かしちゃうのならVMでいいんじゃないかなって感じ
888
(1): 2019/06/14(金)13:05 ID:Hc+IuMb9(12/26) AAS
>>884
> だからこれじゃcygwinと変わらないよ…

cygwinを不要にするためのWSLが作られたのに
cygwinと変わらないと言われても困るんだが(笑)

cygwinはLinuxじゃないので、Linuxのバイナリがそのまま動くことはない
OS付属ですら無い。Windowsが公式にcygwin相当の機能を
独自ディストリやcygwin専用バイナリを使うことなく、
本物のLinuxディストリを使えるようにするために作りました!って最初から公言してる

お前が勘違いしたんやろ?
889
(1): 2019/06/14(金)13:08 ID:J8C5ipsR(10/25) AAS
>>888
いやどう見てもそっちが勘違いしてるんだけど…
コマンドの利便性の話だし
890
(1): 2019/06/14(金)13:09 ID:Hc+IuMb9(13/26) AAS
>>886
用語滅茶苦茶で言いたいことがさっぱりわからんが

WindowsのXserver(VcXsrv)はWindowsのGUIでWSLのXクライアントをX操作できるよ
って言えば良いんか?
891
(1): 2019/06/14(金)13:10 ID:Hc+IuMb9(14/26) AAS
>>889

MS「cygwinと同じことをWindows標準で本物のLinuxを使ってできるようにしました!」
お前「cygwinと同じことしか出来ないやん」

ってことだろ?

お前「スーパーファミコンと同じことできるものを作りました!」っていうニュースを聞いて
「スーパーファミコンと同じことしか出来ないやん」って思うのか?
892
(2): 2019/06/14(金)13:12 ID:J8C5ipsR(11/25) AAS
普段Cygwin使ってないとわからないのかもしれないけど
fs構造がLinuxと分かれててWindows側の直接操作は難しいし
この時点でLinuxのWineと同じ問題を孕んでるんだよね
元がUnixなら同一環境なのでそもそもこの手の問題はない

そらまあまだ出たばかりだからこれから改善はするかも知れないけどね
現時点ではちょっとな
893
(1): 2019/06/14(金)13:16 ID:Hc+IuMb9(15/26) AAS
>>892
両方共UNCパスでアクセスすりゃいいやん?

WindowsのバッチファイルからUNCでWSL上のファイルを参照できるし、
WSLからもdrvfsでWindows上のファイルにアクセスできるやろ?

これはVMでは出来なかったこと
894
(1): 2019/06/14(金)13:17 ID:J8C5ipsR(12/25) AAS
>>890
VcXsrvですら細かい操作に対応がないので
Java経由で死ぬ事があったり

>>891
いやコマンドの利便性の話でしょ?
論点すり替わってるよ君
895
(3): 2019/06/14(金)13:20 ID:J8C5ipsR(13/25) AAS
>>892
うん、だからWineもUnixのPath使ってろって言ってるのと一緒だから
いくら統一してもプラットフォームの違いで固定パスの扱いそのものに
互換性の問題出るって話だよ
896: 2019/06/14(金)13:21 ID:J8C5ipsR(14/25) AAS
>>895>>893宛ね
897: 2019/06/14(金)13:23 ID:Hc+IuMb9(16/26) AAS
そういや1903にしてから試してなかったけど、

エクスプローラで \\wsl$\Ubuntu-18.04\home 以下や
dir コマンドで \\wsl$\Ubuntu-18.04\home とか普通に見れてるな
ファイルも開ける
898
(1): 2019/06/14(金)13:25 ID:Hc+IuMb9(17/26) AAS
>>895
シンボリックリンクで解決できる程度の話を問題視してるってこと?
899
(2): 2019/06/14(金)13:27 ID:Hc+IuMb9(18/26) AAS
>>894
コマンドの利便性の話だからGUIが云々って話はスレ違い
いい加減やめとけよ。MSは最初からWSLはGUIに対応するために作ってませんって言ってるんだから
900
(1): 2019/06/14(金)13:29 ID:J8C5ipsR(15/25) AAS
>>895
いやWindowsの特殊パスと文字コードとケースの話だけど

>>899
つまりコマンドはまだ不便だってことだね
901
(1): 2019/06/14(金)13:35 ID:Hc+IuMb9(19/26) AAS
>>900
バッチファイルからアクセスするときのパスと
WSLからアクセスするときのパスを
共通化してほしいってだけ?
902
(1): 2019/06/14(金)13:37 ID:J8C5ipsR(16/25) AAS
またズレたけど>>898>>899宛ね

GUI云々はそもそもターミナルの話の派生だから元から関係ないよ
ただMSがターゲットにしてないから別件な!ってそんな子供みたいな詭弁はちょっとどうかと思うよ
ユーザーにはそんなの関係ないんだから
903
(1): 2019/06/14(金)13:40 ID:Hc+IuMb9(20/26) AAS
>>902
だからお前は、
「スーパーファミコンと同じことをできるものを作りました!」っていうニュースを聞いて
「ユーザーには関係ない。プレステがしたいんや!」って言ってるのと同じって言ってるんだが。
904
(1): 2019/06/14(金)13:41 ID:J8C5ipsR(17/25) AAS
>>901
影響するのバッチだけじゃなくて全般だよ
「〜ってだけ?」と簡単に言ってるけどOSの根幹の話で根深いからねこれ
905
(1): 2019/06/14(金)13:48 ID:J8C5ipsR(18/25) AAS
>>903
ごめん何が言いたいのかわからない
コマンドの範囲が増えたって言ってもカーネルに近いほど動かなくなるわけだし
取り繕っても他のUnix統合できる環境と比べて別に便利というわけではないよね
Cygwin普通にうんこだし
906
(1): 2019/06/14(金)13:52 ID:Hc+IuMb9(21/26) AAS
>>904
根本的に勘違いしてないか?

WSL自体は単一のLinuxカーネルの機能であって、
ディレクトリ構造っていうのはWSLに含まれてない。

WSLっていうのは複数のディストリを入れられる。
そしてディレクトリ構造はディストリによって決めれている。
つまり、Ubuntuの/etcとDebianの/etcのパスは違うものでなければならない
Linuxで同じことをやるならばコンテナを使った状態

Linuxを使ったとしてもコンテナの外とコンテナの中のパスは
それぞれ独立しており、共通化することは出来ないんだよ
907
(1): 2019/06/14(金)13:54 ID:Hc+IuMb9(22/26) AAS
>>905
> コマンドの範囲が増えたって言ってもカーネルに近いほど動かなくなるわけだし

自分で答え言ってしまってるやんw
「カーネルに遠いほど動くって」

多くのコマンドはカーネルから遠いんだから動く
動くんだから便利だろ。
908
(2): 2019/06/14(金)13:54 ID:J8C5ipsR(19/25) AAS
レスを追っても何がいいたいのかわからないな
そもそも自分はコマンドの利便性が同じでUnixネイティブと比べて不便だろと言ってるだけで
機能がCygwinと同じなんてそんな酷いこと言ってないんだけど

Cygwin(うんこ)と同等の事ができるって言ってるだけじゃん!だからどうした!
ってそれつまり不便と認めてるってことだよね?
それならもうそれで話終わりだぞ?同意してるんだから
909
(1): 2019/06/14(金)13:57 ID:Hc+IuMb9(23/26) AAS
>>908
> レスを追っても何がいいたいのかわからないな
> そもそも自分はコマンドの利便性が同じでUnixネイティブと比べて不便だろと言ってるだけで

その不便っていうのが、不便っていうだけで、何が不便なのか書いてないから
何が言いたいのかわからないんだよ

パスの変換にwslpathコマンドを使わないのが行けないのが不便ってことなのか?
コマンドの実行にwslをつけないといけないのが不便ってことなのか?

これらが必要なのはWindowsとWSLをまたがるときだけで、
Windows内、もしくはWSL内にとどまってる場合には必要ないんだから
俺は、そんだけ(またがるときだけ)だろと思うだけなんだが?
省1
910
(1): 2019/06/14(金)14:00 ID:J8C5ipsR(20/25) AAS
>>906-907
また論点ずれてるよ
少なくともコマンドの利便性云々については
自分も中身で反論しちゃってるんだし、今更目的が違うから云々なんて回避は通用しないんじゃない?
結論出したくないのはわかるけど
911
(1): 2019/06/14(金)14:01 ID:J8C5ipsR(21/25) AAS
>>909
まあそれ全部不便だねうん
比較対象は別のUnix環境だから
912
(1): 2019/06/14(金)14:02 ID:Hc+IuMb9(24/26) AAS
>>908
> Cygwin(うんこ)と同等の事ができるって言ってるだけじゃん!だからどうした!
cygwinとの違いを言えばいいの?

- Linuxバイナリをそのまま動かすことができる
- cygwinは独自パッケージリポジトリなので、用意されてるパッケージが少ない。例えばtigコマンドがない
- cygwinは遅い。WSLの方が速い
- cygwinはMS公式サポートではない。
- cygwinはパッケージマネージャーがGUIベース
- cygwinはUbuntuでもDebianでもない
- cygwinはビルドする時のソースコードが違う。ビルドできるとは限らない。
省1
913
(1): 2019/06/14(金)14:02 ID:Hc+IuMb9(25/26) AAS
>>910
> また論点ずれてるよ
だからお前の論点をはっきりさせろって
お前が論点を言わないのに、論点を合わせられるわけ無いだろw
914: 2019/06/14(金)14:03 ID:SFGaLfty(2/3) AAS
>>864
タスクスケジューラーやスタートアップフォルダにショートカット入れて
PC起動時に適当なシェルスクリプトを実行するように設定しとけばいいのでは
wsl.exe -u root /etc/hoge.sh
915
(1): 2019/06/14(金)14:04 ID:Hc+IuMb9(26/26) AAS
>>911
> 比較対象は別のUnix環境だから

つまりスーパーファミコンを作りましたと言ってるのに
お前はプレステと比較してるってこと?w
916: 2019/06/14(金)14:11 ID:SFGaLfty(3/3) AAS
あぼーんだらけだわ
917
(1): 2019/06/14(金)14:15 ID:J8C5ipsR(22/25) AAS
>>912
出してる例(スーファミ云々)がそもそも君自分で相当に馬鹿にしてるよって話
例えもまともにできてないよ

スーファミと同じものを云々って、こっちはそんな事は言っていない

>>913
もう不毛すぎるからやめるけども、まずこのレスツリーの最初のレス読もう
コマンドの2環境間の使用の話で、そちらはMacでBSD環境のコマンド使うのと同じ感覚でと言ってるよね
コマンドラインでもシェルでも何でもそのまま呼び出せないという点だけでももう感覚違うよね
取り回しにいちいちcygpathやwine挟むのと一緒だから
918: 2019/06/14(金)14:18 ID:J8C5ipsR(23/25) AAS
>>915
その例え好きみたいだけど、もしかして上手いと思ってる ?
最初に言い出してるの君の時点で相当に墓穴掘ってると思うけど
919
(1): 2019/06/14(金)14:24 ID:J8C5ipsR(24/25) AAS
自分から比較して人のせいにし
自分で反論しておいてそれに反論されたら目的が違うとか無茶な回避し

不毛と思わない?
論点ずらしながら中身のない煽り合いでもしたいの?
920: 2019/06/14(金)14:26 ID:J8C5ipsR(25/25) AAS
ごめん>>919のレスなしで
謝ります
921: 2019/06/14(金)14:55 ID:R36bPVG+(1) AAS
伸びてると思ったら、なんだこれ
2人で無駄にやり合うなや…
922: 2019/06/14(金)15:43 ID:NaM43hJg(2/5) AAS
FUSEでマウントしたディレクトリをUNCパスでWindowsから参照出来るのかとやってみたが、
中身は空っぽだった。
FUSE自体は出来たがちょっと残念。
923: 2019/06/14(金)15:55 ID:hTK8l9es(1) AAS
WSL1ではディストリはカーネルにタッチできずMSから提供されたモジュールやドライバを組み込むだけしかできず
ユーザーもWSL環境はLinuxカーネル上で動作しておらず互換性も限定的だった事を意識して利用する必要があったが
WSL2ではディストリ側でカーネルソースやバイナリまでビルドして提供できるようになり
ユーザーもWSL2上ではホスト環境のWindowsとの親和性が増したVMを貫通したサポートドライバがあらかじめ組み込まれたLinuxディストリをVM上で実行しているという認識で利用できるので
仮にパフォーマンスが変わらないならディストリ/ユーザー双方にとって望ましいのはWSL2の実装だろう

何をギャーギャー喚いているのか知らんけど、マカーが不安症候群起こしてて酷いな
まあGNUユーザランドが広大な実行プラットフォーム得、それらがより安定しパフォーマンスを増してゆくことに、悪魔崇拝者どもが脅威と不安を覚えるのは無理もないか
924: 2019/06/14(金)16:46 ID:9kcqhJnG(1) AAS
発狂してるのはmac板荒らしてるエロ同人違法DL無職おじさんですよね
925: 2019/06/14(金)16:55 ID:twmeQRXI(1) AAS
なんだ、またマカーがWSLに嫉妬していたのか
926: 2019/06/14(金)16:58 ID:ZPIGBJUS(1) AAS
>>917
> コマンドラインでもシェルでも何でもそのまま呼び出せないという点だけでももう感覚違うよね

bashを起動すれば、BSD環境のコマンド使うのと全く同じだよ
Windows上のパスが違うけど、WSL環境だけでやればいいだけだし。
WSL環境の外に出る必要はもうなくなった。
927: 2019/06/14(金)18:08 ID:e9Nr40ab(1) AAS
有識者の人に質問。wsl2ってツインムスタングみいなイメージで正解?
928
(1): 2019/06/14(金)18:54 ID:IyPtv2eZ(1/2) AAS
>>850
MSが公開してるソース(外部リンク:thirdpartysource.microsoft.comから適当にモジュール作って読み込ませることはできるんだけど
zfsonlinuxはコンパイルが通らねえな
929
(2): 2019/06/14(金)20:56 ID:NaM43hJg(3/5) AAS
まだ、WSL2からWindowsのホスト環境(WSL1でいうlocalhost)にアクセスできないみたいだな・・・
Win側にXサーバー立ててXアプリ動かそうとしたけど、Xサーバーが見つからないから起動しない。
930: 2019/06/14(金)21:09 ID:2s8d8lP8(1) AAS
>929
IPアドレスが別になってるだけだろ?
そのことはすでに告知済み。現時点での制限としてよく知られている。

ポートフォワーディングで対応可能なんだから
そのうち対応するだろう
931
(1): 2019/06/14(金)21:20 ID:BFocZb+m(2/3) AAS
vncとかで乗り込めば良いんじゃないの?
932: 2019/06/14(金)21:26 ID:IyPtv2eZ(2/2) AAS
>>929
ちゃんとXサーバーをlocalhost以外からも接続受けるようにしろよ
933: 2019/06/14(金)21:45 ID:3/ZJQfp2(2/2) AAS
>>928
zfs 0.7.13はビルド出来てカーネルモジュールのロードも出来たけど、zpool createコマンドでそんなプールは無いって言われた

zfsの使い方を知らないせいだと思うけど…
934: 2019/06/14(金)21:56 ID:c8cHscUJ(1) AAS
ネットワークとか、ファイル共有とかはいらなくて
Linuxのソフトを動かしたいだけの人には
WSL1 + X server
のほうがいいってことですかね。
935: 2019/06/14(金)22:28 ID:5gjg1rej(1) AAS
CheckNetIsolation LoopbackExempt
でループバックを許可したら出来ないのかな。
936: 2019/06/14(金)22:40 ID:BFocZb+m(3/3) AAS
皆WSL2に興味深々だけど、1903から追加されたimportコマンドで、
外部ツール使わずにCドライブ以外にWSL環境作れるようになってるんだな

WSL1とWSL2のexportって何か違うんだろうか
937: 2019/06/14(金)22:46 ID:NaM43hJg(4/5) AAS
>>931
そうか!
Windowsだしxrdpでもいけるかもしれないな・・・
938: 2019/06/14(金)23:44 ID:NaM43hJg(5/5) AAS
xrdpでLXDEのデスクトップは表示できたけど、dbusとか依存サービスがもろもろ動いてないので使い物にならず。
WSL2でGUIは無理か、WSL1でも無理矢理やってる感じだが・・・
939
(2): 2019/06/15(土)00:26 ID:+cVH+56Z(1/2) AAS
Cygwin/MSYS2 は、sjis の日本語に対応してないから、日本語でバグル!
Linux のUTF-8 を、Windows でコンパイルしただけ。
sjis など、MS が使っている、文字コードには対応していない!

WSL は、Windows10 が、環境が切り替わる所で、
sjis/UTF-8 を変換いているから、バグらない

sjis などの何百もある、国ごとに異なる、Windows専用の文字コードは、MSしか対応できない。
これらは、その国だけで使われている、国際化してない文字コード!

一方、UTF-8は、全世界で共通の文字コード

とにかく、sjis/UTF-8の変換は、MS以外ではできない。
オープンソースで出来るのは、Ruby も使っている、NKF だけ!
940: 2019/06/15(土)00:29 ID:5dLAomYC(1/3) AAS
WSL2でDocker動かした人いる?
941: 2019/06/15(土)00:29 ID:q/l0UnmT(1) AAS
MS以外ではできないつったりnkfもできるっつたり忙しい奴だな
942: 2019/06/15(土)00:39 ID:uQpGU93O(1) AAS
JA16SJISTILDE
943
(1): 939 2019/06/15(土)05:11 ID:+cVH+56Z(2/2) AAS
Windows が採用しているのは、sjis を拡張した、CP932。
こういう文字コードを知っている外人は、まずいない

Windows には、同様な外国の文字コードも、わんさかあるけど、
それを使う国の人しか知らない

オープンソースでは、Ruby も使っている、NKF があるけど、
これも、sjis なのか、CP932 にも対応しているのか、よくわからない

だから、UTF-8 以外は、世界中で通用しない!
世界共通ではない!
944: 2019/06/15(土)06:13 ID:9hgLtMZu(1) AAS
nkf だけでないと思うが、iconv cp932
があつかえる。

外部リンク:www.tcom242242.site

ほかにもicu でもあつかえる。
945: 2019/06/15(土)06:29 ID:Cjs3MSJ6(1) AAS
ベンチマーク見た感じだとWSL2はストレージのアクセスが頻繁な処理では劇的に高速化しているな
でもメモリアクセスが重い処理では逆に遅くなっている
946: 2019/06/15(土)13:05 ID:5dLAomYC(2/3) AAS
WSL2にDocker CE入れたら本当に動いたな。
まあ、これから色々見るつもり・・・

外部リンク:docs.docker.com
947: 2019/06/15(土)14:18 ID:3oVnYJwT(1/3) AAS
>>939 >>943
何言ってんのかよくわかんないけど、
Cygwinは2009年のver1.7.1以降、デフォルトロケールがUTF-8になってる。
Windowsのファイル名はCP932だけど、Cygwinが変換してくれるので、Cygwin上のプログラムからはUTF-8に見える。
948
(1): 2019/06/15(土)14:58 ID:UW/+wp4S(1/7) AAS
> Windowsのファイル名はCP932だけど
Windowsのファイル名はNT3.1のころからUnicode(UTF-16)
わかってんだろ?嘘つくなよ
949: 2019/06/15(土)15:26 ID:5dLAomYC(3/3) AAS
メモ帳はとっくにUTF-8標準、改行コードもLFサポートしてるのを知らないジジイだろw
950
(1): 2019/06/15(土)16:30 ID:3oVnYJwT(2/3) AAS
>>948
OSの内部表現じゃなくて、アプリケーションからどう見えるかの話をしてるんだが。
Cygwinの話をしていることからわからなかったか?
951
(1): 2019/06/15(土)16:33 ID:Shy5ns+9(1/2) AAS
>>950
アプリケーションからもUTF-16LEに見えるんだが
952
(1): 2019/06/15(土)16:34 ID:UW/+wp4S(2/7) AAS
アプリケーションからCP932に見えたら
CP932にない絵文字が正しく表示できるわけ無いだろ
リアル馬鹿だなw
953
(2): 2019/06/15(土)16:40 ID:qMjBI3rb(1/3) AAS
XPの時に、ファイル名にSJISにできない文字が含まれるとファイル名が壊れるって現象にぶち当たった覚えあるけど今は大丈夫なのか?
1-
あと 49 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.047s