Alexjan Carraturo

Alexjan Carraturo personal page

10.10.10… esce Ubuntu 10.10, ma…

with 4 comments

Premessa: Questo non è in nessun modo di natura tecnica:oggi 10.10.10, vado sul sito di ubuntu (ore  11.45, per fare il fenomeno ci sarei dovuto andare alla 10.10 ) per cercare di scaricare la nuova ubuntu 10.10. Il sito però rimanda ancora al download della 10.04.1.Aggiornamento: ore 12.17, la 10.10 è disponibile sul sito.

Quanto segue è una critica severa ma onesta all’attuale modello di release delle distro GNU/Linux Mainstream, in particolare di quelle User Friendly. Se pensate che, così come è ora, sia perfetto, forse potete risparmiavi la fatica di leggere.

Onestamente trovo infantile cercare di fare marketing su une “evento” come una data numericamente curiosa (praticamente binaria). Non trovo opportuno il rilascio di prodotti sensibili come i SO secondo un calendario “stretto”. Se c’è una cosa che ci hanno insegnato i colleghi dei sistemi operativi proprietari è che i prodotti devono uscire quando sono pronti, non per questa o quell’altra data. Si badi bene che questo non riguarda esclusivamente ubuntu.

Inoltre trovo non solo inutile ma addirittura dannoso fare release semestrali; oltre a far uscire prodotti poco stabili da un segnale di scarsa stabilità all’utenza, abituata magari ai maggiori periodi di supporto del mondo proprietario (vedi Windows o MacOS); basti pensare al tempo di vita che ha avuto (con i vari upgrade) un sistema con Windows XP.

Queste release in continua successione, mette in crisi l’utente medio, che si trova immerso in processi di installazione un po’ macchinosi e qualche volta assai rischiosi per il funzionamento del computer, a release poco stabili e, qualora decidesse di non passare presto alle nuove release, alla perdita degli aggiornamenti. L’ingresso delle LTS in effetti ha attenuato questo problema, aumentando il ciclo di vita di una release installata, ma risulta difficile proporre agli utenti la vecchia LTS quando c’è già quella nuova.

Nei vari incontri relativi alla promozione del FOSS a cui mi è capitato di partecipare, è sempre stato visto, ma senza fornirne una motivazione veramente valida, le release vicine con un fatto migliorativo. Ma quando invece si lavora con il piano “pratico”, e si vedono gli utenti bloccati nei processi di aggiornamento release delle varie distro, a fare presto i confronti con i sistemi come XP e 7 (dove esserlo anche Vista, ma dato il disastro hanno dovuto tirarlo via molto prima del tempo), o con MacOS, ci si rende facilmente conto di come questa scelta non sia utilissima. Tale considerazione vale ancora di più quando si parla di distribuzioni “User Friendly”, dedicate quindi all’uso comune, e che di certo non necessitano della “last release” di ogni singolo pacchetto.

A pensarci bene, questa rincorsa all’ultima release di alcune distro, più che aggredire veramente il mercato dei OS proprietari, sembra più una lotta interna tra le varie distro GNU/Linux, e, come ho sempre detto, queste “gare” sono sicuramente inutili e nella maggior parte dei casi dannose.

Non a caso, molti utenti più smaliziati, se possono, con il passare del tempo e dell’esperienza, si buttano su distribuzioni con tempi di vita più lunghi (es Arch, inteso come release), Debian o Slack).

Inoltre questo comportamento mette anche a dura prova i team esterni che si occupano di sviluppi di software esterno alle distribuzioni,  packager indipendenti, distro derivate (anche quelle utili come quelle dedicate a casi specifici), o qualsiasi altro tipo di sviluppatori legati in qualche modo a quella specifica distro.

Senza dimenticare che questa “corsa” (ormai la voglio vedere così), mette anche in difficoltà i team di promozione più piccoli o locali (vd. Lug e simili), che devono sempre rimettersi al pari con il materiale con queste versioni, avendo già gli armadi pieni di materiale considerabile obsoleto e non più distribuibile (se non hai fini collezionistici).

Ognuno la può pensare come vuole, ma per me sarebbe opportuno ripensare a questo tipo di approccio, fare dei passi indietro, e vedere cosa hanno fatto altri prima (a mio avviso non sbagliando): innovare non vuol dire buttare via quanto c’era di buono prima.

Written by axjslack

ottobre 10, 2010 a 12:24 pm

Pubblicato su Commenti

Tagged with , , ,

4 Risposte

Subscribe to comments with RSS.

  1. Contrario.

    Le procedure di aggiornamento funzionano, sono testate, provare per credere.

    Il release early, release often funziona parecchio bene a livello psicologico, googlare per credere.

    Le tempistiche sono sì ridotte, ma basta non essere di manica larga nella roadmap (cioè, pianifico di fare quello che è lecito si riesca a fare in 6 mesi).

    Non ho capito cosa intendi quando dici che Arch rientra fra le “distribuzioni con tempi di vita più lunghi”.

    gionn

    ottobre 12, 2010 at 10:18 pm

  2. 1) Guarda, le procedure saranno anche testate, ma sapessi quanti utenti vengono dopo processi di aggiornamento “secondo le procedure” finiti male.

    2) In che modo google dovrebbe confermare una cosa che invece mi deriva direttamente dagli utenti. Forse saranno solo le persone che conosco io, ma è un bel campione abbastanza eterogeneo. Inoltre, a mio avviso, fare “tanti” annunci, in un mondo, quello del FOSS, che è già caratterizzato pesantemente dalla frammentazioni, fare continui annunci di “new release” ne diminuirà l’impatto mediatico. Un po’ un effetto “al lupo, al lupo” a scoppio ritardato.
    E vero che i sistemi GNU/Linux hanno ancora molto da recuperare, ma per nel “general porpouse desktop” hanno fatto passi da gigante; la tattica degli “annunci continui” è un modo per “inseguire”, ma non per stabilizzare. Non discuto che nelle comunità ci sia chi approva questo tipo di approccio, ma, come dirò anche in seguito, da quello che ho potuto provare sul campo, questo approccio ha “più costi, che benefici”.

    3) Onestamente molti utenti non cercano il “bleeding edge”, ma semplicemente cose che funzionino bene, senza troppe complicazioni.

    4) Arch è una rolling distro, praticamente è come se non avesse una release (è sempre in current, ergo non si tagliano mai gli aggiornamenti). E’ un caso estremo di “life time” di una distro.

    Sono fermamente convinto che già cone delle release annuali si migliorerebbe di molto la qualità di certi passaggi, aumenterebbero i tempi di “beta” (o current, o rawhide o unstable o come volete chiamarlo tanto è sempre lo stesso).

    Inoltre, se pensiamo al fattore marketing, sono convinto che le release avrebbero sicuramente più fascino se portassero veramente un grande carico di novità sul piano tecnico e non solo degli “aggiornamenti”. Un po’ come era la differenza una volta tra le “release” x.0 e le subrelease 0.x.

    Non si faccia poi l’errore di confondere il numero delle release con l’aggiornamento dei pacchetti. Si sa bene che è possibile mantenersi aggiornati senza il bisogno di fare nuove release.

    Questo è quello che ho potuto constatare in anni di attivismo sul campo e di contatto diretto con gli utenti. Racconto la realtà che vedo in prima persona, e gli utenti, soprattutto su quelli meno preparati, legati ad una utenza domestica.

    Dato che chi sviluppa le distro non sono dei pirla, e non voglio dire assolutamente questo, hanno fatto delle particolari scelte che, inquadrate nell’ottica del 2005/2006 fino anche al 2008/2009 potevano avere un senso, ma che ora bisogna rendersi conto che ci sono diversi fattori nel mondo GNU/Linux che stanno cambiando, e contestualmente ciò si riflette negli utenti.

    Ovviamente, capisco che molti condividano la posizione delle distro mainline (ed in molti casi lo faccio anche io), ma non su questo punto. Quando raggiungeremo quella che io definisco la “maturità” dei sistemi FOSS, ci renderemo conto che stiamo spendendo molte risorse umane e non solo, per correre dietro ad una idea poco pratica.

    Grazie comunque per aver lasciato il tuo feedback.. non mi ha fatto assolutamente cambiare idea, ma sono sempre convinto che un confronto aperto sulle idee sia sempre auspicabile.

    axjslack

    ottobre 13, 2010 at 1:00 am

  3. Sempre sostenuto che i cicli di sviluppo “a deadline” sono – non solo per progetti come Gnome, che però ne risentono “di meno” – ma soprattutto per una distro, un errore colossale.

    Soprattutto quando da una versione all’altra cambia poco o nulla (versione di Xorg, kernel, ecc.). Oddio, mi pare di essere un eretico a dire che il kernel è “poco o nulla”, ma è vero – se la distro sta usando il kernel come “maintenance”, senza cambiare file system di default, è completamente inutile fare un bump di versione. E’ opportuno magari se si introducono nuove feature come upstart, o se si cambia il sistema di gestione del sonoro da alsa a pulseaudio, ad esempio.
    Ma per un bump di versione di X e Gnome e pacchetti vari? Siamo sicuri che ne valga la pena?

    Visto che si parla di Arch: solitamente ricevo i kernel nuovi (pacchettizzati, ma visto che sono vanilla potrei anche compilarmeli…) molto più velocemente di Ubuntu. Stessa cosa per Xorg e Gnome. Mai avuto (negli ultimi 3 anni) mai la necessità di formattare il sistema / passare alla versione successiva…

    Gianni Vialetto

    novembre 3, 2010 at 3:48 pm

  4. […] in occasione dell’uscita della 10.10, in un mio post su questo blog (il 10/10/2010), avevo accennato come, ad oggi, sia dispersivo ed anacronistico puntare ancora sui […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: