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

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

2025年7月28日原文(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にはそれがないってこと?

Hacker Newsで議論の続きを見る