|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
|
|
|
|
irgendwie hab ich auch das gefuehl, dass in 30 Jahren vielleicht auch 64bit nicht mehr stand der dinge sein wird...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 17. October 2006, 16:06 MEW (#11)
|
|
|
|
|
Warum? 32-bit hat auch etwa 20 Jahre ausgereicht und reicht fast überall immernoch. Man sollte annehmnen das 64-bit etwas länger als doppelt so lange reichen. Sicherlich wird es in nicht allzu ferner Zukunft 128-bit CPUs für spezielle Anwendungen geben. 64-bit CPUs gibt es ja auch schon seit Ende der 80er, in den 90ern gab es den ATARI Jaguar und Alphas. Außerdem ist bei den heutigen AMD64 CPUs der tatsächliche Adressraum immer noch kleiner als 64-bit. Von daher sind die Teile genauso eine Mogelpackung wie 32-bit CPUs vergangener Zeiten, die intern nur 24-bittig waren.
Ein noch größerer Adressraum ist eigentlich nur sinnvoll, wenn man sich von der willkürlichen Trennung zwischen RAM und Festplatte verabschiedet und alles in einen einheitlichen 128-bit oder 256-bit Adressraum packt, so wie das bei Großrechnern der Fall ist. Die Geschichte zeigt ja, dass alles was sich bei Großrechnern als sinnvoll erwiesen hat, irgendwann in der einen oder anderen Form auch im PC ankommt (z.B. virtueller Speicher, Speicherschutz, Paging, Multi-User, Multi-Processing, Virtualisierung etc.).
|
|
|
|
|
|
|
|
|
|
|
|
|
Getestet auf einem etwa 1.5 Jahre alten ROCK Linux System:
blindcoder@fuzzy:~$ uname -a
Linux fuzzy 2.6.15.1-rock #1 SMP PREEMPT Tue Jan 31 09:24:34 CET 2006 i686 unknown unknown GNU/Linux
blindcoder@fuzzy:~$ date -u -d "Tue Jan 19 03:14:07 UTC 2038"
Tue Jan 19 03:14:07 UTC 2038
blindcoder@fuzzy:~$ date -u -d "Tue Jan 19 03:14:08 UTC 2038"
date: invalid date `Tue Jan 19 03:14:08 UTC 2038'
blindcoder@fuzzy:~$
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 17. October 2006, 07:45 MEW (#4)
|
|
|
|
|
Das ist schon deshalb Unsinn, weil das 2^31 Problem praktisch genauso alt ist, wie Y2K.
|
|
|
|
|
|
|
|
|
|
|
|
|
Bloss geht das Geheule darüber erst in 20 Jahren los...
--
Quidquid est, timeo parvus mollis et dona ferens!
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja aber bis dann sind die meisten wenn nicht alle Betriebssysteme und CPU's mindestens 64bit, also schiebt sich das Problem ein paar Millionen Jahre weiter in die Zukunft.
Es duerfte also bis dann gar kein Problem mehr sein.
Blöp
|
|
|
|
|
|
|
|
|
|
|
|
|
Man braucht keine 64bit-CPU um einen 64bit-Wert darzustellen. In C geht sowas auf x86 mit einem simplen "long long int". Das Problem ist nur, dass, nur weil der Computer 64bit ist, noch lange nicht mehr Speicher fuer den sekunden-seit-1970-zaehler reserviert werden. Somit verschiebt sich das Problem ueberhaupt nicht von selbst, Programme umschreiben ist angesagt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Programme umschreiben nicht unbedingt... so man denn time_t verwendet.. ;)
Meiner Meinung nach ist die Annahme sizeof(int) == sizeof(time_t) ungefähr so unpassend wie dass sizeof(int) == sizeof(void*).
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 17. October 2006, 16:17 MEW (#12)
|
|
|
|
|
time_t war eigentlich schon immer und überall "long". Daher wird es automatisch ein 64-bit Integer auf allen gängigen 64-bit Architekturen.
Der durchschnittliche C-Programmierer benutzt time_t aber sowieso nicht vernünftig. So meint er doch tatsächlich man könne damit rechnen oder er speichert die Differenz zweier Zeitstempel in einem int.
Das Problem mit time_t ist gerade im Open-Source-Bereich sicherlich eher uninteressant, da man im Prinzip einfach nur time_t zu einem 64-bit Integer ändern braucht und dann den Compiler neu anschmeissen muss. Closed-Source-Programme kann man natürlich nicht mal eben so patchen. Für viele wird es auch gar keinen (vollständigen) Quellcode mehr geben.
Problematischer ist die Verwendung von Zeitstempeln auf Speichermedien und in Netzwerkprotokollen. Da kann man eben mal nicht gerade zusätzliche 32 bit hineinquetschen oder neukompilieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dummes Zeug, mit Perl kann man sauber programmieren, es muss also etwas anderes sein..
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
|
|
|
|
> Das Problem mit time_t ist gerade im Open-Source-Bereich sicherlich eher uninteressant, da man im
> Prinzip einfach nur time_t zu einem 64-bit Integer ändern braucht und dann den Compiler neu anschmeissen
> muss.
Wenns denn so einfach wäre... hab ich bei
MirOS gemacht, und was bleibt? Fixen fixen
und nochmals fixen. Einige wenige Bugs sind
LP64-spezifisch, die meisten ILP32-spezifisch,
der Rest auf allen vorhanden.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 19. October 2006, 13:58 MEW (#25)
|
|
|
|
|
Diese Bugs sind ja nicht neu, sondern werden erst durch Änderung an time_t deutlich. Wenn eine Software aber davon ausgeht, dass time_t == int ist
(direkt oder indirekt) - oder was auch immer da falsch läuft, dann würde ich mir überlegen, ob ich sie nicht einfach wegschmeisse. Für C braucht man verdammt viel Disziplin und eine gute Portion Grips. Das sehe ich allerdings selten. Die meisten C-Entwickler haben noch nicht einmal den kostenlosen Draft zum Standard zur Hand, Geschweige denn jemals den Standard selbst gelesen. Das gleiche kann man zu POSIX sagen, obwohl man die kompletten Manpages online bei opengroup.org findet und diese auch von Google indiziert sind.
Es ist traurig, wenn nicht gar zum Kotzen, aber man muss immer wieder geistigen Kleinkindern (oft jenseits der 30 Jänner) das kleine 1x1 von C erklären. Als Dank wird man dann als dummer nichtnutziger Pedant ohne Ahnung beschimpft. Selbst Patches werden oft ignoriert oder mit dummen Kommentaren abgelehnt. Die Entwickler sind oft auch zu faul etwas dazuzulernen oder sich selbst die passenden Informationen zu suchen. Warum man denen oft irgendwelche Grundlagen erklären muss, ist mir schleierhaft. Als Daumenregel kann ich sagen, je mehr Alternativen es für ein Programm gibt, umso schwerer ist es, diejenige zu finden, die etwas taugt und nicht unter der Haube aussieht als fliege sie jeden Moment auseinander. Man suche nur mal nach einem vernünftigen Terminal-Emulator und schaue sich jeweils auch den Code dazu an.
Wie das allerdings bei Closed-Source-Programmen aussieht will ich gar nicht erst wissen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Danke, sehr einsichtsvoller Beitrag.
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 17. October 2006, 16:23 MEW (#13)
|
|
|
|
|
64-bit Integer nennt man in C int64_t oder uint64_t. "long long int" wurde wahrscheinlich in etlichen x86-spezifischen Programmen mal wieder vergurkt, so wie schon "long", den alle x86-Programmier für einen 32-bit Integer hielten und dabei das "mindestens" überlesen haben.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 17. October 2006, 21:34 MEW (#16)
|
|
|
|
|
Er hat nur C mit C++ verwechselt. In C++ ist es tatsächlich der long long int.
|
|
|
|
|
|
|
|
|
|
|
|
|
Wer hat das runtermoderiert? Er hat doch
Recht...
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 17. October 2006, 23:54 MEW (#18)
|
|
|
|
|
Wer jetze? In C haben Type wie char, int, long etc. nur Mindestgrößen. Ist long long in C++ immer genau 64-bit breit? Na ja, wie das bei C++ ist, ist mir eigentlich auch Wurst. Mir sind nur die C++-Programmierer ein Dorn im Auge, die meinten, sie hätten Ahnung von C, was seltenst der Fall ist, da sie i.d.R. C nicht von C++ unterscheiden können.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 20. October 2006, 15:48 MEW (#28)
|
|
|
|
|
Wie sagt man? Getroffene Hunde bellen am lautesten. In diesem Sinne: Wau wau!
|
|
|
|
|
|
|
|
|
|
|
|
|
Hab das auch mal etwas ausprobiert. Das Ergebnis:
[root@linuxtest ~]# cat /etc/redhat-release
CentOS release 4.3 (Final)
[root@linuxtest ~]# date
Tue Oct 17 10:18:07 CEST 2006
[root@linuxtest ~]# date -s "Jan 10 10:18:00 CEST 2035"
Wed Jan 10 09:18:00 CET 2035
[root@linuxtest ~]# date
Wed Jan 10 09:18:01 CET 2035
[root@linuxtest ~]# date -s "Jan 20 10:18:00 CEST 2035"
Sat Jan 20 09:18:00 CET 2035
[root@linuxtest ~]# date
Sat Jan 20 09:18:05 CET 2035
[root@linuxtest ~]# date -s "Jan 10 10:18:00 CEST 2036"
Thu Jan 10 09:18:00 CET 2036
[root@linuxtest ~]# date
Thu Jan 10 09:18:02 CET 2036
[root@linuxtest ~]# date -s "Jan 20 10:18:00 CEST 2036"
Sun Jan 20 09:18:00 CET 2036
[root@linuxtest ~]# date
Sun Jan 20 09:18:05 CET 2036
[root@linuxtest ~]# date -s "Jan 10 10:18:00 CEST 2037"
Sat Jan 10 09:18:00 CET 2037
[root@linuxtest ~]# date
Sat Jan 10 09:18:02 CET 2037
[root@linuxtest ~]# date -s "Jan 20 10:18:00 CEST 2037"
Tue Jan 20 09:18:00 CET 2037
[root@linuxtest ~]# date
Tue Jan 20 09:18:01 CET 2037
[root@linuxtest ~]# date -s "Jan 10 10:18:00 CEST 2038"
Sun Jan 10 09:18:00 CET 2038
[root@linuxtest ~]# date
Sun Jan 10 09:18:02 CET 2038
[root@linuxtest ~]# date -s "Jan 20 10:18:00 CEST 2038"
Tue Jan 19 03:14:07 CET 2038
[root@linuxtest ~]# date
Tue Jan 19 03:14:10 CET 2038 --- ;-)
[root@linuxtest ~]# cal
January 2038
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gecko@g4:~ $ uname -srvmpio
Darwin 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC
Power Macintosh powerpc PowerMac3,6 Darwin
gecko@g4:~ $ sudo date -s "Jan 19 3:14:05 UTC 2038"; while date; do sleep 1; done
Tue Jan 19 03:14:05 UTC 2038
Tue Jan 19 03:14:06 UTC 2038
Tue Jan 19 03:14:07 UTC 2038
Fri Dec 13 20:45:52 UTC 1901
Fri Dec 13 20:45:53 UTC 1901
Fri Dec 13 20:45:54 UTC 1901
Mac OS X ist also auch keine Ausnahme.
Mein Motto: Jedem das seine
|
|
|
|
|
|
|
|
|
|
|
|
|
Interessanter Nebeneffekt war auf diesem Linux, dass z.B. nslookup nicht mehr funktionierte ;-)
[root@linuxtest ~]# date -s "Mar 20 10:18:00 CEST 2038"
Tue Jan 19 04:14:07 CET 2038
[root@linuxtest ~]# date
Fri Dec 13 21:45:52 CET 1901
[root@linuxtest ~]# nslookup www.symlink.ch
timer.c:645: fatal error: RUNTIME_CHECK(isc_time_now(&now) == 0) failed
Aborted
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 18. October 2006, 13:45 MEW (#22)
|
|
|
|
|
ISC? ZOMFG!
Da hat bei nslookup wenigstens jemand mitgedacht. Bei anderer Software kommst Du sicher nicht so billig davon. Ich würde von solchen Experimenten eher die Finger lassen, wenn Dir Deine Daten lieb sind.
|
|
|
|
|
|
|
|
|
|
|
|
|
Der ausmerksame Leser hat sicher bemerkt, dass diese Tests auf einem Testrechner durchgeführt habe. Zudem konnte dieser Nebeneffekt mit ntpdate NTP-Server problemlos wieder rückgängig gemacht werden... Und ja, weitere Test mit anderer Software werde ich mir sicher nicht entgehen lassen... Der Gwunder muss gestillt werden....
|
|
|
|
|
|
|
|
|
|
|
|
|
... hab ich eben mal die schlimmsten Bugs dabei
gefixt. Man kann jetzt Zeiten jenseits von
2038 auf i386 nutzen (sparc bleibt beim 32-bit
time_t, 2038 wird die einfach EOL'd), LP64-
Plattformen haben wir keine, aber amd64 (in
Planung) würde sich genau so verhalten, und
man könnte mal ein LP64-i386 bauen, hat schon
mal wer AFAIK gemacht (wenn jemand nen Link
hat, bitte her damit). Bei MirOS ist schon
seit geraumer Zeit der time_t 64-bittig auf
i386.
So, jetzt zum Rest:
Nicht alle Bibliotheksfunktionen mögen es
(strftime(3) zum Beispiel gibt bei date +%s
eine negative Zahl aus), und solange man im
32-Bit Rahmen (bis Februar 2106) bleibt,
läuft der Rest halbwegs, auch wenn die
Timestamps im Dateisystem kaputt sind, da
ffs (UFS1) nur 32 Bit dafür bereitstellt -
Abhilfe schafft UFS2, das bald(TM) kommt.
Ab 2106 wird das Ganze 33-bittig, hier funk-
tioniert dann auch das Netzwerk und "halt"
nicht mehr.
Aber ich denke, da habe ich noch genug Zeit,
das zu fixen... immerhin besser als die Betriebssy-
steme mit mehr Verbreitung ;)
Ich bin BSDler, ich darf das!
Dieser Platz zu vermieten!
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 18. October 2006, 02:48 MEW (#20)
|
|
|
|
|
Fragt sich nur ob es MirOS in 30 Jahren noch gibt.
|
|
|
|
|
