%includes; ]> &header;
2000 年問題 (別名, 「千年紀のバグ」) に対する経営側の理解が深まるにつれ, より多くの企業から, ハードウェアやソフトウェアのベンダに対して, 彼らの製品は 2000 年におこる転覆にどのように対処するのか, 公的な所信表明を要求する声が出てきています.
Unix や FreeBSD のような Unix like OS を使用している団体は, 既にその問題の一歩先を歩んでいます. FreeBSD は 2000 年が過ぎてだいぶたった後でも, 正しく時間を維持することができるでしょう.
(この節は Linux Y2K compliance page の文章に基づいたものです)
すべての Unix と Unix ライクなオペレーティングシステムと同じように, FreeBSD における時間と日付は, 内部的には, 1970 年 1 月 1 日 (Unix の「紀元年」) からの秒数で表現されています. 現在のところ, この数字は 32 bit 長の整数として格納されており, これは 2038 年とちょっとまで行ったところで使い果たされる計算になります. そして, (望むらくは) その頃には, 我々はこの宇宙の終わるときまで役に立つ, 64 bit 長の (あるいはそれ以上の長さの) カウンタを使用しているでしょう.
OS が 2000 年問題に対応済であっても, それが 2000 年問題に対応していない, 誤ったアプリケーションの問題を解決するわけではないことに注意してください.
OS が現在の日時や日付をコンピュータの CMOS クロックから読み込んでいることにも注意してください. それらのデバイスすべてが 2000 年を正しく扱えるわけではありません. ハードウェアクロックが 1999 年から 2000 年へ正しく移行できること, そして 2000 年を正しくうるう年として扱えることを, 各プラットフォームで個別に確かめた方が良いでしょう.
FreeBSD は次の世紀に入っても, 正しく時間を維持し続けることができるでしょう. しかし, サードパーティ製のアプリケーションはそうでないかもしれません. 2000 年問題に対しては, 攻撃は最大の防御と言えます. おなじみの来るべき世界の終わりについての物語にただ耳をすましているだけでは, 千年紀のバグを解決することはできません. ただその時が来るのを待っていても同じことです. FreeBSD プロジェクトは, あなたの団体が, 千年紀の問題に対しても, しっかりしたシステム管理の原則を適用することをお勧めします.
あなたのシステムがどのように反応するか確認する方法があります. クロックを新年の数分前に合わせ, システムの時間を観察して下さい. システムは年として 1900 ではなく 2000 を表示しなければなりません. そして, もし年の表示が不正確であっても, ハードウェアをアップデートするのに十分な時間があるわけです. また, クロックを先に進めたまま, 情報システムに日常の業務を行わせれば, システムのどの部分が 2000 年問題に弱いのか, 価値ある洞察を得ることができます.
「我々は, FreeBSD は 2000 年 (Y2K) 問題に対応済であると信じていますが, それでも保証することはできません. 我々はこの問題を検証するのに膨大な時間を割いてきましたが, それでも何かが見落とされている可能性があるからです. もし将来 2000 年問題に関係するバグが発見された場合, 我々はできる限りすみやかに問題を修正するように努力します.」
David Greenman
Principal Architect, The FreeBSD project
FreeBSD 上では, 以下の 2000 年問題は既に発見され, 修正されています.
この節は, 今はただの場所取りにすぎませんが, 2000 年問題を持つアプリケーションが見つかった場合, そのアプリケーションの名前と, (もし存在するならば) そのソフトウェアのどのバージョンで問題が修正されているのか ここで明らかにしてゆくつもりです.
FreeBSD の 2000 年対応について更なる質問をお持ちであるか, FreeBSD 下で走る 2000 年対応済でないアプリケーションを発見した場合, freebsd-bugs@FreeBSD.ORG まで連絡してください.
&footer;