アカウント名:
パスワード:
まして権限与えなければ、その権限以上のことができない通常の実行ファイルと違って、中間コードを実行してる核たる部分がセキュリティリスクになるんだから手に負えないわ。しかも中間コード自体にバージョン間で互換性が無いから、VMも多数管理しなきゃならない。
これは.NETだけじゃなくJavaなんかもそうで、例えばLibreOfficeなんて現行最新版の3.4.4ですらJava7未対応、LibreOfficeを利用する為には否応なくJRE6u30を入れとかなきゃない。「別にu29やu28でも良いんじゃね?」と思うだろう? ところがそいつらにはセキュリティホールが空いてるという体たらく。
いわゆるスクリプト言語のように、中間コードに変換して実行しようと、そうでない場合と比べて本質的な違いがない場合はともかく、最終的な実行コードとして中間コードを使うのは、もうオワコンだなと痛感した。というかWORAという誇大妄想が消滅した瞬間に既に終わっていたのかも・・・・・・
> まして権限与えなければ、その権限以上のことができない通常の実行ファイルと違って、> 中間コードを実行してる核たる部分がセキュリティリスクになるんだから手に負えないわ。
どの環境orOSでもそれ自体や、ライブラリに不具合があるのは普通だと思います。 重要なのは、その不具合が放置されないことなので、修正された環境で再コンパイルが必要とかでなければ、悲観する必要はないと思います。
> しかも中間コード自体にバージョン間で互換性が無いから、VMも多数管理しなきゃならない。
.Netは、モジュールのローダがロードモジュールのバージョンを意識しないで良いようにしてくれているので普通にWindowsUpdateさえしていれば気にする必要はありません。 また、Javaの場合ロードモジュールを実行するVMの管理が必用ですが、大抵のアプリケーションがインストーラとランチャの部分でVMのバージョンを意識しなくてよいようにしてくれている事が多いと思いますし、エンドユーザは、アップデータがあるので、言われたとおりバージョンアップしてればまず問題ないと思います。
> LibreOfficeを利用する為には否応なくJRE6u30を入れとかなきゃない。> 「別にu29やu28でも良いんじゃね?」と思うだろう? ところがそいつらにはセキュリティホールが空いてるという体たらく。
セキュリティパッチってそういうもんでしょ?これに関しては、何を使っててもおなじでは?
> いわゆるスクリプト言語のように、中間コードに変換して実行しようと、そうでない場合と比べて本質的な違いがない場合はともかく、> 最終的な実行コードとして中間コードを使うのは、もうオワコンだなと痛感した。
中間言語を含む、ロードモジュールを配布するタイプの言語で、コンパイラにバグがあって、ロードモジュールを再コンパイルしないといけない場合以外、スクリプト言語を使ってても、結局実行環境に問題があれば同じだと思います。だけだと思いますが?
そういう意味では、今回の件は、悲観する必要ないと思います。
.Netは、モジュールのローダがロードモジュールのバージョンを意識しないで良いようにしてくれているので普通にWindowsUpdateさえしていれば気にする必要はありません。
普通はそうなんですが、ビルドした環境のランタイムのほうがあたらしければ古いランタイムを持つ環境では期待した動作しないことはままありますよ。ILが異なるのは勿論、挙動から変わる場合があります。大体は元の動作が仕様に沿ってないしろものだったりしますが。# それはそれでリリースノートに書いてほしい・・・なので開発者は注意しないと入らぬ苦労を背負います。
まぁ普通の人は無関係だわな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
なんかもう中間コードってセキュリティリスクの塊やね… (スコア:0, 興味深い)
まして権限与えなければ、その権限以上のことができない通常の実行ファイルと違って、
中間コードを実行してる核たる部分がセキュリティリスクになるんだから手に負えないわ。
しかも中間コード自体にバージョン間で互換性が無いから、VMも多数管理しなきゃならない。
これは.NETだけじゃなくJavaなんかもそうで、例えばLibreOfficeなんて現行最新版の3.4.4ですらJava7未対応、
LibreOfficeを利用する為には否応なくJRE6u30を入れとかなきゃない。
「別にu29やu28でも良いんじゃね?」と思うだろう? ところがそいつらにはセキュリティホールが空いてるという体たらく。
いわゆるスクリプト言語のように、中間コードに変換して実行しようと、そうでない場合と比べて本質的な違いがない場合はともかく、
最終的な実行コードとして中間コードを使うのは、もうオワコンだなと痛感した。
というかWORAという誇大妄想が消滅した瞬間に既に終わっていたのかも・・・・・・
Re:なんかもう中間コードってセキュリティリスクの塊やね… (スコア:2, 参考になる)
> まして権限与えなければ、その権限以上のことができない通常の実行ファイルと違って、
> 中間コードを実行してる核たる部分がセキュリティリスクになるんだから手に負えないわ。
どの環境orOSでもそれ自体や、ライブラリに不具合があるのは普通だと思います。
重要なのは、その不具合が放置されないことなので、修正された環境で再コンパイルが
必要とかでなければ、悲観する必要はないと思います。
> しかも中間コード自体にバージョン間で互換性が無いから、VMも多数管理しなきゃならない。
.Netは、モジュールのローダがロードモジュールのバージョンを意識しないで良いようにしてくれているので
普通にWindowsUpdateさえしていれば気にする必要はありません。
また、Javaの場合ロードモジュールを実行するVMの管理が必用ですが、大抵のアプリケーションが
インストーラとランチャの部分でVMのバージョンを意識しなくてよいようにしてくれている事が多いと思いますし、
エンドユーザは、アップデータがあるので、言われたとおりバージョンアップしてればまず問題ないと思います。
> LibreOfficeを利用する為には否応なくJRE6u30を入れとかなきゃない。
> 「別にu29やu28でも良いんじゃね?」と思うだろう? ところがそいつらにはセキュリティホールが空いてるという体たらく。
セキュリティパッチってそういうもんでしょ?
これに関しては、何を使っててもおなじでは?
> いわゆるスクリプト言語のように、中間コードに変換して実行しようと、そうでない場合と比べて本質的な違いがない場合はともかく、
> 最終的な実行コードとして中間コードを使うのは、もうオワコンだなと痛感した。
中間言語を含む、ロードモジュールを配布するタイプの言語で、コンパイラにバグがあって、ロードモジュールを
再コンパイルしないといけない場合以外、スクリプト言語を使ってても、結局実行環境に問題があれば同じだと思います。
だけだと思いますが?
そういう意味では、今回の件は、悲観する必要ないと思います。
Re: (スコア:0)
.Netは、モジュールのローダがロードモジュールのバージョンを意識しないで良いようにしてくれているので
普通にWindowsUpdateさえしていれば気にする必要はありません。
普通はそうなんですが、ビルドした環境のランタイムのほうがあたらしければ古いランタイムを持つ環境では期待した動作しないことはままありますよ。
ILが異なるのは勿論、挙動から変わる場合があります。大体は元の動作が仕様に沿ってないしろものだったりしますが。
# それはそれでリリースノートに書いてほしい・・・
なので開発者は注意しないと入らぬ苦労を背負います。
まぁ普通の人は無関係だわな。