2038年、みんなどうする?
俺の保守担当している製品、ためしに2038年にしたら 見事にあぼーん。 time_tどうなんのよ。 ちなみに俺の定年まであと35年・・。 微妙。 >>9 ありえない話じゃないような気が。 老人になった俺らがBSDを再起動させるのさ。 おまたのボタンお押して再起動させてみるテスト 俺が定年になってるころには出てるはずだ〜!!!!!!!! だれか作ってくれ〜!!!! Registrant: 2038 (2038-N-DOM) planterarv 19 120 48 enskede gard stockholm, se 120 48 SE Domain Name: 2038.COM Administrative Contact, Technical Contact: J.E, Namnet (EB3084)domain-registry@MRFRIDAY.COM erik bar Administrator Sdra Hamnvgen 48 115 41 STOCKHOLM STOCKHOLM SWEDEN 115 41 SE +46-8-641 95 9 +46-8-641 95 9 Record expires on 22-May-2003. Record created on 22-May-1998. Database last updated on 5-Apr-2003 22:26:03 EST. Domain servers in listed order: NS1.SKARPODATA.COM 193.45.208.2 NS2.SKARPODATA.COM 193.45.208.3 32bitなんて、30年後には今の8bitマシン以下の用途になってるだろう。 Windowsもビルゲイツが死んだら終り。 ま〜 time_t を unsigned にしちゃえば22世紀頃まで持つんで、 ファイルシステムとかDBとかのバイナリデータはあんま問題ないと思うけど。 問題はsignedで大小比較してるプログラムのほうだな。 ほんとだ。time_tってsignedだったんだ。知らなかった。 unsigned intにしたら2106年までもつのね…死んでるからそれでいいや。 てことは、逆に考えると前世紀はまるまる今のtime_t で表せるってこと? /* LP64 の環境なら解決済みじゃない? */ #ifndef _TIME_T #define _TIME_T typedef long time_t; /* time of day in seconds */ #endif /* _TIME_T */ 2038年にUNIXって存在するのか? CUI自体ほとんどつかわれていないんじゃないか? そうでもないかな・・・ >>37 おまえが使ってないだけではと小一時間...(ry >>37 正直、低能力なハードウェア性能のせいで ■無闇やたらに視覚に依存しすぎ、かつ重厚長大で能力の低い出力デバイス ■思った通りに操作するために高い習熟が必要で、かつ体に余計な負荷がかかる 入力デバイス にべったりと依存せざるを得ない、今の形式の「GUI」というシロモノも、 35年先には骨董品としてしか生き残っていないような気がするけどなぁ まあ>>37 は世間しらずのヒキー ドザかマカ。 2038年には、ソラリスもAIXもHP-UXもないだろうな。 残るのは、Win BSD Linux . ただし、このどれも現状とは全く違う環境だろうけど。 もしくは、まったく違うOSが出て MSが、そこ潰しにかかって買収して生き残って 技術的な事は公開せず、乗り遅れたBSDやらlinuxは死ぬか。 もしくは、linuxやBSDコミュニティから新しい物が出てくるか。 記念パピコ 漏れの誕生日が1021 妹1212 因縁を感じますた。 >>1 今のうちに全てのシステムを64bitに移行で解決。いじょ UNIXってCのタイプシステムにべったりじゃん。 しかもCの言語的ないい加減さで実装依存だったりするし。 もちろん、それを言い出したらWindowsやMacだってそうなんだけど。 最終的な答えだとは勿論思わないけど、.NETの目指すCommonTypeSystemってのは この辺りのやっかいな問題も含めて考えられているから好きだ。Javaには こういう視点はなかった。以後2038年問題を、time_tをunsigned intにするとか、 時間の起点を2010年にするなどといった珍案で、小手先の回避をするのではなくて 38年までには根本的な解決がなされている方がいいなあ。ある意味、UNIXを 部分的に否定することを意味するけど。 1970年1月1日からの秒数だからな ライブラリがダメっぽ perl のtimeとか・・・ GPSもあれだっけ? MSのlibcが2036年で溢れたような気がするので、 その対策を真似すればいいだろう。 その頃には現行システムは無いだろうなぁ・・・ 若者達に期待w つーか、虫歯無くしたら歯医者が潰れる、ってのと一緒なんでw まぁ2038年特需だ罠。その前にIPv6特需もありそうだが。 つーか、unsigned longかハードとOSが64bit対応して解決しそうなんだけど、、、 時計を巻き戻して使うのがデフォルトのOSが出るとか。 来年まで生きているか分からないので、どうでもいいや… >>76 そういう人に限って、2037年に引っ張り出されていろいろ苦労するだろう、 と想像してみる。 この前、ATM止まったでしょ。あれプチ2038年問題と言えなくもない。 time_tが0x3FFFFFFFから0x40000000になった途端、バッファが溢れてあぼーん。 ま、そういうコード書いた香具師が悪いんだけど。 >>79 いまさらそんなこと誇らしげに書かれても。 38年特需が今から待ち遠しいです。 そのために問題解決をよりこんなんな方向に仕向ける 何かが必要です。マシンをリプレースして万事OKなんて お手軽なやつじゃダメなんです。 128bitUNIXと2038年問題はどっちが先にやってくるでしょうか? time_tってそもそも32ビットのうち1ビットは正負の符号に使ってるの? 俺はそのころ47歳か・・・。 もうそんな歳になっちまったら、正直世の中どうなってても何ともおもわんよ。 >>99 signed longですから。しょうがない。 2000念問題が何事もなかったんだから何も起こらない。 就労 2038年問題を安心して見届けてぽっくり死ぬ奴がこのスレにいるだろうな。 それよりも30828年問題が気になります。 (WindowsのFILETIMEがオーバーフロー) 2038年、2ちゃんが動かなくなっちゃうぞ!あとc言語のプログラムも。。。 たいへんだぁ。2000ねん問題よりも深刻らしいぞ。 タダ単にプログラムを書き換えればいい問題じゃないぞ。 で、何もしないまま>>1 から1413日経過したわけだが 2038年問題勃発まであと11622日と20時間50分 http://sunpillar2004.hp.infoseek.co.jp/javascript/2038.shtml#TIMER 今年中には残り時間10億秒を切っちゃうよ。 BTAMの時刻オーバーフローが懐かしい。 歴史は何度も繰り返すだろう。 本日10時27分28秒、Xデーまで残り10億秒を切りました。 1234567890 2009/02/14 08:31:30 2000000000 2033/05/18 12:33:20 2047483648 2034/11/19 02:27:28(残り1億秒) 焦ってるのはお前ら小物だけで、 ゲイツやジョブスやリナズはもう策を見出しているよ。 read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる