【Bash】Windows Subsystem for Linux【WSL】8
■ このスレッドは過去ログ倉庫に格納されています
ついにWSL2が登場したぜー。こりゃ完全にLinuxだ。ヒャッハー!WSL最高!開発にLinuxは使わねぇー。Windowsで開発してLinuxは動かすだけや! WSL2アーキテクチャ https://www.atmarkit.co.jp/ait/articles/1906/14/news019.html WSL 2では、仮想マシン環境が起動し、bashがコマンドを受け付けるまで2秒程度という速度で起動できる。 このため、コマンドプロンプトなどからwsl.exeなどを使ってbashコマンドを処理する時間は、 現在のWSL 1とほとんど変わらない。また、本物のLinux実行環境であるため、 これまで正しく動作できなかったアプリケーション、例えばコンテナシステム(Dockerなど)や ユーザーファイルシステム(FUSEなど)も動作させることができる。その上で、現在のWSL 1と同等の機能と使い勝手を実現するという。 WSL 2はWSL 1を置き換えずに併存する WSL 2が登場したからといって、WSL 1は廃止になるわけではなく、引き続き利用可能である。 ファイル共有プロトコル「9P」でWSL 1との互換性を確保 このように、WSL 2とWin32環境の間のファイル共有は、どちらも9Pを使うことになる。 また、WSLからWin32プログラムを起動する「Win32相互運用性」では、最初にWSL側で、 実行ファイルを判別する必要がある。具体的には、実行ファイル先頭のマジックナンバー (Win32ではMZ)を見て、LinuxのELF64か、Win32の実行ファイルなのかを判断する。 【Bash】Windows Subsystem for Linux【WSL】7 https://mao.5ch.net/test/read.cgi/linux/1579395785/
物理ドライブ使えるようになったらWindowsからext4やらxfs使うのが楽になるな しかもLinuxカーネル経由だから互換性の問題も出にくい…のか? そのうちSubsystemだったLinuxが本体のWindows乗っ取る…なんてことはないか Linux Subsystem for Windows >>707 実際にはWSLがのっとってるのはLinux Win8の頃にデスクトップ廃止&モダンアプリ強制しようとしてグダグダに迷走していた頃に もしも明日Windowsが終わっても、Microsoft自体は1年後にMicrosoft Linuxとか出していける企業だからしぶとい みたいな話をしていたが、その後実際にこういう形(WSL)でLinuxを取り込むとは思わなかったな Dockerで何某検証したりk8s使ったりするならdocker desktopを使った方がいいな 開発目的でも言語のバージョン切り替えやミドルウェア連携をハードに依存させたくないならdocker使うべきでしょ 特にないならdocker desktopはいらんかな ノートPC壊したので ジャンクのノートPC1000円で購入 使用していたHDDに換装したら使用できた 再構築しなくて良かったと言う自分用日記 テキストに修飾することはできますか?影付き文字とかにできませんか?テキスト背景は完全に 透明にしたいのですが、完全に透明にすると文字が見えにくくなります 完全透明で見やすいとかありません 文字の問題ではありません 矛盾してます 背景を透明といいますが、背景は透明にはなりません 後ろのウインドウが見えてるはずです。 つまり「他の文字や画像」の上に文字を置くということです 見やすくなるわけがありません 半透明ウインドウでかっこいい!と主張しているサンプルイメージを見てみましょう 後ろに見えるのは壁紙です。あえてそうしています。 実際に使う場面であるウインドウを置いたら見づらいからです。 結局の所、本当に欲しいものは、ターミナルの背景に壁紙を置く機能なのです だから半透明かつ見やすいなんてものは無いって話をしてる 背景を透過や画像にできるかどうかはターミナルエミュレータの機能であって、WSLは関係ないんじゃね Windows側は昔使っていたTera Termで透過ウィンドウできたような記憶はあるけど、今時Tera使うか?って話にもなるし Windows Terminalでできたかどうかは知らない Linux側なら腐るほどある なんならGNOME terminalでできるだろ 半透明はオサレじゃねえ 裏窓内容を確認したい奴には一応実用性あんだよ 完全透明:OSD感覚?透明部分は透過クリックできて操作も可能 半透明:視認目的、メイン窓開いたまま隠れた裏窓の内容が確認できる 窓内壁紙:オサレ、裏見えない メイン窓の視認性は落ちるけどそこは透明度と暗色被せでカバー 全透明は自作アプリで文字周囲だけ表示エフェクトとかやらない限りは厳しそう Windows Terminalも半透明の機能はあるけどアクティブなときだけ有効なんだよ 逆にして欲しいんだが >>731 だから「見にくくなる」のを承知で 後ろのウインドウを見たいって話でしょ? Ubuntu 18.04 だけど、 bin の後ろに、// とあるのは、なぜ? 正常に動くけど、気持ち悪い which yarn /mnt/c/Program Files (x86)/Yarn/bin//yarn yarn --version 1.22.4 Windows のシステム環境変数PATH を見たら、 OpenSSH, nodejs などの末尾に、\ が付いている。 付いていないものも多いけど 一々、直すのは面倒・危険だから、このままにしておきます SSDに換えてから初めてWSL2触ってみたが、なるほどこれはHDDに戻れないな まぁ、でも来年始めたら11年遅くなるわけだし、それに比べたら1年早いということ。 遅れた時間は変えられないが、これからの時間の使い方次第でどうとでもなるでしょ? コマンドラインからディストリビューションのインストールできるようにならないかな。 >>746 正式版は来年だがwingetで出来るんでは 今wsl上のDockerでファイルの書き込みすると変換処理挟んで極端に速度落ちるけど ネイティブなext4ドライブにアクセス出来るようになれば速度落ちずに書き込み出来るようになるのかな? 今はコンテナにマウントしたWindowsのフォルダ(NTFS)に書き込みしてますが10MB/s程度しか出ないです それはWindowsと共有したいからそうしてるんだろ? ext4ドライブに移したら意味なくね? >>746 windows store使わないという意味ならできる What’s new in the Windows Subsystem for Linux - September 2020 https://devblogs.microsoft.com/commandline/whats-new-in-the-windows-subsystem-for-linux-september-2020/ GUI app support in WSL is becoming a reality! We are getting closer to an initial preview and happy to announce a preview release for Windows Insiders within the next couple of months. Below is an early look at an internal build running GUI apps in WSL! You can see that WSL will support many different types of applications, including IDEs running fully in a Linux environment. We have included lots of fit and finish details, such as showing the icons for Linux apps in the task bar and support for audio with your microphone (and yes, that really is the Linux version of Microsoft Teams running in WSL). https://devblogs.microsoft.com/commandline/wp-content/uploads/sites/33/2020/09/gif3.gif Stay tuned for more details about this feature coming soon. $ sleep 1 がいつの間にか動くようになってた 直ったのかな? wsl2 scp でファイル転送するとエラーになるときがある。 wsl1 では問題なし。 もうしばらく様子見かな。 Windows側のOpenSSH(scp.exe)をWSLで呼び出すとどうなる? いや、どうだったんだよw scp.exeで転送出来ないのか? 善きこと まあ自分でセットアップすれば同じ事は既にできるが、 WSL側で標準的な実装を提供してくれるなら、それこそバカチョン化できる よほど思想的にアンチMSを拗らせているようなディストリ以外は、インストーラー側でWSL環境も考慮するようになるだろう Windowsの機能(の一部)としてLinuxを取り込めるなら、拒絶する理由は無い > インストーラー側でWSL環境も考慮するようになるだろう その必要はないんだよなぁ もともとLinuxはGUIがない環境(つまりWSLと同じ)にも対応しているし WSLは本質的にはLinux用バイナリを起動する機能だから 必要なのはそこにファイルがあることだけ それもchrootなどの機能で昔からLinuxは対応してる chrootというのは指定したディレクトリ上にOSのファイルを置いて そのディレクトリをルートディレクトリとしてバイナリを動かすこと chrootで起動するためのディレクトリを作る機能がそのままWSLに応用できるわけよ WSLにインストールされる環境でいちいちchrootなんか使っていないし WSL環境に固有の設定はインストーラ側で対応だし 何言ってんのコイツ WSLのchrootとqemu-user-staticでラズパイのエミュレーション環境を作ったけど? ARMのバイナリをコンパイルするだけでなく、そのまま動作させることもできた。 >>763 chrootしたことある? どうやってchrootするためのディレクトリ作るよ? なんかのツール使ってしかやったことなさそうだね やり方は簡単。 /procや/devといった特殊なもの以外を特定のディレクトリにコピーする /procや/devはバインドマウントするだけ たったこれだけで新しい環境でバイナリが起動できるんだよ Linuxはそういう事ができるように作られてる WSLでやるのはこの環境を作るだけ。Linux側の対応は既に出来てるから不要 chrootおじさんはchrootで時代が止まってそう なんでそう思うんだ?普通にDockerも使ってるが? Docker(コンテナ)も根底にはchrootと同等の技術が使われてる コンテナはchrootの発展だからな。ディレクトリの分離だけでなく リソースの分離まで行うのがコンテナ技術 chrootの使い方なんか誰も聞いていない 現状のWSLでもxrdp経由でグラフィカル環境を実現することは可能だが(君には難しくて無理ということだが)、 WSL側でお仕着せの統一的な環境が容易されるようになれば、ディストリ側のインストーラーが対応することでこれまで自力では設定できなかった馬鹿な奴ら(君のことだよ)でもグラフィカル環境を扱うことができるようになるだろう それは善い事なので、妨げるまでもない…という話に、なぜchroot? 頭おかしいだろ Androidタブレットにchrootで既存のディストリ環境を導入するアプリは利用していてそれなりに便利に使ってはいるが、 それはAndroidでARMだからという環境に強いられた、消極的な理由でしか無いしなあ… x86ならdockerでいい(dockerの方がいい) Windowsと言わず、chromebookですらそうだ >>769 > ディストリ側のインストーラーが対応することで だからそんな必要がないという話 WSLはディストリ側から見れば単にファイルを置いてるだけに過ぎない Linuxは単に実行ファイルを置くだけで動くように作られてるんだよ。 ここに仕組みが書いてあるな https://news.mynavi.jp/article/20200927-windows10report/ > WSLGは隔離されたコンテナのように動作し、Linuxディストリビューションとはソケットによる通信を行う。 Linuxディストリビューション(のデスクトップアプリ)はソケット通信するだけ だからディストリ側のインストーラーがやることなんてなにもない WSLG、これはMSが用意するWSL上で動くコンテナ。 ディストリで提供されるデスクトップ用実行ファイルは ソケット通信でこの用意済みのWSLGコンテナと通信するだけ >>769 お前Linuxでデスクトップ表示する仕組みを知らんだろ? その仕組に則ればディストリ側は何もすることがないんだよ WSL側でお仕着せの統一的なデスクトップを表示するための環境が用意してあって そこにソケット通信するだけだから そのソケット通信をディストリ側が実装なりなんなりしないとあかんのちゃいますん? >>774 5月に発表があった時、年内に進捗を報告する見通しって言ってたじゃん。まだまだよ。 https://www.publickey1.jp/blog/20/wsl_2linuxguimicrosoft_build_2020.html と言ってもWSLも発表されて数年で実装されたし WSL2も発表されて数年で実装されたし、 今までの実績からいって何年もかかるってことはないだろ それぐらいMSの開発スピードは速い >>775 それは既にアプリに実装済みで、その仕組を使ってLinuxのデスクトップは表示されてる。 ソケット通信の先をMSが作るだけ >>771 実行ファイルに通信先のソケットのポートやプロトコルを教えてやる設定はどこに置いて、その設定は結局誰が書くんです? トンチンカンな問答を吹っ掛けられても、読まされるこっちが頭おかしくなりそうなのでアンカー飛ばして来ないでもらえますかね、キチガイ。 ゲストOSからrdp鯖やpulse鯖に見えるWSLGをこれからMSが用意するので ゲストOSのディストリビューターはWSL環境にインストールされた際にこれらを利用する設定を作らないと、 (僕は自力で設定できるが)馬鹿な君らには「WSLでは、グラフィックが使えない。」という状況が変わらない。 ゲストOSやアプリからは既存のプロトコル互換に見えても、それらを利用する設定はユーザーなりディストリなりが明示しなければ、当然使えない訳だが。 ラズパイをヘッドレス運用する際にxrdp入れて使う設定だって、ディストリがxrdpの設定スクリプトや雛型を用意してくれているからバカチョンでできる訳でな 無かったら全部自分で用意することになる。俺はできるが、お前らは無理なんだろ。 >>778 お前バカだろw 環境変数DISPLAYで渡されてるのしらんの? Linuxのデスクトップアプリはこの環境変数に設定されてる IPアドレスに接続するだけなの だからあとはWSLのinitでこの環境変数を提供して 接続先を用意するだけ >>779 > ゲストOSからrdp鯖やpulse鯖に見えるWSLGをこれからMSが用意するので > ゲストOSのディストリビューターはWSL環境にインストールされた際にこれらを利用する設定を作らないと、 不要。「これらを利用する設定」=環境変数DISPLAYとXDG_SESSION_TYPE を準備するだけ 各ディストリのアプリはGUIを表示する時、DISPLAYに接続するように作られてる それがもともとのLinuxデスクトップアプリの仕様だから 環境変数DISPLAYとXDG_SESSION_TYPEを用意するのはWSL(のinit)で実現できる >環境変数DISPLAYで渡されてるのしらんの? だからそれは一体どこの誰が用意して設定してくれるの? お前が知らんうちに勝手に設定されていると思っているものは、誰かが検出して反映(するように設定)してくれたものだ それは誰で、どこで、いつ設定しているの? >Linuxのデスクトップアプリはこの環境変数に設定されてる >IPアドレスに接続するだけなの WSL環境なら接続先はlocalhostなんじゃね(鼻くそほじりながら) もちろんLAN越しや、なんならWAN越しでだって設定はできますがね(君には無理かもしれないが) IPアドレス(笑)よりもポートの方が問題だろ。どこで検出してどうやって伝達して環境変数に反映するんだよ >だからあとはWSLのinitでこの環境変数を提供して >接続先を用意するだけ なんかもっと高度な話の可能性がミリくらい残っているかなと思ったが、とんだ買い被りだったようだ やはりただ煽りたいだけの無知キチガイで結論。もう俺にアンカー飛ばして来るな > ラズパイをヘッドレス運用する際にxrdp入れて使う設定だって だからそれを全部MSが用意するって話なんだが ディストリとは別に、RDP周りの設定が全て準備されてる仮想マシンをMSが1つ作って ディストリ上で動くアプリは環境変数DISPLAYで指定された、そのMSが準備した仮想マシンにソケット接続するだけ あとはMSが作った仮想マシンとWindowsホストとのやり取りで ウインドウを表示するだけだな >>782 > だからそれは一体どこの誰が用意して設定してくれるの? 書いただろ。ディストリ起動するときに実行されるinitが環境変数を用意する。 それは今も行われてる。WSL使ったことないの? WSLのbashを起動したら、環境変数 WSL_DISTRO_NAME=Ubuntu-18.04 とか見えてるんだがw > WSL環境なら接続先はlocalhostなんじゃね(鼻くそほじりながら) それはWindowsホスト、つまりコマンドプロンプトから WSL上で動いているサービスに接続する時の話 なーんもしらんのかw 「おれはインストールイメージファイルを利用しているのでインストーラーが走ることはない、はい論破」レベルのアホかと思ったが、 それ以前の馬鹿だった。 低レベルの話ができる奴なのかと思ったが全くの論外で、誰かのお仕着せのふしぎな仕組みをブラックボックスのまま使うだけの猿だった いや狂犬か 訂正 それはWindowsホスト、つまりコマンドプロンプト"等"な Windows上のブラウザから、WSLのサービスに接続する時もlocalhost Windows上で直接動かしているように見せかけるのがWSLだからね >>785 ほら。お前のレスが証拠。俺のレスの内容へのコメントがなくなったねw 環境変数DISPLAYも知らないレベルが相手だったのかねw ゲスト側がWSL環境を想定していなくても誰かが勝手に適切なポートとアドレスを設定してくれるDISPLAY環境変数があるらしい ふしぎだね! 馬鹿か ああ、そうか、ディストリ上のGUIアプリと仮想マシンとの接続はソケット接続って書いてあるな 環境変数DISPLAYの値はlocalhost:0.0じゃなくてDISPLAY:0.0とかなんだろう これならポート番号もいらんな。 Docker Desktop for WSL2のWSL2インテグレーションと近い仕組みかもしれないな Docker Desktop for WSL2ではWSL1のときに必要だったDOCKER_HOST環境変数が不要になってる どうやってWSL2上のDocker仮想マシンに接続しているかと言うと ディストリの中でdocker-desktop-proxyというプロセスが動いていてソケット接続で待ち受けてる。 あとはディストリ内のDockerクライアントがソケット接続でdocker-desktop-proxyにつないで それがDockerの仮想マシンにプロキシしている。 このdocker-desktop-proxyが必要なのはDockerだからであって MSが作るなら9pプロトコルと同じようにinit自体に内蔵するだろう つまり見た目上ディストリの中では特別なにかが動いているようには見えないが ソケット接続で待ち受けていて、ディストリ上のアプリはそのソケットに接続するだけ >>789 不思議でもなんでもないなw WSLで起動するPID番号1のinitはMSが作ったinit ディストリを起動するときに最初に起動するのがMSのinitなんだから 環境変数の準備なんて普通にできるよ 「MSが作ったinit」も、ディストリ側でそれを利用する設定でないとそもそも活かされない(WSLと協調できない環境がブートする)だけなんだよなあ ファイルを置くだけでどうにかできる、環境変数が勝手に自動で最適な設定で入っている前提のボクちゃんには想像もつかないだろうが >>792 MSが作ったinitは、WSLの各ディストリの(標準の /sbin/int ではなく) /init にコピーされて現在使われてるんですが? ディストリ側で利用する設定になってなくても「WSL登場の最初から使われてる」んですが? MSが作った /init は今現在、すでに使わてるんですが何を言ってるんですか? >>792 ディストリの中身は気にしなくていいんだよ rootfsを作ってインポートするだけでいい 妄想じゃなくて試したら? WSLの特徴は仮想マシン上にディストリを"インストール"してないこと もしこれが一般的な仮想マシンのようのディストリをインストールしていたら インストーラーが起動して、各サービスも起動して・・・ でもそれらはWSLにとっては不要だから無効にしてと ディストリのインストーラーに対していろんな調整が必要になる WSL1は単にLinuxバイナリを起動するだけ WSL2は仮想マシンこそ使われてるがWSL専用の軽量Linuxが動いていて Ubuntuなどのディストリはコンテナ技術を使って起動するから こちらもディストリのインストーラーは使われない WSLの仮想マシンはたった1つだけで、複数のディストリから たった1つの仮想マシン上のLinuxを共有している WSLGもそのたった1つのLinuxで動作する 各ディストリの各アプリは、そのたった1つのLinuxにソケット接続する その妄想とやらに反論がないなら、正しかったことで 終わりってことでいいんじゃない?w >>792 自分でWSL用ディストリを作ったことのない馬鹿の妄言 ___ / ⌒ ⌒\ / (⌒) (⌒)\ / ///(__人__)///\ 2万円のおせち料理が半額だったお | u. `Y⌒y'´ | これでお正月はばっちりだおww \ ゙ー ′ ,/ / __|___ | l.. /l ハワイアン`l ヽ 丶-.,/ |__ おせち _| /`ー、_ノ /  ̄ ̄ ̄/ ________________ |\ ‖ /| | ( ̄肉)_/ ̄V ̄ヽ_ ‖_____∠ | | ( ̄肉) | ,ォ ≠ミ .‖ i\チーズ| | | |`ー´ .|〃 yr=ミ:、‖-ー、\.\ /l | | |( ̄肉) iイ {_ヒri}゙‖ ハム ) \l/l .| | | `ー´ ヾ」^ヽノ‖ヽ_ノ .|__| |\ ̄ ̄ ̄ ̄ ̄ ̄ ̄‖ ̄ ̄ ̄ ̄ ̄ ./| | ┌/⌒⌒⌒⌒ヽ.‖ ̄ ̄ ̄ ̄ ̄ ̄| | | ( {ニニニィ )‖ l⌒l| | | |\ ∨ }/‖ .ィ ≠ミ、| | | | ヽ ゙こ三/ ノ‖ く`ヽ、!/行ミt)| | | | ヘ ノ |‖ .\ ゙.ヒrリ.》 | | ┼ヽ -|r‐、. レ | | | `ー^ー'‖ `ヽノ  ̄Y | . d⌒) ./| _ノ __ノ wsl2 20211で起動しなかったから20206で更新止めてた なんか20206でも起動しなくなった 20226で治ったとか見たから更新したけどやっぱ起動しない 助けて wsl1に戻すと一応起動はしたしフォルダアクセスできたから中身は回収したとしてなんか挙動が変だからwls2に戻したい もうイライラしてwsl自体嫌になってきた助けて 入れ直せってことか 20206ならwsl2で立ち上がるのもあるし駄目なのもあるから入れ直すのはありかもしれんけど 20226は全部無理だから多分入れ直しても無理ですわ 週末までにfixされなかったら20206でやり直すか… ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる