Did you know...?LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. Sometimes it seems that things have gone relatively quiet on the year-2038 front. But time keeps moving forward, and the point in early 2038 when 32-bit time_t values can no longer represent times correctly is
System call conversion for year 2038 [LWN.net] lwn.netでLinuxカーネルを2038年問題に対応させるにはという記事が公開されている。 32bit版Linuxカーネルのtime_tはsigned 32 bitなので、現行の32bit版Linuxカーネルをそのまま使い続けるシステムは、2038年問題の影響を受ける。 問題の日付が近づくにつれ、32bitシステムは様々な楽しげな理由により障害を起こすことが予測されるので、今日のLWN読者は、退職から呼び戻されて、紀南を救うために英雄的な活躍をするだろう。今対策をしなければの話だが。 さて、32bit Linuxカーネルでも、time_tなどの時間の表現に64bitの値を使えば2038年問題は解決できるか。実は、問題はそれほど単純ではない。 カーネル内部の時間表現を64bitに移行するだけでは
Linux 3.16 カーネルがリリースされたわずか2か月後に、Linux 3.17 も世に出た。 Linux 3.17 カーネルは、これまでのところ、2014年では5番目のメジャーカーネルリリースだが、今後24年間は実際には Linux に衝撃を与えない欠陥を修正するためのものだ。 UNIX 2038年バグは、概念的には幾分、1999年まで多くのシステムで修正されなかった Y2K(2000年問題)問題に似ている。しかし、Linux 開発者は2037年まで待つつもりはなく、2000年問題の修正体験を再現しようとは思っていないようだ。 Linux 3.17 があれば、少なくとも2038年問題を修正するパッチがひとつはあることになるが、将来のリリースでは、いくつかの追加作業もありそうだ。 「非スカラー ktime_t の実装は、基本的に、32ビットシステムで過去2038年の日付のサポートを変更
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く