Alessio Biancalana Grab The Blaster di Alessio Biancalana

Intel, Linux e il mistero del tearing

(Ovvero, nel caso specifico, come velocizzare le animazioni di GNOME Shell)

Per la serie “non si finisce mai di imparare”, torniamo a parlare di Linux; al rientro dalla vacanze, nonostante l’esperienza più che discreta con Windows 10, ho deciso di dare una piallata a KDE sulla mia Arch Linux per dare una possibilità a GNOME Shell, dato che in molti nonostante io non fossi particolarmente convinto me ne hanno parlato più che bene.

A questo credo che dedicherò un post a parte; quello che invece voglio trattare in questo momento è una “feature” di cui sono venuto a conoscenza solo oggi riguardante i driver grafici Intel su Linux, che hanno cominciato a darmi qualche noia con GNOME; nello specifico con la Shell ho sempre notato che le animazioni erano veramente poco fluide, con cali di FPS a manetta durante qualsiasi effetto grafico.

Avevo deciso di classificare la cosa come un “non sei tu, sono io”, ma oggi girovagando per l’internet mi sono imbattuto in un tizio sul forum di Arch che aveva lo stesso problema, al quale hanno consigliato di puntare il dito verso l’opzione TearFree dei driver, misteriosamente disabilitata out of the box nel mio e nel suo caso.

Dopo un giretto su Arch Wiki ho trovato quello che mi serviva; ho aperto il file di configurazione dei miei driver (vuoto):

$ sudo vim /etc/X11/xorg.conf.d/20-intel.conf

E ho riempito il file con questa roba:

Section "Device"
	Identifier  "Intel Graphics"
	Driver      "intel"
	Option      "TearFree"    "true"
EndSection

E al riavvio, magicamente, GNOME è diventato performante come un ghepardo.

Quello che non capisco, è come questa roba sia disabilitata out of the box, visto l’incremento di FPS pauroso che mi ha offerto praticamente dal nulla. Su Arch Wiki c’è scritto che con il DRI abilitato anche TearFree dovrebbe essere abilitato di default. Ovviamente sulla mia macchina manco l’ombra.

Tutto è bene, quel che finisce bene.

Internet nel 1995, vista da Topolino

Il Dottor Manhattan sul suo blog racconta l’Internet del 1995 vista da Topolino. Un tuffo nel passato:

Nel bollino rosso si segnala il rischio coppini di cui sopra, perché prima dell’avvento delle tariffe flat si pagavano gli scatti della telefonata tra casa propria e “il nodo di collegamento alla rete”.

E quanti coppini ho ricevuto, io da mamma Blaster, che si è accollata certe bollette astronomiche senza mai tirare un fiato :°-)

Farewell Chrome Apps

Google Chrome

E così, è successo: Google ha iniziato a dire ufficialmente che nel giro di un paio d’anni eliminerà la possibilità di eseguire le cosiddette Chrome Apps, ovvero applicazioni all’interno di Google Chrome – almeno per quanto riguarda Windows, macOS e Linux. Chiaramente questa possibilità penso rimarrà confinata al loro ChromeOS.

ChromeOS sul quale si continua a lavorare, e per il quale è stata annunciata proprio poche ore fa una nuova feature (il PIN di sblocco al posto della password di Google); questo a riprova del fatto che secondo me la strategia di centralizzare in Chrome le operazioni degli utenti da parte di Google è fallita miseramente.

Chrome runtime VS Electron

Col tempo infatti ha preso piede sì l’idea di eseguire delle webapp su desktop, ma in modo molto diverso da come Google aveva concepito la cosa; mentre a Mountain View si cercava di rendere Chrome il motore immobile dell’ambiente desktop, legando di fatto l’esecuzione delle applicazioni a quella del browser, anche se in finestre separate, GitHub ha tirato fuori dal cilindro un suo container agnostico per applicazioni web.

Il risultato usando Electron è molto meglio, dato che non è in nessun modo legato al browser in uso, e le applicazioni risultano molto, molto meglio integrate nel sistema operativo. Così l’idea delle Chrome Apps per macOS, Windows, Linux è andata a morire in favore di un sistema che a fronte di una omogeneità maggiore col sistema operativo e con l’ambiente desktop anziché col browser offre comunque un agnosticismo di fondo che consente di portare il codice su tutte le piattaforme senza troppi sbattimenti.

Tutti amano i runtime, a nessuno piace il contenitore

Secondo me le Chrome Apps (che per un periodo stavano prendendo piede) sono state uccise dai runtime per una ragione molto semplice: a tutti piace il runtime, mentre a nessuno piace vedere una webapp “vestita” da app desktop con così poca cura, e con così poca differenza rispetto al sito che la rappresenta.

A me è sempre sembrata una presa in giro, e mentre le Chrome Apps cominciano ad essere allontanate persino dai loro creatori, i runtime simili ad Electron (addirittura compatbili con questo) crescono di numero: Mozilla ha il suo, e GNOME agogna la possibilità di trasformare un pezzo di Epiphany in una shell simile.

Di positivo c’è che trovo che Chrome stia tornando pian piano a fare solo il browser. Ed è una cosa di cui c’è da essere contenti.

Photo courtesy of Thomas Hawk

Bootstrapping a React project

Effettivamente, dovrei cominciare a scrivere della mia esperienza con React, che in qualche coppia di settimane è diventata piuttosto estesa. Intanto però, mi annoto questo articolo sul blog di Auth0 sul kickstart di un progetto con React, che può tornare utile.

PowerShell is open sourced and is available on Linux

PowerShell non solo è open source (possiamo vedere tutto il codice su GitHub), ma possiamo installarla anche su Linux e macOS.

As we port PowerShell to Linux, we are making sure that we are a first class citizen on that platform. We fit in well with the architecture, idioms and existing tools. This was pretty easy as most of the original PowerShell team had deep Unix backgrounds and that shows in our design.

A me come shell non piace tantissimo, ma sono un grande fan della disponibilità dei software su ogni piattaforma e della possibilità di ampia scelta. Non so cos’altro abbia in mente Microsoft, ma io posso solo fare i complimenti.