ハクソク

世界を動かす技術を、日本語で。

Debianがすべてにおいて64ビット時間に移行

301日前原文(theregister.com)

概要

  • Debian が「Y2K38問題」対策として 64ビットtime_t へ移行
  • Debian 13 "Trixie" から32ビットアーキテクチャにも適用
  • i386 のみ互換性維持のため32ビットtime_tを継続使用
  • 移行は ABI非互換 の大規模変更
  • 詳細や検証方法は Debian Wiki で案内

Debian、Y2K38問題への対応策

  • Debian は「Unix Epochalypse」こと Y2K38問題 回避のため、 64ビットtime_t を32ビットアーキテクチャにも導入
  • Debian 13 "Trixie" リリース以降で適用予定
  • 32ビット符号付きint による時間表現が 2038年1月19日03:14:07 UTC で限界値を超える問題
  • 64ビットtime_t への移行で2038年問題を根本解決
  • i386ポート は既存x86バイナリとの互換性維持のため32ビットtime_tを継続利用
    • 新しい i686 ABI/アーキテクチャ 導入の可能性も検討
  • hurd-i386 はカーネル未対応のため未移行、 hurd-amd64 への切替作業中

Y2K38問題の背景と重要性

  • Y2K問題 （2000年問題）と同様、 システムの長期的安定性 への影響
  • Unix時間 は1970年1月1日からの経過秒数で管理
  • 32ビット符号付き整数 では約68年分しか表現できず、2038年でオーバーフロー
  • 64ビットハードウェア では既に問題なし
  • Debian は 古い/組込機器 や リソース制約環境 で広く利用
    • IoT機器、車載、TV、ルーター、産業制御 など

技術的対応と影響範囲

  • time_t変数 は 6,429パッケージ に分散
  • ABI非互換 のため、全関連ライブラリを同時に更新
  • Debian は十分な検証を実施し、移行準備完了を宣言
  • 既存x86バイナリ との互換性維持や 移行手順 も検討
  • 開発者向けに 64ビットtime_t での動作確認方法を Debian Wiki で公開

今後の展望と注意点

  • コスト重視の32ビット機器 は依然出荷・稼働中
    • OpenEmbedded、Alpine、Android、Gentoo 等も活用
  • Debianベース の組込用途は今後も一定期間残存見込み
  • 2038年問題 への早期対応で「Y2Kの二の舞」回避
  • 新規開発 や 長期稼働システム では 64ビットtime_t 対応の重要性増大

参考情報

  • 詳細や移行ガイド、テスト方法は Debian Wiki 参照
  • 開発者・管理者は 自システムの対応状況 確認推奨

Hackerたちの意見

「すべて」というのは、最も広く使われている32ビットアーキテクチャの一つを含まない「すべて」のことだよね。（皮肉はさておき、i386の変更についての議論は理解してるし、彼らが正しい判断をしたと思う。ただ、見出しにはちょっと疑問があるかな。）

└

i386がまだ広く使われてるとは思えないな。Linuxを動かしてるのは、むしろ組み込みのARM32デバイスの方が多いし、x86はレトロコンピューティングのコミュニティに限られると思う。

└

i386はtrixieではもうちゃんとサポートされてないみたい:

trixieからは、i386は通常のアーキテクチャとしてサポートされなくなりました。公式のカーネルも、i386システム用のDebianインストーラーもありません。 i386システムを使っているユーザーは、trixieにアップグレードしない方がいいです。代わりに、可能であればamd64として再インストールするか、ハードウェアを引退させることを推奨します。 https://www.debian.org/releases/trixie/release-notes/issues....

└

産業機器のコントローラーや組み込みボードのような32ビットx86の実用は、最近はi686をサポートしていて、64ビットのtime_tに移行してるね。

無制限の動的コマンドライン長に切り替えられない？96GBのシステムで「引数リストが長すぎる」っていうのにうんざりしてるんだよ。

└

xargsって聞いたことある？

└

100k近いコマンドライン長の制限を回避するためにカーネルを再コンパイルできるよ: https://stackoverflow.com/questions/33051108/how-to-get-arou... でも、これは問題の根本を解決してない気がする。4kのJPEG分のコマンドライン引数が何に使われるのか、全然わからないし。

└

RLIMIT_STACKの値を上げればいいよ。例えば、ulimit -s 4000で4MBのスタックに簡単に調整できる。けど、もっと大きくするには/etc/security/limits.confみたいなファイルを変更して、ログアウトして再ログインする必要があるかも。

└

MAX_ARG_STRLENを再定義してカーネルを再コンパイルすることもできるよ。もしくは、ページサイズが大きいマシンを使うって手もある。例えば、RHELは64kページサイズのArmカーネルを提供してるし。でも、コマンドバッファじゃなくてプロセス間で物を移動させるのにパイプを使う方が簡単だよね…

└

Electronにパッケージ化して、HTTP POSTのJSONリクエストを送信すればいいよ。

└

96GBって何か関係あるの？それってブートディスクのサイズ？

Debianは、Debian 13「Trixie」のリリース後に移行することに自信を持っている – 少なくともほとんどのハードウェアに対して。つまり、Trixieにはそれがないってこと？

└

リリースノートによると、trixieに入ってるみたいだよ: https://www.debian.org/releases/trixie/release-notes/whats-n...

ただ先延ばしにしてるだけだね。292277026596年12月4日の15:30:07 UTCに人々は何をするんだろう？

└

その頃にはもっと良いカレンダーに移行してるといいけど… とはいえ、タイムスタンプの問題は変わらないよね。

└

地球の表面のすべては、太陽が赤色巨星になるまでの50億年以内に蒸発するだろうね。

└

完全なIPv6の採用から100年を祝おう！

└

128ビットの時間に移行しよう。

└

それはとても素晴らしい問題だね。

└

UTCは292277026596年になる前に、もう存在しなくなるだろうね。

すべての解決策が64ビットの秒数だけで済むわけじゃないけど、64ビットのtime_tは確実にエポカリプスを解決するよ。ext4はかなり前に30ビットの小数点解像度（ナノ秒単位）と34ビットの秒解像度に移行したんだ。これで問題を400年くらい先に先送りできる。最終的には128ビットのタイムスタンプ、64ビットの秒数と64ビットの小数点解像度に落ち着くと思うし、それで人類の foreseeable な歴史には対応できるはず。

└

ありがとう、ext4とタイムスタンプについて気になってたんだ。zfsやbtrfs系のファイルシステムはどうしてるんだろう。ちょっと調べるのが面倒だけど、btrfsは64ビットを使ってると思う。zfsについては、ext4に合わせてるなら驚かないな（編集：ここはext4のことを言いたかった）。

└

64ビットの秒数って、だいたい5850億年だね。[1]

Debianのメンテナは、関連する変数time_tを「あちこちで見つけた」と言ってるけど、ちょっと違うよ。time_tはデータ型であって、変数じゃないから。

└

これはDebianのウィキページの記者による要約で、「time_tはあちこちに出てくる。Debianの35,960パッケージのうち6,429がソースにtime_tを含んでいる。ABIでtime_tを含む構造体を公開しているパッケージはABIが変更されるため、そういったライブラリは一緒に移行する必要がある」と書いてある。ウィキページで記事よりも明確に感じた重要な点がいくつかあるよ。「すべてのプラットフォーム」というのは「armel、armhf、hppa、m68k、powerpc、sh4では対応するが、i386ではない」という意味。i386にはあまり未来がないと判断されたみたいで、主に既存のバイナリ（動的リンクのものも含む）を動かすためのものだから、互換性を壊したくないみたい。「Debian 13 'Trixie'のリリース後に移行が行われる」というのは「この変更はTrixieに含まれる」という意味だね。

問題はtime_tじゃないよ。それを使うなら64ビットへの切り替えは簡単なんだ。問題は、開発者が馬鹿な理由でintを使ったときだね。そうなると、そのすべてのインスタンスを見つけてtime_tに変更しなきゃいけない。

└

sizeof(time_t)が変わると何が起こるかを評価するのは、intをtime_tに置き換えるより難しいから、そこが問題だとは思わないな。

└

そんなに簡単じゃないよ。彼らはまた多くのライブラリのユーザースペースABIを壊しちゃったから。だからパッケージ名が全部変わるし、ユーザーにdebを配布するのが面倒なんだ。明らかに、誰もそんなことをすべきじゃないというイデオロギー的な信念を持ってるみたいだけど、彼らは間違ってる。

└

time_tがキャストされるたびにフラグを立てるアナライザーを使ったらどう？小さすぎるmemcpyも追加しておくといいかも。たぶん、time_tから実際に64ビットのデータ型へのキャストが厄介かもしれないね。例えば、こんな感じの構造体 Callback { int64_t(*fn)(int64_t); int64_t context; } で、contextにtime_tを使って、int64_tをint32_tにダウンキャストしたら、捕まえるのが難しいかも。もしかしたら、int64_tが実際に何かを注釈するためにランタイム型情報が必要かもね。

└

ほとんどのオープンソースソフトウェアパッケージはBSD系にもコンパイルされていて、ずいぶん前に64ビットのtime_tに切り替えて、問題があれば上流に報告してるよ。

└

そうだね、問題は32ビットと64ビットのアーキテクチャの違いというより、時間のデータ表現の方が大きいみたい。間違ってたら教えてほしいけど、32ビットチップが登場するずっと前からlong intはあったと思うし（64ビットの前にはlong longもね）。システムスケジューラーが1970年1月1日からの経過秒数を知る必要があるのかな？1日に86400秒しかないし（1年は31536000秒、2^32 = 4294967296 - これで十分じゃない？時間を2つに分けてもいいと思うけど）。余談だけど、1年前に古いラズパイを使ってテレビでちょっとしたコンピューターステーションを作ろうとしたんだけど、最新のraspbian-i386はかなりひどかった。数年前に似たようなことをやったときはもっとサクサク動いてた気がするし、周辺機器の認識も良かったような気がする。今は新しい技術を買わないとダメって感じだし、古いものはもう役立たずになってるんだろうな。デザインされた陳腐化って言葉がぴったりかも。トンネルの先に光が見えたのはRISC OSを見つけたことだけど、3ボタンマウスのせいでうまくいかなかったし、時間も足りなかった。またこのプロジェクトに戻ることがあれば、SARPi（Slackware）も考えてるし、Plan 9もありかも？最近の子供たちは古いコンピュータが魅力的じゃないと思ってるみたい。まあ、それも仕方ないけど、環境にもお財布にも優しいかもしれないね。

スティーブ・ランガセックは、人生の最後の数年間にこの問題に取り組むことを決めて、進展の大きな原動力となりました。彼がいなくなるのは寂しいし、64ビットのtime_tを見るたびに彼のことを思い出すだろうな。

OpenBSD 5.5が同じ変更を行ったのは、たった11年後のことだよね。https://www.openbsd.org/55.html

└

ちょっと話が逸れるけど、こういう時こそ、パブリックサーバーをLinxからOpenBSDに切り替えたくなるな。

└

OpenBSDは互換性をあまり気にしなくていいし、ユーザーも桁違いに少ないから、変更が珍しいエッジケースからバグを引き起こす可能性も低いんだよね。

ある年代の読者は、2桁の年を使って数バイトを節約しようとした結果生じた「Y2K問題」をよく覚えているだろう。つまり、「2000年」は「00」と表現され、「1900年」と見なされていた。この表現はちょっと厳しすぎる気がする。1. 一部のシステムや用途では、その2バイトは非常に高価だった、90年代中頃まで。2. 70年代、80年代、90年代にはソフトウェアが急速に進化していて、5年後にまだ使われているとは思わなかったし、ましてや神話の「2000年」まで続くとは考えていなかった。

└

これは「早すぎる最適化」が良かったケースだね。日付を1900年からの単純な整数値で表現できたはず。日数を日/月/年に変換するのは、70年代のコンピュータでもかなり簡単だし、最終的には数バイト以上の節約になったはず。3バイトで1900年から約44000年までの日数を表現できるし、2バイトでも1900年から2070年までカバーできたよ。

└

Y2Kの直前に、大手銀行の株が暴落すると思って大量のプットオプションを買った人を知ってるけど、結局あんまり起こらなかったね…