アカウント名:
パスワード:
0dayのパッチがWindowsだけ遅い状況が解消されて、うれしい限り
しかし、Windowsのパッチが遅いと書いたときに月1回じゃないととか、過去の経緯が云々とかいってたMS信者は、月1回を貫き通してほしいものですなw
というか、なぜWindowsはシステム更新でOS再起動が必要なのだろう?
サービス更新なら、サービス立ち上げなおせばいいし。設定ファイル更新なら、読み込め直せばいいし。9x時代から(それ以前から?)、なぜこれを改善しないのか。
なにか認識不足だろうか。
あんだけ大量にあるサービス全部立ち上げなおすの?それなら再起動したほうが早いだろ
パッチに関連するのだけで良いだろ、って話なんじゃないかな。それとも毎回kernelいじってるの?
Windowsの場合、OS側のファイル操作仕様が強制ロック (mandatory lock) なので、UNIXで一般的なアドバイザリロック (advisory lock) とは異なり、何をどうやっても排他ロックのかけられたファイルに書き込むことができません。これを回避する目的で、再起動後に反映する仕組み(MoveFileExのMOVEFILE_DELAY_UNTIL_REBOOTフラグ)がありますが、これによって関連するサービスの再起動だけでは済まない事情が発生してしまっています。(プログラムファイル自身もそうですし、それらが使用しているデータファイルも同様です)
UNIXで一般的なアドバイザリロックの場合は、逆に「パッチは適用したつもりだけど、サービス類の再起動を忘れて実は新しいモジュールやデータが反映されてなかった」事態が起こりえますので、一長一短ではあります。
いやいや、現在の実装では、Windowsのカーネルは実行モジュールに排他ロックをかけますが、これは別に必須ではなく、UNIXのようにロックせずにファイルを開くことだってできます。単にUNIXには(あらゆる状況で信頼できる方法では)強制ロックをかける機能がない、というだけの話です。
また、セキュリティフィックスの場合は直ちに適用することが必要ですから、いずれにしろアップデート対象モジュールに依存しているプロセスは再起動が必要です。
ですから、Windowsがmandatory lockを持っていることはこの件には関係ないと思います。
で、Windowsだってアップデートされたモジ
mandatory lockは関係するのでは? 関係なければ、再起動前の処理だけで十分であり、再起動後に延々と更新処理する必要がないでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
パッチの提供が早くなるのであれば歓迎 (スコア:0, おもしろおかしい)
0dayのパッチがWindowsだけ遅い状況が解消されて、うれしい限り
しかし、Windowsのパッチが遅いと書いたときに月1回じゃないととか、
過去の経緯が云々とかいってたMS信者は、月1回を貫き通してほしいものですなw
Re: (スコア:0)
というか、なぜWindowsはシステム更新でOS再起動が必要なのだろう?
サービス更新なら、サービス立ち上げなおせばいいし。
設定ファイル更新なら、読み込め直せばいいし。
9x時代から(それ以前から?)、なぜこれを改善しないのか。
なにか認識不足だろうか。
Re: (スコア:0)
あんだけ大量にあるサービス全部立ち上げなおすの?
それなら再起動したほうが早いだろ
Re: (スコア:0)
パッチに関連するのだけで良いだろ、って話なんじゃないかな。
それとも毎回kernelいじってるの?
Re: (スコア:2, 参考になる)
Windowsの場合、OS側のファイル操作仕様が強制ロック (mandatory lock) なので、UNIXで一般的なアドバイザリロック (advisory lock) とは異なり、何をどうやっても排他ロックのかけられたファイルに書き込むことができません。
これを回避する目的で、再起動後に反映する仕組み(MoveFileExのMOVEFILE_DELAY_UNTIL_REBOOTフラグ)がありますが、これによって関連するサービスの再起動だけでは済まない事情が発生してしまっています。
(プログラムファイル自身もそうですし、それらが使用しているデータファイルも同様です)
UNIXで一般的なアドバイザリロックの場合は、逆に「パッチは適用したつもりだけど、サービス類の再起動を忘れて実は新しいモジュールやデータが反映されてなかった」事態が起こりえますので、一長一短ではあります。
Re: (スコア:5, 参考になる)
いやいや、現在の実装では、Windowsのカーネルは実行モジュールに排他ロックをかけますが、
これは別に必須ではなく、UNIXのようにロックせずにファイルを開くことだってできます。
単にUNIXには(あらゆる状況で信頼できる方法では)強制ロックをかける機能がない、というだけの話です。
また、セキュリティフィックスの場合は直ちに適用することが必要ですから、
いずれにしろアップデート対象モジュールに依存しているプロセスは再起動が必要です。
ですから、Windowsがmandatory lockを持っていることはこの件には関係ないと思います。
で、Windowsだってアップデートされたモジ
Re:パッチの提供が早くなるのであれば歓迎 (スコア:0)
mandatory lockは関係するのでは? 関係なければ、再起動前の処理だけで十分であり、再起動後に延々と更新処理する必要がないでしょう。