Zuk Z1 in arrivo

Zuk Z1

Dopo alcuni mesi di Windows Phone, di cui parlerò di nuovo prossimamente, ho appena ordinato uno Zuk Z1. Per quale motivo? Svariati, ne elencherò solo alcuni:

  • 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.

Attendiamo l'arrivo, ne farò un bel resoconto.

Analisi delle principali piattaforme di Virtualizzazione: VMware, Proxmox, Hyper-V, oVirt - Bologna, 19 Novembre 2015

BOLOGNA, 19 NOVEMBRE 2015, ore 9,30 -15,30 - Hotel Mercure (di fronte alla Stazione FF.SS. Bologna Centrale)

Posti limitati: iscrizioni entro il 12 novembre 2015 in ordine di arrivo:

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.

OBIETTIVI: Il mondo della Virtualizzazione, sia in ambito server che desktop, è cresciuto e riveste un'importanza sempre maggiore. Grandi novità e nuovi contendenti si presentano di anno in anno. Moltissime sono le soluzioni disponibili, ma le principali possono essere elencate sulle dita di una mano. Il corso prende in esame i principali prodotti, mettendone in luce pregi e difetti, e fornisce strumenti di analisi per identificare meglio la corrispondenza degli stessi alle proprie esigenze.

PROGRAMMA CORSO: Introduzione, identificazione del concetto di “Virtualizzazione”, analisi delle principali componenti dei virtualizzatori e dei sistemi operativi virtualizzati. Introduzione a VMware, Proxmox, Hyper-V, oVirt, analisi dei prodotti e delle principali caratteristiche. Comparazione tra alcune delle funzionalità e degli stessi, delle prestazioni e delle procedure. Gestione dello storage (locale, via SAN, georeplicato, distribuito), gestione dei backup, procedure di disaster recovery. La conversione tra i sistemi e compatibilità. Presentazione di alcuni casi di conversione. Cenni su altri Virtualizzatori. Dimostrazioni pratiche. Quesiti dei partecipanti.

QUOTA D’ISCRIZIONE a giornata e a persona (oltre IVA 22 per cento e se IVA esente per le pubbliche amministrazioni ex art. 14, L. n. 537/1993, oltre BOLLO DI EURO 2,00 SULLA FATTURA; dà diritto a partecipare al corso, a ricevere il materiale didattico e al coffee-break delle 11.30 circa): euro 180,00 per pagamenti in contanti o assegni non trasferibili direttamente alla segreteria del corso il giorno stesso; euro 200 se con modalità diverse. SCADENZA ISCRIZIONI: entro il 12.11.2015 e dopo solo nel limite di eventuali posti disponibili. Inviare il modulo d’iscrizione a 3F FORMER srl. fax 0516504570 o pec 3f-former@pec.it o 3f@3f-former.it (modulo scaricabile anche dal sito www.3f-former.it) Fatti salvi i casi derivanti dagli obblighi di fatturazione elettronica, VENGONO CONSEGNATI IL GIORNO DEL CORSO AL PARTECIPANTE L’ATTESTATO DI PARTECIPAZIONE E LA FATTURA. NO CIG perché trattasi di quota di partecipazione e no di appalto.

DOCENTE: Dott. Stefano Marinelli, Esperto e consulente in materia di imprese pubbliche e private, titolare della Dragas IT, azienda specializzata in soluzioni informatiche avanzate e hosting

ISCRIZIONI (impegnativa per l’Ente) ENTRO IL GIORNO 12.11.2015. Specificare il numero degli iscritti e la modalità di pagamento prescelta. Le iscrizioni possono essere effettuate dopo la scadenza nei limiti dei posti disponibili. Le iscrizioni possono essere effettuate anche telefonicamente e perfezionate successivamente entro la scadenza mediante invio modulo di iscrizione (se ritenuto opportuno, potrà essere utilizzato il modulo seguente). Verrà data comunicazione dell’effettivo svolgimento del corso al fax/email indicati nella scheda d’iscrizione, ma l’iscritto è tenuto a informarsi della disponibilità dei posti e dell’effettivo svolgimento del corso (tel. 051731984, 3391307697 3384621905 3738353525). Le rinunce d’iscrizione, dovute a qualsiasi causa, anche di forza maggiore, devono essere effettuate esclusivamente per fax o pec precedute da telefonata, 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. Il corso potrà essere annullato o rinviato in qualsiasi momento. Il pagamento se avvenuto verrà restituito, salvo diversi accordi. Ringrazio per l’attenzione e saluto cordialmente.

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

La Guerra dei Browser Continua

Guerra dei Browser 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.

Odio PHP. Punto.

PHP

Lo ammetto: non ho mai amato PHP. Anche recentemente ho spiegato perché ho preferito rendere il blog statico, evitando ulteriori "complicazioni" proprio col PHP. È sui server, funziona, ma se posso evito. L'ho utilizzato in molte occasioni, lo utilizzo in molte occasioni, scrivo anche qualcosina in questo linguaggio che, però, continua a restarmi sullo stomaco.

La ragione è semplice: secondo me è pericoloso per natura. Tra mille sforzi e con impegno, stanno tentando di renderlo migliore ma gli effetti, per ora, non sono eccelsi come si vorrebbe. Il problema è che PHP è nato come un piccolo linguaggio per fare piccole cose. Si è poi espanso in quanto semplice da impiegare (basta un web server con un interprete), meno semplice da apprendere come si deve, e induce, per natura, ad errori madornali di programmazione in quanto consente (o, a volte, richiede) di fare delle cose in un modo formalmente non propriamente corretto.

PHP ha permesso a molte persone di mettersi a fare programmazione web, pur non avendone le basi. E non le ha guidate verso una giusta direzione (le persone, pur senza basi, possono imparare e diventare brave) ma spinge a fare le cose in un modo insicuro. Il programmatore, a volte, deve risolvere dei problemi legati alle carenze del linguaggio stesso.

Alla gente PHP è piaciuto. Un commento su PHP che ho letto di recente diceva una cosa del tipo "people like php because php is cheap, and people like cheap things". Ecco, il punto è proprio questo: PHP è a buon mercato, non inteso come prezzo d'acquisto ma come prezzo da pagare per impararlo e utilizzarlo. Non è come il C, o come il Java. Purtroppo, allo stesso tempo, non è pulito come il Perl o il mio amato Python (recente passione). PHP fornisce tutti gli strumenti per fare qualunque cosa. Il problema è come questa cosa verrà realizzata.

È nato come un linguaggio per non-programmatori. Ricordiamolo. Ed è stato evoluto aggiungendo roba senza curarsi di rendere il tutto coerente con quello che c'era prima. Sembra quasi una corsa, e ora la rincorsa è a risolvere i problemi che, da sempre, lo affliggono.

Ovviamente c'è chi lo conosce bene, chi lo riesce a domare sul serio. In mano a queste persone, PHP è ottimo tanto quanto i più blasonati linguaggi di programmazione. Lavoro quotidianamente con degli ottimi sviluppatori PHP, e vedo quanta fatica fanno a tenere in piedi il tutto. Li ammiro, a me salterebbero i nervi molto prima di aprire l'editor di testo. Aggiungiamo, inoltre, che il guaio è che il 90% degli sviluppatori in questo linguaggio non sono particolarmente esperti né di PHP, né di programmazione, tantomeno di sicurezza informatica. Col risultato che quasi tutte le newsletter di sicurezza che mi arrivano quotidianamente parlano di PHP stesso o di software in PHP.

Parlandone in giro, mi sento rispondere che è normale che sia così in quanto è il più diffuso, quindi necessariamente il più bersagliato. In parte ciò è vero (nessuno noterebbe un bug di sicurezza di un linguaggio usato da piccole percentuali di sviluppatori), ma osservando attentamente la documentazione stessa di PHP si percepisce immediatamente l'idiosincrasia tra la buona programmazione e la programmazione "stile PHP".

Ho anche letto, recentemente, un interessante (e ormai famoso) articolo sui problemi di PHP. Ne consiglio la lettura, pur essendo un articolo molto lungo. A mio avviso spiega bene le cose.

Insomma, PHP c'è e ci sarà a lungo, ma a me è antipatico. Ci lavoro, ci lavorerò, lo userò quando necessario ma no, non mi piace e non credo potrà mai piacermi.

Lo Swap e la Memoria Virtuale

Introduzione

Si sentono sempre, in giro, tantissime diverse opinioni sull'utilizzo dello Swap. Ci sono quelli della filosofia (arcaica) che "deve essere il doppio della RAM", quelli che dicono che "oggi non serve più, abbiamo RAM più che sufficiente", poi ci sono quelli che dicono che il sistema "senza Swap è più veloce" e quelli che dicono che è più lento.

Ma nel 2015, con la RAM a basso costo, vale ancora la pena investire dello spazio su disco da dedicare allo Swap? La risposta rapida è: Sì, ne vale la pena. Ma andiamo ad analizzare la situazione.

La Memoria Virtuale

Swap

Ho avuto l'onore, durante i miei studi Universitari, di seguire due corsi (e sostenerne i relativi esami) col prof. Ozalp Babaoglu, colui che ha introdotto e sviluppato la Memoria Virtuale (e molto altro, tra cui il TCP/IP) in Unix. Sì, l'originale Unix! L'argomento, dunque, mi è sempre stato molto a cuore.

Tutti i dispositivi informatici hanno una RAM, ovvero una memoria ad accesso rapido su cui vengono appoggiati i dati in uso. Essa è veloce, decisamente più di qualunque disco fisso (anche delle moderne SSD), ed è una delle principali componenti che determinano la velocità operativa di una macchina, sia essa un server, un computer "tradizionale" che uno SmartPhone, Tablet, ecc.

La Memoria Virtuale è la somma della RAM e dello spazio che definiamo come Swap, ovvero uno spazio su un dispositivo di memorizzazione più lento che viene utilizzato quando il sistema ha bisogno di (o decide che sia meglio) liberare un certo quantitativo di memoria ad accesso rapido (RAM, appunto).

Il Sistema Operativo, in pratica, decide cosa sia meglio tenere pronto all'uso e cosa possa parcheggiare in un luogo meno conveniente, ma ugualmente accessibile. La Memoria totale vista da esso è, dunque, la somma tra RAM e Swap. Oltre questo quantitativo non si può andare, e se si dovesse superare la soglia di tolleranza il sistema inizierebbe a mandare degli OOM1 e gestire la situazione. Come verrà gestita è completamente dipendente dal sistema operativo in uso2.

Lo Swap

Ogni Sistema Operativo ha una gestione diversa del concetto di Swap, ma il succo è sempre il solito:

Swap è uno spazio su un dispositivo più lento che viene utilizzato come estensione della memoria RAM

Storicamente, Windows ha gestito lo Swap come un file presente nel file system principale. Di dimensione dinamica (cresce al crescere delle esigenze), viene principalmente utilizzato quando la RAM della macchina comincia ad essere piena.

Nei sistemi Unix-Like (quindi anche i *BSD e GNU/Linux), lo Swap è stato generalmente collocato in una partizione dedicata e ottimizzata allo scopo. Il principio è semplice: i file system devono occuparsi di gestire file (quindi permessi d'accesso, orari di creazione e modifica, redistribuzione dei vari pezzi dei file stessi nelle varie porzioni di disco, problemi di frammentazione3, ecc), aggiungendo quindi uno strato alla mera lettura/scrittura fisica sul dispositivo. La partizione di Swap è dunque dedicata solo allo Swap, e il sistema operativo può usufruirne senza dover fare tutti quei controlli e senza andare ad appesantire un file system più complesso. È comunque possibile, anche su GNU/Linux e i vari *BSD, utilizzare un file di swap, e può essere una soluzione comoda sia per necessità (es: bisogno di aggiungere dello Swap successivamente all'installazione, oppure incrementarlo solo per periodi limitati) che per malleabilità. Ci sono infatti degli interessanti programmi che gestiscono dinamicamente gli swap-file, facendoli crescere o cancellandoli in base alle reali necessità della macchina.

A volte mi sento dire:

"Ma io ho tanta RAM, molta più di quanta me ne serva. Perché dovrei comunque creare uno spazio di Swap?"

Ci sono (almeno) due ragioni distinte:

  1. I Sistemi Operativi come GNU/Linux hanno una gestione molto intelligente della RAM. Sapendo che è un bene prezioso, cercano di sfruttarla al massimo. Tutto lo spazio libero, quindi, cercheranno di utilizzarlo per fare cache delle letture e scritture sui dischi. Terrà dunque in memoria tutto ciò che ha letto fino a quando questa memoria non sia piena o necessaria per altri utilizzi più importanti. Linux, ad esempio, tende ad utilizzare TUTTA la RAM a disposizione, partendo dal principio che sarebbe sprecato tenerla ferma a non far nulla. In questi casi, lo Swap è utile in quanto dopo un certo tempo il Kernel si accorge che certe applicazioni (es: init, alcuni daemon come cron che potrebbero non avere nulla da fare, ciò che riguarda il boot e lo shutdown, ecc.) non vengono utilizzate da un bel po' ma stanno stagionando nella nostra preziosa RAM. Pur non avendone stretta necessità, deciderà di spostare ciò che è relativo a queste applicazioni nello Swap, così da avere più RAM libera sia per la cache dei dischi che per eventuali picchi di carico. L'aggressività di questo comportamento è configurabile mediante l'impostazione della swappiness. Per fare un esempio pratico, se abbiamo il tavolo vuoto e torniamo con i sacchetti della spesa, conviene lasciarla a lungo sul tavolo o mettere a posto le cose negli stipetti e avere il tavolo libero per qualunque utilizzo successivo?

  2. Quasi tutte le distribuzioni di GNU/Linux utilizzano lo Swap come spazio di memorizzazione dati in caso di ibernazione. Il contenuto della RAM viene dunque "congelato" e copiato nello Swap, pronto ad essere ricaricato e rimesso al proprio posto al boot successivo. In questo caso, è necessario che lo Swap sia almeno grande quanto il contenuto (escluse le cache, ovviamente) della RAM stessa.

Insomma, in molti casi possiamo lavorare anche senza Swap ma la sua presenza migliora l'efficienza di gestione delle nostre risorse.

Quanto deve essere grande la mia partizione di Swap?

Non esiste una risposta universale. Dipende

Un tempo si diceva che dovesse essere il doppio della RAM, ma erano i tempi in cui misuravamo la memoria in Megabyte, non in Gigabyte. Oggi sarebbe, a mio avviso, quasi sempre uno spreco di risorse. Se avete bisogno di ibernare il PC, consiglio di dare una dimensione leggermente maggiore del quantitativo della vostra memoria RAM. In caso di sistemi che non hanno questa necessità (es: server), suggerisco di valutare caso per caso, ma dare sempre almeno un paio di GB. In caso di picchi o di necessità mutate e di impossibilità a modificare le partizioni, c'è sempre la già citata possibilità di utilizzare uno swap-file (fisso o dinamicamente allocato).

C'è sempre poi da ricordare che nello Swap vengono memorizzate porzioni di memoria RAM, dunque è possibile analizzare lo spazio anche dopo lo spegnimento del computer e trovarvi password, dati personali, ecc. Per i più attenti c'è sempre la possibilità di crittare lo Swap, sia con chiave fissa (richiesta ad ogni boot) che con chiave dinamicamente generata ad ogni avvio, che appunto si invalida allo spegnimento della macchina.


  1. OOM sta per Out Of Memory, ossia "ho finito la memoria a disposizione". 

  2. Linux, così come FreeBSD, ha un OOM killer intelligente e ragionevolmente efficiente. Esso cerca i processi più onerosi e tenta di capire se sono fondamentali per l'esecuzione del sistema. Di solito, nella mia esperienza, gli OOM killer uccidono Apache e MySQL, che reggono bene e "ripartono" alleggeriti. Windows, invece, non ha un OOM Killer e il sistema diventa instabile fino a crashare completamente. Consiglio questa interessante lettura 

  3. Per quanto molta gente sia convinta del contrario, anche i file system supportati nativamente da Linux (e *BSD) soffrono di frammentazione. La differenza rispetto a Windows è che essi ne soffrono meno, ma non ne sono immuni. L'utilizzo di SSD annulla quasi completamente il problema.