slacky.eu

Come ex utente DOS/Windows, non ho neppure il coraggio di ridere; ma, a questo punto, penso che la M$ sia proprio da abolire ...

http://www.corriere.it/scienze_e_tecnol ... aabc.shtml

http://www.brisbanetimes.com.au/news/te ... 37534.html

In realta' l'unico problema della Microsoft e' voler intervenire in alcuni mercati.
Dovrebbero limitarsi a fare quello che sanno fare bene, e che fanno da anni.
Cioe' i giochi:-)

bye

Dopo il problema 1999-2000,
M$ ha inventato il problema 2009,
dimenticando che il 2008 era bisestile.

UNIX/Linux a 32bit aspetta il 2038!

Non mi stupisco, ma mi devono dire cosa caspita c' entra alla fine del primo articolo quella cosa dell' apple.
Ma qui veramente stiamo degenerando...

Mario Vanoni ha scritto:UNIX/Linux a 32bit aspetta il 2038!

In un ambiente a 32 bit, i signed int permettono di rappresentare un numero con segno compreso tra -2147483648 e +2147483647; la conseguenza è che il contatore (signed int) UNIX/Linux che indica i secondi trascorsi dalle ore 00:00:00 del 01/01/1970 va in overflow esattamente alle 03:14:07 del 19/01/2038!

Da qualche parte però ho letto che i kernel Linux a 32 bit ormai sono passati al tipo unsigned int per gestire quel contatore; non so se la notizia sia vera, ma in caso affermativo Linux avrebbe a disposizione ulteriori 68 anni di tranquillità, sempre a partire dalle 03:14:07 del 19/01/2038.

zxzxasas ha scritto:Non mi stupisco, ma mi devono dire cosa caspita c' entra alla fine del primo articolo quella cosa dell' apple.
Ma qui veramente stiamo degenerando...

Mi sa che l'articolo del Corriere è frutto di un copia/incolla, per cui ... a forza di tagli e ritagli è rimasta quella frase che non c'entra nulla.

phobos3576 ha scritto:Da qualche parte però ho letto che i kernel Linux a 32 bit ormai sono passati al tipo unsigned int per gestire quel contatore; non so se la notizia sia vera, ma in caso affermativo Linux avrebbe a disposizione ulteriori 68 anni di tranquillità, sempre a partire dalle 03:14:07 del 19/01/2038.

Proprio oggi stavo rileggendo qualcosa in proposito.
Ma a quanto leggevo l'eventualità che si passi da signed ad unsigned int dovrebbe causare grossi problemi di compatibilità, qualcuno ha qualche informazione al riguardo?
Segnalo anche -a chi fosse incuriosito dall'argomento- la pagina di wikipedia al riguardo: http://it.wikipedia.org/wiki/Bug_dell%27anno_2038

phobos3576 ha scritto:Mi sa che l'articolo del Corriere è frutto di un copia/incolla, per cui ... a forza di tagli e ritagli è rimasta quella frase che non c'entra nulla.

Anche secondo me si tratta di un patetico refuso dovuto a cut-and-paste... Certo che rileggere gli articoli prima di pubblicarli...

m0rdr3d ha scritto:Ma a quanto leggevo l'eventualità che si passi da signed ad unsigned int dovrebbe causare grossi problemi di compatibilità, qualcuno ha qualche informazione al riguardo?

Il problema è che ormai esiste una enorme quantità di software che, per quel contatore, si aspetta un signed int; proprio per questo motivo, la soluzione non appare semplice.

Qui c'è una lunga discussione sull'argomento:

http://lkml.indiana.edu/hypermail/linux ... /0056.html

In ogni caso, il passaggio al kernel a 64 bit risolve il problema per miliardi di anni ...

Il fatto del 1970 è una cosa del linguaggio C, nello specifico della time.h
Quando si avvicinerà il 2038, ammesso che il C si usi ancora, basterà ridefinire la time.h e iniziare a contare...chessò...dal 2000 e avere altri 30 anni. Si ricompila TUTTO con la nuova time.h e tutto dovrebbe andare bene!

Il problema è per l'appunto ricompilare tutto...
Nel 2038 sarà (mi auguro) ormai completata la migrazione ai 64 bit, ma permangono comunque numerosi dispositivi embedded per i quali ricompilare tutto d'accapo non sarebbe cosa così semplice
O anche server particolarmente vecchi (ok, nel 2038 sarebbero forse *troppo* vecchi).

Ad ogni modo l'operazione comporterebbe dei costi non indifferenti.

m0rdr3d ha scritto:Il problema è per l'appunto ricompilare tutto...

Illusione!

Ingo Molnar nella LKML mette gcc 4.1.0 e 4.1.1 quali
"Sorry, your compiler is too old, too buggy or not recognized."
Questo per i kernel dal 2.6.28 e futuri.
Attuale funzionante pare sia il gcc 4.1.2

Mario Vanoni ha scritto:Illusione!

Ingo Molnar nella LKML mette gcc 4.1.0 e 4.1.1 quali
"Sorry, your compiler is too old, too buggy or not recognized."
Questo per i kernel dal 2.6.28 e futuri.
Attuale funzionante pare sia il gcc 4.1.2

Scusami non ho capito bene la questione. Puoi spiegare meglio?

zxzxasas ha scritto:

Mario Vanoni ha scritto:Illusione!

Ingo Molnar nella LKML mette gcc 4.1.0 e 4.1.1 quali
"Sorry, your compiler is too old, too buggy or not recognized."
Questo per i kernel dal 2.6.28 e futuri.
Attuale funzionante pare sia il gcc 4.1.2

Scusami non ho capito bene la questione. Puoi spiegare meglio?

Se i kernel nuovi hanno problemi con i compilatori vecchi,
quanti problemi avranno programmi scritti 10 anni fa
con i compilatori odierni, di quelli vecchi, che ne ha ancora?
Dieci anni fa usavo gcc 2.5.8 per i kernel 1.2.#.

Ho letto che i problemi con la data del 2038 si stanno manifestando già da adesso!
Accade quando si cerca di creare un certificato di sicurezza per una pagina web che scade oltre il 2038; OpenSSL reagisce molto male in casi del genere:

http://www.mail-archive.com/openssl-use ... 53112.html

Un'altra curiosità è che il problema del 2038 sembra affliggere anche WindowsXP; evidentemente, nel suo kernel è rimasta qualche traccia di UNIX ...

freefred ha scritto:In realta' l'unico problema della Microsoft e' voler intervenire in alcuni mercati.
Dovrebbero limitarsi a fare quello che sanno fare bene, e che fanno da anni.

Non uso M$, ma per correttezza in un forum tecnico:

problema Y2K9

M$ Zune 30 e Toshiba S30/S60 stesso problema,
processore MC13783 e driver di Freescale.

Da biasimare la loro superficialita`.

Mario Vanoni ha scritto:Da biasimare la loro superficialita`.

Dai però, bisogna anche tenere conto di quello str***o di Murphy
Per carità, è anche vero che di mezzo ci stanno i nostri soldi...