Sun nelle mani di Oracle

Sun nelle mani di Oracle

Un breve articolo, che avevo in programma da tempo (dal 30/01 quando ho saputo di Sun). Anzi, ad essere precisi era già per metà tra le bozze.

Alla fine, per fortuna aggiungo io, l’acquisizione di Sun e tutto quello che c’è attaccato (MySQL, che era il nuovo arrivato in casa Sun, e Java per citare due nomi) è stata completata.

L’operazione è stata mostruosamente veloce: a 24 ore dal perfezionamento dell’accordo, i due siti (sun.com ed oracle.com) erano già incrociati (per esempio, tutte le pagine dei prodotti sono già su oracle.com), e in homepage appariva una cosa che mi ha impressionato: la scritta “SOFTWARE. HARDWARE. COMPLETE. Oracle Finalizes Sun Deal”. Questo la dice lunga sui piani di Oracle. E non sembrano così tanto lontani dalla realtà.

Seguiva questo link http://www.oracle.com/features/suncustomers.html:

Una vera e propria promessa, insomma, che Oracle fa ai clienti Sun. Fatta in modo inaspettatamente diretto, il che ha un certo impatto dopo che per mesi se ne sono dette veramente di tutti i colori (la paura dei più era che Oracle facesse sparire MySQL per far spazio al suo omonimo DB).

Certo, il messaggio contenuto in questa promessa è molto forte. Oracle, colosso storico nel mondo del Software, per 30 anni non ha toccato il settore Hardware. Adesso decide di farlo, in modo tra l’altro così diretto.

Staremo a vedere, la partita è iniziata.

(E io continuo ad aspettare che qualcuno compri Debian: una struttura societaria forte non può che giovare ad un progetto Open Source a mio parere.)

Giorgio

Host 1e100.net: cosa sono?

Host 1e100.net: cosa sono?

Sono molto attento alle connessioni aperte dai miei pc, quindi ogni tanto mi metto a fare controlli con TCPDump o simili. Tempo fa avevo notato una valanga di connessioni verso hosts tipo:

fx-in-f83.1e100.net

fx-in-f147.1e100.net

fx-in-f118.1e100.net

La struttura dei nomi mi ha subito ricordato lo schema che usa Google per i suoi load balancers, ed un veloce controllo WHOIS e sugli IP ha confermato quello che avevo intuito: si trattava di un suo dominio “di servizio”. In rete, non avevo trovato nessuna informazione. Alla fine, mi è uscito dalla testa.

Ieri per caso ho trovato questo articolo su TheRegister.co.uk, ed ho scoperto il senso del nome 1e100.net (su cui non avevo fatto alcuna ricerca, credevo fosse totalmente casuale):

But on closer inspection, the domain is obviously Google’s, chosen with a mathematician’s wink at the search giant’s famously misspelled name. This mystery domain is 1e100.net. “1e100” would be scientific notation for 10 100, a one followed by 100 zeros, also known as a googol.

Il nome è quindi, come spiega TheRegister, la notazione scientifica di 10^100, 1 seguito da 100 zero, definito googol, da cui deriva il nome google.

E’ interessante notare la crescita delle visite verso il dominio, secondo Alexa:

Una linea verticale!

Giorgio

Fibre vs rame: 2010 vs 1960

Fibre vs rame: 2010 vs 1960

In questo periodo sto facendo test senza scopo tirando in mezzo cavi seriali, paralleli, ethernet e fibre, tecnologie vecchie di 30 anni, e ne sto misurando latenze e velocità. Credo pubblicherò un report completo a breve, ma qualche appunto preso “on the road” lo trovate già QUI.

Oggi parlando con un amico mi è venuto in mente un paragone, tecnicamente non proprio completo e rigoroso*, ma veramente utile per capire, con una tecnica che definirei “da fruttivendolo”, il progresso e gli enormi vantaggi portati dalle fibre ottiche.

Un cavo in fibra ottica può portare 160 lunghezze d’onda. Ognuna di queste lunghezze d’onda porta un segnale da 10 Gbps. Ci sono quindi 1600 Gbps disponibili**. Un cavo seriale porta, in totale, al massimo 115200 bps. Quindi:

Velocità max fibra ottica = MaxFC = 1600 Gbps = 1 600 000 Mbps

Velocità max cavo seriale = MaxSC = 115200 bps = 0.1152 Mbps

Calcoliamo quindi quanti cavi seriali ci servono per raggiungere la velocità di una fibra ottica:

Numero cavi seriali = NSC = MaxFC / MaxSC = 1 600 000 Mbps / 0.1152 Mbps = 13 888 889

Adesso arriva la perla: un metro di cavo seriale pesa 50 grammi. Un metro di fibra ottica ne pesa meno di 2:

Peso fibra ottica = PFC = 2 g

Peso cavo seriale = PSC = 50 g

Per finire dobbiamo quindi calcolare quanti Kg di cavi seriali ci servono per raggiungere la velocità di un singolo cavo in fibra, dal peso di 2 grammi (0.002 Kg):

PtotSC = NSC x PSC = 13 888 889 x 50 g = 694 444 450 g = 694 444 , 450 Kg

Concludendo: per sostituire un cavo in fibra ottica (dal peso, come già detto, di due soli grammi) utilizzato per connettere due punti ad una velocità di 1600 Gbps ed alla distanza di un metro, ci servirebbero 14 milioni di cavi seriali, che avrebbero un peso totale di circa 700 tonnellate. Per UN SOLO metro di distanza. Vi lascio solo immaginare cosa vorrebbe dire sostituire anche solo le fibre transatlantiche.

C’è un’altro dato interessante: la fibra ottica ha una latenza di 5 microsecondi al Km, mentre un cavo seriale ha una latenza di 5 millisecondi al metro.

Latenza fibra ottica = LFC = 5 microsec / Km = 0.005 ms / Km

Latenza cavo seriale = LSC = 5 ms / m = 5000 ms / Km

Immaginiamo di dover collegare Amsterdam a New York e consideriamo una distanza in linea retta tra le due città di circa 6000 Km (inutile dire che chiaramente quella reale percorsa dai cavi sarebbe maggiore). Calcoliamo quindi la latenza, ovvero il tempo impiegato per percorrere questa distanza sui due tipi di cavi:

Distanza = D = 6000 Km

Tempo di percorrenza fibra ottica = TFC = LFC x D = (0.005 ms / Km) * 6000 Km = 30  ms

Tempo di percorrenza cavo seriale = TSC = LSC x D = (5000 ms / Km) * 6000 Km = 30 000 000 ms = 30 000 secondi = 500 minuti = 8 ore e 30 minuti

Questo, in linea teorica. Perchè per percorrere distanze così enormi il segnale deve essere rigenerato, e questo introduce tremendi ritardi nella trasmissione. Ricordo che per percorrere questi 6000 Km il segnale sul cavo in fibra (che percorre 50 Km senza rigenerazione) dovrebbe essere rigenerato (amplificato) 120 volte, mentre quello seriale dovrebbe essere rigenerato ogni 8 metri, ovvero 750 000 volte.

Numero rigenerazioni fibra ottica = NrFC = 120

Numero rigenerazioni cavo seriale = NrSC = 750 000

Qui azzardo una serie di conti, di cui non garantisco l’accuratezza teorica. Quello che è certo, è che comunque i numeri che otterrò saranno inferiori a quelli reali:

Il tempo reale di percorrenza in fibra ottica della linea Amsterdam – New York è di circa 80 ms. Quello teorico calcolato in linea retta è di 30 ms, quindi sembra ragionevole calcolare 40 ms teorici sulla tratta realmente percorsa. Significa che abbiamo circa 40 ms (sottraggo i 40 di tempo teorico agli 80 di tempo reale misurato) di tempo perso nelle 120 rigenerazioni. Questo vuol dire che una rigenerazione del segnale in fibra ottica ritarda il tutto di 0.34 ms.

Tempo reale percorrenza fibra ottica = TpFC = 80 ms

Tempo totale rigenerazione fibra ottica = TtotrFC = 40 ms

Tempo rigenerazione fibra ottica = TrFC = 0.34 ms

Con questi dati, calcolo il tempo impiegato da una rigenerazione del segnale per un cavo seriale. Uso la relazione LFC : TrFC = LSC : TrSC, quindi:

Tempo rigenerazione cavo seriale = TrSC = (LSC x TrFC) / LFC = (5000 ms / Km x 0.34 ms) / (0.005 ms / Km) = 340 000 ms

Come già detto, per percorrere questa distanza, il segnale di un cavo seriale deve essere rigenerato 750 000 volte, quindi calcoliamo il tempo totale di rigenerazione:

Tempo totale rigenerazione cavo seriale = TtotrSC = TrSC * NrSC = 340 000 ms * 750 000 = 225 000 000 000 ms

Per concludere devo calcolare il tempo totale impiegato per la percorrenza di questa tratta tramite cavo seriale:

Tempo reale percorrenza cavo seriale = TpSC = TtotrSC + TSC = 255 000 000 000 ms + 30 000 000 ms = 255 030 000 000 ms = 255 030 000 secondi = 4 250 500 minuti = 70 842 ore = 2951 giorni = 8 anni.

In fibra ottica, andiamo da Amsterdam a New York in 80 millisecondi. Con un cavo seriale, impiegheremmo 8 anni. Probabilmente sarebbe molto più conveniente inviare una lettera invece che una mail.

Giorgio

* RS 232 non è stato concepito per comunicazioni a lunga distanza: era usato per collegare i modem o i nodi di un cluster, comunque entro pochi metri. La sua portata è intorno agli 8 metri, questo vuol dire che ogni 8 metri serve un rigeneratore di segnale. Le fibre vanno invece per 50 Km o più senza essere toccate. Per finire, ad oggi non esiste modo di connettere due singoli punti utilizzando tutta la banda disponibile su un cavo in fibra ottica. Allo stesso modo non esiste un modo per connettere due host con 14 milioni di cavi seriali.

** Metto lì un dato senza approfondirlo ulteriormente: abbiamo una velocità di 1600 Gbps per singolo cavo. Le linee transoceaniche sono però composte di fasci di 864 cavi, e di solito sono stese a coppie.

DNS resolvers: a quick reference

DNS resolvers: a quick reference

Ho una lista, ma puntualmente la perdo, quindi credo sia il caso di appuntarsi qui i vari servizi di risoluzione DNS ed i loro IP (in prima riga i primari, in seconda, se disponibili, i secondari):

Google Public DNS:

8.8.8.8, 8.8.4.4

Level3 DNS (Unofficial*):

4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.4

4.2.2.5, 4.2.2.6

OpenDNS:

208.67.222.222, 208.67.220.220

208.67.222.220, 208.67.220.222

DNSAdvantage (UltraDNS):

156.154.70.1, 156.154.71.1

* Il servizio non è mai stato reso pubblico. Questi resolver funzionano, funzionano perfettamente, ma Level3 li ha mai resi disponibili al pubblico ufficialmente.

Spamassassin e il bug di capodanno

Spamassassin e il bug di capodanno

Stavo notando un improvviso incremento dello spam, senza notare un incremento del numero totale di mail ricevute su alcuni server che gestisco. Cosa chiaramente anomala.

Con un pò di smanettamenti ho notato che le email che venivano falciate risultavano positive per “FH_DATE_PAST_20XX”.

Con ulteriori smanettamenti sono arrivato qui:

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

In pratica il test verifica se l’header “Date:” è palesemente nel futuro. Come fa? Controlla se è tra il 2010 e il 2099. Con conseguenze catastrofiche visto che ormai siamo veramente nel 2010.

Mi sembra strano che nessuno ne parli, son l’unico pistola che lo ha notato?

Al momento comunque l’unica soluzione credo sia inserire nel local.cf questo:

score FH_DATE_PAST_20XX 0.0

Giorgio