X
2038年、みんなどうする？
0194名無しさん＠お腹いっぱい。
垢版 |
2008/01/21(月) 19:46:24
どうもこのまま行くと2038年頃には革の鎧を着たモヒカン男が
一般市民を襲ってる時代が来そうなのであまり心配する必要はないと思えてきた。
0195名無しさん＠お腹いっぱい。
垢版 |
2008/01/21(月) 21:28:42
>>194
だが、コマンドラインのUnixなマシンは尚も稼働していたのだった。
新世紀Unix伝説　ラヲウさまはUnixによる覇道完遂　ケンシロウは…

最終決戦で、ラヲウさまは天にボードを突き上げ咆哮「我がうにくす人生に一片の悔い無し」
0196名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 12:50:18
今日になって、あと 30 年ないことに気がついた・・。
0198名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 14:54:32
そんなの関係ない、そんなの関係ない、そんなの関係ない・・・

おれ多分現役じゃありませんから。
0199名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 17:40:31
>>197
いや、だから、 30 年もないです。

あと、 29 年 11 カ月とちょっとです。
0200名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 20:50:45
今のうちに高台へ非難する
0201名無しさん＠お腹いっぱい。
垢版 |
2008/01/28(月) 20:05:31
預言者ジュセリーノは2042年に人類は滅亡すると言っている。
2038年と4年しか違わない

2038年が人類のタイムリミットに思えてくる。
預言は本当かもしれない、と思うのはやっぱ歳をとったからか
0204名無しさん＠お腹いっぱい。
垢版 |
2008/01/30(水) 04:16:53
2000年問題の後に2038年問題が起こる
一度起きた事をもう一度繰り返す。
それってただの馬鹿じゃん。
問題を先延ばしにしてもそれは解決した事にはならない
根本的な問題を解決できなければそこでUNIXは終わりだな
0205名無しさん＠お腹いっぱい。
垢版 |
2008/01/30(水) 05:21:43
>二度繰り返す
いや、Y2K需要が記憶から消えた辺りで38を仕掛ければ
大概の企業の担当は世代が入れ替わっているので
ほくほく、同じ手でボッたくれるのです。
0207名無しさん＠お腹いっぱい。
垢版 |
2008/02/03(日) 13:14:42
>>203
動的というなら

メモリがでかくなりすぎて、そろそろmallocの引数が悲鳴を上げるんじゃね？
特に32bit版でコンパイルして、64bit版で使った場合。互換性あるようコンパイルしとけば、そのまま使えるでしょ。たしか

2GB以上一度に確保するとやばいことになる予感
0210名無しさん＠お腹いっぱい。
垢版 |
2008/02/15(金) 12:51:02
Matzにっき(2008-02-09)
http://www.rubyist.net/~matz/20080209.html

_ [言語] use Perl | Perl is now Y2038 safe
http://use.perl.org/articles/08/02/07/197204.shtml

Perlが2038年問題を解決した、という話。

基本的なアルゴリズムは

1. Write a 64 bit clean gmtime().
2. Run your time through this new gmtime_64().
3. Change the year to a year between 2012 and 2037.
4. Run it through the 32 bit system localtime() to get time zone stuff.
5. Move the year back to the original.

というもの。もちろん、政治的に決まるDST(夏時間)には対応不可能だが、未来のことは誰にもわからない(ので対応は期待されない)ので大丈夫。

Rubyも同じやり方で対応しようかなあ。でも時間関数にはトラウマがあるので(DSTバグでえらい苦労した)、あまり自分ではやりたくないなあ。

誰か手をあげてくれないかなあ。
0211名無しさん＠お腹いっぱい。
垢版 |
2008/02/20(水) 11:58:06
UNIX誕生から約40年、これから約30年あることを考えれば、
そのうちなんとかなるべよ、って気もする
0212名無しさん＠お腹いっぱい。
垢版 |
2008/02/22(金) 02:58:32
>>207
別に確保に失敗すればNULLを返すだけでしょ。
今も何も変わらない。
0221名無しさん＠お腹いっぱい。
垢版 |
2008/06/02(月) 01:01:12
2038年問題他のカウントダウンRSS作ってみた
http://sunpillar.jf.land.to/cgi-bin/RSS/rss.cgi?rss=countdown

2038年問題が発動するまでサイトが持つかどうかわからないし、
今後RSSなんて廃れた技術になっちゃうかもしれないがｗ

あと日で計算してるから、秒計算のカウントダウンタイマーとは1日ずれる時間帯がある

--
2038年問題発生まであと10822日
0224名無しさん＠お腹いっぱい。
垢版 |
2008/10/02(木) 12:45:08
2038年〜新しいウィルスが開始した

2040年前半〜限界のウィルスが壊れた

2040年後半〜ウィルスでゾンビ達になった。アメリカから


2041年〜世界全滅


2056年〜世界で20人は生き残っています
0228名無しさん＠お腹いっぱい。
垢版 |
2008/12/12(金) 01:54:25
システムコールはそうでないから、/* e.g.stat(2) */
ファイルシステムだけ64bitにしても、
結局は既存のls(1)等が利用できるように32bitにして渡してやらないといけない。
つまりユーザ側からは64bitになったことは見えない。
というわけで、急いで64bitにする必然性がない。
fpos_tが64bitになった時のように、
システムコールを二枚立てにするんじゃないかな。
0229名無しさん＠お腹いっぱい。
垢版 |
2008/12/12(金) 17:40:14
coreutilsを64bitOSで動かせばいいんじゃないの？
ファイルシステムが32bitだから64bitOS使っても38年問題が残るという話なんだけど
0231名無しさん＠お腹いっぱい。
垢版 |
2008/12/12(金) 22:15:23
64bitOS(ILP64)では、sizeof(size_t)は必然的に8になってるだろうが、
sizeof(time_t)を必ず8にする必要はない。
逆にIP32でもtime_tは64bitにした方が良い。IP16でさえ。
0232名無しさん＠お腹いっぱい。
垢版 |
2008/12/18(木) 16:14:34
ext2のmtime　　unsigned int
struct inodeのmtime　long
なので
64bitOSなら19700101を起点として2106まで使えるということみたいですね。
struct inodeの中の日付データはlongなのでキャッシュされてる時点では、
unsigned intの範囲外のデータも扱えるということですか。64bitOSにて、
2106以降の日付を誤って入力した場合、保存されるデータはすべて2106に直されるけど、
1970以前の値の場合はどんな値になるか、入力されたデータ次第ということですね。
30年後は分からないけど、100年後にはLinuxなんて100%消滅してるはずなので、
これが一番現実的かも。
0233名無しさん＠お腹いっぱい。
垢版 |
2008/12/24(水) 23:57:18
>>208自己レス（随分前だけど、たしか自分のレス）
ext4は1901年12月14日から2514年4月25日までだった。ただしソースはウィキペディア

http://ja.wikipedia.org/wiki/Ext4

>>232
それだと1970年以前の日付が表記できなくなる。でも、1970年以前の日付使う必要性がないからまあいいかｗ

--
あと、参考までにこの間x86-64で試した結果
sizeof(int) =4
sizeof(long int)=8
sizeof(long long int)=8
sizeof(void*)=8

x86だとこうなる
sizeof(int) =4
sizeof(long int)=4
sizeof(long long int)=8
sizeof(void*)=4
0244名無しさん＠お腹いっぱい。
垢版 |
2009/07/13(月) 20:26:16
>>243
自己レス。残念、2秒遅かった・・・

ちなみに
残り10億　Sat May 13 2006 10:27:28 GMT+0900
残り 9億　Mon Jul 13 2009 20:14:08 GMT+0900
残り 8億　Thu Sep 13 2012 06:00:48 GMT+0900
残り 7億　Sat Nov 14 2015 15:47:28 GMT+0900
残り 6億　Tue Jan 15 2019 01:34:08 GMT+0900
残り 5億　Thu Mar 17 2022 11:20:48 GMT+0900
残り 4億　Sat May 17 2025 21:07:28 GMT+0900
残り 3億　Tue Jul 18 2028 06:54:08 GMT+0900
残り 2億　Thu Sep 18 2031 16:40:48 GMT+0900
残り 1億　Sun Nov 19 2034 02:27:28 GMT+0900

残り1000万秒　Fri Sep 25 2037 18:27:28 GMT+0900
残り 100万秒　Thu Jan 07 2038 22:27:28 GMT+0900
残り　10万秒　Mon Jan 18 2038 08:27:28 GMT+0900
残り　 1万秒　Tue Jan 19 2038 09:27:28 GMT+0900
残り 1000秒　Tue Jan 19 2038 11:57:28 GMT+0900
残り　100秒　Tue Jan 19 2038 12:12:28 GMT+0900
残り　 10秒　Tue Jan 19 2038 12:13:58 GMT+0900
残り　　1秒　Tue Jan 19 2038 12:14:07 GMT+0900
0246名無しさん＠お腹いっぱい。
垢版 |
2010/01/10(日) 14:06:28
19 日であと 28 年かぁ。
0247名無しさん＠お腹いっぱい。
垢版 |
2010/01/19(火) 18:58:56
2038年1月19日は今日と同じ火曜日でうるう年の2年後。
月日曜日だけが問題になるシステムなら2010年か1982年に戻せばいいかもしれないがそんなシステム少ないですよね。
0248名無しさん＠お腹いっぱい。
垢版 |
2010/01/19(火) 23:36:01
残り28年。まだまだ先だけど、着実にその時は近づく…
0254名無しさん＠お腹いっぱい。
垢版 |
2010/09/04(土) 07:53:04
残り10000日を切った。

残り9999日と4時間20分ぐらい
0256名無しさん＠お腹いっぱい。
垢版 |
2010/09/16(木) 18:43:02

残り10億　Sat May 13 2006 10:27:28 GMT+0900
残り 9億　Mon Jul 13 2009 20:14:08 GMT+0900
残り 8億　Thu Sep 13 2012 06:00:48 GMT+0900
残り 7億　Sat Nov 14 2015 15:47:28 GMT+0900
残り 6億　Tue Jan 15 2019 01:34:08 GMT+0900
残り 5億　Thu Mar 17 2022 11:20:48 GMT+0900
残り 4億　Sat May 17 2025 21:07:28 GMT+0900
残り 3億　Tue Jul 18 2028 06:54:08 GMT+0900
残り 2億　Thu Sep 18 2031 16:40:48 GMT+0900
残り 1億　Sun Nov 19 2034 02:27:28 GMT+0900

残り1000万秒　Fri Sep 25 2037 18:27:28 GMT+0900
残り 100万秒　Thu Jan 07 2038 22:27:28 GMT+0900
残り　10万秒　Mon Jan 18 2038 08:27:28 GMT+0900
残り　 1万秒　Tue Jan 19 2038 09:27:28 GMT+0900
残り 1000秒　Tue Jan 19 2038 11:57:28 GMT+0900
残り　100秒　Tue Jan 19 2038 12:12:28 GMT+0900
残り　 10秒　Tue Jan 19 2038 12:13:58 GMT+0900
残り　　1秒　Tue Jan 19 2038 12:14:07 GMT+0900
0260名無しさん＠お腹いっぱい。
垢版 |
2011/01/21(金) 21:48:30
残り27年age
0265名無しさん＠お腹いっぱい。
垢版 |
2011/04/22(金) 23:55:09.29
アプリケーションが完全に対応するのに10年以上はかかるだろうから
OSは今から10年以内に対応を終える必要がある
0268名無しさん＠お腹いっぱい。
垢版 |
2012/01/21(土) 18:53:05.70
残り26年age
そして、もうすぐスレ立って10年だな
0269名無しさん＠お腹いっぱい。
垢版 |
2012/05/13(日) 17:02:25.07
スレ10周年・・・・って昨日だったかw

2038年問題って大分解決したんだろうか。最近知った話だと、B-CASも2038年問題があるらしい
（契約終了日を表す変数の最大値が0xffff=2038年4月22日なのでそれ以降使えない）
0271名無しさん＠お腹いっぱい。
垢版 |
2012/06/15(金) 20:56:33.88
デジタル放送は20年以内に再び移行させられる（krmmk3） - BLOGOS（ブロゴス）
http://blogos.com/article/41076/
0273名無しさん＠お腹いっぱい。
垢版 |
2012/09/20(木) 09:29:46.02
2038には全く異なるアーキテクチャが出現している筈だった。
なのにおまいらときたら、古いしきたりをいつまでも引き摺りおって
0274名無しさん＠お腹いっぱい。
垢版 |
2012/09/20(木) 20:05:43.24
なんかipv6と話が似てるな
0275名無しさん＠お腹いっぱい。
垢版 |
2013/01/24(木) 00:04:00.02
あと25年
0278名無しさん＠お腹いっぱい。
垢版 |
2013/06/27(木) 01:25:38.34
あと25年か
0279名無しさん＠お腹いっぱい。
垢版 |
2013/08/08(木) NY:AN:NY.AN
最近の気象は異常だと思うよ。人間として生活できる環境が既に崩れつつある。
人としての子作りは、幸福という名の自己満足。今どきの少子は、老後の保険。
お金に余裕があって、水と食料がなければ、適応できなければ自然淘汰される。
0280名無しさん＠お腹いっぱい。
垢版 |
2013/11/21(木) 19:50:46.01
市販のウイルス対策ソフトが、Nationalスパイウェアに化ける時代だよ、みんなどうする？
0282名無しさん＠お腹いっぱい。
垢版 |
2013/11/26(火) 19:05:19.29
米国からの要請で急いでいる特定秘密保護法案
0283名無しさん＠お腹いっぱい。
垢版 |
2013/11/26(火) 20:52:04.77
TPP参加条件
0286名無しさん＠お腹いっぱい。
垢版 |
2015/01/31(土) 19:47:34.65
あと23年。今年の11月14日には7億秒を切る
0288名無しさん＠お腹いっぱい。
垢版 |
2015/12/10(木) 01:53:17.82
ハゲ侍 サブコミュ イケメン スカイプ マリリンマンソン Twitter マリオ64 ゲーム実況者 マリオカート
ハゲ侍 ツイッター 星のカービィ64 マリオサンシャイン ニコニコ超会議 ポケモン フレコ MH4G アメブロ
ハゲ侍 アメーバブログ 仕事 Skype ツイキャス モンハン 歌い手 スプラトゥーン マニアック
ハゲ侍 動画 顔 ドリームクラブ 好き 刃牙 サイレントヒル ドラゴンボール イケボ
ハゲ侍 漫画 フレンドコード NG縛り ニコニコ生放送 歌ってみた 太刀 ニコニコ超パーティー コミュニティ
ハゲ侍 大学 アキネーター 配信 ニコ生 サブコミュ マリリンマンソン イケメン 学歴
ハゲ侍 マリオカート Twitter スカイプ マリオ64 ツイッター ゲーム実況者 星のカービィ64 ニコニコ超会議
ハゲ侍 ポケモン マリオサンシャイン フレコ MH4G アメーバブログ 仕事 Skype ツイキャス
ハゲ侍 モンハン 歌い手 マニアック 動画 アメブロ スプラトゥーン 刃牙 ドリームクラブ
ハゲ侍 好き サイレントヒル ドラゴンボール 漫画 顔 NG縛り フレンドコード ニコニコ生放送
http://kanae.2ch.net/test/read.cgi/pcqa/1421101110/51
http://kanae.2ch.net/test/read.cgi/pcqa/1415921104/55
http://kanae.2ch.net/test/read.cgi/pcqa/1436852775/17
0289名無しさん＠お腹いっぱい。
垢版 |
2015/12/15(火) 07:27:49.85
このスレ2038年まで持つかな？
0290名無しさん＠お腹いっぱい。
垢版 |
2016/01/24(日) 21:53:19.93
西暦じゃなくて皇紀表記にしてしまえばよくないか？
今でも役所のシステムは裏で、昭和91年1月24日21時53分18秒って表記されてるんだろ？
0292名無しさん＠お腹いっぱい。
垢版 |
2016/01/27(水) 14:18:13.69
あっという間なんだよな
0294名無しさん＠お腹いっぱい。
垢版 |
2016/03/10(木) 08:21:03.60
>>291
昭和でも2025年、皇紀でも2040年、平成でも2089年しか持たないんだよな
(２桁表示の場合)
0297名無しさん＠お腹いっぱい。
垢版 |
2017/12/29(金) 09:28:41.91
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

MO5LP1YKVV
0298名無しさん＠お腹いっぱい。
垢版 |
2018/01/19(金) 23:43:13.13
>>190から10年。あと20年を切った
10年で100レス強なら500前後で2038年問題がやってくるかな？
今日で7304日だから今年の暮れには残り7000日を切るな
0299名無しさん＠お腹いっぱい。
垢版 |
2018/05/22(火) 03:08:10.62
知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

3D4H9
0301名無しさん＠お腹いっぱい。
垢版 |
2019/03/06(水) 21:17:34.82
xp x64 版で2038年問題を試してみた。
WinMediaPlayer10が開けないという事態になった...orz
0303名無しさん＠お腹いっぱい。
垢版 |
2019/03/11(月) 08:28:33.69
ツイッターで#テクノロジー犯罪と検索して、まじでやばいことを四代目澄田会の幹部がやってる
被害者に対して暴力団以外にタゲそらしをしてるがやってるのは暴力団で普段外に出ることが少ないため遊びで公共の電波と同じような電波を使って殺人をしてる
統失はほとんどが作られた病気で実際は電波によって音声送信や思考盗聴ができることが最近明らかになりつつある
警察や病院では病気としてマニュアル化されてしまっているのが現状で被害者は泣き寝入りしてる
被害者がリアルタイムで多い現状を知って、被害者間でしか本当の事だと認知できていない
実際にできると思われていない事だから、ただの幻聴ではない実際に頭の中で会話ができる
できないことだと思われているからこそ真面目に被害を訴えてる
海外でも周知されつつあることを知ってほしい。
このままだとどんどん被害が広がる一方

#テクノロジー犯罪
#四代目澄田会
0304名無しさん＠お腹いっぱい。
垢版 |
2019/07/11(木) 12:53:00.36
そもそもの話、西暦やEPOCHタイムのような一つのタイムラインを延々と使い続けること自体に無理があるんだよ。
UNIXタイムのように2038年を64ビットにして西暦100億年先まで大丈夫と謂われても、結局西洋式の時間的概念だと一見合理的だが、必ず終焉への特異点は避けて通れないようになっている。
結局、UNIX上の西暦表記もEPOCHタイムを置き換えてるだけで、たまたま政治的な優位性で西暦をデフォルトで表示してるようなもの。
電算機を扱う上では、一つのタイムラインで続けるんじゃなく、元号のように一つの時代が終わると一度リセットし、新しい元号を使うことで時間的な特異点を迎えることなく、常若の精神のもと延々と繁栄し続けることが可能になる。

EPOCHタイムや西暦のような一つのタイムラインで管理するカレンダーはダメだってことは、前の文明アトランティス文明、ムー文明、レムリア文明で証明されてんじゃん。
0305名無しさん＠お腹いっぱい。
垢版 |
2019/07/11(木) 12:55:18.41
やっぱ、電算機の時間も式年遷宮方式が一番いいと思うぞ。
0307名無しさん＠お腹いっぱい。
垢版 |
2020/01/19(日) 14:29:00.48
・signed 32bit time_t rollover
2038年1月19日3時14分7秒

・unsigned 16bit MJD rollover ←B-CASとか
2038年4月22日

・GPS week rollover (3回目) ←去年2回目
2038年11月21日
0308名無しさん＠お腹いっぱい。
垢版 |
2020/03/08(日) 17:17:25.04
その前に昭和100年問題はどうすんだよ。
2038年問題なんて、64bitにして解決。
0309名無しさん＠お腹いっぱい。
垢版 |
2020/03/25(水) 20:51:17.14
たぶん死んでます...
0311名無しさん＠お腹いっぱい。
垢版 |
2020/11/28(土) 23:39:36.72
>>294

１６進表記にすれば、大丈夫だろ。
0316名無しさん＠お腹いっぱい。
垢版 |
2024/03/27(水) 19:58:04.19
にもかかわらず
0317名無しさん＠お腹いっぱい。
垢版 |
2024/03/27(水) 21:01:43.08
だからメトホルミンを飲んでないと思っていた60代の異性に相手してない
他に見ることが発覚
セルフで取るようになって感じは当時を経験してたんやろか
https://i.imgur.com/fn6S9b9.jpg
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況