On 03:14:08 グリニッジ標準時（GMT、別名協定世界時）2038年1月19日（火曜日です）、世界は終わります。 まあ、聖書の「ヨハネの黙示録」のような意味ではないのですが。 しかし、Linuxや旧バージョンのmacOSなど、32ビットベースのUnix系OSの時間の値が足りなくなり、負の数で時間をカウントし始めるということが起こるのです。 これは良くないことです。 これらのオペレーティングシステムを実行している32ビットコンピュータは、発作を起こすことが予想されます。 幸いなことに、Linuxの開発者はすでに修正プログラムを用意していた。
問題は、Unixが時間を伝える方法から始まっています。 Unix とその関連システムである Linux、macOS、およびその他の POSIX 互換 OS は、時間の始まりを 1970 年 1 月 1 日の Epoch: 00:00:00 GMT から記録しています。 Unix系は、エポックからの秒数で時間を計ります。
ここまではいいとして。 しかし、Unix系は32ビットOSとしてスタートしたため、時刻の値は1つの符号付き32ビット整数値として保持されます。 それは多くの秒数ですが、前世紀のY2Kバグと同じように、十分ではありません。
Linux の開発者は、何十年も前からこの事態が起こることを見越していました。 そこで、Linuxカーネル開発者のArnd Bergmannらは修復に取り組んできた。 これらの修正は、近々リリースされるLinux 5.6カーネルに搭載されています。 Bergmann は、「Linux-5.6、または私が 5.4 にパッチをバックポートしたものは、2038 年以降も動作するように設計された 32 ビット システムのベースとして機能する最初のリリースになるはずです」と説明しています。
いくつかの注意点があります。
- すべてのユーザー空間は 64 ビット time_t でコンパイルしなければならず、それは来る musl-1 でサポートされることになります。2 および glibc-2.32 リリース、および Linux-5.6 以降のインストール済みカーネル ヘッダーでサポートされます。
- システムコール インターフェイスを直接使用するアプリケーションは、既存のシステムコールの代わりに Linux-5.1 で追加された time64 システムコールを使用するように移植される必要があります。
- カーネル uapi ヘッダー ファイルのプライベート コピーまたはそのコンテンツを使用するアプリケーションは、Linux-5.6 バージョンにアップデートする必要があるかもしれません。
- 残りのいくつかのインターフェイスは、互換性のある方法で 64 ビット time_t を渡すように変更できないため、CLOCK_MONOTONIC 時間を使用するように設定する必要があります。 特に、これは、符号付き 32 ビット秒を使用するディスク上のタイムスタンプを持つファイル システムに影響します: ext4 with ext3-style small inode, ext2, xfs (to be fixed soon) and ufs。
MacOS は 10 年以上にわたって 32 ビット ソフトウェアからの移行を進めてきました。 しかし、ttは、Appleが32ビットアプリにブートを与えたのは、2019年後半のリリースであるmacOS Catalinaのときでした。
さて、あなたは不思議に思うかもしれません — 最近では私たちは皆 64 ビット コンピューターを実行しているので — なぜこれが問題になるのでしょうか。 それは、次のようなことです。 まず、多くの組み込みシステムおよび IoT (Internet of Things) デバイスは、まだ 32 ビット オペレーティング システムを実行しています。 実際、2038年までには、おそらくまだ新しい32ビットデバイスが市場に登場することでしょう。
また、2020年にY2Kバグが再び出現するおかげで、18年後に埋立地に捨てられると想定されるシステムがまだ健在で、エポックにはひどく誤動作することも分かっています。
しかし、このように考えてみてください。 これを修正した後は、12 月 4 日 (日) 15:30:08 GMT (29,227,702,659) まで、64 ビット Linux の秒数不足を心配する必要はなくなります。 個人的には、その心配はないのですが。
関連記事：
- Y2Kバグが復活、再び開発者の頭痛の種に
- 韓国政府、WindowsからLinuxデスクトップに移行検討
- 不快なLinux、macOS sudoバグ発見し修正
