【Bash】Windows Subsystem for Linux【WSL】3
■ このスレッドは過去ログ倉庫に格納されています
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でサーバー機能を提供しても、
ライセンス的に問題ないという理解で良い? curlとかBSDのtarはWindowsに取り込んでるな。 紛れもなくbsdtarの方なんだが、どこ見てGNUと判断した Win搭載のtar.exeの元はbsdで、WSL上のtarはGNUと言うことだろ
(LinuxではGNU tarだけど)WSLでわざわざbsd tarを配布するなんてしないだろう GNU tarを使ってるのは、GPLに汚染される可能性を考慮してそうなってるのかな? >>498
>>130あたり読み返してたら、何となく >>597
Windows Serverの適切なCALを購入していれば、
そりゃライセンス的に問題はないだろうさ >>508
サーバーライセンスだけじゃなく、CALも必要なのね VMより効率いいとは言っても結局のところ画面とかないからね
coLinuxを精子せょう進化させたほうがええやん >>510
ならcoLinuxを発展・進化させるプロジェクトを立ち上げて
WSLに対抗したらいいんじゃない? >>510
画面はWindowsを使いたいから
WSL使うんでしょ? WSLは魅力的だけど、Windowsの画面描画が汚すぎてアレ。
とくにフォントヒンティングはひどすぎて、どないしようもない。
これ、いい加減になんとかしてほしいんだよな、過去の互換性を全部捨ててでも。 >>513
WSLには関係ないし。ネタとしてつまらん。 >>515
自分の字が汚い人ほどいちゃもんをつけたくなるそうです。 フォントに関しては見慣れてるかどうかで印象変わる気がする
個人的にアンチエイリアスかかってるフォントはボケッとしてて好きじゃない
winのゴシックはボケないけどジャギがめだたなくて好き
明朝系のヒゲフォントはモニタ上では見たくない > 個人的にアンチエイリアスかかってるフォントはボケッとしてて好きじゃない
アンチエイリアスが掛かってないフォントを見たことがあるの? でもMSゴシックなんかもう殆ど使われてなくね?
WSLのスレなんだからWindows 10を使ってるだろうけど、
ちょうどこの間SSDが壊れて再インストールしたんだよね。
初期のWindowsはフォントがなんかおかしかったんだけど
そういやフォント設定何もいじってないことに気づいた
コンパネの中からもMSゴシック消えてね?
Windows自体からMSゴシックは消えて、一部の
古いアプリだけしかもう使ってない気がする おれはターミナルのフォントには12ドットのビットマップのMSゴシック(等幅)を使い続けている。
大量のテキストを眺めるときは、アンチエリアスの掛からないビットマップフォントの方が、圧倒的に目が楽だ。
眼は、対象の輪郭でピント調整するからな。その輪郭がボヤけていれば、目に余計な負担が掛かるのは当然。
12ドットビットマップは、FullHD辺りまでの環境では表示密度的にもベスト。
同じ理屈で、4Kや8K環境向けに24ドットのビットマップフォントで手頃なものがあると良いのだが… いやごめんアンチエイリアスはwinでも皆かかってるんだけどClearType的な?
Linuxデスクトップ上のフォントってジャギー部分の灰色成分が多いというか
紙の印刷物スキャンした画像ファイルみたいなもやっとした印象があって
クッキリフォント見慣れてると違和感がある
まあ旧来のフォントに慣れすぎてるだけなんだけど >>518
まあDOSから上がってきた人間なもんで ビットマップフォントだと古いMacで使われていたosakaフォントもあるけど、
osakaは小文字のaとe,o辺りの判別がシルエットからはつきにくい、という致命的な欠陥が。
1とlなんかもつらいね。まあ、およそコードやターミナルを扱う人のためのフォントではない。
4K/8K時代のコンソール環境を考えると、高品位な24〜48ドットのビットマップフォントが欲しくなるのだけど、これがなかなか見当たらないのが惜しいし、目下差し迫りつつある問題でもある…。
そもそもアンチエリアスなんて解像度が不足しているから仕方なくやるもので、解像度が十分なら本来不要な処理だしなあ。 MacのASCII文字は、chicagoだったか。
いずれにしてもコードやコンソールには向かないフォント。 ChicagoはGUI用の伝統的なフォントだがコンソール用はMonacoが伝統的なフォント
Osaka等幅のASCII部分はMonacoと等しい
Monacoは非常に素晴らしいフォントで個人的には今でも現役 build 1803でCJK環境でターミナルのフォントがバグるの改善されたの知らないの? そもそもターミナルのフォントバグの話なんか誰もしてなかったという ■ このスレッドは過去ログ倉庫に格納されています