#8 LINUX FA SCHIFO: Bug-fixing, ci sei?

L’ottavo capitolo della rubrica vi piacerà, oh eccome se vi piacerà. Certo, non alla stessa maniera di come avete gustato quei piatti di carne o pesce nelle località di mare in cui siete stati, e nemmeno allo stesso modo di quelle meravigliose granite con brioche calde col “tuppo” che avete trangugiato (i terroni conterranei capiranno). Ma vi piacerà. Spero. Male che vada un colpo di ALT-F4 risolve sempre tutto.

Prima di inviarmi insulti razzisti, colgo l’occasione per fare la SOLITA premessa: il seguente contenuto non è da intendere come “ah ma ti stai lamentando di Linux?” ma invece come “mi hai fatto riflettere su un aspetto molto interessante, un aspetto migliorabile, facendomi anche fare 4 risate :D”. In parole povere, la rubrica “LINUX FA SCHIFO” è nata per discutere insieme di alcune problematiche/carenze del sistema che, una volta migliorate, lo renderebbero perfetto. Nessun reale sfottò, nessuna presa in giro.

Vorrei inoltre linkarvi il terzo capitolo della rubrica, che si ricollega parecchio a quello di oggi:

#3 LINUX FA SCHIFO: uno sviluppo non proprio efficiente?

Ma proseguiamo.

I Bug ragazzi, i bug!

Prendiamo in considerazione l’idea di creare un software, uno qualsiasi, con uno scopo qualunque. Ci trovassimo sotto le direttive di un azienda, ci verrebbe anche fornito un iter di lavoro, che in genere consiste in:

• Tempo di sviluppo prefissato;
• Funzionalità prefissate;
• Ordine di sviluppo prefissato.

fossimo invece degli sviluppatori a tempo libero, la situazione sarebbe la seguente:

• Tempo di sviluppo libero (potreste metterci 5 minuti come 5 anni);
• Funzionalità dalla decisione sempre libera (dopo 1 ora volete aggiungerne un’altra, dopo 2, un’altra ancora);
• Ordine di sviluppo prefissato o meno (o vi fate uno schemino, o procedete come capita prima).

ora, entrambe le modalità di sviluppo hanno vantaggi e svantaggi, ad esempio avere la possibilità di aggiungere e modificare funzioni quando si preferisce dà largo spazio alla creatività, ma non avere uno schema di sviluppo (così come non porsi dei tempi più o meno prefissati) è da pazzi. PAZZI.

Esempio: vi trovate tra le mani il pannello di controllo dello schermo su Ubuntu. Volete ruotare lo schermo, perché magari avete la testa piegata a 90 (?) o per qualche bug (successo realmente a non so quanta gente) lo schermo viene visualizzato, di default, a 90 gradi. <<Beh, facile, premiamo qua>>. Cliccate su Ruota Schermo e niente. Niente, non succede niente. Sarà un problema di driver? togli i Open-Source ed installi quelli proprietari. Stesso discorso di prima. Allora cercando sul web, scopri che è un vero e proprio bug del server grafico X.Org. L’unica cosa da fare è, quindi, aspettare un bugfix.

Bugfix. Ma il bugfix, per degli sviluppatori che non sono stati assunti da nessuno e lavorano gratis nel tempo libero, che cos’è? E’ un CONCETTO ASTRATTO, che l’unica variabile che prevede è il buonsenso del developer stesso (o qualcun’altro in grado di risolvere il problema). Ora, quello citato è un esempio generico che non credo nemmeno esista, ma vi parlo di uno reale (e ancora vivo….purtroppo).

Nel frattempo, 14 anni fa….

Il 14 Luglio del 2004, un utente russo riportò sul web un problema che aveva avuto utilizzando (o meglio, provando ad utilizzare) le scorciatoie da tastiera per cambiare layout della tastiera da americano a russo. Cos’è successo a sto tizio, in pratica una volta premuta la combinazione CTRL+SHIFT il layout da tastiera risultata direttamente cambiato, cosa che sarebbe dovuta avvenire invece premendo CTRL+SHIFT+KEY come Up o Down. In parole povere, usando le Shortcut, era impossibile gestire direttamente il cambio lingua (a meno che giusto giusto vivi in un paese in cui si parla inglese come prima lingua). Potete analizzare il bug qui.

Ora, il problema sta nel fatto che questo bug (così come molti altri) è vecchio di ben 14 anni e non è ancora stato risolto (nelle ultime righe si parla di una patch correttiva da applicare manualmente sulle ultime versioni di Ubuntu e Mint per risolvere, ma sempre manuale).

La correzione bug su Linux in genere funziona nella seguente maniera:

• Un povero martire parla del bug nei principali canali di report bug, a volte specifici per quel problema nella speranza venga risolto;
• nel frattempo, se molti altri hanno avuto lo stesso problema, continuano a confermare il problema dopo di lui;
• una volta che il problema ha raggiunto un bel numero di utenti, forse (ammesso qualcuno sappia risolto) viene risolto.

La correzione bug su Windows (o in altri casi di sistemi con introiti economici) funziona in genere così:

• Gli sviluppatori analizzano il codice e trovano la falla;
• Lo correggono (in tempi sensati).

Immaginate ora di avere un bug fastidiosissimo (se non problematico al punto tale da non permettervi di usare Linux o la distro specifica) e, prima di venire risolto, potrebbero anche passare anni perché nessun developer che lavora gratis è tenuto (logicamente) a correggere il proprio codice. Una tragedia.

Una priorità non priorizzata

Concludendo, è fondamentale che, insieme allo sviluppo di driver e roba varia, venga priorizzato il bug-fixing, che insieme ad altri fattori contribuisce in maniera fondamentale a creare un software di qualità.

E voi, cosa ne pensate? Dovrebbero avere una certa priorità i bugfix o preferite tenerveli?