Una inchiesta davvero bella e sconvolgente.
Un problema che mi ha sempre interessato ed inquietato.
Segnali dei tempi che stiamo vivendo: di nuovi schiavi globalizzati e delle vere bombe di cui dovremmo avere timore! Altro che problema immigrazione e sicurezza, bandiera di questa nostra destruccia populista e xenofoba che scarica sul più povero le sue manchevolezze.

Come economista in erba mi sento di dire che se riuscissimo ad internalizzare i costi di trasporto nel prezzo delle merci che ogni giorno troviamo nei supermercati risolveremo in parte anche questo problema, oltre che parte di quello ambientale.
Come neo-militante di Sinistra Ecologia e Libertà, invece, segnalo che il partito si propone di realizzare il suo Congresso Nazionale fondativo a impatto il più basso possibile, anche chiedendo ai suoi militanti di raggiungere Firenze in treno (articolo).

Un bug mai segnalato prima è classificato come nuovo fino a quando qualcuno non lo riesce a riprodurre (o, purtroppo, vi incappa involontariamente e lo segnala), ed il baco diventa confermato. Vi sono poi altre categorie di classificazione come risolto, informazioni aggiuntive richieste, ben segnalato, ecc…

La prima cosa da fare per risolvere un baco è se qualcun altro (di un’altra comunità) lo ha risolto. Nel caso di Ubuntu ad esempio andando a vedere se in Debian è stato riscontrato e risolto (dato che il 75% dei pacchetti è comune) ed il contrario. Oppure se il pacchette è ad esempio OpenOffice.org se la comunità di OOo lo ha riscontrato e risolto (potrebbe ad esempio affliggere tutti i pacchetti di quell’applicazione, siano essi per Windows, per Mac OSX, o per qualunque altro SO).

Gli sviluppatori chiedono agli utenti di seguire alcune semplici indicazioni per “non farli arrabbiare”

• nel momento della segnalazione riportare tutte le informazioni necessarie alla riproduzione del baco; tipo il modello della macchina sulla quale si è riscontrato un problema nella gestione della batteria;
• nel momento della segnalazione NON riportare informazioni superflue: tipo il modello della macchina sulla quale è stato riscontrato un errore di traduzione;
• scrivere in inglese;
• scrivere in modo schematico: del tipo: ho fatto questo, poi quest’altro ed è successo questo;
• scrivere nel posto giusto: se Inkscape ha un baco sia nella versione per GNU/Linux che in quella per Windows segnalarlo all’autore di Inscape, mentre se il problema si presenta solo con la versione per Debian segnalarlo alla Comunità del SO;
• segnalare la reale priorità/gravità del baco. La segnalazione di una falsa priorità aumenterà solo il lavoro degli sviluppatori, che dovranno correggere la priorità riportandola al corretto livello, senza aumentare le probabilità che il problema venga corretto in tempi più brevi: lo sviluppatore, dopo aver corretto il livello di priorità della segnalazione passerà ad un bug più grave.
• seguire la segnalazione, rispondendo ad eventuali richieste dello sviluppatore per completare la segnalazione (anche se la segnalazione del tutto corretta);
• rispondere con precisione alle domande che ci vengono poste: dire l’ultima data di aggiornamento del sistema quando ci viene chiesta la versione del kernel in uso non va bene…

Come abbiamo detto nel post precedente, in Debian i bugs segnalati sono consultabili su bugs.debian.org cercando il numero del baco che ci interessa. Ogni baco è taggabile in diversi modi come riportato in http://www.debian.org/Bugs/Developer#tags.

Dal Terminale possiamo lanciare Reportbug che ha tre interfacce: una completamente testuale, una semi-grafica ed una grafica. Per segnalare un bug posso procedere come segue:

1. Qual’è il pacchetto che devo segnalare, cioè quello in cui si trova il comando che ha generato in problema?

   $ which <COMANDO>
   <PACCHETTO_DOVE_SI_TROVA_IL_COMANDO>

2. Lancio reportbug seguito dal nome del pacchetto trovato al punto 1.
3. Controllo i duplicati che mi vengono proposti e decido se sottoscrivere un bug già aperto o se aprirne uno nuovo.
4. Per segnalarne uno nuovo, inserisco l’argomento/riassunto che apparirà in BTS (in inglese).
5. Scelgo la gravità del baco.
6. Inserisco dei TAG (facoltativo).
7. scrivo il corpo dell’E-mail, descrivendo il problema (in inglese).
   Scriverò una cosa tipo “Ciao a tutti, stavo facendo così e cosà aspettandomi succedesse questo mentre invece è successo quest’altro” inserendo tutte le informazioni di cui dispongo e che ritengo utili.

In Ubuntu la procedura è molto simile anche se più di immediata comprensione dato che tutto passa attraverso un sistema di concezione web 2.0 come è Launchpad.

————————————————————————————————————————————————

post precedente

In Ubuntu i bachi si segnalano attraverso Launchpad. Nella fase di sviluppo è inoltre presente in Help la “voce segnala un bug”. Altrimenti possiamo usare il comando $ ubuntu-bug-N°ID_PROGRAMMA (dove N°ID_PROGRAMMA va sostituito con l’ID dell’applicazione in cui si è riscontrato il baco – che se non sbaglio si trova con $ pidof NOME_PROGRAMMA).

Per prima cosa mi vengono mostrati bachi simili in modo da raggruppare problemi che si somigliano. Se marco un baco simile posso segnarlo come “affligge anche me”, incrementando la probabilità che il baco venga risolto in breve tempo, o anche “sottoscrivere il baco”, così da ricevere E-mail che lo riguardano e poter risolvere il problema.

Se non esiste un baco simile ne posso aprire uno nuovo. Se ho utilizzato un programma per segnalare il bug alcune informazioni (riguardo la configurazione della macchina su cui si è verificato) saranno già riportate. Importante è riportare più informazioni possibili, dato che lo sviluppatore per correggere il problema avrà bisogno di riprodurlo. Le informazioni indispensabili sono del tipo “ho fatto questo, mi aspettavo che succedesse questo mentre è successo quest’altro”. Le informazioni sono da riportare in inglese, ma quanto più schematica è la frase tanto meglio è (dato che anche lo sviluppatore saprà un inglese un po’ arrangiato come molti di noi).

Infine, è utile conoscere il comando $ apport-collect N°_BUG che riporta informazioni riguardo il baco indicato (il cui numero si trova nella relativa pagina di Launchpad).

In Debian, invece, si usa BTS (Bug Tracking System) che possiamo trovare su bugs.debian.org.

Il sistema apparirà immediatamente obsoleto è complesso (soprattutto rispetto alla concezione web 2.0 di Launchpad), ma cambiare il sistema è uno sforzo titanico dato l’altissimo numero di informazioni raccolte negli anni. Tutto è gestito per via testuale attraverso l’invio di E-mail (ricordiamoci come Debian utilizzi principalmente ML per comunicare, a differenza di Ubuntu che privilegia i forum). L’interfaccia web serve solo per consultare l’archivio con cui si interagisce unicamente via posta elettronica, mandando messaggi alle seguenti caselle:

• submit AT bugs.debian.org per le segnalazioni;
• control AT bugs.debian.org per i metadati;
• NNNNNN AT bugs.debian.org per le risposte a segnalazioni di altri (ad NNNNNN va sostituito il numero della segnalazione);
• NNNNNN-done AT bugs.debian.org per chiudere un bug risolto.

Anche in questo caso si vede come Debian sia molto più aderente alla filosofia Unix “dura e pura” secondo cui si fa in modo che ogni programma faccia una sola cosa e bene, mentre Ubuntu predilige la semplicità e immediatezza creando un luogo, Launchpad, che serve a fare molte cose diverse fra loro. Possiamo notare come questo tema ricorra in tutte le sessioni della giornata e sia davvero centrale nei rapporti fra le due Comunità.

Nell’E-mail che segnala un baco è necessario inserire specifici TAG che il sistema riconosce ed interpreta, le risposte sono invece semplici file di testo. Reportbug è un programma che aiuta proprio a scrivere correttamente e rapidamente l’E-mail di segnalazione.

———————————————————————————————————————————————–

post precedente

post successivo

Gli utenti di Ubuntu si dividono in due categorie: quelli che aggiornano ogni 6 mesi e quelli che aggiornano ogni 2 anni (rilascio LTS) -vedi politica dei rilasci di Ubuntu in wikipedia.

Lo sviluppo di una nuova versione procede così:

1. si prende la versione precedente e la si riallinea con la versione in sviluppo di Debian;
2. si aggiungono a queste i pacchetti che differenziano Ubuntu da Debian (meno del 25%) e si giunge così alla Alpha1;
3. si procede nello sviluppo aggiungendo nuove funzionalità e programmi rilasciando un certo numero di Alpha n;
4. quando viene rilasciata la Beta non vengono più aggiunte nuove funzionalità, ma sono corretti i problemi esistenti, così da stabilizzare il sistema;
5. solitamente alla Beta segue la Release Candidate (RC) che è da considerarsi quasi uguale a quella definitiva e la Comunità si concentra nella correzione dei bugs.
6. segue infine il rilascio della versione definitiva al grande pubblico.

Il Gruppo Test di Ubuntu-it ha dunque il compito di testare le immagini ISO rilasciate di volta in volta durante il processo di sviluppo del SO. Come è facile intuire si tratta di un compito di vitale importanza per la Comunità, dato che più persone effettuano test più bugs verranno scoperti e maggiore sarà la partecipazione della Comunità nella definizione delle priorità che gli sviluppatori devono perseguire.

Tutto ciò che si deve fare per entrare a far parte del Gruppo Test è spiegato alla pagina http://wiki.ubuntu-it.org/GruppoTest#partecipare.

Dal punto di vista pratico, i test si effettuano scaricando l’immagine ISO della distribuzione (tenendola aggiornata con un comando da terminale che vi permette di non dover riscaricare tutto da capo ad ogni rilascio) e creando una USB avviabile. I test possibili sono numerosi, ma la Comunità italiana ha deciso di concentrarsi su quelli che riguardano la versione Live del SO.

————————————————————————————————————————————————

post precedente

post successivo

La sessione è stata tenuta da Francesca Ciceri (della comunità Debian Italia) e Milo Casagrande (di Ubuntu-it).

Tutto è iniziato dalla considerazione che l’inglese non è la lingua più comune, ma è quella più comunemente parlata (vedi su Wikipedia). Dunque, è importante tradurre il software che gli utenti dovranno utilizzare per abbassare le barriere culturali e permettere di usare un numero maggiore di programmi (cioè anche quelli sviluppati da persone di altre lingue, concetto piuttosto centrale del Software Libero – mi viene in mente che la prima libertà sarebbe altrimenti solo dichiarata, dal momento che se sono libero di eseguire il programma, ma non conosco la lingua in cui è scritto, di fatto non sono libero di eseguirlo).

Esistono gruppi di traduzione per ogni distribuzione ed inoltre esistono gruppi di traduzione di singoli progetti, ma fra di essi vi è scarsa collaborazione e poco coordinamento.

Per tradurre non è sufficiente conoscere l’inglese e non è nemmeno sufficiente conoscere l’italiano, dato che non basta conoscere una lingua per saperne rendere il senso in una traduzione. Bisogna invece porre attenzione ai termini usati e alle culture cui ci riferiamo. Bisogna inoltre conoscere l’argomento di cui parliamo per utilizzare i termini corretti in quell’ambito semantico.

Per quanto riguarda il Team di Debian, esso si coordina tramite ML dato che solitamente una traduzione viene presa in carico da un singolo volontario, ma è poi necessaria la revisione di molti altri membri della comunità per evitare errori e svista che si possono commettere.

La traduzione dei programmi è principalmente demandata al Debian Translation Project, mentre la comunità italiana si occupa di tradurre le guide ed il sito web (news letter, wiki, ecc…). le traduzioni più semplici sono quelle relative al Wiki e alla descrizione dei pacchetti riportata in Aptitude. Più complesso è invece tradurre il Sito web.

Il Team di Ubuntu, invece, è composto da 25 persone di cui 12 si occupano di tradurre il SO, mentre le restanti 13 traducono una pubblicazione chiamata Full Circle Magazine (FCM) – gli stessi membri della Comunità facevano notare il paradosso.

Per tradurre viene usato Launchpad che è un’interfaccia web (il suo corrispondente offline è Gtranslator)  che mostra solamente i termini da tradurre prescindendo dal codice scritto dallo sviluppatore. Questo da una parte semplifica il lavoro dei traduttori (rendendolo alla portata di un maggio numero di volontari), ma dall’altra può produrre errori nel codice del programma (derivanti dal fatto che il traduttore non ha alcuna idea di come sta modificando il codice). Vi sono poi altri programmi utili ai traduttori per estrarre le parti di codice da tradurre che sono inserite in file .po (compilati poi in file .mo attraverso gettext e utilizzati dall’installatore nel momento dell’installazione per localizzare l’applicazione).

Merita notare come le due Comunità si distinguano molto su questo punto. Mentre Ubuntu-it ritiene più importante la semplicità (anche un utente con scarse capacità informatiche è capace di dare un contributo, anche minimo, allo sviluppo del SO) anche a discapito della qualità, per Debian la qualità è imprescindibile e al suo altare si sacrifica volentieri la semplicità. Non penso si possano dare semplici giudizi di valore: Debian si proclama Sistema Operativo universale, ma vuole anche presentarsi come un prodotto stabile e qualitativamente valido (si pensi alla politica del rilascio quando è pronto, del tutto opposta a quella di Ubuntu del rilascio ogni sei mesi ad ogni costo). Da una parte, dunque, c’è la volontà di aprirsi al maggior numero di contributi possibile (tutti gli utenti sono anche membri di una Comunità che sviluppa ciò che usa, in modo da svilupparlo come le serve, come lo vuole); dall’altra, invece, c’è la necessità di avere contributi di qualità (gli sviluppatori sono pochissimi e devono, dunque, concentrare le poche forze su ciò che è davvero importante e non “perdere tempo” a valutare “idiozie” dette dal primo che passa). Questi concetti torneranno utili anche per capire le differenze esistenti nel modo di segnalare bugs che esistono fra le due distribuzioni che illustrerò in uno dei prossimi post.

A differenza della comunità Debian, Ubuntu-it riscrive da capo il Sito web, invece di tradurre la versione in inglese. Questa differenza fra le due comunità è molto accentuata. In Debian esiste una sola comunità internazionale (un solo dominio, un solo portalte, ecc…), mentre le comunità locali (es. Debianizzàti) non sono legate al progetto e comunque comunicano molto più attraverso ML che attraverso Forum. In Ubuntu accade invece il contrario: ogni Local Team ha grande indipendenza (un proprio dominio, un proprio portale, ecc…) e la comunità sfrutta molto di più i forum per comunicare.

A questa parte “teorica” è seguita anche una parte pratica con un esempio di traduzione di un’applicazione per Gnome (fileroller). La traduzione è stata fatta usando le modalità tipiche di Ubuntu e sottolineando di volta in volta le differenze che questi hanno rispetto alle modalità impiegate da Debian, sottolineando pregi e difetti di entrambe.

——————————————————————————————————————————————-

post precedente

post successivo

La giornata è stata molto divertente ed interessante. Innanzitutto ho avuto modo di conoscere una realtà per me nuova. Già da alcuni anni (6 circa) mi interesso di Software Libero (GNU/Linux in particolare) a livello amatoriale e già altre volte avevo partecipato a qualche incontro/conferenza sul tema. Ma a differenza delle altre volte lì ho ritrovato il mondo del volontariato che ben conosco attraverso la mia esperienza scout (CNGEI): persone che si impegnano in modo disinteressato e, per questo, convinto e sentito in qualcosa, con la speranza che possa servire agli altri, senza aspettarsi da questi altro che un “grazie”, sotto qualunque forma questo arrivi.

Al di la delle sensazioni, ho anche potuto capire meglio le criticità che lo sviluppo di una distribuzione GNU/Linux oggi ha e come, invece, io possa dare una mano, anche con poco sforzo.

Infine, i contenuti, che sono stati davvero di ottimo livello e di grande interesse. Ho potuto seguire alcune sessioni su

• Traduzione;
• Testing;
• Segnalazione di un baco;
• Bug-triaging,

ed uno splendido intervento di Stefano Zacchiroli (Debian Project Leader).
Il mio amico Arvin ha, invece, seguito le sessioni di

• Sviluppo;
• Pacchettizzazione;
• Marketing,

che si svolgevano in contemporanea.

Cercherò in alcuni post di riassumere quanto ho sentito (per visualizzare i relativi post basta seguire i link delle sessioni a cui ho partecipato, elencate qualche riga sopra).

Ringrazio le comunità italiane di Debian ed Ubuntu per avermi offerto questa opportunità.

Questo video molto simpatico e ben fatto sponsorizza proprio la velocità di avvio come caratteristica fondamentale di questo fantastico Sistema Operativo.

Penso che anche Berlusconi sia vittima del berlusconismo.

Una verità di cui sono convinto da un po’.

L’intervista a Vendola, ospite ieri sera a Tetris, è veramente bella e piena di significato (la potete vedere qui).