2038年、みんなどうする?
俺の保守担当している製品、ためしに2038年にしたら 見事にあぼーん。 time_tどうなんのよ。 ちなみに俺の定年まであと35年・・。 微妙。 今年生まれる子が、2038年には36歳。 心配しなくてもこいつらがなんとかしてくれる。 >>4 確かにうたがう余地無しだな。こんちくしょう >>3 その通り。年金問題も国債債務問題も靖国問題も環境問題も 官僚問題も同和問題も憲法第9条も特殊法人問題も構造改革も全て先送り。 私達の子孫が何とかしてくれる。 >>6 そして子孫達は問う。 なぜ私達の祖先は何もしなかったのかと。 >>3 「もうUNIXがわかる技術者は君達しかいない」と再召集される罠 time_tを64bitにすれば解決、とかいう話ではない? もちろんファイルシステムとかバイナリデータの互換性は失われるけど。 年号を4桁にすれば解決、とかいう話ではない? もちろんデータベースとかバイナリデータの互換性は失われるけど。 >>8 なぜ、そーゆうコンテクストでは、「金属」バットなんだろ? 木製の方がイケテルとおもうんだけどなぁ。 >>13-14 誰かが勝手にちめを1970に決めてしまったのだから また誰かが2010くらいに起点を決めて うすらとぼければいいのではという話ではない? ところでSunとその上にのるメジャーな商用ソフトは 38年問題は解決済みなのかな?もちろんレガシー の話は抜きにして。 >>17 2038にサポートしてない現在のOSやハードに商用ソフトが (サポート終了しているといえばいいか) あえて解決策をとったりソレを公にアピールする必要は無いと思われ。 64bit化の過程で偶然解決された(される)ことはあるだろうが 2000年問題の事例をみればわかるだろうが 30年経ったらまた書き込むとベスト つーかこのご時世、そこまでつかいつづけんでしょ。 2038年が来る前に、旧いマシンの部品供給がでけんよーになってあぼーんヨ。 アホな会社が、1990年代のソースを2038年まで使いつづけてたら知らんけど。 >>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ビットは正負の符号に使ってるの? read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる