Quante volte ci è capitato di prendere una distribuzione Linux, magari una di quelle più famose, installarla sul nostro nuovo computer e ritrovarsi con una situazione sub-ottimale? Magari uno specifico componente hardware che non funziona, qualcosa che non viene rilevato correttamente, o una configurazione che non riusciamo proprio ad applicare, nonostante le specifiche del nostro hardware ne decantino il supporto?
Fino a qualche anno fa era più comune questa situazione che non quella di un installazione che facesse funzionare il nostro computer al 100% senza doversi “sporcarsi le mani”. E pare che anche al giorno d’oggi a volte capiti, ma qual è realmente il problema?
E’ l’argomento della recente puntata del podcast “Destination Linux 186”, intitolata, a ragione, “Quality Control in Linux”. Se volessimo riassumere la puntata con un piccolo estratto sarebbe:
You can go to a Best Buy and purchase a computer, but depending on who made that computer, when that computer was made, when in a release cycle that computer was made, what software was available at the time, what the release cadences were of the software projects when that LTS or that distro came out, all affects the quality and the experience you get as an end user.
Puoi andare in un Best Buy e comprare un computer, ma a seconda di chi ha fatto quel computer, quando quel computer è stato fatto, qual’era il ciclo di rilascio [della distro, ndt.] quando è stato fatto quel computer, quali software erano disponibili in quel periodo, qual’era la cadenza delle release dei progetti software quando quella LTS o quella distribuzione sono uscite, tutto questo affligge la qualità e l’esperienza che ottieni come utente finale.
Il problema dunque è che, vuoi per la frammentazione dei software nelle diverse distribuzioni, vuoi per la grande varietà di combinazioni hardware disponibili sul mercato, è impossibile assicurare che una data distribuzione Linux funzioni su qualsiasi hardware, quindi è un problema di controllo qualità.
Certo, ci sono soluzioni attuabili, basti pensare a Microsoft ed alla sua “armata” di “Windows Insiders” che testanto i futuri rilasci di Windows su una pletora di hardware differenti, ma nel caso specifico del sistema di Redmond stiamo parlando di un singolo sistema operativo. Gli utenti Linux, come ben sappiamo, utilizzano decine di kernel differenti, versioni differenti di software che hanno tempi di rilascio ed aggiornamento tra i più vari, e le distribuzioni si basano quasi unicamente sulla loro community per il test. Più una distro è piccola (in termini di base utenza), minore sarà l’hardware su cui viene testata, ma anche “giganti” come Ubuntu necessiterebbero di un sistema più strutturato.
C’è una bella discussione aperta, proprio a seguito di quella puntata, su Destination Linux Network, con proposte a possibili soluzioni ed un’idea su cosa dovrebbe avere il sistema di gestione dei test:
Website with a developer section where they can submit a request for testing. Form would allow for Dev to specify criteria to the type of testers they need (example: only testers with HiDPI monitors or only testers with AMD GPU’s)
An additional form for people to sign up for being a tester. Capture hardware information and additional info regarding their OS and whether they’re willing to test on bare metal or only a VM, etc.
Response form that testers fill out. Allow some customizable fields from devs. The responses are consolidated into a summary report.
Un sito con una sezione sviluppatori dove possono inserire richieste di test. Il form deve permettere agli sviluppatori di specificare i criteri per chi dovrà testare il software (esempio: solo sviluppatori con monitor HiDiPi o solo sviluppatori con GPU AMD).
Un form addizionale per le persone che vogliono essere i tester. Acquisire quindi informazioni sull’hardware ed aggiuntive riguardo il loro OS e su dove vorranno eseguire i test, direttamente sull’hardware o solo su macchine virtuali.
Un form da riempire per i tester con le risposte ai test, con la possibilità per gli sviluppatori di personalizzare i campi del form. Le risposte dovranno poi essere consolidate in un report.
Stanno cercando persone per lavorare a questo progetto e chissà che qualcuno di voi lettori di MiaMammaUsaLinux.org non possa dare una mano.
Bisogno ce n’è molto, perchè anche le grosse distribuzioni con partnership specifiche hanno problemi in tal senso. Per citarne uno, Jason Evangelho, contributore di Forbes, sta attualmente testando il ThinkPad P53 di Lenovo nato dalla partnership con Fedora. Qui la situazione dovrebbe essere assolutamente sotto controllo: hardware e distribuzione ben specifici, ed una partnership che mette a lavorare insieme entrambe le parti, ma nonostante questo si è trovato un bug che bloccava l’installazione del driver Nvidia proprietario per la scheda presente sul portatile. Certo, ha mandato un’email al team Linux di Lenovo ed aperto un bugreport sul Bugzilla di Fedora ed il problema è stato risolto rapidamente, ma neanche queste due entità “di grossa portata” avevano rilevato il bug prima della distribuzione del portatile, figuriamoci quando non ci sono partnership in atto o si utilizzano distribuzioni molto meno diffuse.
Vi lasciamo con il podcast di cui parlavamo e, chissà, magari avete qualche ottima idea da proporre nei commenti!
Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.
Lascia un commento