アカウント名:
パスワード:
https://ja.wikipedia.org/wiki/%E9%96%8F%E7%A7%92 [wikipedia.org]＞この現行方式のUTCは1972年に始まった。
これでタレコミ文の＞うるう秒の問題は一般的に使用されるオペレーティングシステムでは処理ができないことが多く、が事実とするなら驚愕するしかない。アプリケーションならともかく。
驚愕も何も、実際に、2012年にもなってうるう秒を処理できなかったOSがあったんだよ…。http://ringeye.jawfish.org/~ori/misc/leapsecond-20120701.html [jawfish.org]
有名な話やで。
2012年の閏秒でのLinuxカーネルトラブルの重要なポイントは、「閏秒に対応していなかったために問題が起きた」のではなく、「前回の閏秒以降に閏秒関係のコードにバグが混入していた」のが「閏秒実施のタイミングで発覚した」という所でしょう。
そんなわけで、「バグはもう直したから大丈夫」とは言い切れるものではなく、「前回の閏秒以降に新たなバグが混入したかも」とドキドキする羽目になるんです。
対策としては、ntpd を slew モードにするのが無難ですね。1秒につき0.1m秒ずつ、3時間ちょっとかけて正しい時間に修正してくれるので問題はおきないはず。
優しさ（？）で個別の事件には言及してませんけど、実際のところは、2012年のLinuxの事故の経験が今回のような対応を取ることになった理由ですよね。
まれにしかないイベントに対応するシステムの信頼性確保は難しい。
うるう秒を0.1秒単位にして頻繁に入れれば実行する頻度が上がって信頼性が上がりますよ。
大震災とか大津波のときにだけ作動するシステム…どきどき…。
# さすがに、しくじると人命に直結するシステムはかんべんです。気象会社の津波警報とか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
44年間なにをやってた？ (スコア:0)
https://ja.wikipedia.org/wiki/%E9%96%8F%E7%A7%92 [wikipedia.org]
＞この現行方式のUTCは1972年に始まった。
これでタレコミ文の
＞うるう秒の問題は一般的に使用されるオペレーティングシステムでは処理ができないことが多く、
が事実とするなら驚愕するしかない。アプリケーションならともかく。
Re:44年間なにをやってた？ (スコア:0)
驚愕も何も、実際に、2012年にもなってうるう秒を処理できなかったOSがあったんだよ…。
http://ringeye.jawfish.org/~ori/misc/leapsecond-20120701.html [jawfish.org]
有名な話やで。
Re:44年間なにをやってた？ (スコア:1)
2012年の閏秒でのLinuxカーネルトラブルの重要なポイントは、
「閏秒に対応していなかったために問題が起きた」のではなく、
「前回の閏秒以降に閏秒関係のコードにバグが混入していた」のが「閏秒実施のタイミングで発覚した」
という所でしょう。
そんなわけで、「バグはもう直したから大丈夫」とは言い切れるものではなく、
「前回の閏秒以降に新たなバグが混入したかも」とドキドキする羽目になるんです。
対策としては、ntpd を slew モードにするのが無難ですね。1秒につき0.1m秒ずつ、3時間ちょっとかけて正しい時間に修正してくれるので問題はおきないはず。
Re:44年間なにをやってた？ (スコア:1)
優しさ（？）で個別の事件には言及してませんけど、実際のところは、
2012年のLinuxの事故の経験が今回のような対応を取ることになった理由ですよね。
まれにしかないイベントに対応するシステムの信頼性確保は難しい。
Re: (スコア:0)
うるう秒を0.1秒単位にして頻繁に入れれば実行する頻度が上がって信頼性が上がりますよ。
Re: (スコア:0)
まれにしかないイベントに対応するシステムの信頼性確保は難しい。
大震災とか大津波のときにだけ作動するシステム…どきどき…。
# さすがに、しくじると人命に直結するシステムはかんべんです。気象会社の津波警報とか。