Stefano Marinelli's Blog (Articoli su recensioni)

Alla Ricerca del Backup Perfetto: Borg e Restic

Stefano Marinelli — Wed, 23 May 2018 07:42:37 GMT

English version here

Backup: tecniche principali

In passato ho già affrontato l'argomento backup ponendo alcune basi e dando alcune indicazioni sulle principali modalità e sul perché è fondamentale farlo, sul perché il RAID non può essere considerato una forma di backup e su alcuni software da me presi in esame e utilizzati in precedenza. Invito dunque a leggere l'articolo collegato, per una base di partenza. Questa volta, però, daro delle guide su come io realizzo i backup e su come io riesca a garantire un certo grado di sicurezza.

Backup: le basi di partenza

Proporrò l'argomento sotto forma di elenco puntato, onde coprire le principali problematiche da gestire:

Sistema Operativo e dati da salvare: ogni sistema operativo è un universo. E' ragionevole pensare che non esista una soluzione universale, anche se molti dei principali software open source sono multi-piattaforma. Il principale divario è tra i sistemi Unix-Like (GNU/Linux, BSD, MacOS, ecc.) e Windows. Lo stesso software, pur essendo disponibile per più piattaforme, potrebbe non essere il migliore per la propria o per le proprie necessità.
Tipo di dati da salvare: ogni tipo di backup richiede soluzioni diverse. Ci sono situazioni in cui si ha la necessità di copie pressoché sempre incrementali in quanto i file crescono ma non vengono modificati. In questo caso, un qualunque sistema appunto incrementale (es: Duplicity ) può essere sufficiente. Nel caso, invece, di backup sempre diversi (es: un database che cambia costantemente), un sistema come quello precedente può essere estremamente inefficiente, specialmente nel lungo periodo.
Necessità di crittografia o meno: i backup delle mie fatture, ad esempio, potrei anche evitare di crittarli...
Rapidità di esecuzione e di recupero: ci sono strumenti che sono estremamente efficienti nell'effettuare l'operazione di copia, ma che rendono estremamente lento il recupero. Una delle (poche) carenze da me riscontrate in BURP Backup, di cui ho parlato nell'articolo precedente e che utilizzo ancora con successo in certe situazioni, è che richiede il restore dei file e non consente, per lo meno direttamente, di navigare nel backup come fosse un file system locale. Stesso discorso vale, ad esempio, per il backup nativo di Proxmox: è comodissimo da impostare, completo e nativo ma il tempo di recupero può essere importante, specialmente se effettuato in postazioni remote e su connessioni lente. Recuperare un file richiederà, molto spesso, il recupero totale della macchina.
Snapshot: ultima in lista, ma questione di primaria importanza. Un backup di un file system "live" avrà un momento di inizio e un momento di fine. Nel frattempo, i dati cambieranno all'interno di esso e potrebbe generarsi incoerenza. In passato ho avuto problemi del genere: un database (mysql) di qualche GB è stato rovinato da un cliente e me ne è stato chiesto il recupero. Ho preso, con baldanza, l'ultimo backup e ho ripristinato i vari file (non un dump). Inutile dire che è stato impossibile farlo ripartire: il file molto grande era cambiato troppo tra l'inizio del backup dello stesso e la fine, per cui era incoerente. Per i maliziosi: avevo anche il dump, ovviamente, per cui ho recuperato quello. Ma la questione resta chiara: fare un backup di un file system live è pericoloso, a meno che non si stia copiando la cartella "Documenti" o "Immagini". Un database aperto, come anche semplicemente quello del browser, ha altissime probabilità di corrompersi e rendere inutile la copia di sicurezza fatta. La tecnica è fare uno snapshot dell'intero file system prima di iniziare la copia. Ci sono margini di rischio anche in questo (il backup avrà all'incirca lo stesso stato che avrebbe la macchina se venisse improvvisamente staccata la spina), ma largamente inferiori. Ad oggi, utilizzando snapshot, sono stato in grado di recuperare tutto.

Continua la lettura… (ulteriori 9 minuti di lettura)

Un assaggio di Alfa Romeo Giulietta

Stefano Marinelli — Thu, 17 Aug 2017 17:33:31 GMT

Preambolo

Poco meno di due anni fa ho raccontato di come mi sia trovato con la Nuova Panda a Metano e riportato la mia (ottima) esperienza in merito. Percorrendo molti km ogni anno, c'era però necessità di una vettura più "concreta", sia come spazio che come comfort.

La scelta è dunque caduta sulla vettura che aveva mio padre, ovvero una Alfa Romeo Giulietta. La vettura è stata immatricolata nel Dicembre del 2010 (dunque aveva circa sei anni a Marzo, quando l'ho presa in carico) ma aveva solo 30.000 km.

Ecco le caratteristiche:

Continua la lettura... … (ulteriori 4 minuti di lettura)

Un assaggio di Docker

Stefano Marinelli — Sat, 05 Aug 2017 19:30:12 GMT

Preambolo

Ho fatto i primi passi nella virtualizzazione nel lontano 1998. Mi affascinava l'idea di inscatolare un intero computer all'interno del mio PC e non dover più essere schiavo di installare, cancellare, reinstallare, avere due sistemi operativi diversi per scopi diversi contemporaneamente nella stessa macchina e avere eventuali problemi di boot all'aggiornamento di uno ei due.

Sperimentai dunque VMWare e capii subito che la virtualizzazione sarebbe stata il futuro. Nel corso degli anni la penalizzazione sulle prestazioni si è via via assottigliata e nella mia tesi di laurea, nel 2003, mi occupai proprio degli internal di vari virtualizzatori tra cui il neonato i QEMU. Il bello di qemu era proprio la possibilità di emulare piattaforme hardware diverse per lo sviluppo o l'emulazione, e in maniera sufficientemente (per l'epoca) rapida grazie alla traslazione dinamica delle chiamate di sistema, un metodo per l'epoca rivoluzionario. C'erano anche i primordi di Xen, che dava risultati assolutamente interessanti ma richiedeva modifiche al sistema operativo guest. Venne poi fuori un modulo kernel per qemu (divenuto poi KVM, la base dei principali virtualizzatori moderni) che gestiva la virtualizzazione passando direttamente le chiamate all'hardware sottostante, abbattendo l'overhead prestazionale a livelli bassissimi e consentendo di avere un buon numero di VM su un server fisico.

Da allora mi occupo di virtualizzazione ma ho sempre cercato anche altre possibilità proprio perché nell'informatica bisogna sempre avere fame di novità.

Ho lavorato (con estremo successo, ne racconterò prima o poi l'esperienza) già dal 2005 con OpenVZ, che mi ha permesso (per anni) di far girare il mio server principale sia sul VIA EPIA che su un server esterno a cui migravo il tutto in base alle necessità. I container, insomma, mi sono sempre piaciuti.

Nel 2010, ho iniziato a implementare soluzioni basate su FreeBSD proprio per avere le sue jail, ovvero degli ambienti non emulati ma separati dal sistema operativo principale. In pratica, stesso kernel ma userland completamente diversa. Nessun overhead di virtualizzazione ma semplice separazione degli ambienti. Non era un concetto nuovo, infatti Solaris utilizza i container (o zone) già dal 2004, ma di sicuro un concetto vincente: se il mio scopo non è avere sistemi operativi diversi ma solo tenere separati i servizi, perché dover lanciare n macchine virtuali con n sistemi operativi uguali in esecuzione?

Poco dopo è arrivato anche GNU/Linux, e già nel 2011 sperimentavo con lxc, pur sapendo che non c'erano ancora i requisiti di sicurezza necessari, ma avevo già degli strumenti per tenere separati vari ambienti basati su GNU/Linux.

Proprio su lxc si basa Docker, una soluzione di inscatolamento di ambienti, che ne consente la creazione e l'utilizzo su qualsiasi piattaforma compatibile e crea un ambiente standard in un solo comando.

I miei primi passi con Docker

...sono stati disastrosi, come credo quelli di tutti quelli che hanno iniziato ai suoi albori. Docker è un progetto relativamente recente e, come tale, in forte sviluppo. Uno dei problemi, infatti, è che lo sviluppo è rapido e, a volte, distruttivo. Basta un aggiornamento e cambia qualcosa nella riga di comando, nel setup della rete, nella funzionalità e ci si può trovare con un sistema malfunzionante. Il primo passo che feci non fu diverso. Installai Docker, lo misi in funzione per alcuni test, aggiornai alla nuova versione stabile e tutti i miei contenitori smisero di funzionare per variazioni di struttura. Decisi di buttare via tutto e aspettare tempi migliori.

D'altronde si sa come funziona: o una tecnologia diventa sufficientemente matura in poco tempo, oppure muore. Nel primo caso, l'attesa non è così lunga. Nel secondo, non conviene perdere tempo con qualcosa che non avrà futuro.

Alcuni mesi fa ho deciso di rimettere in piedi il discorso. Di solito imparo qualcosa per necessità, poi lo espando e lo riutilizzo. A volte la necessità è puro vezzo privato, magari per fare qualcosa di non strettamente lavorativo ma si sa, l'animo nerd non lo si tiene a freno e, anzi, guai se ciò avvenisse!

Docker su strada

Rimettere in strada Docker non è stato difficile. A oggi, infatti, le cose sono state rese più facili (sia per architetture tradizionali che per le ARM come Raspberry PI o similari) da un rapido & semplice comando:

curl -sSL get.docker.com | sh

ovviamente a patto di avere curl installato, cosa non del tutto scontata in tutte le installazioni (Debian base non ce l'ha).

In un lampo, sono stato pronto col mio eseguibile pronto da usare e libero di fare dei test.

Ho iniziato. Immediatamente mi sono trovato a mio agio sia con la sintassi (anche se, a mio avviso, va ancora un po' uniformata tra un container normale e uno Swarm sia col funzionamento generale. Il vantaggio dell'inscatolamento delle risorse è indubbiamente evidente. Ogni cosa resta nel suo mondo, con le sue dipendenze, senza andare a intaccare o modificare alcunché sul resto del sistema.

Ho subito iniziato ad aver bisogno di alcune funzionalità non ancora presenti nei container presenti nell'hub ufficiale (specialmente per quanto riguarda le architetture ARM in mio possesso) per cui ho esplorato la creazione di una immagine personalizzata. Anche qui semplicità assoluta, un Dockerfile con tutte le istruzioni necessarie e una bella procedura. In un lampo ho avuto tutto il necessario.

Gli Swarm

Uno Swarm è un gruppo di sistemi su cui Docker è installato che si uniscono in un cluster. In uno swarm, ogni worker può far partire uno dei container e metterlo a disposizione. In uno swarm, un container può essere definito come servizio singolo (farne girare sempre uno su uno dei nodi), oppure come servizio multiplo (far girare n copie, che verranno distribuite nei nodi dello swarm) e milioni di sfumature di configurazione.

In uno Swarm, per scelta progettuale, una porta esposta da un container sarà raggiungibile connettendosi all'IP di uno qualunque dei nodi. Se, ad esempio, abbiamo due nodi (nodo1 e nodo2) e un container che espone la porta 80 (un server http), una volta configurato il servizio come parte dello Swarm sarà possibile connettersi al container stesso sia sull'IP del nodo1 che su quello del nodo2.

Conclusioni

Questo articolo voleva essere solo una rapida carrellata su quella che è stata la mia recente esperienza con Docker e sul perché ho deciso non solo di utilizzarlo ma di approfondirne sempre di più le potenzialità.

Seguiranno altri articoli in merito, quando il tempo me lo consentirà, che spiegheranno come ho risolto alcune delle problematiche principali che possono occorrere nell'utilizzo quotidiano e in produzione di un sistema del genere (es: storage condiviso tra nodi, ecc.)

Suggerisco a tutti di cominciare a prendere in considerazione questo tipo di tecnologia, sia per ragioni di sicurezza che di scalabilità e praticità. Volenti o nolenti, sarà il futuro. O il presente.

Alla ricerca del Backup Perfetto

Stefano Marinelli — Thu, 17 Dec 2015 10:30:00 GMT

English version here

Backup: perché farlo

Da che mondo è mondo, tutto può essere perso. Sia per ragioni accidentali che per ragioni ben ponderate, qualsiasi cosa può essere fatta sparire o può sparire per errore. Quante volte ci sarà capitato di perdere un oggetto e non trovarlo mai più?

Da quando esiste l'informatica, poi, questo concetto si è espanso a dismisura. Mentre è difficile perdere un oggetto, è molto più facile cancellare un file o una informazione dal computer, oppure voler ripristinare una versione precedente.

Molte persone pensano che sia sufficiente garantire che il supporto di memorizzazione sia ridondato, e si è a posto. SBAGLIATO!: un raid senza dubbio aiuta a non perdere tutto in caso di guasto di un disco, ma cosa accade quando il dato viene accidentalmente cancellato, quando viene compromesso per colpa di un virus o di una qualsiasi entità esterna, oppure quando l'elaboratore (raid o meno) viene rubato, o prende fuoco, o una situazione di questo tipo?

Ho collezionato esperienze di ogni genere. Tanto per elencarne alcune:

sale server finite sott'acqua per colpa di alluvioni
server distrutti dal terremoto, ovvero da crolli murari che hanno investito le sale macchine
ransomware vari, che ultimamente colpiscono molto più che in passato
danno volontariamente causato da qualcuno che ne ha tutto l'interesse (es: aziende informatiche che, poco correttamente, causano danni per crearsi lavoro. Sì, ho visto anche questo, e non una sola volta, purtroppo. E sto gestendo una situazione del genere proprio in questi giorni.)
errori da parte dell'amministratore (può succedere a chiunque)

Se poi parliamo di server esposti su Internet (es: e-commerce, server di posta elettronica, ecc.), la situazione diventa ancor più delicata in quanto oltre che la correttezza dei dati, c'è bisogno di garantire anche la continuità operativa del servizio.

La soluzione migliore, dunque, è avere sempre dei backup a disposizione. Ma quali caratteristiche dovrebbero avere questi backup?

Continua la lettura... … (ulteriori 10 minuti di lettura)

S'è rotto il MacBook Pro Retina (Late 2013). Di già.

Stefano Marinelli — Sun, 06 Dec 2015 09:00:00 GMT

Io e la Apple: gli albori

I prodotti Apple mi sono sempre piaciuti e anche alla luce degli ultimi eventi, continuano a piacermi. Ho ancora un iMac G3 verdone, 400 MHz(1. iMac G3), acquistato (usato) nel 2001 e che tengo come oggetto d'arredamento.

Il mio iBook G4 (2. iBook G4 933MHz), arrivato nel Dicembre 2003, ha effettuato un buon servizio, rimpiazzato da un "normale" portatile x86 per ragioni di compatibilità con i sistemi di macchine virtuali che utilizzavo già allora.

Ho avuto due iPhone, un 3G e un 4 (3. iPhone 4 (dopo breve parentesi di 3G)), un MacBook Pro del 2009 (4. MacBook PRO 15" Mid 2009), che sto usando in questo momento per scrivere questo articolo e, nel Novembre 2013, ho pensato fosse arrivato il momento di affiancare al "vecchio" Pro una nuova macchina da usare prevalentemente a casa: un MacBook Pro Retina 15" Late 2013. Processore i7, 16 GB di Ram, SSD da 512 GB (5. MacBook Pro Retina 15" Late 2013). Una bellissima macchina. Aggiungerei alla lista un iPod Nano (prima versione), un iPod Nano più recente, e un iPod Touch (6. Gli iPod).

Io e la Apple: i dispositivi e i loro problemi

Di elettronica ne ho avuta tanta, e come tutti ho avuto dei problemi, nel corso degli anni. Però la mia statistica personale mostra che i prodotti Apple sono bellissimi ma non esenti sia da errori di progettazione che da problemi di affidabilità. Racconterò di tutti i problemi avuti con i miei dispositivi Apple, finendo con quello che, forse, sarà il mio ultimo dispositivo della casa della mela. Sono ancora convinto che siano dei bei prodotti, ma costano troppo e non sono così affidabili come dovrebbero. Poi ognuno avrà le sue esperienze, io racconto le mie.

Continua la lettura... … (ulteriori 15 minuti di lettura)

Un assaggio di Zuk Z1

Stefano Marinelli — Sun, 22 Nov 2015 22:05:37 GMT

Come antcipato alcun giorni addietro, ho ordinato un nuovo Zuk Z1. Le ragioni sono molteplici, prima tra tutte la voglia di girare con un solo telefono (dual sim) invece che, come avviene già da dieci anni, con due terminali. Considerando inoltre l'aumento medio di dimensioni di uno smartphone odierno, non bastavano più le tasche per tenerli.

Perché scegliere proprio un Zuk Z1? Avevo già elencato le motivazioni, le riprenderò qui:

Cyanogen OS nativo - che utilizzo anche sui miei altri Android.
Dual Sim - comincio ad essere stanco di portare sempre in giro due telefoni. Meglio uno più grande che due.
Batteria mostruosa - secondo me, il maggior limite degli smartphone moderni è la durata della batteria. Apprezzo ancora il LG G2 proprio per questa ragione, ma 4100 mAh sono davvero da record.
3 Giga di Ram, 64 giga di memoria integrata - anche se con una microSD, diventano interessanti anche altri terminali.
Per me è assurdo spendere più di 500 euro per uno smartphone. Che tra 6 mesi sarà vecchio, pur non essendolo.

Cosa mi piace

Anticipo subito che le mie aspettative sono state decisamente soddisfatte e che, anzi, il terminale è ben al di sopra delle mie più rosee previsioni.

La prima cosa che ho notato è che dal vivo è decisamente più bello che in foto, la qualità percepita è notevole e lo schermo ha un'ottima resa. Ho ordinato anche la cover in TPU e l'eccellente pellicola protettiva che l'e-commerce da cui l'ho acquistato proponeva, e pur avendolo reso leggermente più tozzo, di sicuro è ora protetto a dovere.

Il primo boot è stato decisamente lento. Più lento della media dei terminali che ho avuto, ma nessun problema in quanto dall'avvio successivo il tutto è diventato più rapido, inoltre non ho l'abitudine di spegnere lo smartphone a meno che non sia strettamente necessario. Il Z1, inoltre, supporta il Quick Boot, una sorta di ibernazione che consente uno spegnimento parziale e un'accensione pressoché immediata. Un po' come facevano i cari, vecchi BlackBerry. Ma attenzione: non fatelo se avete impostato la sveglia. Essa suonerà, ma sarà praticamente impossibile disattivarla fino a quando non avrà smesso di suonare. Siete stati avvisati.

CyanogenOS si comporta egregiamente: tantissime personalizzazioni possibili, sempre snello e fluido (Android Stock è rapido, sono tutte le "schifezze" installate dai vari produttori che lo rallentano a dismisura), funzioni giuste e ho già ricevuto cinque aggiornamenti, per cui il terminale è in pieno sviluppo. Sarebbe grave il contrario, visto che è appena uscito.

Lo schermo ha una buona risoluzione (FullHD) e a mio avviso è ottimo. I QuadHD appesantiscono i chipset, e a meno di volere il massimo della risoluzione a oggi esistente nel mercato consumer, non sono una condizione necessaria. Il Zuk si legge bene, di notte diventa riposante grazie alla sua impostazione automatica di colori in base all'ora e alla luce presente, e rende bene anche i colori.

La fotocamera si comporta bene. Non ha la rapidità di messa a fuoco del laser, ma sufficiente per le mie necessità. Non è paragonabile a quella del Lumia 930, ovviamente, ma è adeguata alle normali necessità. In caso di voglia di foto ben fatte, preferisco usare la mia reflex più che un telefono cellulare.

Ottimo l'audio, per la fascia di prezzo. Si sentono anche alcuni bassi e ha un volume degno di nota. Una piacevole sorpresa, così come è stato sorprendente il lettore di impronte digitali: rapidissimo, non sbaglia un colpo. Unico (piccolo) difetto, probabilmente dovrò ritararlo in quanto dopo aver messo la pellicola, il dito tocca con una diversa inclinazione e potrebbe non riconoscerlo immediatamente.

Fantastica la gestione delle due sim: entrambe possono essere impostate in LTE, ma solo una alla volta. Di solito tendo a tenere in LTE quella connessa alla rete dati, mentre lascio in 2G quella che utilizzo per la voce. Invertire le due cose, comunque, è banale e rapido, per cui non ci sono problemi. Utile anche la possibilità di disabilitare i dati in roaming in maniera separata "per-sim", in modo da non rischiare pesanti addebiti sull'altra.

Ma la cosa che mi soddisfa di più è LA BATTERIA. Finalmente un telefono capace di portarmi a sera in ogni condizione, e sempre con una percentuale elevata di carica residua. Fino ad oggi non ho mai raggiunto un valore inferiore al 50%, anche con utilizzo intenso. Smartwatch attivo, impianto viva voce Bluetooth in auto attivo, rete dati attiva, wifi attiva, eppure non perde colpi. Lo carico comunque tutte le sere, per avere sempre la massima autonomia nel giorno successivo, ma ho finalmente potuto staccare il caricatore dalla presa di corrente dell'auto.

Cosa NON mi piace

Non è tutto oro ciò che luccica. Anche il Zuk ha i suoi difetti. Il principale, a mio avviso, è la mancanza della banda degli 800 Mhz. Alcuni dicono sia inutile, altri che solo Wind, in Italia, la utilizzi ma la mia prova comparativa tra il "vecchio" LG G2 e il Zuk ha mostrato le differenze anche con gestori come Tim e Vodafone, i miei principali. In città, infatti, non vedo grosse lacune (anche il Z1 si connette in LTE), ma appena si esce e si finisce in periferia, si nota subito che mentre il G2 riesce ad avere accesso alla rete LTE (a piene tacche, quindi non a distanza), il Zuk passa in 3G. C'è poco da dire, la "bassa" frequenza è utile proprio per coprire una maggior estensione con minor concentrazione di BTS, e il Zuk non la supporta. Nel mio caso, non è un problema: per l'uso che faccio dello smartphone, non ho necessità dell'LTE, per cui potrei anche tenerlo disattivato. Il 3G ha banda e latenza sufficienti per i miei utilizzi mobili. Ma il problema c'è, e non è il caso di nascondere la testa sotto la sabbia fingendo che non ci sia. Chi ha necessità estrema di LTE sugli 800 Mhz, dovrebbe evitare il Zuk Z1.

Altra (bazzecola) che non mi piace: il cavo fornito è corto, cosa che ultimamente accade spesso. Al momento, non è neanche facile trovare un (buon) cavo lungo USB Tipo C, in quanto ancora non ci sono molte apparecchiature che lo supportano. Tempo al tempo.

Conclusioni

Promosso, a pieni voti. Solido, stabile, poco importa se un po' mattone o se non ha l'NFC, se non ha gli 800 Mhz e lo schermo QuadHD, chi se ne importa se monta "solo" un Qualcomm Snapdragon 801 e non l'810 (che lo avrebbe reso anche una comoda stufetta portatile). Un terminale da usare tutti i giorni, tutto il giorno, che richiede un basso sforzo economico per l'acquisto e può dare molte soddisfazioni. E ha scalzato qualunque Windows Phone dalla classifica dei miei smartphone preferiti.

50.000 km con la Nuova Panda a Metano

Stefano Marinelli — Sat, 14 Nov 2015 22:00:27 GMT

La Scelta

Chi mi conosce da tempo è al corrente del fatto che mi piacciono le auto. Lungi da me il fare pubblicità ad un prodotto specifico, ma mi piace raccontare quelle che sono le mie impressioni su ciò che utilizzo quotidianamente.

Nell'Aprile del 2013 ho deciso di ordinare un mezzo aziendale. Un Van, utile per caricare gli strumenti di lavoro. Volevo fosse pratico, di bassi consumi, sufficientemente confortevole e sicuro. Tra le varie opzioni, escludendo i veri e propri furgoncini, erano rimaste due opzioni: La Volkswagen eco up! e la Nuova Fiat Panda a metano.

Perché a metano? Sia per ragioni ambientali, ma anche economiche. Il nuovo motore TwinAir da 85 cavalli (piccolo di cilindrata, sufficientemente potente e bicilindrico) mi ispirava. La preferenza è andata verso la Panda, per vari motivi:

Volevo un'auto italiana, anche per ridare una possibilità a FIAT, dopo brutte esperienze passate (ma molto tempo addietro)
La Panda ha un serbatoio di benzina normale, non ridotto come la up!. Questo è un difetto per chi gira sempre a metano e per chi compra l'autovettura (non Van) in quanto deve pagare un bollo normale, mentre la up!, con pochi litri di benzina, è considerata monocarburante e dunque paga in maniera ridotta. Nel mio caso, essendo autocarro, pago comunque un bollo diverso e non c'è differenza in base all'alimentazione. Avevo dunque paura di rimanere senza metano e senza benzina, preferendo dunque un serbatoio "classico" di maggior autonomia. In 50.000 km, non ho mai avuto bisogno di fare più di qualche decina di km a benzina (se non per scelta)
Il TwinAir della Panda è piccolo, brioso e scattante, mentre l'aspirato della up! è più lento e consuma di più.
La Panda, a livello estetico, mi piaceva di più.

Decisione presa: l'8 Aprile parte l'ordine. Prima osservazione: il prezzo. Non è basso, per niente. La Panda Van parte, di listino, circa allo stesso prezzo della normale. La principale differenza, però, è che la Van è davvero un modello base (tanto per citare uno spot d'epoca). Non sono comprese cose a oggi ormai basilari come il tergi posteriore, lunotto termico, ma anche chiave col telecomando o aria condizionata. Tutto è optional, e per avere un veicolo "moderno" a sufficienza, bisogna mettere tantissimi accessori. Ok, ho inserito anche il Blue&Me e l'ESP (sulla sicurezza è sempre meglio non risparmiare), ma il prezzo di listino si avvicinava ai 19.000 euro. Un po' di sconto, non tanto (non c'erano incentivi, in quel momento), e l'ordine è partito. 60 giorni di attesa.

Le prime impressioni

L'auto è arrivata in concessionaria nei tempi stabiliti. Grazie al colore e ai sensori posteriori, sembra una normalissima Panda. Non il classico furgone, ma la tipica utilitaria italiana. Alla prima accensione, già la prima sorpresa: il motore è decisamente silenzioso, e il rombo è particolare. Non sentivo un bicilindrico da anni.

Viaggio di oltre 200 km per portarla a casa, quasi tutti in autostrada. Essendo Giugno, un po' di climatizzatore è servito, ed ero decisamente impressionato: confort eccellente (per la categoria), un pelo rigida ma lo immaginavo, essendo a metano e un Van. Ottima integrazione dell'impianto a metano, essendo di serie, con il cruscotto dell'auto e, in generale, una inaspettata percezione di qualità. A 130 è silenziosa (il rumore motore è quasi assente, e sono abituato ad altri standard), pronta a riprendere in caso di sorpasso e sufficientemente parca nei consumi.

Ogni tanto vibra un po', ad esempio in accelerazione, ma è normale: sono pur sempre due cilindri. Diverte, comunque, quando il regime si abbassa e si sentono i singoli pistoni battere, stile motociclistico.

I consumi

E qui viene il bello. Ok, è risaputo che le auto a metano sono economiche nella gestione quotidiana, ma sono rimasto ulteriormente soddisfatto. Ad andature miste urbane/extraurbane, supero abbondatemente i 300 km con un pieno di metano di circa 10 euro. Il record positivo è stato di 410 km, negativo di 200 ma la qualità del metano è molto importante ai fini della resa, e da zona a zona cambia anche molto. In autostrada, in media, supero i 250 km con un pieno. Insomma, un'auto decisamente parca, ed essendo un mezzo aziendale e di lavoro non è senza dubbio male. Ci sono giornate in cui si gira dalla mattina alla sera e la spesa finale è di...10 euro, per 350 km. Notevole.

Il primo tagliando

FIAT consiglia il primo tagliando dopo due anni o 30.000 km. Sono arrivato ben prima ai 30.000 che ai due anni, e a Ottobre 2014 è finita per la prima volta in officina. La sorpresa, in questo caso, non è stata positiva: 288 euro, quasi l'equivalente di quello che avevo speso per il tagliando della BMW 118d (dei 150.000 km) nello stesso periodo. Non saprei dire se sia stata l'officina ad essere particolarmente cara o se questi siano i prezzi standard, ma mi è sembrato decisamente alto. Chiarirò il dubbio al prossimo tagliando, che verrà effettuato in un'officina FIAT diversa.

Il primo guasto

A circa 40.000 km, la scorsa estate, si è iniziato ad udire un sibilo dal climatizzatore. Ad essere onesti, il sibilo era già percepibile (più ovattato) anche l'estate precedente, ma non avevo dato peso alla cosa. Peggiorando di giorno in giorno, ho deciso un ricovero in officina (causa anche l'approssimarsi della fine della garanzia). Il meccanico ha rilevato un allentamento di alcune fascette di contenimento del gas del climatizzatore, probabilmente causato dalle vibrazioni del bicilindrico. L'auto (anzi, l'autocarro) viene tenuto sempre in garage, dunque protetto.

Riparata dunque in garanzia (ho però dovuto pagare la carica del gas, considerato da FIAT come consumabile...peccato che l'auto l'abbia "consumato" a causa di un guasto riconosciuto in garanzia, ma amen), tutto è tornato a posto... fino al giorno prima di Ferragosto: al minimo, si è sentito un forte sfiato dal motore e di nuovo il clima ha iniziato a sibilare. Tornato in officina dopo la riapertura ferragostana, mi hanno detto che ci sarebbe stato di nuovo bisogno di fermarla per la riparazione e, a dir la verità, non ho ancora avuto tempo di farlo. Alias al momento il clima non funziona, e spero riconosceranno di nuovo il guasto in garanzia (pur essendone ormai fuori) in quanto è di nuovo accaduto ciò che si era presentato (e riparato) in piena garanzia.

I 50.000 km

Il traguardo dei 50.000 km è stato superato in Autostrada, nel corso di un viaggio in giornata di oltre 600 km in mezzo alla nebbia novembrina. Prova ampiamente, come al solito, superata. Alla luce di tutto, ecco cosa penso, a oggi, di questo mezzo:

Qualità interna decente. Non ottima. Le plastiche interne, pur non terribili, sembrano un po' dozzinali. Tratto bene le mie auto, eppure la Panda mostra alcuni graffi interni in punti in cui ho sempre e solo appoggiato telefoni cellulari (con custodie morbide) o fogli. Una volta mi è caduta una penna sul tunnel centrale, lo ha leggermente graffiato. Un po' delicata, per i miei gusti... Ma nessun cigolio o altri rumori interni, è ancora compatta come da nuova, davvero una piacevole sorpresa
Ottimo cambio. Si è sciolto con rapidità, e ha innesti sicuri e semplici. Cambio e frizione promossi a pieni voti. Ci vuole attenzione con la retro, una bella grattata è altrimenti assicurata.
Rigida, ma non scomoda. Sul pianale della 4x4 per far spazio alle bombole, è rigidina ma non troppo.
Motore gradevolmente strano. Bisogna guidarlo come un diesel, ed è un pochino fiacco ai bassissimi regimi (complice la cilindrata bassa), ma brioso appena si schiaccia l'acceleratore.

La consiglierei? Beh, in base all'esperienza accumulata fino ad oggi, decisamente sì. Pur col problema, non ancora risolto, al climatizzatore, non mi ha mai riservato sorprese negative. In rapporto alla Golf V TDI DSG acquistata nuova nel 2005 e venduta un anno dopo per disperazione, la Panda è un campione di affidabilità. Il mio record, però, è ancora la già citata (e venduta di recente) BMW 118d. 180.000 km in 9 anni e mai, MAI un problema.

Addendum del 12/07/2019:

La Panda è giunta a 100.000 km, è ancora perfetta e non ha mostrato alcun problema importante.

La Guerra dei Browser Continua

Stefano Marinelli — Sun, 11 Oct 2015 09:28:49 GMT

Utilizzo Internet dal 1994. All'inizio, ovviamente, non ne sapevo molto (non avevo neanche quindici anni), ma capii subito che ci sarebbe stato un futuro. Ho sempre avuto una passione per le reti e sognavo un mondo interconnesso. Ciò è avvenuto, e in meno tempo del previsto.

Da quando si naviga su Internet, c'è sempre stato un bel problema: trovare lo strumento più adatto allo scopo prefissato. Le mie prime scelte furono Eudora per la posta elettronica, e Mosaic come browser web, rimpiazzato successivamente dal mitico Netscape.

Quando, nel 1996, iniziai ad esplorare il mondo GNU/Linux, mi trovai costretto a cercare delle alternative. Scoprii il potente Mutt per la posta elettronica, che uso ancora di tanto in tanto, slrn (e successivamente tin, in accoppiata prima a INN+Suck poi a Leafnode) per Usenet, ma no, Lynx o Elinks come browser principali non erano contemplabili, per cui, per navigare, rimasi ancorato all'interfaccia grafica.

Da allora, non sono mai stato un fedelissimo di un singolo browser. Ho esplorato, cambiato, cercato, trovato, perso preferiti, consigliato, pubblicizzato. Non mi sono mai fermato, complice anche il supporto ai vari sistemi operativi con cui ho dovuto lavorare nel corso degli anni.

Da Netscape passai a Mozilla, e fui estasiato quando uscì la versione leggera del browser, ovvero Firefox. Anni di Firefox, per poi passare a Safari in quanto leggero e rapido e utilizzavo prevalentemente Mac OS. Non è durato molto, in quanto mi scontrai con dei problemi e preferivo avere un qualcosa che fosse meno legato alla piattaforma stessa (Safari c'è solo per Mac OS, ne esiste una arcaica versione per Windows, che gira anche su Wine, ma è vecchia e non ha mai funzionato a dovere).

Ho dunque scoperto Google Chome, velocissimo e completo. Concettualmente mi piace grazie al fatto che apre un processo per ogni pagina aperta. Consuma più RAM, ma garantisce un isolamento completo che, in caso di malfunzionamenti, permette di isolare e uccidere solo la pagina incriminata. Firefox, al contrario, utilizza un unico processo per tutto, ragion per cui una singola pagina malfunzionante rischia di bloccare tutto. Grazie a Chrome, a suo tempo, ho inoltre scoperto anche un modo elegante di tenere sincronizzate le schede tra computer e dispositivi mobili, e questa era una di quelle funzionalità che cercavo da una vita. Spesso devo spegnere il computer e muovermi, ma sono a metà di una lettura interessante, oppure ho aperto dei tab su uno dei computer e voglio continuare la lettura da un altro: Chrome aveva risolto questo problema, e ne ero felice.

Tra Chrome e Chromium, quindi, sono andato avanti per anni. Con soddisfazione, pur non riuscendo ad avere tutte le funzionalità che avrei voluto e non trovandone tra i componenti installabili.

Nelle ultime settimane, però, ho avvertito il bisogno di rimettermi in moto: alcuni rallentamenti, anche su hardware potente, e un più generico senso di curiosità. Lavorando con OS diversi e su piattaforme diverse (compresi Raspberry PI, Banana Pro, ecc.), non sempre riesco ad avere una versione recente di Chromium. Spesso, addirittura, non ci riesco proprio (NetBSD non sempre si riesce ad avere buona compatibilità). Firefox, invece, è onnipresente.

Memore di un certo senso di lentezza rispetto a Chrome, ho iniziato facendo alcuni test. Non ho utilizzato strumenti particolari, ma il famoso ed efficiente spannometro. Non scientifico, forse, ma soddifacente. E i risultati sono stati sorprendenti: dopo aver importato i preferiti e la cronologia (ottima cosa, mi sono portato dietro tutto!), Firefox si comporta in modo decisamente più efficiente di Chrome, nella release attuale.Per lo meno, in base ai miei test e al mio utilizzo.

Ho dunque iniziato, giorno per giorno, ad usare Firefox. Ho installato delle interessanti estensioni, come Unloadtab e cliget, e sono molto felice della mia scelta. Trovo le schede sincronizzate tra computer e OS, tra mobile e fisso, peccato manchi per Windows Phone.

Insomma, la guerra dei browser (nella mia testa) continua, ed è bello vedere come i vari prodotti migliorino proprio grazie ad una bonaria concorrenza.

Ah, non ho parlato di Internet Explorer. Nulla in contrario, ma non l'ho mai reputato un buon browser. È diventato uno standard solo grazie al fatto che era preinstallato sulla maggior parte dei computer in circolazione, e non ha mai avuto doti particolari per primeggiare, tecnicamente parlando, sugli altri. Vederlo declinare non mi rende felice, ma non mi rattrista di certo.

L'unica cosa che mi strappa sempre un sorriso è la guerra alle numerazioni delle release. Oggi se non hai un numero "grande" non sei nessuno, per cui tutti corrono ad aumentare, ad ogni rilascio anche minimale, la versione in modo vertiginoso. Immagino che tra qualche anno avremo Firefox 1542 e Chrome 1612.

Meglio Debian o Ubuntu su Server?

Stefano Marinelli — Thu, 17 Sep 2015 07:41:42 GMT

Preambolo

Da quando è uscita Ubuntu, ormai più di dieci anni fa, il panorama delle distribuzioni GNU/Linux è cambiato. Ubuntu ha cercato di creare un sistema completo, semplice da installare e usare. Canonical ha stabilito una politica di aggiornamenti chiara e precisa, distinguendo tra rilasci normali e LTS, e un calendario di supporto stabiito prima ancora dell'uscita della versione stessa.

Ho più volte parlato di Ubuntu, e già otto anni fa ne davo un giudizio abbastanza positivo. In questi otto anni, la posizione della distribuzione basata su Debian più famosa al mondo (ahimè, più di Debian stessa) si è consolidata e ha raggiunto una sua importante fetta di mercato. In un mio lamento dello scorso anno ho criticato il passaggio a Unity e nel complesso la strada che le distribuzioni stanno prendendo, sempre meno fedeli al proprio progetto iniziale e sempre più ricche di effetti speciali (market di applicazioni, di contenuti, ecc. Ma non bastavano i cari, vecchi repository?)

Una delle critiche maggiori che ho sempre mosso a Debian è la mancanza di prevedibilità sul supporto a lungo termine. Debian esce "quando è pronta" e da quel momento inizia il conto alla rovescia sugli aggiornamenti di sicurezza della release precedente. Sempre tempi abbondantemente lunghi, ma ci sono server su cui non si può dover aggiornare ogni due anni. Gestisco dei server contenenti siti di e-commerce, ed essi sono stati ottimizzati a puntino sulle specifiche versioni delle piattaforme installate, ad esempio sulla versione di PHP. In questi casi, un aggiornamento potrebbe richiedere un importante lavoro di rifacimento, di risistemazione e di sviluppo moduli e il cliente non è sempre rapido o ben disposto sull'effettuazione delle modifiche. "Ma non possiamo lasciare tutto alla versione attuale? Sembra funzionare bene! Se non facciamo modifiche, perché dovrebbe smettere di andare?", chiedono. E quando rispondo che "No, non si può fare, ci bucherebbero il server in men che non si dica", mi guardano come se stessi cercando di fregarli o di mettere fretta.

Debian Stable vs Ubuntu LTS

Dopo alcuni scambi di opinione¹ con alcuni clienti proprio in merito a queste problematiche, ho iniziato a pensare che avrei avuto bisogno di una distribuzione più prevedibile. Un supporto di cinque anni, ad esempio, sarebbe stato sufficiente per gestire la situazione al meglio. CentOS ha un supporto addirittura più a lungo termine, ma non ho mai avuto particolare simpatia per le distribuzioni rpm-based. Probabilmente sbaglio, ma ho sempre avuto la sensazione che fossero difficilmente aggiornabili. Hanno un supporto a lungo termine, ma aggiornare diventa più complesso. Sono dunque sempre stato più legato alle distribuzioni deb-based, e ho iniziato a valutare le candidate. La scelta è stata quasi automatica: Ubuntu LTS.

Vantaggi rispetto a Debian (al momento della scelta):

Aggiornamenti di sicurezza automatici. Non sono mai stato un fan degli aggiornamenti automatici, ma a volte è necessario, specialmente quando si tratta di aggiornamenti di sicurezza. Se si hanno in giro centinaia di server attivi e in produzione, non si riesce ad aggiornarli tutti prima che qualcuno tenti di sfruttare la falla appena pubblicata. Gestibile anche su Debian con gli unattended-upgrades, ma test fatti allora non davano buoni risultati.
Supporto a lungo termine, dunque un tempo di vita prevedibile e concreto, senza sorprese.
Moderno, generalmente Kernel e versioni delle applicazioni principali sono più recenti di quelle inserite nella Debian Stable
Ottimizzato, a parità di installazione, Ubuntu sembrava decisamente più performante, grazie anche alle configurazioni di base diverse specifiche per le poche architetture supportate
Miglior supporto per lxc

Ho dunque installato e messo in produzione moltissimi Ubuntu 12.04 LTS e, più recentemente 14.04 LTS su server. I risultati sono sempre stati buoni, nessun problema particolare e nessuna sorpresa negativa. A distanza di qualche anno, posso dunque dire che Ubuntu LTS su Server si comporta egregiamente, e lo consiglierei senza particolari esitazioni

MA...

Ad un certo punto, Debian ha annunciato un esperimento di supporto LTS per Squeeze. E ingranato la marcia. Wheezy e Jessie sono moderne, rispetto agli standard medi di release Debian, e decisamente tornate ai vecchi fasti. Supportano alcune delle belle funzioni introdotte da Ubuntu, e allo stesso tempo restano fedeli alla filosofia Debian originale.

Uno dei principali vantaggi di Debian rispetto ad Ubuntu LTS è il fatto che è, appunto, una distribuzione che tende a restare ferma, a meno di aggiornamenti di sicurezza. Un server richiede questo: stabilità e prevedibilità.

Ubuntu LTS, infatti, aggiorna spesso. TROPPO spesso. Ogni paio di giorni ci sono aggiornamenti da fare, non necessariamente di sicurezza. E questo, su server, non è il massimo. I Virtualmin che ho su Debian non mi scrivono mai nulla, mentre gli Ubuntu LTS si fanno vivi ogni paio di giorni: nel primo caso, installano da soli gli aggiornamenti di sicurezza e amen, nel secondo caso, invece, ogni giorno vengo allertato che ci sono degli aggiornamenti (non importanti) da fare. Il kernel, poi, è il più gettonato: mi basta non entrare in ssh per qualche giorno sulle Ubuntu che, al login successivo, appare il messaggio "È necessario riavviare per applicare gli aggiornamenti di sicurezza". Peggio di Windows, insomma :-)

Gli uptime che ho su Debian non li ho mai raggiunti su Ubuntu, principalmente per la ragione appena esposta. Confido in kpatch, perché non sempre è possibile riavviare senza problemi un server. Non per problemi di boot, ma di tempo di riavvio che, in alcuni casi, diventa estremamente alto e problematico.

Ad oggi, dunque, ho ricominciato ad installare server Debian al posto di Ubuntu LTS.

Conclusioni

Dopo 19 anni di Debian (eh, si, ho in giro roba con Debian dentro dal lontano 1996!) e 11 anni di Ubuntu, posso dire che, alla luce della mia esperienza, non c'è un vincitore e un perdente, ma sono entrambe delle ottime scelte, dettate più dalla preferenza personale che da vere e proprie motivazioni tecniche.

Personalmente, sto tornando ad installare Debian. Il supporto LTS aiuta negli aggiornamenti, e il minor numero di aggiornamenti inutili ne semplifica anche la gestione quotidiana.

Chi lavora nel settore, sa bene che gli scambi di opinione con i clienti sono spesso molto più simpatici di quanto si possa pensare. Il cliente crede di capire tutto, perché ormai il web è solo una questione di click, l'informatico è sempre quello che cerca di fregare complicando le cose semplici, e la rete è pericolosa perché non abbiamo comprato "l'ultimo prodotto di sicurezza informatica" ↩

Da Pelican a Nikola

Stefano Marinelli — Wed, 09 Sep 2015 09:18:41 GMT

Dopo tutto il bene che ho detto di Pelican, credo che qualcuno rimarrà sorpreso nel leggere un articolo del genere, così come sarà rimasto sorpreso chi ha visto cambiare motore del Blog, di nuovo e dopo pochi giorni. La domanda che potrebbe sorgere spontanea è: perché?

La mia risposta: perché si può, perché si vuole, perché si deve provare tutto. E, visti i risultati, ho deciso di tenere Nikola come motore di generazione del blog.

La scelta di Nikola come compilatore (mi piace pensarlo così) è dettata non da problemi con Pelican, ma da alcuni vantaggi che Nikola stesso mi ha mostrato.

Farò dunque un rapido e non esaustivo elenco delle ragioni che mi hanno spinto a usare Nikola:

Entrambi sono in Python - pari
Entrambi installabili via pip in un virtualenv - pari, anche se Pelican ha molte meno dipendenze
Pelican ricalcola ogni volta tutto, ricreando tutti i file. Ci sono delle opzioni di caching, ma non mi hanno dato risultati entusiasmanti. Nikola, al contrario, ricostruisce solo ciò che è stato modificato e le relative dipendenze, in maniera molto rapida. Essendo un generatore statico, anche se c'è da aspettare un minuto in più quella volta che viene fatta una modifica non è che sia la fine del mondo, ma le ottimizzazioni ci stanno sempre bene - Nikola
Pelican genera solo i file .html. Per sitemap e le versioni in gzip degli articoli (utile per minimizzare i tempi di trasferimento), c'è da installare qualche plugin. Non che sia un problema, ma è bello trovare tutto pronto e coerente. Inoltre è potenzialmente meno pericoloso in fase di aggiornamento. - Nikola
Nikola supporta Pandoc e moltissimi formati di input. Io utilizzo, al momento, il Markdown, ma non escludo di imparare altro. - Nikola
L'importazione da WordPress è più completa. Per importare da Pelican, infatti, ho utilizzato il dump che avevo effettuato e reinserito i nuovi articoli. Pur interpretando entrambi il Markdown, hanno un formato leggermente diverso. Mi è piaciuto il fatto che è andato a pescarsi le immagini dal sito originale e se le è copiate internamente. Ho dovuto comunque provvedere a fare alcune modifiche. - Nikola
Nikola supporta internamente le redirezioni, per cui mi ha creato autonomamente una mappa dal vecchio formato WordPress al nuovo. Gli articoli sono dunque automaticamente ancora raggiungibili senza fare alcuna modifica nel file .htaccess - Nikola
Supporta nativamente i pretty urls, ovvero la rimozione del .html dall'URL stesso. In teoria, a livello SEO, non dovrebbe fare alcuna differenza, e su Pelican è fattibile tramite .htaccess, ma è bello trovare tutto fatto in automatismo. In pratica, Nikola crea delle directory col nome (slug) dell'articolo e ci infila dentro un index.html. I browser, quindi, caricheranno automaticamente l'index quando verrà richiesta la directory. - Nikola
Sembra produrre, di base, un sito più SEO-friendly. - Nikola
La simpatia dello sviluppatore. Sarà per la sua radice latina, si ha sempre la percezione di leggere qualcosa scritta da una persona solare e simpatica. - Nikola

Ho dunque deciso di mettere online il sito prodotto da Nikola, addirittura col tema grafico di base (non mi dispiace).

Se continuerei a consigliare Pelican? Decisamente sì, non vedo ragioni per cui non debba essere utilizzato. Suggerisco quindi di provarli entrambi.