In debian esistono 4 tipi di repository:
- stable
- testing
- unstable
- experimental

La stable viene rilasciata quando il sistema debian è stabile a livello di dipendenze o sicurezza software. Di norma ogni 2-3 anni ed è usata solo per i server perché, ad esempio, da quando Facebook è passato da http a https: pidgin e altri software hanno smesso di funzionare su debian stable. Quindi i software usati dai desktop come Chrome, Firefox, pidgin rimangono troppo vecchi per un uso desktop e non vengono fixati perché non sono bug di sicurezza o di dipendenze. (a mio avviso è una cazzata per l’ambito desktop ma una scelta giusta per ambito server a cui è legato debian)

La testing contiene i pacchetti che un giorno diventeranno stable. Quindi sono più aggiornati. 6-10 mesi prima che la testing diventa la prossima stable i pacchetti non vengono più aggiornati di versione ma si fixano solo bug di sicurezza o dipendenze: questo periodo si chiama freeze di versione.

La unstable contiene tutti i software aggiornati all’ultima versione. Se vai sul sito di VLC e trovi che l’ultima vlc stabile è 2.0.4 allora questa la trovi nel repository unstable (per i browser Chrome, Firefox o software grandi si ritarda di 1 mese. Per gnome o kde si ritarda da 2 a 4 mesi). Quindi la unstable è una finta unstable perché trovi tutti software aggiornati secondo quello che dice il sito ufficiale del software

La experimental è la stessa cosa di unstable ma contiene beta ed alpha dei software. Inoltre trovi entro 1 settimana anche i software pesanti come gnome, kde, Firefox e Chrome dell’ultima versione.

In debian esistono anche 3 nomi di versioni dei repository:
- squeeze è l’attuale soprannome di stable
- wheezy è l’attuale soprannome di testing (che da febbraio 2013 dovrebbe diventare il soprannome di stable). Successivamente verrà scelto un’altro soprannome di solito un personaggio di ToyStory
- sid è il soprannome di unstable da sempre

Il giorno che viene pubblicata una nuova versione stable di debian il repository testing e il repository stable sono IDENTICI.

La Debian Rolling si intende avere i pacchetti e software aggiornati come fa il repository debian SID (ma anche testing può essere ritenuta Rolling perché sono abbastanza aggiornate).

Rolling = avere i software aggiornati all’ultima versione presente sul sito ufficiale del software stesso. Se esce gnome 3.8 oggi una distribuzione per dirsi Rolling deve metterlo nel repository nell’arco di 1-3 settimane al massimo un mese. La vera Rolling è Arch Linux. Debian SID è troppo lento infatti ancora non c’è gnome 3.6 mentre su archlinux lo hanno da mesi

Molto spesso ci si chiede quale sia la differenza sostanziale fra le licenze opensource senza leggere i 50 paragrafi di cui sono costituite. Ne esistono un 5-6 principali di cui ne derivano altre. Vorrei analizzare le più usate e dire in due righe qual’è la differenza.

[GPLv2]
Questa licenza è la più usata attualmente nei software opensource, ecco le caratteristiche principali che la rendono la migliore agli occhi di molti:
Utilizzo: Se crei un software sotto questa licenza e qualcuno vuole utilizzarne parte del codice (o tutto il tuo software) ha il consenso di:
1) Usare o modificare il codice  ma le modifiche effettuate al tuo codice opensource orginale (se è stato modificato) devono essere rese pubbliche sotto licenza GPLv2 o superiore. Questa licenza rende le componenti che dialogano con esso a sua volta in GPLv2 quindi in breve «tutto ciò che tocca la GPL diventa a sua volta GPL»
2) Può vendere il software
3) È obbligato a citare l’autore del codice originale nei credits del software (e nel rispettivo sorgente usato)
4) È constito forkare il progetto (copiarlo tutto), fare piccole modifiche e lasciarlo con lo stesso nome originale
5) È consentito passare da GPLv2 a una GPLv3 o superiore ma non tornare alla GPLv1
6) Tivoization: nonostante il software sia opensource (e quindi possa essere modificato o copiato) è possibile bloccarne la modifica tramite hardware. Se hai un modem con un firmware opensource puoi modificarlo, copiarlo ma l’azienda che ha creato il modem non è obbligata a permetterti di sostituire il software originale del modem stesso con il tuo modificato (è consentito il blocco scrittura del firmware) .
7) Nessuna responsabilità di danni in caso di malfunzionamento del software originale o delle copie.
8) Puoi applicare questa licenza su: immagini, sorgente, testi

[GPLv3]
Questa licenza non sta prendendo molto piede perchè troppo «restrittiva», ecco le caratteristiche principali che la caratterizzano:
Utilizzo: Se crei un software sotto questa licenza e qualcuno vuole utilizzarne parte del codice (o tutto il tuo software) ha il consenso di:
1) Usare o modificare il codice  ma le modifiche effettuate al tuo codice opensource orginale (se è stato modificato) devono essere rese pubbliche sotto licenza GPLv3 o superiore. Questa licenza rende le componenti che dialogano con esso a sua volta in GPLv3 quindi in breve «tutto ciò che tocca la GPL diventa a sua volta GPL». Migliora la compatibilità con le altre licenze (indica quali possono essere usare insieme alla GPL) e il codice sorgente può essere fornito su richiesta (o specificando il modo per ottenerlo). Questa licenza ha il difetto di costringere a passare a GPLv3 le altre licenze compatibili (come MIT/BSD-3Clause/GPLv2) se vengono usate insieme a codici GPLv3 per questo è poco apprezzata da tutti
3) È obbligato a citare l’autore del codice originale nei credits del software (e nel rispettivo sorgente usato)
4) È consentito forkare il progetto (copiarlo tutto), fare piccole modifiche ma non usare lo stesso nome originale del progetto
5) È consentito passare da GPLv3 a una GPLv4 o superiore ma non tornare alla GPLv1 o GPLv2
6) Tivoization: non ci devono essere limiti hardware (ad esempio blocco scrittura del firmware) nel sostituire il software opensource originale di un dispositivo elettronico. Se hai un modem con un firmware opensource puoi modificarlo, copiarlo e l’azienda che ha creato il modem è obbligata a darti il permesso di sostituire il software originale del modem stesso con il tuo modificato.
7) Puoi applicare questa licenza su: immagini, sorgente, testi

[LGPL]
Questa licenza è adatta alle librerie software (ad esempio librerie .h del c/c++ o classi java), ecco le caratteristiche principali che la caratterizzano:
Utilizzo: Se crei un software sotto questa licenza e qualcuno vuole utilizzarne parte del codice (o tutto il tuo software) ha il consenso di:
1) Usare o modificare il codice  ma le modifiche effettuate al tuo codice opensource orginale (se è stato modificato) devono essere rese pubbliche sotto licenza LGPL. Questa particolare derivata della GPL permette di usare codice compilato anche in software closedsource (ad esempio se il vostro software è una .dll di windows o .so di linux). Se create una .dll opensource in LGPL questa può essere «linkata» da software closedsource ma non può essere «incorporata» nel vostro programma diventando closed.
3) È obbligato a citare l’autore del codice originale nei credits del software (e nel rispettivo sorgente usato)
4) È consentito forkare il progetto (copiarlo tutto), fare piccole modifiche ma non usare lo stesso nome originale del progetto
5) È consentito passare da LGPLv3 a una LGPLv4 o superiore ma non tornare alla LGPLv1 o LGPLv2
6) Nessuna responsabilità di danni in caso di malfunzionamento del software originale o delle copie.
7) Puoi applicare questa licenza su: immagini, sorgente, testi

[AGPL]
Questa licenza è adatta a sitiweb o software di rete, ecco le caratteristiche principali che la caratterizzano:
Utilizzo: Se crei un software sotto questa licenza e qualcuno vuole utilizzarne parte del codice (o tutto il tuo software) ha il consenso di:
1) Usare o modificare il codice  ma le modifiche effettuate al tuo codice opensource orginale (se è stato modificato) devono essere rese pubbliche sotto licenza AGPL. La differenza con la GPL classica è che la licenza AGPL è ottimizzata per sitiweb, cms o software di rete o per la rete (contiene delle clausole aggiuntive utili)
3) È obbligato a citare l’autore del codice originale nei credits del software (e nel rispettivo sorgente usato)
4) È consentito forkare il progetto (copiarlo tutto), fare piccole modifiche ma non usare lo stesso nome originale del progetto
5) È consentito passare da AGPLv3 a unaA GPLv4 o superiore ma non tornare alla AGPLv1 o AGPLv2
6) Nessuna responsabilità di danni in caso di malfunzionamento del software originale o delle copie.
7) Puoi applicare questa licenza su: immagini, sorgente, testi

[MIT]
Questa licenza è detta senza limiti, ecco le caratteristiche principali che la caratterizzano:
Utilizzo: Se crei un software sotto questa licenza e qualcuno vuole utilizzarne parte del codice (o tutto il tuo software) ha il consenso di:
1) Usare il codice alla «fai come c*o ti pare» quindi anche in software closedsource o cambiare licenza direttamente
2) Può vendere il software.
3) Non è obbligato a citare l’autore del codice originale nei credits (ma deve lasciarlo nei sorgenti).
4) Nessuna responsabilità di danni in caso di malfunzionamento del software originale o delle copie.
5) Puoi applicare questa licenza su: immagini, sorgente, testi

[BSD 3-Clause]
Questa licenza è detta senza limiti con diritto d’autore, ecco le caratteristiche principali che la caratterizzano:
Utilizzo: Se crei un software sotto questa licenza e qualcuno vuole utilizzarne parte del codice (o tutto il tuo software) ha il consenso di:
1) Usare il codice in software closed source, modificarlo o  copiarlo ma deve dichiarare chi è l’autore nei credits e  nel sorgente.
2) Può vendere il software.
3) È obbligato a citare l’autore del codice originale (deve lasciarlo nei sorgenti, credits e dovunque sia necessario indicarlo).
4) Nessuna responsabilità di danni in caso di malfunzionamento del software originale o delle copie.
5) Puoi applicare questa licenza su: immagini, sorgente, testi

[CAMBIARE LICENZA]
Per quanto possa sembrare strano le licenze opensource si riferiscono alle loro «copie» e non all’autore originale. Un software creato da PIPPO in GPLv3 può essere reso closedsource nelle versioni successive (ma le versioni precedenti rimangono opensource sotto GPLv3).

Se ho un software 1.0 in GPL e io sono l’unico autore e decido che con la 1.1 diventa closed source (o cambia licenza in BSD/MIT) lo posso fare. La versione 1.0 (e precedenti) rimangono GPL. Un ipotetico utente XXXX può prendere la 1.0 e dire: fanculo PIPPO, tu lo fai proprietario e io lo porto avanti in GPL. Ovviamente non può cambiare la licenza della 1.0 ma è costretto ad usare la GPL perchè non è l’autore ma un forker del progetto e si deve tenere per forza la licenza originale (in questo caso GPL).

[IL KERNEL LINUX PUÒ DIVENTARE CLOSEDSOURCE?] 
No, in quanto per cambiare licenza devono essere consenzienti tutti gli autori/contributors/patcher che hanno contribuito al progetto originale. Ciò significa che nel caso del kernel linux devono essere d’accordo più di 10.000 persone e questo non è possibile.

L’utente normale, di per sè, non riesce a distinguere la differenza tra opensource o freeware: per lui è semplicemente gratis. Nel mondo degli esperti del settore la cosa ha un risvolto molto diverso: opensource = libertà di modificare, creare, aiutare.

Purtroppo, Android, è gestito interamente da Google in maniera closedsource fino alla major release. Google continua ogni 6 mesi a rilasciare una versione di android di nascosto per dare l’effetto sorpresa all’utente ma che si perde in una totale dispersione di versioni che oramai android 2.3 e android 4.1 sembrano due sistemi operativi TOTALMENTE DIVERSI.

Inizialmente, quando venne rilasciata la versione 2.1 di android pensavo che il cuore (kernel+api) di android fossero aggiornate e gestite da google stessa mentre applicativi e interfaccia grafica del produttore (al tempo HTC con il Dram o il Desire) imitando la filosofia linux dove il DE come Gnome/KDE veniva creato da un team, initscript da un’altro, systemd da un’altro e così via… Mi ero solo illuso.

Android ha sbagliato nel voler creare un prodotto unico, a mio avviso doveva creare due canali di updates:
~ Canale google: api android + kernel
~ Canale produttore: apps+launcher+mod personalizzate
In questo modo, abilitando questi «due repository» non sarebbe mai esistita la frammentazione perchè le api sono tutte retrocompatibili e non avrebbero causato danni al canale produttore (o almeno il produttore avrebbe deciso quando eseguire l’update dal repository google dopo una serie di testing).

Dopo questa breve spiegazione degli errori di google nel non aver imitato il mondo linux ma voler creare tutto da sola posso dire che android ha contribuito molto in due ambiti dell’opensource.

~ ARM
Lo sviluppo di android ha fatto sì che le distribuzioni linux iniziasserò a sviluppare le proprie distribuzioni nell’ottica dei processori arm e il kernel da quando è nato android ha avuto un impennata di commit e fix per i dispositivi arm molto elevato. La cosa fa ben sperare per la futura generazione di server o laptop arm a risparmio energetico con una durata della batteria in uso anche di diversi giorni: fantastico per chi odia stare 24h su 24 con il cavo della corrente mentre usa il suo portatile. Nel 2011 google con Android Device Kit ha rilasciato un intero pacchetto api per interfacciarsi con arduino e creare piccoli gadget personali android: c’è chi ha fatto un telecomando per chiudere la porta della stanza, chi ha sviluppato una lampada che si accende/spegne con android, chi una macchina telecomandata con i lego e altre cose a livello di domotica o semplicemnte svago.

~OUYA
Grazie ad android a marzo 2013 verrà rilasciata una console di giochi (tipo playstation/xbox) totalmente opensource. Sulla vostra playstation siete obbligati a comprare cd originali o giochi online dalla piattaforma sony ma non potete creare un gioco da soli, masterizzarlo e giocarci perchè tutti i giochi devono essere certificati dalla playstation e visionati: ecco ouya viene incontro a chi vuole creare giochi e giocarci. Immaginate come android abbia 10000 giochi gratuiti sul play store (ex market android), ouya avrà sicuramente persone che vorranno creare giochi opensource gratis che tu scarichi, masterizzi e giochi senza pagare niente! Ecco il vantaggio di android, permette progetti di questo genere.

Android non ha contribuito particolarmente a linux e al kernel stesso, se scarichiamo i sorgenti di un qualsiasi kernel di HTC/Samsung/LG (che deve essere rilasciato secondo il contratto GPLv2 del kernel originale) ci sono 1000-2000 righe di codice in più dove non c’è scritto quasi niente di rilevante: di solito sono solo collegamenti ai driver closed source del processore, scheda grafica, voltaggi componenti, etc.

Se prendiamo Android come piattaforma dove creare qualcosa di nuovo allora si. Cyanogenmod, Ouya, Arduino, Android X86 sono progetti che, basati o in collaborazione con android, offrono un’esperienza nuova. Anche semplicemente la Cyanogenmod che è una rom (firmware) per i telefoni che aggiunge features utili, nuove e che gli utenti desiderano. Molto spesso android e i produttori come HTC/Samsung copiano le loro modifiche aggiungendole ai loro firmware (ovviamente riscrivendo da zero per non dire che hanno copiato da cyanogenmod). Basta prendere HTC che nel menu a tendina delle notifiche ha aggiunto i collegamenti rapidi a wifi/bluetooth/gps/etc che in cyanogenmod esisteva dalla versione froyo di android.

Ognuno vede questo os opensource come vuole ma per molti aspetti sembra solo un sistema operativo che sfrutta linux per andare per la sua strada. Penso che nonostante android sia stato forkato e poi incluso nuovamente nel kernel originale 3.3 di torvalds riesca comunque a stare per conto suo. Le distribuzioni linux continuano ad aggiornare i propri pacchetti in modo quasi syncrono perchè basta prendere una ubuntu LTS o una Fedora 17 e i pacchetti che vi sono all’interno sono gli stessi o differenziati di una minor release mentra android se prendiamo un device galaxy s e un htc desire con hardware simile la versione del galaxy è ferma alla 2.2.7 mentre quella del htc desire alla 2.1 per colpa della sense.

Il fatto che device con un hardware simile abbiano versioni diverse lascia solo supporre che a google, samsung, htc, lg, sony non frega assolutamente niente della frammentazione e vogliono solo e soltanto vendere.