Premessa

Ebbene sì, torno a scrivere sul blog dopo molto tempo. Ci sono vari articoli iniziati e mai terminati, non ho più il tempo che avevo una volta di aggiornare molto spesso. Cercherò di rimediare. Non sono mai stato esageratamente costante nel seguire i siti, per cui chi mi conosce non resterà certamente meravigliato.

Sin dal lontano 2006 (più di nove anni fa...), ho iniziato ad usare Wordpress per il mio blog e, di conseguenza, per altri siti. Dopo una breve parentesi di Joomla, prevalentemente utilizzato per alcuni siti realizzati per dei clienti (non questo blog), sono tornato a Wordpress proprio perché la sua aggiornabilità e la sua espandibilità mi avevano sempre soddisfatto. Il blog è rimasto su Wordpress, appunto, per più di nove anni.

Fino a quando...

non è arrivata la Cookie Law (ne parlerò in uno dei prossimi articoli). Ho dovuto, rapidamente, fare una scansione di tutti i miei CMS per capire cosa andava disattivato e cosa sarebbe potuto restare. Ho scoperto - si fa per dire - che buona parte dei miei amati plugin di Wordpress avrebbero avuto bisogno di una bella informativa. Non ne ho mai installati troppi, ma quei pochi erano già sufficienti a causare potenziali problemi.

Ho disattivato ciò che ho potuto, mantenendo tutti i contenuti, le cache, ecc. mentre ho disattivato tutti i vari pulsanti sociali (davano dei numeri, quindi contattavano i social network in oggetto per avere le informazioni), il Jetpack con relative statistiche, e altre piccole cose meno importanti.

A quel punto mi sono posto una domanda: ma ho davvero bisogno di un CMS completo, mastodontico, con tanto di database MySQL, per gestire un blog e qualche commento?. Premesso che non ho interesse a mandare pubblicità, tantomeno a tracciare i visitatori, che alcuni dei miei plugin preferiti sono stati resi (quasi) inutilizzabili dalla legge di cui sopra, perché devo far eseguire un plugin che faccia cache html degli elaborati PHP quando basterebbero, effettivamente, dei buoni HTML? Non da trascurare, inoltre, che quasi ogni giorno escono patch di sicurezza di WordPress (o di suoi plugin), spesso vengono fuori vulnerabilità di PHP (che non ho mai amato, per me è la maggior fortuna e allo stesso tempo rovina del Web), e che MySQL è comunque "sprecato" per contenere qualche centinaio di articoli testuali.

La risposta che mi sono dato è stata: e poi, come li gestisci tutti quegli HTML statici?. Ho fatto una rapida ricerca e ho scoperto un mondo a me allora ignoto: quello dei generatori di siti statici.

Generatori di siti statici

I generatori di siti statici...generano siti statici! :-)

Scherzi a parte, sono degli strumenti che si occupano di prendere dei file di testo (o anche in Markdown, html puro, ecc.), elaborarli, inserire il tema, creare gli indici, ecc. Insomma, fanno tutto ciò che farebbe un CMS, ma lo fanno una volta e generano dei normalissimi HTML statici. Leggeri, pratici, portabili. Nessuna necessità di database, nessun bisogno di alcuno strumento sul server in cui il sito verrà pubblicato, il risultato dell'elaborazione di questi generatori sarà una directory popolata di file html, pronta per essere caricata in qualunque server, anche embedded (i primi test li ho fatti su Raspberry PI. Si possono generare i file sul proprio computer e caricare la directory contenente i file html, onde non dover tenere nulla sul server. I siti così generati possono essere messi in hosting praticamente ovunque, compresi github, Amazon S3, ecc.

Ho iniziato a guardarmi intorno. Ce ne sono moltissimi, molti sono dei fork del "capostipite" Jekyll, che ho provato e ritenuto ottimo. Ho però, già da qualche anno, un interesse verso il Python, di conseguenza mi sono orientato verso una risorsa scritta in questo linguaggio. Pelican è stata la mia scelta, e dopo qualche giorno di studio, sono riuscito ad iniziare a creare qualcosa di decente. Veloce, pulito, semplice. Non avrei potuto chiedere di meglio. L'alternativa, meno versatile e decisamente più limitata, sarebbe stata BashBlog, che non ha dipendenze a parte bash, appunto.

Importazione di un sito WordPress su Pelican

Fortunatamente, Pelican comprende anche un programma che si occupa di importare (quasi) del tutto autonomamente i precedenti contenuti di WordPress. Ho effettuato una esportazione e una importazione, con il risultato che buona parte degli articoli sono andati correttamente al loro posto e ben collegati. Categorie e tag compresi.

Ho però avuto due problemi, non banali:

* L'importazione dei commenti
* La conversione di due generazioni di URL verso una terza, nuova generazione

L'importazione dei comenti

Per quanto concerne il primo punto, avevo tre scelte. Buttare via i vecchi commenti, importarli in Disqus oppure provare ad importare e implementare in ISSO.

Le prime due opzioni avrebbero permesso l'approccio senza alcun componente dinamico, mantenendo l'idea di avere un server completamente statico. Però mi sarebbe dispiaciuto perdere i vecchi commenti, c'è della roba carina e ormai storicamente interessante, vista l'epoca in cui sono stati scritti. L'approccio esterno non mi entusiasmava. Non mi piace dipendere da aziende che potrebbero cessare il servizio, renderli a pagamento, cambiare le condizioni. Ho dunque deciso di gestire la cosa con ISSO, anche se ho dovuto fare qualche manovra per far riconoscere i vecchi commenti con i nuovi URL. Nessun problema, il database interno è Sqlite3, per cui è stato un gioco da ragazzi.

La conversione degli URL

Più complessa e meno banale è stata l'operazione di conversione degli URL. Il blog è spesso finito su siti di informazione generalista, su link di altri blog, su forum, tanto che vedo ancor oggi arrivare collegamenti da risorse che non sapevo neanche che ci fossero, considerata anche l'età media di molti di questi articoli.

I generatori statici creano file .html, quindi l'url sarà:

http://www.dragas.net/articolo.html

I miei articoli precedenti, invece, avevano una struttura di questo tipo, tra l'altro indicizzata da Google:

http://www.dragas.net/articolo/

I problema, appunto, è che i vecchi link arrivavano con i vecchissimi URL:

http://www.dragas.net/?p=11

e il caro WordPress, tramite un plugin, era in grado di redirezionare verso i permalink corretti. Ho dovuto quindi lavorare di .htaccess (il server su cui è al momento ospitato il Blog gira su Apache) e creare una serie di redirezioni manuali, sia per togliere lo slash finale e aggiungere .html, sia per fare un reindirizzamento corretto con i "?p=".

Il risultato finale sembra essere, almeno al momento, positivo. Il Blog è quasi completamente raggiungibile coi vecchi URL, i commenti sono al loro posto e correttamente legati ai singoli articoli, probabilmente è cosmeticamente meno affascinante (pur non avendo mai stupito con effetti speciali), ma decisamente più prestante e non devo più preoccuparmi degli aggiornamenti di sicurezza di Wordpress (che comunque avvenivano automaticamente) o di plugin non mantenuti o mal programmati che potrebbero diventare dei punti d'accesso discretamente pericolosi.

Considerazioni Finali

Dopo 9 anni di WordPress, posso ritenermi decisamente soddisfatto: personalmente non ho mai avuto un problema, mai un server bucato per colpa di WordPress (a differenza di Joomla, Magento, ecc.), ma non mi dispiace l'idea di avere un sito statico. Mi piace scrivere in Markdown, il fatto di non aver necessità di un Database, facilità di backup anche dei commenti, leggerezza generale dell'infrastruttura. Continuerò a suggerire WordPress a chi non è in grado di gestire una infrastruttura come quella di Pelican (semplicissima, ma di certo un attimo più complessa del classico editor WYSIWYG stile TinyMCE) o a chi ha esigenze particolari, diverse dalla semplice scrittura di un normale blog (es: autori multipli, ecc).

Finalmente posso tornare a concentrarmi sul testo e non sulla piattaforma. Tra ricerca di plugin, aggiornamenti, migrazioni, predisposizione di backup del database, cambiamento di temi, ecc, probabilmente ho speso molto più tempo sulla piattaforma che sulla scrittura di articoli. Ora, invece, posso usare il mio adorato vim, ovunque io sia, senza particolari problemi. La mia filosofia Informatica è sempre stata fedele alla teoria del rasoio di Occam: la soluzione più semplice, se sufficiente, è sempre la migliore.

Dopo avere usato ZFS per molto tempo e aver capito che senza l'hardware adeguato i difetti superano i pregi, ho deciso di guardarmi intorno. Leggo di BTRFS da anni, ormai. L'unica cosa che tutti dicono è che "non è ancora pronto per essere considerato stabile, ma è strabiliante". Ho dunque provato a formattare la memoria USB di uno dei miei Raspberry PI in BTRFS, decidendo di lasciar perdere a causa della lentezza.

Il mio server Atom casalingo (4GB di Ram, 3 dischi da 1 TB, di cui uno che funge da Time Capsule, ecc.), invece, potrebbe essere un ottimo banco di prova.

Il server ha questa struttura:

• sistema operativo: Ubuntu 12.04 server, installato su una memoria USB da 4 GB, con alcune modifiche per girare in sola lettura (onde evitare riempimento o usura della memoria USB stessa)
• Script vari di controllo dischi (ereditati dall'epoca in cui usavo l'Alix o il Dockstar): controllando la presenza dei dischi rotanti o del disco esterno, lanciano degli script su di essi per abilitare i servizi necessari o lanciare container)
• Se e' presente il disco USB3 da 1 TB, lancia il netatalk e si annuncia sulla rete onde fingersi una veloce e comoda Time Machine, che permette ai miei Mac di effettuare backup criptati e automatici (Powernap, grande cosa...lo vorrei anche su macchine GNU/Linux!)
• Se sono presenti i due dischi replicati, lancia i vari servizi di condivisione e alcuni container lxc. Attraverso lxc ho separato quasi tutti i servizi, dal Munin che crea grafici sulla temperatura della casa (uno dei prossimi articoli sarà proprio su come ho creato un efficiente sistema di controllo climatico della casa attraverso un Raspberry PI), un Nagios che tiene d'occhio tutte le apparecchiature (alcune di quelle connesse via Powerline tendono a "sparire", ogni tanto. Indagini in corso...) e ad attivare e disattivare servizi ed elettrodomestici sulla base della mia presenza o meno in casa, nonché un container ZoneMinder per la videosorveglianza di casa, ingresso e dei garage, un container per il server Plex e la gestione dei miei file multimediali...e così via

Circa un anno fa, quindi, ho deciso di convertire i vari dischi a BTRFS, grazie anche alla semplice procedura ext4-to-btrfs.

Il risultato? Eccellente, sotto tanti punti di vista. Il file system è stabile, la compressione ha migliorato (e non di poco) la velocità di lettura e la deduplicazione ha permesso un recupero di parecchi GB di spazio, specialmente considerando che ogni notte effettuo backup di vari server esterni con molti file comuni (sto valutando l'applicazione, anche in locale, di StoreBackup, che mi ha dato ottimi risultati se usato esternamente).

Due dei tre dischi sono stati configurati in replicazione. Di fatto, niente raid "classico". Replicazione e compressione lzo al volo. Punto. Posso incrementare, decrementare, aggiungere, rimuovere, sostituire dischi senza alcun problema. Anche al volo.

E' stato però necessario tener conto di alcuni dettagli non secondari:

• BTRFS lavora in COW: alcuni file grandi e costantemente mutevoli (file immagine di VM in esecuzione, file dei DB di MySQL di ZoneMinder, ecc.) si comportano molto male in questo modo. Ho preferito disabilitare il COW sulle directory in oggetto. Si perdono alcune possibilità, nonché la compressione, ma il gioco vale la candela, altrimenti lentezza e frammentazione diventano insostenibili.
• Meglio lavorare con Kernel e btrfs-progs recenti: ho installato l'ultimo (al momento) Linux 3.18 rc. Ad ogni nuova release, vedo il sistema migliorare.
• BTRFS è ancora un file system non del tutto stabile. Pur non avendo avuto seri problemi, è bene ricordare che non c'è ancora quel livello di affidabilità a cui ci hanno abituato i file system maggiormente diffusi nell'ambiente GNU/Linux

Mi sentirei dunque di consigliare BTRFS al grande pubblico? Dipende. Nel mio caso, mi trovo molto bene nell'usarlo in alcuni specifici frangenti ma non mi sognerei neanche di metterlo in produzione su server importanti. Non prima di averne davvero valutato tutti i pregi e difetti.

Buona sperimentazione a tutti!

A CHI SI RIVOLGE: Ai direttori degli enti e gli amministratori pubblici e privati. Ai responsabili dei sistemi informativi e ai responsabili degli acquisti informatici (hardware e software). Ai responsabili dei servizi (in particolare Comunicazione, Urp, Servizi anagrafici, Suap) di EE.LL. e aziende gestrici di pubblici servizi.

PROGRAMMA:  giornata del 4.2.2014 - Introduzione, identificazione del concetto di “sicurezza informatica”, le attuali normative sulla sicurezza informatica, le differenti tipologie di sistema informatico (esposizione locale, su Intranet, su Internet), principali rischi per l’amministratore e per il responsabile, principali problematiche di sicurezza, tecniche di difesa. La protezione dell’integrità dei dati, della privacy, degli archivi. Analisi dei più comuni punti deboli dei sistemi informativi. Pericoli derivanti da bug, da malconfigurazioni, da comportamenti sbagliati di utenti e amministratori. Definizione di Firewall, di Trojan, di Phishing. La protezione dei dati come principale scopo del sistema informativo. Il concetto di backup, pratiche di stoccaggio, le principali normative sul backup. Il disaster recovery, metodi per prevenire situazioni di irrecuperabilità, studio di pianificazione delle principali tecniche di messa in sicurezza dei dati. Dimostrazioni pratiche. Quesiti dei partecipanti.

PROGRAMMA:  giornata del 5.2.2014 Introduzione approfondita al "Cloud" (cosa si intende per cloud, come ci si è arrivati, ecc.), comparazione tra approccio server tradizionale e "cloud" (sia locale che esterno), comparazione tra sicurezza nel cloud e nei server tradizionali (sicurezza dei dati, privacy, ecc.), criteri di scelta di sistemi cloud rispetto ai sistemi tradizionali, il Cloud come sistema dinamico rispetto al "monolitico" tradizionale, eventuali nuove problematiche. Analisi generale dei principali Cloud attualmente in circolazione, introduzione agli studi attuali per capire che direzione prenderà il "Cloud". Dimostrazioni pratiche. Quesiti dei partecipanti.

QUOTA D’ISCRIZIONE a giornata e per persona (dà diritto a partecipare al corso, a ricevere il materiale didattico e al coffee-break delle 11.30 circa). (oltre IVA 22 per cento. IVA esente per le pubbliche amministrazioni ex art. 14,  L. n. 537/1993). Se IVA ESENTE oppure  se viene richiesto dall’ente BOLLO DI EURO 2,00 SULLA FATTURA (importo totale maggiorato di euro 2,00 a carico dell’ente): euro 180 per pagamenti in contanti o assegni non trasferibili direttamente il giorno stesso; euro 220 in tutti gli altri casi.  SCONTO: 10 per cento dalla seconda persona. PER ISCRIZIONE ALLE DUE GIORNATE: euro 300 per pagamenti in contanti o assegni non trasferibili direttamente il giorno stesso; euro 350 in tutti gli altri casi.

PER ISCRIVERSI: inviare il modulo d’iscrizione a 3F FORMER srl. fax 0516504570 (modulo scaricabile anche dal sito www.3f-former.it  oppure previo accordi anche per e-mail).

ATTESTATO DI PARTECIPAZIONE E FATTURA VENGONO CONSEGNATI IL GIORNO DEL CORSO

DOCENTE: dott. STEFANO MARINELLI, Esperto e consulente in materia di imprese pubbliche e private, titolare della DragasIT, azienda specializzata in soluzioni informatiche e hosting.

ISCRIZIONE (impegnativa per l’Ente): per fax (0516504570), e-mail o PEC 3f-former@pec.it: Specificare il numero degli iscritti e la modalità di pagamento prescelta. Le iscrizioni possono essere effettuate dopo la scadenza solo nei limiti dei posti disponibili. Le rinunce d’iscrizione, dovute a qualsiasi causa, anche di forza maggiore, devono essere effettuate esclusivamente per fax entro la data di scadenza delle iscrizioni e non verranno accettate se perverranno successivamente alla predetta scadenza e la quota dovrà essere comunque versata per intero, senza compensazione o recupero. L’iscritto avrà comunque diritto a ricevere il materiale didattico distribuito. E’ comunque possibile sostituire l’iscritto anche il giorno stesso del corso. Le iscrizioni possono essere effettuate anche telefonicamente e perfezionate successivamente entro la scadenza mediante invio dell’iscrizione. Verrà data comunicazione dell’effettivo svolgimento del corso al fax indicato nella scheda d’iscrizione. Nell’interesse dell’iscritto si consiglia di informarsi preventivamente della disponibilità dei posti e dell’effettivo svolgimento del corso (tel. 051731984, 3391307697 3384621905). Ringrazio per l’attenzione e saluto cordialmente.

3F FORMER s.r.l.- Dott.ssa Franca Berti cell. 3391307697

Di tanto in tanto, guardo alcune statistiche e mi rendo conto che la gente, su Internet, cerca di tutto. Ma come finisce sul mio sito? Ho già dato un'occhiata, nel 2009, alle keyword principali, alcune cose sono cambiate. Non troppe, a giudicare dalle domande, il che mi lascia pensare che ci sono delle cose che non cambiano mai. Ma analizziamo i dati principali:

stefano marinelli - eccomi, sono io. Presente! Beh ,non mi meraviglia che si finisca sul mio sito cercando il mio nome. Sarebbe grave il contrario, anche se certi consulenti SEO non riescono nell'intento (vedi articolo di qualche giorno fa)

che cosa è il voip - domanda sempre attuale. Ne ho parlato qui, qualche anno fa, e le cose non sono (troppo) cambiate. Se per fortuna o purtroppo, giudicatelo voi

perche si scrive tutto su facebook? - Nel 2009 dicevo "scriveteci quello che vi pare". Oggi sono decisamente di opinione diversa. Ne scriverò in merito appena avrò un po' di tempo.

i router sono tutti uguali - Assolutamente no.

per i blackberry occorre un contratto particolare? - sì, dovendo usufruire dei servizi della BlackBerry Limited per collegarsi ad Internet

blackberry i piu affidabile - mmm no, considerando anche che spesso si sente di paralisi completa di tutti i servizi. Ricordo che per usufruire della connessione, il BlackBerry deve connettersi ai suoi server. Se essi vanno giù, si ferma tutto.

cm e il tel black berry - tempo fa avrei detto "notevole", oggi direi "superato". Se non si svegliano, vanno a picco. Purtroppo, aggiungerei.

invenzioni degli anni 80 - gli anni '80 hanno posto le basi delle tecnologie odierne. ho parlato di varie invenzioni, alcune sono apparse in special modo negli anni '80

i modem sono tutti uguali - ancora...noooo! :)

cellulare invenzione - ne ho parlato tempo fa

la nascita della seo - ne ho parlato di recente

blackberry o android - oggi? Android, senza dubbio.

gps come funziona - ho parlato sia del GPS che dei navigatori satellitari. Grazie a questo articolo mi hanno addirittura intervistato in TV.

Chi mi conosce, sa anche che sono un fautore di GNU/Linux e lo sono stato sin dalle mie prime esperienze con esso, ovvero dal 1996. All'inizio era un po' ostico, ma pian piano ci ho preso mano e ho iniziato a farci praticamente tutto. Sono praticamente Windows-free dal 1998, e ne sono fiero, visto che ogni approccio di avvicinamento ai prodotti Microsoft mi ha sempre causato problemi (X-Box 360 esclusa).

Qualcosa, però, negli ultimi anni è cominciato a cambiare. La forte spinta commerciale di aziende (come Oracle, Sun, IBM, ecc.) ha creato una situazione in cui lo sviluppo del kernel (e di molte distribuzioni) fosse guidato non più da mere ragioni tecnico/pratiche ma da ragioni quasi sempre commerciali. Alcune funzionalità sono state abbandonate per permettere lo sviluppo a tempo pieno di altre soluzioni. Intendiamoci, chi paga per sviluppare Open Source decide cosa e quando svilupparlo, ma il punto è che non sempre questo significhi un miglioramento dell'esperienza utente. Anzi, a volte certe aziende sembrano voler "dirottare" l'Open Source verso le loro soluzioni per vendere consulenza. Più che lecito, ma non sono sempre sicuro che questa poi sia la miglior soluzione per gli utenti finali.

Colossi come Red Hat, poi, hanno creato una sorta di sudditanza inconscia di tutto il team di sviluppo. Si pensi a KVM e alla sua scelta di inclusione come  sistema di virtualizzazione "ufficiale" all'interno del kernel. E' stata una scelta dettata da Red Hat, la quale ha sempre voluto avere un forte controllo sul prodotto e screditato tutto ciò che non fosse sviluppato da loro stessi proprio per far spazio alle proprie tecnologie. KVM è stato, almeno inizialmente, nettamente inferiore a XEN, specialmente ai tempi in cui la scelta è stata "inspiegabilmente" deviata verso il primo prodotto. Perché? La risposta è semplice: anche nello sviluppo di GNU/Linux, ormai ciò che conta non è più quello che viene fatto e come ma QUANTO ciò possa rendere alle aziende che ci investono sopra.

Intendiamoci, ciò è naturale e non criticabile. D'altronde molti rispondono che GNU/Linux è un sistema aperto, e come tale chiunque può partecipare o fare il suo fork. Ma guardiamo in faccia la realtà: se non sei nessuno e non segui le linee guida prestabilite, non vieni minimamente considerato. Il bazaar è in realtà ormai una Cattedrale con dentro tante belle bancarelle. Il visitatore crede di essere libero, ma di fatto lo è solo in parte. La libertà c'è, ma nei limiti di quello che fa comodo ai colossi del settore.

E chi si metterebbe a fare un fork di un progetto come Linux? Chi se ne accolla  i backport, i bugfix, ecc? Troppo codice, sarebbe un'operazione decisamente fuori da quello che è realizzabile da un singolo o da una azienda a capitale limitato.

Oggi, più che dieci anni fa, si è molto dipendenti dalle distribuzioni, avendo esse preso strade molto diverse tra di loro. Ultimamente ho avuto grattacapi negli aggiornamenti di Debian (da stable a stable, sia chiaro), con pacchetti lasciati non funzionanti. Oppure bug non sistemati anche se noti (es: Debian 6.0 aveva noie e il kernel Xen dom0 non partiva di default perché Grub continuava a piazzarlo dopo quello normale. Mai risolto, bisognava sistemare a mano).

A livello di Workstation, sono stati fatti grossi passi avanti sulla compatibilità hardware, eppure quello a cui non riesco ad abituarmi è il problema degli aggiornamenti. Se voglio avere un computer ragionevolmente stabile ma aggiornato, devo usare una distribuzione aggiornabile e che non "rompa" qualcosa ogni 6 mesi o ad ogni aggiornamento importante. Io con il computer ci lavoro, non posso correre rischi. E ho bisogno di strumenti aggiornati. Ubuntu è passata a Unity e di colpo tutto è cambiato completamente (ok, è installabile anche un'altra interfaccia, ma...). Mint, che mi piace, ha due versioni: una Rolling (che non è aggiornata in molti pacchetti, derivando da Debian Testing, e non voglio mettermi a tirare dentro mille repository esterni) e una che effettua release ogni tot mesi ma che non ha un metodo "ufficiale" di aggiornamento. Alias in teoria sarebbe opportuno cancellare e reinstallare tutto. E ho fatto solo alcuni esempi. Una alternativa sarebbe installare Ubuntu 12.04 LTS, che ultimamente ho iniziato ad usare felicemente su alcuni nuovi server, al posto di Debian. Ha la possibilità di mettere dentro kernel recenti e sarà supportata fino al 2017, aggiornando comunque i pacchetti principali (browser, ecc.) fino a tale data.

Continuo ad apprezzare GNU/Linux e le varie distribuzioni, e le utilizzo e utilizzerò con piacere sui miei server e su alcune Workstation, insieme ai vari *BSD. Però nessuno si meravigli se, per la produttività quotidiana, utilizzo un MacBook PRO (del 2009 fino a un mese fa, un nuovo Retina ora). Acquistato nel 2009 con Leopard (MacOS 10.5), backup effettuati con Time Machine in rete (su una Time Capsule simulata da un server locale GNU/Linux  e netatalk) e da cui ho recuperato spesso dati. Aggiornamenti fino all'ultimo MacOS (10.9.1) effettuati senza alcun problema o rottura di compatibilità, e passaggio dal vecchio al nuovo Mac in maniera indolore, sfruttando il backup di rete che avevo. In un'ora avevo un Mac nuovo con dentro tutto il necessario per riprendere il lavoro.

Neanche MacOS ha preso una bella piega (la iOS-izzazione di OS X non mi piace per niente), e molti potrebbero dire che Apple è peggio di Microsoft (forse è così...), però ho uno strumento di lavoro affidabile, rapido e funzionale.

Che poi è ciò che interessa a buona parte dell'utenza che col computer ci lavora.