Windows Updateでそれをしないのは、Windowsが対象とするユーザにとって、それが（単純なケースを除いて）現実的でないからでは？ コアのDLLをアップデートする場合、依存関係のチェインは非常に複雑になりえますし、 バックグラウンドサービスの場合、再起動してよいか一般ユーザに判断がつかない場合が多いでしょう。 結局、再起動させるのが唯一の現実解だと思います。
今時のLinux Desktopのことはわかりませんが、もしセキュリティフィックスに再起動を要求せず、 再起動するまで、脆弱性のある共有オブジェクトを利用し続けることを許しているなら、 Linux Desktopのやり方は、一般ユーザに対するアップデート方法として潜在的に危険で不適切な方法だと思います。
パッチの提供が早くなるのであれば歓迎 (スコア:0, おもしろおかしい)
0dayのパッチがWindowsだけ遅い状況が解消されて、うれしい限り
しかし、Windowsのパッチが遅いと書いたときに月1回じゃないととか、
過去の経緯が云々とかいってたMS信者は、月1回を貫き通してほしいものですなｗ
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だってアップデートされたモジュールに関連するプロセスだけを終了させることで、
OSを再起動せずにアップデートできますし、一部にはそうやっている製品も実際にありますよね。
（「アップデートの前にXXXのアプリを終了させてください」ってやつ）
Windows Updateでそれをしないのは、Windowsが対象とするユーザにとって、それが（単純なケースを除いて）現実的でないからでは？
コアのDLLをアップデートする場合、依存関係のチェインは非常に複雑になりえますし、
バックグラウンドサービスの場合、再起動してよいか一般ユーザに判断がつかない場合が多いでしょう。
結局、再起動させるのが唯一の現実解だと思います。
今時のLinux Desktopのことはわかりませんが、もしセキュリティフィックスに再起動を要求せず、
再起動するまで、脆弱性のある共有オブジェクトを利用し続けることを許しているなら、
Linux Desktopのやり方は、一般ユーザに対するアップデート方法として潜在的に危険で不適切な方法だと思います。
これは、一般ユーザの使うOSにとって、利便性を損なうことなく、いたずらにITの知識を要求することもなく、
セキュリティを維持するための適切な方法がどういうものかという問題です。
Windowsのやり方は妥当なものだと思いますよ。
Re: (スコア:0)
同意しますね。
ubuntuのデフォルトにはありませんが、Linux系の場合は事前に手作業で何らかの手順を必須とするような構成を組んでる可能性もあって、簡単に再起動出来ない場合があります。
ただこれ、止めるだけなのに番人や手間が必要な作りを平然と組み込む側の問題で、システム的には如何ともしがたいと思います。
systemdがこのあたりの打開になればいいのですが。。
Re: (スコア:0)
Linuxの場合、更新によってバックグランドサービスは自動的に再起動しますし、それによって問題が起きるべきではないでしょう。
アプリケーションの再起動については、ブラウザを除いてアレですが。
Re: (スコア:0)
mandatory lockは関係するのでは? 関係なければ、再起動前の処理だけで十分であり、再起動後に延々と更新処理する必要がないでしょう。
Re: (スコア:0)
Linuxは違うかも知れないけれど、Unixは管理者がパッチを当てるもので、一般ユーザはイジれない。
パッチ当てたあとどうするかはシステムが決めるんじゃなくて管理者が決める。
基本的に管理者主導な作りだから。
Re: (スコア:0)
Linuxの場合ではなくてパッケージ管理システムが再起動してくれているだけ。
自分でmakeしているような物だと自分で再起動が必要。
Re: (スコア:0)
WindowsがLinuxやBSDに一番負けているのはパッケージ管理システムだよなぁ…
インストーラと自動アップデートを各自組み込むってのは開発コストの面で嬉しくない。
でも、全部込み込みのストアアプリ主体ならその辺はどうでも良くなるが、今度はアプリごとにライブラリのアップデートが…
Re:パッチの提供が早くなるのであれば歓迎 (スコア:1)
別にWindowsだって、実行中のファイルは上書きできないだけで、リネームはできるよ。だからDLLを再起動せずに入れ替える事もできる。
「パッチは適用したつもりだけど、サービス類の再起動を忘れて実は新しいモジュールやデータが反映されてなかった」のが発生するのも同じ。
Re:パッチの提供が早くなるのであれば歓迎 (スコア:3, 参考になる)
それで思い出したので貼っておきます。
Windows 秘話 : Windows では可能でも行わないことがある [microsoft.com]
実は、Windows では元の DLL の名前を変更し、そこに新しいファイルをコピーすることで、使用中の DLL を置き換えることができます。しかし、Windows ではこの処理が行われていません。なぜでしょう。
Re: (スコア:0)
Open中のファイルをリネームできます?
Re: (スコア:0)
実行だけでなく、オープン一般の話であれば、CreateFileの際にFILE_SHARE_DELETEをつけてるならリネームできる。
(Windows KernelがEXE/DLLを実行用に開く時は、このフラグをつけてる)
Re: (スコア:0)
>Windows では、再起動しない場合に発生する複雑さを回避しているだけ
これは酷い言い訳ですね…。脆弱性の修正については、構造体の意味を変更しない小さな修正の方が多いというのに。
まぁ、この先、live patchingの流行(*1)によって、Microsoftも方針を見直すでしょう、多分。
*1 Oracleが、Kspliceをユーザー空間向けに拡張中
http://japan.zdnet.com/article/35063253/3/ [zdnet.com]
Re: (スコア:0)
Hotpatching ぐらい、Windows Server 2003 以降には搭載されています。
Re: (スコア:0)
構造体は一例じゃないですかね。
小さい修正でも組み合わせテストはしなきゃならないから複雑には違いないでしょう。
10DLL×10世代で100パターンとかなったら嫌になる。
現実はもっと多いでしょうし。
Linuxはこの辺の問題をどうやって避けてるんですかね。
＃ってか記事を書いたのRaymond Chenなのか。
Re:パッチの提供が早くなるのであれば歓迎 (スコア:1)
おお、本当だ、凄い。既にWindowsには搭載されてますね>Hotpatching。ただし、Windows Updateからは利用不可(*1)と。ダメじゃん。
Hotpatchingを有効にするためには、アップデータのインストール時の引数に"/hotpatch:enable"を渡す必要があるらしいです。
ううむ、何が問題なんでしょうね。
*1
http://jpassing.com/2011/05/01/windows-hotpatching/ [jpassing.com]
Re: (スコア:0)
リンク先では、
「システムにA.dllと
A.dllから呼び出されるB.dllがあったときに
A.dllだけ更新されると上手く動作しない可能性がある。」
という問題が指摘されています。
でもこれは複数の会社が開発したプロプライエタリなDLLが混在する環境を想定していますよね。
Linuxのようにディストリビュータが全てのソースコードにアクセスできる場合は、
「古いB.dllでも動作するようにパッチを当てたA.dllをリリースする」という方法で対応できます。
(少なくとも理論上は)
このようにちょっとした不具合なら誰でも修正できるのがオープンソフトのメリットです。
Richard StallmanのFreesoftの理念も
「オレのコンピュータで動作しているソフトを自由に改造したい」というものでしょう。