Linuxなどで同様のオペレーションをしてもキチンとシステム周りが更新されます。
どのような仕組みの差なのでしょうか?
専門用語で解説していただいてかまいません。
よろしくお願いします。
最新でも正確でもありませんが、こんな文章で雰囲気は、つかめますか?
モノリシックなカーネルに様々な機能を取り込むことで巨大化することによる欠点・弊害としては、OSの機能を動的に切り替えたり更新したりすることが(マイクロカーネルと比較した場合に)困難なものになりやすいこと等が挙げられる。
Windows NTは、当初よりマイクロカーネル方式での実装を模索していたが、オーバーヘッドを削減するためにNT 4.0でWindowsサブシステムとグラフィクスデバイスドライバがカーネル空間から直接見える様に修正された。さらにWindows 2000以降では、ハードウェア管理機能の一部をマイクロカーネル直轄のモジュールとしての外部モジュールからカーネル制御部本体による制御方式に切り替えており、純粋なマイクロカーネルから外れた実装になっている。
単純に設計思想の違いじゃないでしょうか。
マルチユーザーなUnixの流れだと、誰かが何かをアップデートしてシステム再起動なんてダメですよね。Windowsは実質シングルユーザー向けですから。
Windowsの功績は再起動への抵抗をユーザーから取り払ったことだって誰かが言っていました。
Windowsでも再起動が必要になるのは基本的にOSに絡む部分など起動時に読み込まれる系のものであり、Linuxでもカーネルの更新ではさすがに再起動が必要なので、その部分は同じ気がします(ちょうど半年前ぐらいにライブパッチ機構入りのものがリリースされましたが http://gihyo.jp/admin/clip/01/linux_dt/201504/14 )。
また、Windowsは定期的にOSのアップデートをMS側が送りつけてきてくれて「再起動しないとダメだよ!」と半ば強制してくれるので「しょっちゅう再起動させられるな!」という印象になるのに対し、Linuxはyum等でパッケージやKernelのファイル自体は更新しているものの「Linuxは再起動しなくて楽だなー」って思いながら古いKernelプロセスのまま使い続けてる人もそれなりにいそうな予感も。
ただ、確かにWindowsの方は通常のアプリケーションっぽいものでもアップデート後に再起動を求めるモノもあり、そういったケースは「プロセスが立ち上がりっぱなしでアップデートされたファイルが有効になってないかもしれないので念のため再起動してね」(=システム的な理由と思想的な理由が半々)の意味合いもあると思います(実際しばらく再起動せずに作業し続けてもそんなに支障がなかったりも)。
Unix系だと設定ファイルの読み直しやデーモン再起動で済むことが多いのでその辺は取り入れて欲しいなあと。サーバ機では同じ操作でも不要なことがあるのも不思議です。
DLLの仕組み的にロードし直しなせいかと思いますがsoだとどうやってるんだろうと。
リンク先のモノリシックカーネルの採用例を見ると
2015/10/18 22:14:12WindowsもLinuxもUnixも入っているのでそこでは差が無いようですが・・・