01 Nov 2016
Durante queste settimane, GNOME 3.22 è arrivato nei repository Extra di Arch Linux, e io non ho minimamente perso l’occasione di scaricare i pacchetti aggiornati e installarli immediatamente - a parte un paio di giorni di routine per lasciare agli sviluppatori il tempo di aggiustare eventuali bug sulle estensioni della community più blasonate. Durante l’uso non andava nemmeno poi male, se non che ad un certo punto mi sono trovato a voler riavviare GNOME Shell, e l’ambiente desktop mi ha recitato uno strano messaggio:
Ho fatto due cose quindi: la prima è stata controllare che effettivamente stessi usando Wayland, il che mi è stato confermato dalle informazioni su GNOME, e da qualche giro di ps in cui compariva chiaramente Chrome sotto XWayland e GDM sotto Wayland.
La seconda è stata naturalmente dare una possibilità a Wayland come display server principale, e devo dire che sono piuttosto soddisfatto.
Il supporto di GNOME a Wayland è ottimo infatti, e non ho sofferto di alcuna regressione grafica se non di qualche lag per quanto riguarda (stranamente) il cursore del mouse. Ogni tanto infatti, senza apparente motivo, rallenta per qualche secondo fino a bloccarsi un po’, poi riprende la sua corsa senza problemi. Il resto, beh, tutto ottimo: specialmente l’uso di XWayland da parte delle applicazioni che hanno tardato un po’ la corsa al nuovo server grafico, totalmente trasparente, senza artefatti e senza nessun fattore che metta a disagio l’utente.
Queste prove le ho effettuate con una scheda video Intel; ovviamente mi dicono dalla regia che con un equipaggiamento Nvidia la situazione non è esattamente rose e fiori come la descrivo io. Nel frattempo però chi ha come me una situazione di doppia scheda video può tranquillamente lasciare la Nvidia spenta ed affidarsi alla Intel - a me non dà fastidio dato che la scheda “potente” la uso solo per giocare, e in questo periodo mi sono attaccato come una vongola alla mia PS4 e ad Overwatch. :-D
Adesso, beh, c’è solo da sperare che Wayland migliori sempre di più, che i desktop environment lo sfruttino al meglio (dato che a livello di compositing ognuno può scriversi la sua implementazione), e che per noi utenti tutto questo si traduca in un beneficio tangibile.
31 Oct 2016
In questi giorni mi sono astenuto dal commentare il nuovo Macbook presentato da Apple, in parte perché non ho avuto tempo, in parte per formarmi un’opinione tutta mia che sostanzialmente, ora, in fondo alla corsa, si riduce a questi punti fondamentali:
- Il nuovo colore Space Gray per il Macbook è la cosa che mi fa considerare l’acquisto di un nuovo modello;
- La touchbar è una cosa che per quanto utile, a me non serve;
- La rimozione del tasto Esc fisico è tamponata con la touchbar, ma ad un utilizzatore compulsivo di Vim come me questa sembra un’eresia;
- L’hardware all’interno è roba assolutamente non all’altezza di un ultrabook killer;
- L’unica novità di Sierra, l’ultima release di macOS, è Siri, di cui a me importa ben poco, e a quanto vedo pure agli altri.
Mentre vari fattori contribuivano a formare questo groviglio di sentimenti dentro di me, ho letto vari feedback in merito a questo, che consiglio:
Insomma, tanto per riprendere la frase finale del post di Tim Bray:
My best bet is to buy a future Mac that’s aimed at people like me. Which requires that Apple wants to build one; they don’t at the moment, but maybe they will again before this box I’m typing on runs out of gas. But some of the combos above don’t sound terrible.
Probabilmente non solo per me, che non sono mai stato un grosso affezionato, ma anche per molti altri è tempo di cominciare a pensare a cosa c’è dopo il Mac, dato che quell’aura di potenza senza compromessi comincia a evaporare come la neve al sole. Un tempo possedere un Mac significava avere accesso a un ecosistema Unix vasto, flessibile, senza rinunciare alla comodità di un sistema operativo orientato all’utente finale, ottimizzato per task multimediali, con una bella interfaccia grafica.
Di tutto questo è rimasta solo l’interfaccia grafica, dato che l’ottimizzazione del sistema operativo è andata a donnine col tempo, e l’ecosistema Unix ormai tra Linux che lo offre nativamente e Windows 10 che lo offre tramite subsystem dedicato comincia ad essere una caratteristica che spacciata come inarrivabile pregio sembra quasi naìf.
Nel frattempo i competitor stanno ridefinendo i traguardi a cui puntare, e stanno ormai sorpassando a tutta manetta quelli che Apple vede ancora come tali. Basta guardare come funziona GNOME Shell sul mio computer fisso, o come Microsoft sia riuscita a sfornare un prodotto clamoroso con un consenso globale con il suo ultimo Surface Studio.
Insomma, oltre il confine tracciato dal Mac sembra esserci una terra fatta di meravigliose novità. E forse il fatto che Apple stessa per questo nuovo Macbook abbia spento la mela sempre accesa sul lid del blasonatissimo portatile, è metaforico di un destino in calo.
16 Oct 2016
Circa un mese fa, ho deciso di migrare le macchine di una API abbastanza famosa (che ho scritto io, e il cui sorgente è disponibile su GitHub) da Linux a qualcosa di diverso. Tanto per continuare a studiare, ho scelto FreeBSD come sistema operativo di base, e mi sono veramente stupito di quanto sia ben ingegnerizzata l’alternativa a Linux che io stesso avevo sempre sottovalutato.
FreeBSD 11: novità (?)
A dire il vero le novità di questa FreeBSD 11 non sono poi molte: c’è un sacco di carne al fuoco per ZFS, il cui supporto nativo è stato aumentato lungo tutta la catena di utility del sistema come bsdinstall e sade. Per il resto, la cosa che risalta di più olte i soliti bugfix al kernel è chiaramente l’aggiornamento di tutto il parco software, dei port e dei pacchetti.
L’aggiornamento per me che venivo da FreeBSD 10.3 è stato veramente rapido e indolore: qualche colpo di freebsd-update e un giro di pkg hanno fatto avanzare di versione le mie macchine senza che io dovessi fare letteralmente niente. Una volta fatto un piccolo test in laboratorio ho lanciato tutti i comandi in sequenza e olé. La cosa stupefacente (circa) è che durante tutta la procedura le applicazioni funzionano a meraviglia, anche durante gli step intermedi, per via della separazione che avviene tra software applicativo e software di sistema effettuata a monte.
Sistema di base, port e pacchetti
Pur conoscendo un minimo la struttura del sistema operativo, dover usare BSD per il deploy di un servizio REST mi ha permesso di apprezzare e - letteralmente - di farmi innamorare dell’architettura di sistema, che mette a disposizione tre elementi fondamentali: il sistema operativo di base, formato dal kernel e da tutta la userland (quindi i comandi di base, come cp, ls e così via), un sistema di package management che non fa né più né meno di quello che deve, ossia gestire bene i pacchetti scaricabili da un repository, e un gestore di port, che sono tutti quegli script il cui formato ha avuto un successo stellare (basti considerare i PKGBUILD di Arch Linux o gli Slackbuild di Slackware, ma anche gli ebuild di Gentoo), che permettono con un singolo comando di scaricare i sorgenti di un software, compilarli e installare il risultato sul sistema tenendone traccia insieme a tutte le dipendenze.
Questo fa si da un lato che ogni cosa funzioni in maniera molto più isolata, dato che di massima i software continuano a funzionare anche nonostante degli aggiornamenti al layer di base sottostante; nel frattempo, il tutto dà un feeling di massima integrazione al sistema, dato che il tutto viene considerato come un unico prodotto, un unico grande artefatto, e di conseguenza installato, manutenuto e aggiornato come tale.
È espresso in maniera molto, molto chiara quindi il fatto che al di fuori della codebase di BSD, il resto sia proprio “il resto”, ossia pacchetti che si vanno a innestare in cima a una struttura che li accoglie e permette ai software l’esecuzione.
Insomma, anche troppe parole per dire: mi è piaciuta veramente tanto l’architettura del sistema.
Solidità e sicurezza
4.4BSD è un sistema che ha gli anni che ha. FreeBSD stesso è un sistema operativo che, per quanto possa reggere botta in maniera impressionante come abbiamo visto, ha gli anni che ha. Per la precisione ventitré. Nonostante questo, il sistema è robusto e dà ancora oggi la stessa sensazione che all’epoca aveva avuto Daniel Robbins:
Molte delle differenze tra Linux e FreeBSD provengono dalle diverse strutture di sviluppo che li caratterizzano. Lo sviluppo di Linux è molto decentralizzato, e ci affidiamo alle distribuzioni per mettere insieme ed unire i vari pezzi di Linux sparsi per Internet. Confrontate ciò con FreeBSD e gli altri BSD (OpenBSD e NetBSD), dove c’è un team di sviluppo unificato che lavora su di un unico insieme di sorgenti. Bene, ogni BSD ha il suo unico insieme di sorgenti unificati. Questa può essere una cosa positiva ed ha come conseguenza che FreeBSD non ha quel feeling di “messo insieme con le patch” come molte delle distribuzioni Linux.
Successivamente, possiamo confrontare la tecnologia che sta sotto il cofano. Molti dei fan di FreeBSD sosterranno che FreeBSD è predisposto meglio di Linux per essere un server. Vi diranno che FreeBSD è meglio se sottoposto a carichi pesanti e che ha uno stack TCP/IP migliore. Se confrontate Linux 2.2 o precedente con FreeBSD, devo ritenermi d’accordo.
Per quanto Linux abbia integrato dei software di grandissimo valore nel tempo, e possa essere vera anche la seconda parte di quello che Robbins scriveva al tempo della fondazione di Gentoo…
Mi è capitato di essere un grande fan dei kernel di test della serie 2.4 che ho utilizzato. Sono veramente fantastici e contengono un buon stack TCP/IP ed un sistema “netfilter” totalmente riprogettato che è veramente esplosivo. In conclusione, penso che Linux sarà il sistema operativo che definirà nuovi standard di performance e che renderà i server Unix liberi persino più competitivi contro le loro controparti commerciali.
… è altrettanto vero che per quella che è la mia prospettiva alcune scelte compiute all’interno di questo ecosistema (quello Linux) hanno portato una regressione a livello di performance e architetturale, oltre a lasciare Linux a girare attorno a sé stesso senza prendere una direzione del tutto innovativa, che è ciò che mi aspetto da un sistema operativo del genere. Queste regressioni hanno portato addirittura alternative un tempo ritenute molto meno rilevanti a poter trattare alla pari con Linux, se non persino superarlo. Tra i BSD, trovo che OpenBSD ricopra benissimo questo ruolo.
E questo ruolo è ricoperto con eccellenza grazie anche a pf, il firewall di OpenBSD presente anche in FreeBSD, uno dei cavalli di battaglia della scuola BSD VS Linux, ed effettivamente un grande alleato di chi si occupa di security.
Ending theme
Insomma, questo weekend mi sono divertito un sacco con FreeBSD e con i BSD in generale. A breve mi sono ripromesso di cominciare a pistolare con OpenBSD, dato che molti amici (nerdoni) autorevoli tra cui Gianguido e Roberto mi hanno consigliato di farci un giro.
Photo courtesy of lolwho
Ho sempre creduto nell’operato di Google, non tanto in quanto realtà industriale ma in quanto coacervo di progetti innovativi.
John Gruber, sul suo Daring Fireball:
Google then-VP of engineering Vic Gundotra devoted his 2010 I/O keynote to ripping into the iPhone and iPad, pedal to the metal on “open beats closed” and how an ecosystem of over 60 different Android devices (a drop in the pond compared to today) was winning, saving the world from a future where “one man, one company, one device” controls mobile.
Purtroppo, l’unico desiderio di Google sembra ormai quello non di fornire una soluzione il più possibile aperta a quelle che sono le necessità degli utenti, rendendo oltretutto la cosa profittevole, ma semplicemente sostituire a quello che addita come cattivo un altro cattivo, ossia sé stessa.
Questi ultimi Nexus non mi hanno convinto nemmeno un po’, è vero. Ma a convincermi ancora meno è una strategia in cui non mi vedo più preso di mira in quanto “smanettone”, mentre vedo prese di mira categorie di cosumatori a cui Google non ha da dare niente, i quali non hanno la minima voglia di cambiare. E forse, se queste sono le carte sul tavolo, fanno pure bene.
07 Oct 2016
Nell’ultimo periodo, ho iniziato a rivedere alcune idee che mi ero fatto riguardo un’applicazione da scrivere nel tempo libero per testare alcune tecnologie sul campo. Quello che ho iniziato a scrivere era un banalissimo pastebin, dato che in azienda non avevamo un’istanza di un software del genere, e ho pensato che ci potesse fare comodo.
All’inizio volevo mettere in piedi un backend di API REST, composto di microservizi, con un frontend impostato con VueJS che fosse una single page app. Per un pastebin però è troppa roba. Pur avendo pistolato con un’implementazione del backend primitiva e con un frontendino basato su Materialize, ho iniziato a pensare di “buttare” (non è la parola adatta) tutto e scrivere dei template server-side.
Quello che mi ha sorpreso, è stato leggere in questi giorni una serie di post che mi hanno fatto alzare il sopracciglio. Nell’ordine:
Sto per addentrarmi in una questione squisitamente relativa allo sviluppo web, che mi rendo conto essere una cosa che di riffa o di raffa non ho mai trattato ad un livello così profondamente tecnico su questo blog. Get ready.
We started with a JSON API and a React front end and slowly migrated to server rendered HTML.
Best practice
La cosa che mi ha lasciato impressionato è stata leggere in meno di una settimana svariati articoli, umoristici o meno, che riportavano l’attenzione proprio su questo aspetto: sviluppare la solita single page app con approccio REST e tutto il rest-o (hahah), è veramente considerabile come una sorta di dogma? Ovviamente no. Pare che invece, affrontata nel modo inverso (ovvero, posso non scrivere una SPA?), la questione appaia drammatica. Se non usi React non sei nessuno. Se non hai una single page app da sviluppare non sei nessuno. Se non ti schieri nella faida (perché tale sembra) tra Angular e React, sei irrilevante.
Lo sviluppo web sta subendo sicuramente una svolta in questi anni, ma forse è troppo repentina perché le persone non la subiscano come una sorta di religione emergente, per cui all’interno dei vari user group e delle community ormai si sente parlare in modo ossessivo di nuovi framework che fanno le stesse cose dei vecchi framework, ma cambiando una virgola nei parametri da passare ai costruttori (costruttori? Ho detto costruttori?).
Puoi pronunciare le parole “generiamo HTML server-side” solo se affianco ci infili “il nostro Javascript è isomorfico”. Altrimenti ti inseguono con un forcone.
Ironia a parte, a me pare che ci sia una frazione di persone che al posto di pensare con la propria testa vada appresso alle mode in modo cieco. Questo a volte porta dei risultati, altre volte porta alcuni irresponsabili a fare dei danni non da poco.
Ho scritto un’app MVC e mi è piaciuto
Non c’è nessuna colpa nel seguire un approccio che è ritenuto legacy dalla maggior parte degli sviluppatori “alla moda”. Quando scriviamo un programma, dobbiamo tenere conto di alcuni fattori che non sono solo semplicemente quale approccio, nell’istante in cui apriamo l’editor di testo vuoto, è considerato il più corretto.
- Quanto debito tecnico abbiamo nei confronti di un approccio più innovativo
- Che tipo di caratteristiche dobbiamo sviluppare
- Quanto sarà facile che arrivino contributi complicando eventualmente l’architettura
Sono solo tre delle domande infinite che mi sono trovato ad affrontare progettando un’applicazione da zero. A volte può capitare di dover sacrificare qualche tecnologia molto alla moda perché le persone con cui lavori non la capirebbero mai, perché non hai tempo per studiare e la consegna è tra tre quarti di giornata, o perché semplicemente fare in un certo modo (in quel modo, il modo troppo fico) sarebbe sbagliato (!).
Prendiamo l’esempio del mio stupidissimo pastebin: ha senso immaginare una single-page application con un sistema di rotte per un diamine di affare che prende del testo e lo renderizza un po’ più carino? Decisamente no. Ha senso utilizzare React, invece, per accelerare lo sviluppo di una webapp altamente dinamica? Decisamente si.
Spesso alle persone (e, attenzione, io ricado in questo esempio parecchie volte :-D) piace tirare in mezzo tecnologie e pattern all’ultima moda solo per sperimentare, senza considerare tutti gli aspetti di contorno e l’intento dell’attività che si sta svolgendo.
Ma quindi ti fa schifo React?
No, anzi. Mi sono trovato di recente in una situazione spinosa pur avendo un margine di tempo per studiare. Ero da solo, e improvvisamente mi sono trovato con la richiesta pendente sulla testa di scrivere una webapp che facesse determinate cose. Potendo scegliere cosa tirare in campo per facilitarmi la vita, ho deciso di utilizzare React, e sono ancora vivo nonchè molto soddisfatto.
Tuttavia, il punto della questione è un altro: oggi è il 6 ottobre 2016. Ci sono cose che nel 2016 possono ancora essere impiegate con tantissima efficacia.
JQuery ha ancora da dire la sua nel 2016.
Un’architettura monolitica ha ancora da dire la sua nel 2016.
L’HTML server-side ha ancora da dire la sua (e ne ha ben donde) nel 2016.
E probabilmente, lo sviluppatore più anziano del vostro ufficio ha ancora da dire la sua nel 2016.
Sviluppa responsabilmente
Si, dico proprio a te che stai leggendo. Lo so che ti piace sperimentare. Lo so che è molto più facile ascoltare gli altri in maniera cieca. Ma guarda che stai facendo, stai usando React, che incentiva gli stili inline, quando gli stili inline sono stati demonizzati per anni, insieme al templating schiantato dentro il codice, e insieme a tutta una serie di cose che React fa e ti costringe a fare.
Quando sei davanti a una directory vuota, trepidante nell’attesa di scrivere il primo file del progetto, accendi il cervello, e chiediti quale sia veramente la cosa giusta.
È gratis.
Photo courtesy of ThoroughlyReviewed
