Twitter, distruzione scampata

L'apocalisse del cinguettio è stata scongiurata. Solo qualche client non aggiornato mostra ancora qualche difficoltà. Tutta colpa di quei miseri 32bit

Roma - Un po' come il bug dell'anno 2000, quello che doveva distruggere il mondo e poi è passato praticamente senza colpo ferire. L'apocalisse di Twitter, ovvero la "Twitpocalypse", si è annunciata, è giunta e trascorsa senza che ci fossero particolari disagi per gli utenti: la colpa è stata, un po' come accadrà presto per il protocollo IPv4, l'adozione di un numero di bit insufficiente a indicizzare l'universo delle chiacchiere online. Appena trentadue, pari a non più di 2.147.483.647 tweet: e così, dopo due miliardi circa di messaggini, il sistema ha avuto bisogno di una rettifica.

L'attenzione sulla Twitpocalypse l'ha generata la canadese Wherecloud, autrice per l'appunto di un client per la piattaforma, con tanto di homepage con il countdown per la fatidica soglia: raggiunto il numero massimo di messaggi indicizzabili con 32bit, spiegavano dal Nordamerica, parecchi programmi di terze parti avrebbero potuto incontrare problemi.

Una questione legata ad una libreria impiegata da molte applicazioni, denominata MGTwitterEngine ed utilizzata per integrare il supporto a Twitter in una applicazione Cocoa (si parla quindi di ambiente Mac OSX, mobile o tradizionale), afflitta da un bug sistemato comunque molte settimane addietro. Il problema, ovviamente, è che non sempre un componente di questo tipo viene aggiornato ad ogni nuova build di una applicazione.
Di conseguenza, giunti alla fatidica soglia del 2.147.483.647eismo tweet alcune applicazioni avrebbero potuto incontrare qualche difficoltà: pare proprio sia stato il caso di Twitterrific per iPhone, tanto per fare un esempio, che ha dovuto rilasciare una nuova release (la 2.0.2) per sopperire al problema. Per il resto, non sembrerebbe che a poche ore di distanza dal fatidico momento della verità si registrino particolari difficoltà (nonostante qualche uccello del malaugurio): anzi, i cinguettii sembrano sempre di più attirare le attenzioni delle aziende in cerca di nuovi meccanismi di marketing diretto con i propri clienti.

Alla storia, in ogni caso, resterà il tweet di @nk (al secolo Nick Hallen), postato alle 16:52 ora del Pacifico del 12 giugno, contrassegnato dal progressivo 2.147.483.649 e dunque il primo oltre il traguardo della Twitpocalypse. "The Tweets must flow", recita, parafrasando il più noto "La spezia deve affluire" tratto dalla saga Dune di Frank Herbert e aggiungendoci anche un LOLcats che non ci sta mai male. Chissà se Nick era consapevole della storicità del suo cinguettio: di certo, è stato un tweet ben riuscito.
22 Commenti alla Notizia Twitter, distruzione scampata
Ordina
  • L'aritcolo dice che con 32 bit puoi indicizzare massimo 2.147.483.647 messaggi. E' falso indipendentemente che la codifica sia int signed o unsigned.
    Con 32 bit puoi creare 2.147.483.648 * 2 "simboli" diversi, e in C con un int (signed o non) sono tutti usabili (da notare che con un double sarebbero stati molti meno). E' che ci si ostina a ritenere lo 0 il primo numero e si fa,alle volte, confusione tra codifica di un numero e la sua rappresentazione.

    Come altri hanno fatto notare la scelta unsigned sarebbe forse stata più ragionevole, ma ci possono essere dei motivi ragionevoli che a prima vista non appaiono. Ad esempio forse non tutti i dispositivi supportano l'aritmetica unsigned. La JVM ad esempio non supporta gli unsigned (ma gli int sono a 64 bit).

    Nonostante unsigned sia probabilmente la scelta migliore, nulla vieta di assegnare al primo messaggio -2.147.483.648, ad esempio.
    L'obiezione che non si voglino messaggi "negativi" è irrilevante. Dato l'id del messaggio basta sommargli 2.147.483.648 per avere l'ordinale del messaggio... nella frase "questo è il 1024° messaggio" 1024 è solo una rappresentazione di un numero, la sua codifica è altra cosa.

    Va bhè, era per scrivere qualcosa, come precisazione è un po' tecnicaSorride
    non+autenticato
  • 2.147.483.647 non 2^31 non 2^32!

    quindi si tratta di un int signed
    non+autenticato
  • Finalmente un commento intelligente.
    non+autenticato
  • - Scritto da: Francesco
    > 2.147.483.647 non 2^31 non 2^32!
    >
    > quindi si tratta di un int signed

    Infatti.. forse volevano contare anche i tweet negativi Pirata
  • mi chiedo perchè mai, per un contatore del genere, non abbiano usato fin dall'inizio un tipo unsigned (a prescindere dal "limite"). Concettualmente non ha senso averlo negativo, quindi perchè mai usare un tipo signed ?
    Sempre più convinto che certa gente scrive codice con diverse parti anatomiche...
    non+autenticato
  • Probabilmente si tratta di livelli di astrazione che manco si pongono il problema se un int sia signed o unsigned... sinché non compare il "problemuccio"Sorride

    Faranno come lo unix time, saremo nel 2038 ancora afflitti da macchine a 32 bit che non supportano i 64 e quindi non riusciranno a superare la fatidica dataSorride
    non+autenticato
  • - Scritto da: Ale
    > mi chiedo perchè mai, per un contatore del
    > genere, non abbiano usato fin dall'inizio un tipo
    > unsigned (a prescindere dal "limite").
    > Concettualmente non ha senso averlo negativo,
    > quindi perchè mai usare un tipo signed
    > ?
    > Sempre più convinto che certa gente scrive codice
    > con diverse parti
    > anatomiche...

    Perche' probabilmente hanno una funzione tipo: "int get_count()" che in caso di errore identifica con un valore negativo il mancato successo?

    Niente toglie che potessero fare:

    "err_t get_count( unsigned int *x )", ma e' poco elegante... oppure ancora meglio potevano usare un tipo piu' grande: "int64_t get_count()"

    Meglio ancora sarebbe usare le eccezioni, ma considerando che potrebbero usare linguaggi diversi all'interno del sistema il C e' il collante definitivo (ma non ha le eccezioni).

    Nel caso in cui usassero linguaggi differenti, non tutti i linguaggi hanno i tipi unsigned (tipo Java).

    Buona giornata a tutti!
  • quante cazzate tutte insieme..
    non+autenticato
  • - Scritto da: adfs gfdsf
    > quante cazzate tutte insieme..

    Sono troppo scazzato (e rilassato) perfino per mandarti dove gia' sai... Occhiolino

    Se non altro argomenta...
  • - Scritto da: adfs gfdsf
    > quante cazzate tutte insieme..

    Nah ha scritto cose sensate, non condivido la preferenza per l'eccezioni che *secondo me* incitano alla cattiva programmazione (tanto c'è l'handler) ma per il resto ha ragione.
    non+autenticato
  • - Scritto da: Francesco
    > 2.147.483.647 non 2^31 non 2^32!
    >
    > quindi si tratta di un int signed

    Hai perfettamente ragione!
    non+autenticato
  • - Scritto da: Francesco
    > 2.147.483.647 non 2^31 non 2^32!
    >
    > quindi si tratta di un int signed

    Secondo me si tratta di marketing...
    non+autenticato
  • Anche in ambiti diversi dal puro e semplice s.o.
    bisognerebbe passare ad un numero più elevato (esempio 64bit sui s.o.) x superare questo limite sempre più evidente.
    siamo nel 2009, i 32bit sono nati a metà degli anni 90.. sono passati quasi 15 anni!!
    LROBY
    lroby
    5311
  • Attento... mi stai confondendo lo spazio di indirizzamento memoria a 32bits (max 4GB RAM) con un contatore a 32bits, semplice scelta errata di dimensionamento da parte del/dei programmatori. Sono due concetti molto, molto diversi. Anche se usano la stessa unità di misura.
  • Mah...la storia dei 64bit oggi come oggi per molti aspetti in ambito desktop e' tempo perso. Gli unici aspetti in cui i 64bit fanno la differenza e' sulle dimensioni di memoria e dischi. Ma per il resto, le applicazioni comuni non hanno necessita' di 64bit...
    Caso particolare e' il contatore del tempo nei sistemi unix, che in molti ambiti e' ancora a 32bit e questo sara' un problema tra una quindicina d'anni.
    Il caso di twitter e' solo uno degli esempi di mancanza di previsione...penso che gia' un paio d'anni fa avrebbero potuto fare la transizione a 64bit dell'indice dei messaggi...l'idiozia si dimostra nell'arrivare sempre all'ultimo per correggere un problema.
  • trattasi semplicemente di usare una variabile diversa. I due miliardi e rotti sono di una long signed (prima cappella). Avessero usato da subito una unità molto più capiente, il problema non si sarebbe posto. Questo avviene quando i programmatori sono abituati a usare sempre le stesse unità di variabili, tutte signed (escluso il byte, ovviamente) e non al di sopra di una long (4 bytes). Oltretutto non si sbattono nemmeno di eliminare il segno meno e portarla a 4 miliardi e rotti.
    I 64 bit non servono proprio in questo caso, qualsiasi linguaggio di programmazione permette il superamento dei 4 miliardi (i 2 li lasciamo ai programmatori... svogliati).
    non+autenticato
  • - Scritto da: laforge
    > Mah...la storia dei 64bit oggi come oggi per
    > molti aspetti in ambito desktop e' tempo perso.
    > Gli unici aspetti in cui i 64bit fanno la
    > differenza e' sulle dimensioni di memoria e
    > dischi. Ma per il resto, le applicazioni comuni
    > non hanno necessita' di
    > 64bit...

    Non è vero, per i programmi di scacchi 64bit sono utilissimi (le caselle di una scacchiera sono 64). Così il mio motore di scacchi preferito risparmia 27 ms a mossa, ti pare poco?Con la lingua fuori

    No cmq hai xfettamente ragione, anche perché tutti i programmi (al meno in Windows) sono compilati a 32 bit (tranne quelli per versione a 64 bit, che però hanno bisogno di un una versione dell'o.s. a sua volta compilato a 64 bit che in pratica nessuno ha). Tanto è vero che da quando è scita l'archittettura a 64 bit non mi pare ci siano stati grandi passi avanti nel suo sviluppo.
    non+autenticato
  • provato a usare la calcolatrice del tuo OS? Fa calcoli a 64 bit. Perchè? Perchè è stata programmata in modo adeguato.
    Non c'è bisogno di un OD a 64 bit per fare calcoli al di sopra dei 4 miliardi. Per altre cose si, ma esulano dal computing che puoi fare tu come utente.
    non+autenticato
  • 640 Kb should be enough for anybody.

    Occhiolino
    non+autenticato
  • - Scritto da: lroby
    > Anche in ambiti diversi dal puro e semplice s.o.
    > bisognerebbe passare ad un numero più elevato
    > (esempio 64bit sui s.o.) x superare questo limite
    > sempre più
    > evidente.
    > siamo nel 2009, i 32bit sono nati a metà degli
    > anni 90.. sono passati quasi 15
    > anni!!
    > LROBY

    Direi che il problema e' x86, che come al solito e' arrivato dopo la banda: http://en.wikipedia.org/wiki/64bit#64-bit_processo...

    Per non andare eccessivamente nella preistoria dell'informatica, gli SPARC a 64 bit sono arrivati nel '95 ed i MIPS nel '91.

    Ciao!
  • - Scritto da: LeaningTowerAvenger
    > - Scritto da: lroby
    > > Anche in ambiti diversi dal puro e semplice s.o.
    > > bisognerebbe passare ad un numero più elevato
    > > (esempio 64bit sui s.o.) x superare questo
    > limite
    > > sempre più
    > > evidente.
    > > siamo nel 2009, i 32bit sono nati a metà degli
    > > anni 90.. sono passati quasi 15
    > > anni!!
    > > LROBY
    >
    > Direi che il problema e' x86, che come al solito
    > e' arrivato dopo la banda:
    > http://en.wikipedia.org/wiki/64bit#64-bit_processo
    >
    > Per non andare eccessivamente nella preistoria
    > dell'informatica, gli SPARC a 64 bit sono
    > arrivati nel '95 ed i MIPS nel
    > '91.
    >
    > Ciao!
    E non dimenticarti l'Alpha 21064 (DECchip 21064)Occhiolino
    non+autenticato
  • Si ma presumibilmente erano per applicazioni per cui i 64bit servivano.
    non+autenticato