SCRUB: L’Endeavour (STS-134) rimane a terra

SCRUB: L’Endeavour (STS-134) rimane a terra

Volevo seguire il lancio della missione STS-134 in diretta, ed ero pronto, lo scorso Venerdì, con NasaTV aperta in una scheda e la pagina Twitter del KSC (NASA Kennedy Space Center) in un’altra. Ci tenevo, perchè la STS-134 è la penultima missione dello Space Transportation System, e l’ultima missione dello Shuttle Endeavour.

Ad un certo punto, con non indifferente sorpresa, mi sono capitati sott’occhio questi due tweet:

In poche parole, lancio annullato. Lo Shuttle Endeavour sarebbe rimasto a terra per problemi tecnici. Nei tweet successivi hanno parlato di un guasto al riscaldamento di una linea per il combustibile diretto ad una delle Auxiliary Power Unit.

E’ stato abbastanza triste e deludente, perchè era già partito il conto alla rovescia (3 ore) e gli astronauti avevano già indossato le ACES (altrimenti definite “pigiamini arancioni”) ed erano già in viaggio nel CTV (è incredibile come ogni oggetto in NASA sia definito con una sigla) diretti al Launch Pad 39A.

Il lancio è stato inizialmente rimandato a Lunedì 2 Maggio, poi è stato spiegato che non sarebbe stato possibile fino all’8 Maggio e nelle ultime ore hanno avvisato che lo Shuttle non potrà essere spedito in orbita prima del 10 Maggio.

E’ stato successivamente spiegato che si è resa necessaria la sostituzione dell’APU Heater Power Box (scatoletta di alimentazione del riscaldamento dell’APU). Nella conferenza più recente parlano di sostituzione di un certo ALCA-2 (aft load control assembly-2). Il componente è stato rimosso oggi e sarà nelle prossime ore rimpiazzato. Comunque non voglio dilungarmi, non era mia intenzione fare una telecronaca dell’accaduto. Volevo solo far notare questa foto:

Due tecnici, probabilmente tra i più qualificati al mondo, incastrati in un compartimento di servizio dello Space Shuttle, a frugare tra cavi e tubi, per sostituire qualcosa che alla fine sarà una resistenzina da 2 euro o un diodo da 50 centesimi o qualcosa così.

Class-action contro Aruba: la pazzia continua.

Class-action contro Aruba: la pazzia continua.

Solo un veloce aggiornamento sulla vicenda (di cui ho parlato dettagliatamente qui). L’idea di Class-Action contro Aruba da parte del Codacons ha riscosso molto meno successo di quanto pensassi. Immaginavo centinaia di commenti in pochi giorni sul blog dell’Avv. Rienzi (sul quale è stato formalmente richiesto dal Codacons di rilasciare una pre-adesione), invece dopo 5 giorni questi sono appena una sessantina, di cui almeno la metà sono contro l’azione di gruppo nei confronti del colosso dell’hosting o di persone che come me tentano di spiegare, a tempo perso, la situazione.

Così tanto FLOP che da ieri ho iniziato a taggare i miei tweet riguardo la vicenda con il tag #FLOP oltre che #Aruba e #Codacons.

Segnalo l’articolo di Antonio Angelino, che riprende in parte i miei punti del precedente post ed estende il discorso. Per chi fosse interessato ad approfondire un minimo il discorso tecnico o a leggere pareri di professionisti come me, segnalo questo thread su HostingTalk.it.

Sto anche continuando a leggere (e a rispondere) divertito ai commenti dei vari utenti che si lamentano delle perdite milionarie subite a causa del down di 12 ore si un hosting lowcost da 30 € annuali che non offre garanzie da contratto. Inutile commentarli o rispondere a uno a uno, ma nell’insieme emergono alcuni punti interessanti. Non intendo trattarli nel dettaglio (anche perchè un professionista del settore o presunto tale -questo dovrebbe essere il mio target, considerato che non so scrivere in modo umano- dovrebbe capire senza troppe spiegazioni), ma solo elencarli:

  • Nessuno dei clienti che intendono proseguire nell’azione contro Aruba ha letto il contratto prima di sottoscriverlo. Appare ovvio, perchè al suo interno è esplicitamente contemplata la possibilità di danni per incendio e l’impossibilità di offrire rimborsi ai clienti. Più in generale non ci si rende conto che al momento della firma di un contratto per un servizio lowcost, la sostanza dell’accordo tra Provider e Cliente è “Ok Cliente, io ti do un servizio che costa la metà, ma sappi che per abbassare il prezzo devo togliere garanzie, va bene?”.
  • C’è una scarsissima conoscenza del mercato. Anche una nocciolina (fatta eccezione per qualche mia amica l’arachide è la cosa più stupida che conosca), vedendo che esistono pacchetti di hosting da 10 €, da 40 €, da 250 € e da 1500, tenterebbe di informarsi e di capirne le differenze, arrivando così in ben poco tempo a parlare di uptime, garanzie, penali etc.
  • C’è anche una conoscenza tecnica pari a zero. E’ comprensibile ovviamente, ma quello che non è comprensibile è la pari presunzione di esprimere pareri a riguardo. Ci sono persone che parlano di “server di emergenza” senza sapere minimamente cosa significhino la parola failover o la parola sincronizzazione, altri che parlando di “misure di emergenza” che Aruba AVREBBE DOVUTO mettere in atto senza riuscire minimamente a spiegare di cosa si stia parlando.
  • Si nota anche un certo livello di illogicità: c’è chi fatica a capire che anche se ha acquistato 20 pacchetti da 40 €, questi rimangono 20 pacchetti lowcost, o chi tira fuori la solita storia del mancato pagamento del rinnovo causa imprevisto dell’ultimo momento (si, esatto, quello li, quello che ti impedisce di pagare al sessantesimo giorno il dominio, senza che si capisca bene cosa hai fatto per i 59 giorni precedenti).
  • AGGIUNTA: Me l’ero dimenticata ma è di importanza fondamentale. Certi utenti hanno un’idea di “pagamento rateale” abbastanza alterata. Il ragionamento, in sostanza è: “sono dieci anni che pago 30 euro, quindi dovrebbero aggiungere ridondanza”. Bene, svelerò un segreto: no, non funziona così. Pagare 30 euro annuali per 10 anni non obbliga l’azienda ad offrire un servizio da 300 euro annuali.

E molto, molto altro. #FLOP

Giorgio

PS: Non so quale sia la fonte dell’immagine di Aruba in fiamme. Io l’ho presa QUI.

Class-Action contro Aruba: un delirio?

Class-Action contro Aruba: un delirio?

Ieri, Venerdì 29 Aprile 2011, alle 4 di mattina un corto circuito nella sala batterie del sistema UPS della WebFarm di Arezzo del gruppo Aruba ha causato uno spegnimento di tutta la struttura, portando offline i milioni di siti ospitati, caselle email, server dedicati etc. Ne hanno parlato testate autorevoli, come il TGCOM, il Quotidiano Nazionale o il Giornale.

Alle 10.30 è iniziata la rimessa in tensione delle sale. In qualche ora tutti i server erano nuovamente alimentati e i servizi iniziavano a tornare online (discorso diverso chiaramente per le macchine con filesystem corrotti a causa dello spegnimento improvviso). In serata, poi, è arrivato il Comunicato Stampa.

Il Comunicato spiega che si è attivato normalmente il sistema antincendio della sala UPS, ma che poi il fumo, diffuso in tutta la struttura, ha fatto scattare anche quello delle sale dati che ha causato l’interruzione di corrente. Sembra quindi che dopo il corto circuito relativo agli UPS sia entrato in funzione senza problemi il sistema di bypass di questi ultimi e le sale dati siano rimaste alimentate, salvo poi essere “spente” per un “errore” del sistema antincendio. Ma la questione è di poca importanza, perchè comunque i Vigili del Fuoco avrebbero chiesto di staccare l’interruttore generale prima di intervenire.

La cosa veramente interessante (cioè, ridicola) in tutta la vicenda è la Class-Action (cos’è?) che il Codacons ha promesso nei confronti di Aruba, per i disagi causati ai clienti durante il downtime. Da leggere assolutamente i commenti sul blog dell’Avv. Rienzi di chi non si rende conto che nessuno ha in mano coltelli, ma c’è un contratto, firmato, di chi ha una mail fondamentale per il suo lavoro ma la mette su un lowcost, di chi ha un sito fondamentale tramite il quale fa un immenso fatturato ma decide di ospitarlo su un pacchetto lowcost senza garanzie etc etc.

Mi fanno piacere i commenti di chi ha si scelto di ospitare un E-Commerce (anzi, 30) su sistema lowcost, ma sapeva a cosa andava incontro, sapeva cosa stava comprando e ha agito di conseguenza. Sono molti anche quelli che insultano il Codacons contro la class-action, da notare chi assume un atteggiamento “pan per focaccia” nei confronti dell’avvocato e del suo blog. C’è poi chi come al solito incolpa l’Italia, e confonde il bollino dorato “Uptime Garantito” con una garanzia da contratto e non si rende conto che per quel prezzo è semplicemente IMPOSSIBILE offrire garanzie. Ovviamente ci sono anche il MIO commento e quello dello (stimato) ex-collega Domenico De Monte.

Il punto focale è che il contratto firmato dai clienti spiega chiaramente che non sono fornite garanzie in termini di uptime, e che il prodotto offerto è soggetto a questo tipo di problemi. Il pacchetto di hosting è quindi qualcosa di “best effort”, ovvero “il meglio possibile”, in parole povere Aruba promette di offrire al cliente un buon servizio (ovviamente non può essere down 24ore al giorno), ma senza offrire garanzie in caso di problemi. Il cliente deve quindi saper valutare, decidere se il rischio di downtime per lui è accettabile.

Se lo ritiene accettabile, utilizza un servizio risparmiando non pochi euro (per soluzioni con delle garanze di uptime si parlerebbe di prezzi intorno alle migliaia di euro annuali), ma accetta di non richiedere risarcimenti in caso di downtime. Se non lo ritiene accettabile, ovvero crede che il rischio sia troppo alto e che l’eventuale perdita sarebbe troppo grossa, deve guardare da altre parti e tirare fuori il libretto degli assegni.

Una class-action che costringa il provider a risarcire i clienti quando da contratto negava questa possibilità, nata da clienti insoddisfatti di un servizio che hanno semplicemente sbagliato a comprare, sarebbe distruttiva per il settore: si costringerebbero le aziende ad offrire risarcimenti in situazioni economicamente impossibili. Il che può portare ad una sola cosa: la fine del lowcost. Essendo costretti a fornire risarcimenti in caso di problemi, i provider deciderebbero di offrire solo servizi all’altezza di una simile prospettiva, al fine di evitare inutili perdite.

Insomma, se volete sottoscrivere questa class-action, fatelo ma ricordate:

  1. Chi ha subito danni li ha subiti in quanto non ha letto il contratto e ha acquistato un servizio inadatto alle sue esigenze
  2. No, non avete perso email. Il protocollo SMTP è studiato per far fronte a queste situazioni
  3. Una azione simile, se vinta dai consumatori, creerebbe conseguenze catastrofiche sul mercato
  4. Eventi simili sono rarissimi, si fa prima a cancellare e ripartire

Vi terrò aggiornati.

Giorgio

ProgettoIdeaDelirio: GrG, 5 metri sottoterra

ProgettoIdeaDelirio: GrG, 5 metri sottoterra

Qualche riga per descrivere l’idea fuori di testa nonchè inutile delle 18.45 di Mercoledì 06 Aprile 2011. L’atto ufficiale, un post Facebook, è qui.


Partiamo dall’inizio. Mi incuriosiscono molto le piattaforme embedded ALIX, specialmente la Alix 2d3 (Caratteristiche Tecniche). In breve, è un micro-pc con una CPU da 500 mhz, 256 MB di RAM, 3 Ethernet e 2 USB. Non ha porte per la tastiera e il mouse o per il monitor, tutta la gestione avviene attraverso la porta COM (Cavo Null-Modem). Lo storage primario è una scheda FLASH (da utilizzare esternamente per l’installazione del sistema operativo) e si possono facilmente aggiungere dischi (o chiavette) USB.  Non ha ventole (raffreddamento passivo), ma in compenso è di ridottissime dimensioni. Si alimenta a 12 V e consuma 5 Watt.

Ho passato giorni e giorni a trovare un progetto inutile in cui utilizzarla. E oggi, l’idea: servire il mio blog (quello che state leggendo ora per intenderci) da 5 metri sottoterra.

Come? Intendo comprare questa board, installarci tutto il necessario, poi chiuderla in una scatola di quelle elettriche per esterni (sigillate) da cui usciranno solo Ethernet, COM e alimentazione. Dopo aver sigillato ogni fessura, finirà tutto in un buco in giardino. C’è solo qualche dubbio sulla portata di un cavo seriale, nel caso si potrebbe pensare ad un extender su Ethernet, chiuso anche quello nella scatola.

Per disperdere il calore potrei anche annegare tutto nell’olio di girasole (ma ho paura possano esserci problemi con gli abitanti del sottosuolo). Per ridurre al minimo i problemi causati da una potenziale perdita di tensione, dovrei pensare di inscatolare anche una batteria: considerato che parliamo di 12V non dovrebbe essere difficile, basta la batteria di una moto. La board consuma, come detto, 5W a 12V, ovvero 0.4AH, le batterie di questo tipo sono di circa 10AH: questo mi garantisce una autonomia di circa 24 ore.

Ancora più utile potrebbe essere alimentarlo a batteria (in modo che non sia sostituibile) e farlo connettere al mondo in WiFi.

Ci lavoro un pò e vi aggiorno.

Giorgio

Quando l’MX è indeciso…

Quando l’MX è indeciso…

Ho un piccolo hosting su AwardSpace, comprato più per provare il servizio che per altro. Oggi così per curiosità ho dato un occhio agli headers di una mail in entrata. Sono rimasto O_O (è difficile descrivere a parole).

Return-Path: <donotreply@akismet.com>
X-Original-To: giorgio@FAKEDOMAIN.COM
received: from mx2.runhosting.com (mx2.runhosting.com [82.197.130.202])by mbox2.runhosting.com (Postfix) with ESMTP id 4B1F3607F34Efor <giorgio@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:03:26 +0000 (UTC)
received: from mx2.runhosting.com (in2.defender.mail [82.197.130.203])by mx2.runhosting.com (Postfix) with ESMTP id B26D850600for <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:07 +0000 (UTC)
received: by mx2.runhosting.com (Postfix, from userid 65534)id A426C50615; Sun, 23 Jan 2011 00:07:07 +0000 (UTC)
received: from mail2.runhosting.com (mail2.runhosting.com [82.197.130.204])by mx2.runhosting.com (Postfix) with ESMTP id 6390C50600for <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:06 +0000 (UTC)
received: from mail2.runhosting.com (unknown [82.197.130.206])by mail2.runhosting.com (Postfix) with ESMTP id 965413EADCfor <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:06 +0000 (UTC)
received: by mail2.runhosting.com (Postfix, from userid 65534)id 7D3163F708; Sun, 23 Jan 2011 00:07:06 +0000 (UTC)
received: from mbox2.runhosting.com (mbox2.runhosting.com [82.197.130.207])(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))(No client certificate requested)by mail2.runhosting.com (Postfix) with ESMTPS id 088E63EADCfor <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:05 +0000 (UTC)
received: from mx2.runhosting.com (mx2.runhosting.com [82.197.130.202])by mbox2.runhosting.com (Postfix) with ESMTP id 8F221607F34Efor <admin@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:02:54 +0000 (UTC)
received: from mx2.runhosting.com (in2.defender.mail [82.197.130.203])by mx2.runhosting.com (Postfix) with ESMTP id 14FC850600for <admin@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:06:36 +0000 (UTC)
received: by mx2.runhosting.com (Postfix, from userid 65534)id F17CC50615; Sun, 23 Jan 2011 00:06:35 +0000 (UTC)
received: from smtp1.sat.wordpress.com (smtp1.sat.wordpress.com [76.74.254.15])by mx2.runhosting.com (Postfix) with ESMTP id 192E950600for <admin@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:06:33 +0000 (UTC)
received: from smtp1.sat.wordpress.com (localhost.localdomain [127.0.0.1])by smtp1.sat.wordpress.com (Postfix) with ESMTP id 02EC4241C198for <admin@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:02:57 +0000 (UTC)
received: from _ (c6.sat.akismet.com [66.135.58.48])by smtp1.sat.wordpress.com (Postfix) with ESMTP id E7883241C18Afor <admin@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:02:56 +0000 (UTC)
X-Spam-Score: -2.0
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on in2.defender.mail
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL autolearn=disabledversion=3.2.5
Dkim-Signature: v=1; a=rsa-sha1; c=relaxed; d=akismet.com; h=date:to:from:subject:message-id:reply-to:mime-version:content-transfer-encoding:content-type; s=my3; bh=CC4iVqFNhHYEprW6wy8MS/KCPqo=; b=l28OC3lmyUmdoLIK+8ts7rfM9RV81WUySnA3O6aDa55rCS00aSTV8Cp70ziz0e6mrbOuoRwPPanQC77Xm/agtA==
Domainkey-Signature: a=rsa-sha1; c=nofws; d=akismet.com; h=date:to:from:subject:message-id:reply-to:mime-version:content-transfer-encoding:content-type; q=dns; s=my3; b=weli02Y9jlA0+tE5g8DpzJAwO+PFYAPGqC4iAOw7AYXthPs3m2Rx//oJ2iN2kkL6/Ixa1Ba9raPhtNxoNlqYtg==
Date: Sat, 22 Jan 2011 16:02:56 +0000
To: admin@FAKEDOMAIN.COM
From: Akismet Support <support@akismet.com>
Subject: Your new Akismet API key
Message-Id: <2c88cc629485167f7c160c4737027367@_>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
Reply-To: support@akismet.com
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=”UTF-8″
x-virus-scanned: ClamAV using ClamSMTP (in2.defender.mail(82.197.130.203), client: 82.197.130.202)
x-virus-scanned: ClamAV using ClamSMTP (out2.defender.mail(82.197.130.206), client: 82.197.130.204)
x-virus-scanned: ClamAV using ClamSMTP (in2.defender.mail(82.197.130.203), client: 82.197.130.202)

E’ spaventoso. C’è un forwarding che per qualche motivo a me sconosciuto non viene effettuato in locale pur essendo parte dello stesso dominio (probabilmente un doppio check antispam sulle mail in uscita). Si notano poi continui rimbalzi altrettanto inspiegabili (le mail tornano ad un certo nodo dopo che le ha buttate fuori lui stesso).

Chiederò spiegazioni al supporto.

UPDATE: @cxunix ha definito il fenomeno come “Il giro della posta in 80 MX”. Ci facciamo un film?