アカウント名:
パスワード:
さすがにカーネルがGPLとかなるわけないだろFree/Net/OpenBSDのカーネルがベースならともかく
Linuxでなければ意味がないです。
この話の背景には、今一番"""いけてる"""業界であるところのWeb界隈において、GitHubからzipとかどっかの大学教授のホームページとかから変なコマンドとかで落としてきて本番WebサーバにFTPでアップするファイルが手元のノートで動くことが非常に重視されることがあります。
変なコマンドはx86_64版のバイナリを落としてくるのが常で、つまり数あるOSや中間言語VMその他のうちx86_64版GNU/Linux環境は最もコストや話題性で補正したシェアの高い"ABI"の一つと言えるのではないか、そして本義とは異なるけれどその"ABI"互換性を最も高く保つためにはLinux KernelとGNUユーザランドを採用するのが最も筋が良い実装方法ではないか、じゃあやっちゃいなよMicrosoft、というのがESRの主張です。で、いや筋良くねーしやるわけねーし、と言ってるのがこのストーリで取り上げられてる反論です。
いずれにしろ誰がいつこねたかも分からんネットに落ちてたLinuxのバイナリが動くことがノーパソのマーケティング上重要になっているからというのが起点で、OpenBSDのカーネルに差し替えればプロプラでバグだらけのNTなんかより優れているんだ、みたいな話ではないです。
どーでもいいことで争ってんなーって見てました。が、この解説あるいは主張を読んで、もしこれが正しいなら「え、ほんとにESRってそこまでお**さんなの？」とびっくりしました。
アプリさえ動けばいいという主張であればLinuxカーネルがどうとかこうとか以前の問題ですよね。Linuxカーネルのバージョンが同じであってもGNU/Linuxディストリビューションごとに、dll地獄、アプリのver違い地獄,ざっくり言えば環境の違い地獄で、同一ﾊﾞｲﾅﾘがLinuxカーネル上でありさえすれば動作するなんて現代でも幻想でしょう。
であるならば、WindowsがLinuxカーネルになっちゃんだよね～!!マジなんだぜ～!!!!とか、それを真っ向から相手をして否定するとか、しないとか、愚かすぎて論評にも値しないってことになりませんかねこれ
これほんと?魂消たなぁ
そのへんはSnapとかflappyが解決してくれるsnapでしか配布されないアプリをsnap非対応環境で使う方法とかはない。
「GitHubからzipとかどっかの大学教授のホームページとかから変なコマンドとかで落としてきて」獲得したファイルというのは、たいてい全部静的リンクしてあり、外部のコマンドなどにも依存しないようになっていて、dll地獄やアプリのver違い地獄は一応遭遇しないはずになっている。あなたの懸念する問題がこれですべて解決しているわけではないだろうけど、大抵のGNU/Linuxディストリビューションでなんとなく動く。
そういう調子で作られたプログラム、私のコンピュータにはたとえばdocker、kubectl、helm、terraform、jqなどがある。どれも適当にダウンロードして/usr/local/binに置いてある。
（静的リンクしたバイナリの用意が無理なら、x86_64用Dockerイメージを用意して「docker run XXXすれば試せるよ」となっていることも多い。#3909471で言われているとおりsnapなどの場合もある。ここでもx86_64 LinuxのABIであることが重宝される）
なぜそんなにESRの肩を持ちたいのかはわかりかねますが、それにしてもなんか斜め上に行っちゃってません？
あなたが縷々説明してくださった内容は、それがどうWindowsのカーネルにLinuxカーネルを採用するようになるという論拠になるのかの説明になってますか？
仮に、イケてるweb界隈でそんなに拾ってきたバイナリファイルを使うことが本当にそれほど重要なら、開発環境に最初からWindowsなんぞ選択しますか。むしろ、web屋界隈じゃ本番環境もあえて仮想環境上に構築されていてハードウェアやOSを変更しても影響が出ないようにしてあることが多いのではないですか。あるいは開発用に本番環境を仮想化し、その中で開発すればいいだけでしょう。それこそベースのOSなんて何でもいいという結論になるんじゃないでしょうか。
にも拘らずWindowsのカーネルがLinuxとなるのだ、という結論を導出したESRの論拠の説明になってるんですか?
そのとおりだ。
それがどうWindowsのカーネルにLinuxカーネルを採用するようになるという論拠になるのかの説明になってますか？
その説明にはなっていないよ、あなたの感じているように。
だってESRの意見への賛否とは無関係にチャチャとして#3909617を書いたから。肩透かしだったら悪かったな。
WSL1でABI互換性に苦労した挙げ句WSL2で本物のLinuxカーネルを採用するのは実際にやってるんだよなあ
本物のLinuxカーネルもなにもアレは事実上内部的にHyper-Vで動かしてるだけだよMacOSのぱられるとかでもMacOS側でWindows側のGUIを表示する機能とかあったでしょ？アレのWindows版みたいなもん
Windowsの場合はもっと奥まで突っ込んでてWSL2を有効化するとホストOSのWin10も仮想化環境で動くようになってる
なんの苦労もしてないでしょWSL1の仕組み(SFUと同じ)だとカーネルの機能を直接叩くソフトが動作しないのは初めから分かってた事だし。
自分の願望をさも世界の願望であるかのように語るな
もしかして、それが今のWindowsでは出来ないと思ってる？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
GPL汚染 (スコア:0)
さすがにカーネルがGPLとかなるわけないだろ
Free/Net/OpenBSDのカーネルがベースならともかく
Re:GPL汚染 (スコア:2)
Linuxでなければ意味がないです。
この話の背景には、今一番"""いけてる"""業界であるところのWeb界隈において、GitHubからzipとかどっかの大学教授のホームページとかから変なコマンドとかで落としてきて本番WebサーバにFTPでアップするファイルが手元のノートで動くことが非常に重視されることがあります。
変なコマンドはx86_64版のバイナリを落としてくるのが常で、つまり数あるOSや中間言語VMその他のうちx86_64版GNU/Linux環境は最もコストや話題性で補正したシェアの高い"ABI"の一つと言えるのではないか、そして本義とは異なるけれどその"ABI"互換性を最も高く保つためにはLinux KernelとGNUユーザランドを採用するのが最も筋が良い実装方法ではないか、じゃあやっちゃいなよMicrosoft、というのがESRの主張です。で、いや筋良くねーしやるわけねーし、と言ってるのがこのストーリで取り上げられてる反論です。
いずれにしろ誰がいつこねたかも分からんネットに落ちてたLinuxのバイナリが動くことがノーパソのマーケティング上重要になっているからというのが起点で、OpenBSDのカーネルに差し替えればプロプラでバグだらけのNTなんかより優れているんだ、みたいな話ではないです。
Re: (スコア:0)
どーでもいいことで争ってんなーって見てました。
が、この解説あるいは主張を読んで、もしこれが正しいなら「え、ほんとにESRってそこまでお**さんなの？」とびっくりしました。
アプリさえ動けばいいという主張であればLinuxカーネルがどうとかこうとか以前の問題ですよね。
Linuxカーネルのバージョンが同じであってもGNU/Linuxディストリビューションごとに、dll地獄、アプリのver違い地獄,
ざっくり言えば環境の違い地獄で、同一ﾊﾞｲﾅﾘがLinuxカーネル上でありさえすれば動作するなんて現代でも幻想でしょう。
であるならば、WindowsがLinuxカーネルになっちゃんだよね～!!マジなんだぜ～!!!!とか、それを真っ向から相手をして否定するとか、しないとか、愚かすぎて論評にも値しないってことになりませんかねこれ
これほんと?
魂消たなぁ
Re: (スコア:0)
そのへんはSnapとかflappyが解決してくれる
snapでしか配布されないアプリをsnap非対応環境で使う方法とかはない。
Re: (スコア:0)
「GitHubからzipとかどっかの大学教授のホームページとかから変なコマンドとかで落としてきて」獲得したファイルというのは、たいてい全部静的リンクしてあり、外部のコマンドなどにも依存しないようになっていて、dll地獄やアプリのver違い地獄は一応遭遇しないはずになっている。あなたの懸念する問題がこれですべて解決しているわけではないだろうけど、大抵のGNU/Linuxディストリビューションでなんとなく動く。
そういう調子で作られたプログラム、私のコンピュータにはたとえばdocker、kubectl、helm、terraform、jqなどがある。どれも適当にダウンロードして/usr/local/binに置いてある。
（静的リンクしたバイナリの用意が無理なら、x86_64用Dockerイメージを用意して「docker run XXXすれば試せるよ」となっていることも多い。#3909471で言われているとおりsnapなどの場合もある。ここでもx86_64 LinuxのABIであることが重宝される）
Re: (スコア:0)
なぜそんなにESRの肩を持ちたいのかはわかりかねますが、それにしてもなんか斜め上に行っちゃってません？
あなたが縷々説明してくださった内容は、それがどうWindowsのカーネルにLinuxカーネルを採用するようになるという論拠になるのかの説明になってますか？
仮に、イケてるweb界隈でそんなに拾ってきたバイナリファイルを使うことが本当にそれほど重要なら、開発環境に最初からWindowsなんぞ選択しますか。
むしろ、web屋界隈じゃ本番環境もあえて仮想環境上に構築されていてハードウェアやOSを変更しても影響が出ないようにしてあることが多いのではないですか。
あるいは開発用に本番環境を仮想化し、その中で開発すればいいだけでしょう。
それこそベースのOSなんて何でもいいという結論になるんじゃないでしょうか。
にも拘らずWindowsのカーネルがLinuxとなるのだ、という結論を導出したESRの論拠の説明になってるんですか?
Re: (スコア:0)
そのとおりだ。
それがどうWindowsのカーネルにLinuxカーネルを採用するようになるという論拠になるのかの説明になってますか？
その説明にはなっていないよ、あなたの感じているように。
だってESRの意見への賛否とは無関係にチャチャとして#3909617を書いたから。肩透かしだったら悪かったな。
Re: (スコア:0)
WSL1でABI互換性に苦労した挙げ句WSL2で本物のLinuxカーネルを採用するのは実際にやってるんだよなあ
Re: (スコア:0)
本物のLinuxカーネルもなにもアレは事実上内部的にHyper-Vで動かしてるだけだよ
MacOSのぱられるとかでもMacOS側でWindows側のGUIを表示する機能とかあったでしょ？
アレのWindows版みたいなもん
Windowsの場合はもっと奥まで突っ込んでてWSL2を有効化するとホストOSのWin10も仮想化環境で動くようになってる
Re: (スコア:0)
なんの苦労もしてないでしょWSL1の仕組み(SFUと同じ)だとカーネルの機能を
直接叩くソフトが動作しないのは初めから分かってた事だし。
Re: (スコア:0)
自分の願望をさも世界の願望であるかのように語るな
Re: (スコア:0)
もしかして、それが今のWindowsでは出来ないと思ってる？