Quante volte noi utilizzatori di Linux abbiamo sentito questa frase? Il motivo è sempre stato chiaro a tutti: Linux, purtroppo, ha nel runlevel 5 (o 4) il suo punto debole. Quali sono i problemi delle interfacce grafiche che girano su Linux? Performance? Usabilità? Interoperabilità? La lista sarebbe molto lunga, e le motivazioni che ci hanno portato all’attuale situazione sono varie.

Il venerando protocollo X, ad esempio, ha numerosi punti di forza: il suo concetto di protocollo “client” e “server”, croce e delizia, ha permesso di realizzare il concetto di rendering remoto, di poter quindi lanciare applicazioni su un server e poter visualizzare la loro parte grafica in locale; il poter quindi far transitare il tutto in un tunnel ssh inverso, per poter installare software che preveda un’interfaccia grafica, senza essere fisicamente davanti all’installer. Il concetto stesso di nesting, la modularità dei suoi componenti, il supporto per quasi ogni scheda grafica esistente, la possibilità di configurare anche il più piccolo dettaglio, dalle caratteristiche del monitor alla RAM dedicata per la scheda grafica, il tutto implementato con uno sforzo di compatibilità all’indietro talmente grande da risultare quasi commovente. Le direttive stesse scelte dagli autori, Bob Scheifler e Jim Gettys, che avrebbero guidato tutti gli sviluppi del protocollo X sono così sane e ragionevoli da risultare adatte a qualsiasi soluzione software:

Do not add new functionality unless an implementor cannot complete a real application without it.

It is as important to decide what a system is not as to decide what it is. Do not serve all the world’s needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

The only thing worse than generalizing from one example is generalizing from no examples at all.

If a problem is not completely understood, it is probably best to provide no solution at all.

If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution.

Isolate complexity as much as possible.

Provide mechanism rather than policy. In particular, place user interface policy in the clients’ hands

(Non aggiungere nuove funzionalità a meno che chi la implementi non possa creare una vera applicazione senza di essa. Il decidere cosa non sia un sistema è importante tanto quanto il decidere cosa un sistema sia. Non cercare di risolvere tutti i problemi del mondo: piuttosto, rendi il sistema estensibile in modo che i bisogni possano essere soddisfatti in una modalità compatibile. L’unica cosa più sbagliata di generalizzare da un esempio e il generalizzare da nessun esempio. Se il problema non è completamente compreso, forse è meglio non fornire alcuna soluzione. Se riesci ad ottenere il 90% dell’effetto desiderato con il 10% del lavoro, usa la soluzione più semplice. Isola la complessità il più possibile. Fornisci meccanismi anzichè policy. In particolar modo, fai in modo che la policy dell’interfaccia sia nelle mani del client)

Ma il protocollo X ha anche parecchi problemi, intrinseci nel suo design e quindi impossibili da risolvere: problemi di sicurezza, di performance rispetto ai suoi concorrenti, e soprattutto il concetto di base con cui è stato concepito, e cioè chi fossero gli utenti finali designati al momento della sua nascita: gli amministratori di sistema.

Tutti questi elementi uniti insieme hanno creato un software meraviglioso e completo dal punto di vista della configurabilità e della versatilità, ma al tempo stesso parecchio scomodo e complicato per dei semplici utenti dalle scarse pretese oltre che l’avere un’interfaccia grafica veloce, performante e della quale configurare soltanto la dimensione dello schermo, la risoluzione e i colori.

Il protocollo Wayland, il successore di X, avrebbe dovuto essere la risposta moderna a tutte le problematiche sopra menzionate; avrebbe potuto prendere il buono di tutto ciò che era stato sviluppato negli ultimi vent’anni, scartando le problematiche di design, svecchiando gli elementi nati in un contesto storico differente, e creando qualcosa di nuovo dalle ceneri del suo predecessore. Purtroppo, come spesso accade nell’ecosistema GNU/Linux moderno, chi ha iniziato a sviluppare il nuovo protocollo ha deciso di ignorare completamente i propri predecessori, di creare un prodotto completamente da zero, secondo paradigmi e decisioni architetturali completamente arbitrarie – e soprattutto ignorando qualsiasi possibile compatibilità all’indietro: col risultato, prevedibile, di creare delle divisioni interne alla community, e quindi avendo un impatto negativo sulla salute della community stessa.

Un destino simile ha subito GNOME, il quale, dalla sua versione 3, è un pallido ricordo del Desktop Manager che ha accompagnato le prime distribuzioni Linux. Anche in questo caso, non è stato adottato un processo di design e sviluppo globalmente accettato e condiviso, e sono state prese alcune decisioni arbitrarie che hanno reso l’interfaccia più lenta, meno usabile, e che hanno portato la creazione di fork da parte di chi non era d’accordo con il nuovo design – uno fra tutti Linus Torvalds stesso.

The developers have apparently decided that it’s ‘too complicated’ to actually do real work on your desktop, and have decided to make it really annoying to do

“Gli sviluppatori hanno deciso sostanzialmente che sia troppo complicato il poter davvero lavorare sul proprio desktop, e hanno deciso di renderlo il più scomodo possibile”

Anche in questo caso c’è stata una divisione, e, anzichè portare lo sviluppo verso una direzione condivisa e con decisioni prese collegialmente, magari da un gruppo di persone dal background tecnico e personale di un livello adatto alla delicatezza del tema, la community ha preso molteplici strade, scindendosi in gruppi, ognuno dei quali ha voluto avere la pretesa di conoscere il modo migliore di procedere. Probabilmente è questo il problema maggiore dell’Open Source, che nasce purtroppo dalla sua forza: la totale democrazia nelle decisioni, e conseguentemente il chiudersi sulle proprie posizioni e il non ascoltare le esigenze degli utenti finali, incastrandosi in tecnicismi che poco interessano all’utente medio.

Ed è per questo che da anni sentiamo questa fase, in tono di scherno: “Questo è l’anno di GNU/Linux sul desktop!” da parte di utilizzatori di interfacce grafiche ben più blasonate, prodotte da corporazioni che, sì, hanno davvero a cuore l’opinione degli utenti, in quanto paganti. Ed è per questo che siamo costretti a dover apprendere che il 2021 è, per davvero, l’anno di Linux sul Desktop, ma non per merito della community Open Source.

Difatti, Google è riuscita a vendere circa 12 milioni di Chromebook nel solo primo quarto del 2001. E i dati di vendita indicano che il trend è in crescita.

Chromebook è effettivamente un laptop a basso costo, dal consumo energetico risibile, che fa girare Chrome OS ed è una delle periferiche attualmente più usate nelle scuole americane, dove i ragazzi possono utilizzarlo per loggarsi su Google Classroom, tramite il loro account Google, rigorosamente obbligatorio anche solo per utilizzare il sistema operativo. E a tutti gli effetti è un sistema operativo Linux. Quanto sarebbe stato difficile poter costituire un progetto di questo tipo, negli USA, con finanziamenti statali, portando il concetto stesso di “Open Source” in un contesto pratico e di sani principi come può essere l’insegnamento?

E’ stata l’ennesima occasione persa, tra una fork e l’altra, o in mezzo ad una discussione di technicalities che non interessano a nessuno.

Jean Pierre Brunod

Sostenitore di lunga data dell’Open Source, Sysadmin ma anche programmatore, mi appassiona qualsiasi cosa nell’IT che possa permettere un’espressione di creatività. Nostalgico della filosofia dei tempi andati, ma incuriosito dalle potenzialità dei paradigmi moderni.