Shuttleworth: cicli di rilasci lunghi sincronizzati

mmmm ... mi sono letto il luuuuungo post di Mark “voglio la concordia universale” Shuttleworth, e devo dire che è un po' meno schematico e rozzo di come lo hai dipinto tu (ovviamente al fine della simpatia nel mondo).
MS nn dimentica, ad es, che KDE 4 ha intervalli di rilascio brevi, ma dice che il grande cambiamento tra kde3 e kde4 nn si sarebbe potuto realizzare con cicli di release brevi, e anzi valorizza il fatto che kde 4.0 ha avuto un supporto molto limitato (in quanto prima release, e pertanto buggata di default ... stesso discorso per python 3)

propone inoltre di unire i cicli (stile LTS) di release di Debian e di ubuntu, chiede un tot di pareri su come chiamare tale cicli, di quanto farli lunghi, vuole stimolare il dibattito su pro e contro del ciclo breve vs lungo (e porta esempi reali x la casistica).

articolo interessante in definitiva, magari nn fa morire dal ridere ma mi è parso molto propositivo, e pertanto mi è molto piaciuto

Beh ovviamente l'intenzione è segnalare l'articolo originale... non vorrei aver dato l'impressione di giudicare Shuttleworth "schematico e rozzo", ma e opzioni sono: a) schematizzare o b) trasformarsi nel traduttore di S., cosa che non mi intriga per niente ;)

Ad ogni modo, non è decisamente la prima volta che prova a proporre la concordia sincronizzata universale, chissà come andrà a finire...

Non ho letto l'articolo ma le sintesi fatte da voi sembrano interessanti.
Vorrei, senza citare esplicitamente alcuna distribuzione e senza entusiasmi dediti al proselitismo, aggiungere che, oltre ai cicli brevi e lunghi... esiste anche la rolling release.
Forse, tra l'altro, è propio una peculiarità del mondo open del tutto estranea ai modelli propietari!

Ne aveva già parlato in passato. L'idea che ha in testa secondo me è che tutte le distro 'non rolling' si adeguino al concetto (e ai tempi) delle LTS di Canonical.

Questo dal punto di vista commerciale darebbe maggiore forza (basta vedere come Dell utilizzi SOLO le LTS sui propri sistemi) ma soprattutto metterebbe ordine all'interno dell'intera comunità e consentirebbe di sincronizzare gli sforzi. Il rilascio di tante piccole novità nelle versioni normali, dedicate + ad utenti appassionati che alle masse, dove tutti sviluppano idee e apportano contributi in modo individuale e invece uno sviluppo condiviso delle scelte dietro alle LTS.

IMHO geniale ma non sarà mai accettato Novell e RH sono troppo grosse per scendere a compromessi e i singoli sviluppatori già altre volte in passato hanno dimostrato di essere troppo 'anarchici'.

Winzozz non può essere considerata una rolling release???
Perchè non creare due grandi conte-repo(contenitori di metapacchetti)
Uno stabile e l'altro di testing.
E sfornare aggiornamenti in rolling release per un anno.
I pacchetti nel repo in testing entrano in quello stable dopo attente valutazioni.
Ogni anno si rilascio una release aggiornata, in modo che uno non deve scaricarsi, appena installata, 1gb di roba.

No, per il semplice fatto che gli aggiornamenti dei singoli programmi non passano da Microsoft, la quale si limita soltanto a fare bug fixing sull'esistente e ad introdurre qualche novità con i service pack.

Per il resto quello che descrivi è una Debian con dei rilasci un po' più rapidi ;)

Omar quello che hai descritto tu è il modo di ragionare delle distro rolling release. Arch fa così...
Secondo me i rilasci a rolling release sono molto meglio ma a quanto pare Mark Shuttleworth non la pensa cosi.
A mio parere è impossibile coordinarsi con Red Hat e Suse, mentre invece dovrebbe concentrarsi per collaborare con Debian(cosa d'altronde anche piu coerente essendo Ubuntu basata su di essa) cosi magari gli da' una smossa e una mano. Va bene che la filosofia di Debian è di essere rilasciata "quando è pronta", ma se il pronto è un po prima è meglio, no?

Secondo me un ciclo di rilascio di sei mesi come quello corrente diluisce troppo le novita' e il clamore davanti a una nuova release di Ubuntu. Non e' il caso di cambiare tutto l'aspetto grafico come fa windows ogni anno, ma sembra di aver fatto l'aggiornamento per nulla, perche' il sistema e' uguale a prima...

...........................................................................................
Dimmi che Jaunty è uguale a Intrepid
...........................................................................................

Rilasci brevi: avere un sistema che è sempre al passo coi tempi.

Windows può permettersi rilasci lunghi perchè non deve far cont con applicazioni che ri aggiornano autonomamente.

Su Ubuntu è diverso: non per niente fino alla relase successiva i pacchetti sono quelli.

L'aggiornamento semestrale permette di includere i pacchetti (su Jaunty OOo3, e via dicendo) che hanno sviluppo veloce e autonomo che sarebbero solamente disponibili solo su vari PPA e così via. Io mi accorgo che a 3-4 mesi dal rilascio di una distro comincio a riempire il mio sources.list di repository alternativi per avere il NON-PLUS-ULTRA delle applicazioni.
.
Debian ha un'altra filosofia, un uscita di 18 mesi è completamete un'altra storia.

io darei fiducia al mastro shuttleworth....

Per me va beh, a patto però di aggiornare un pochino di più i repository ufficiali, senza demandare ogni major update dei pacchetti per la release corrente ai backport. Non dimentichiamo che su Linux a distanza di 3 mesi possono esserci miglioramenti notevoli ad esempio per quanto riguarda driver, supporto hardware, etc.

Insomma il buon Mark si vuole sincronizzare a openSUSE,
l'unica con cicli di sviluppo di 9 mesi.

Veramente no: si parla di due, tre anni.

Il buon Mark (e Debian con lui) sa una cosa molto concreta. Se aspiri al supporto più ampio (anche e soprattutto da terze parti che sviluppano software proprietario) un rallentamento delle major release non costringerebbe a riscrivere driver e applicativi ogni 6 mesi perchè l'ultimissima release di questa o quest'altra libreria impedisce a quel pacchetto (o peggio suite) di lanciarsi correttamente.
E soprattutto quelli che nello sviluppo ci investono milioni di dollari, (penso ad Adobe o Autodesk) potrebbero pure farci un pensiero a rilasciare il loro prodotto pure per il pinguino, sapendo di non doverlo aggiornare, o peggio, riscrivere a intervalli regolari.
Io, molto francamente, mi trovo d'accordo. Non è un gran dramma se mi muoiono le note appiccicose sul desktop, un'altro problema è riscrivere o patchare Maya (tanto per citare un software proprietario che supporta anche il pinguino) perchè, magari, va in conflitto con le ultime librerie grafiche "sbrilluccicose" appena rilasciate.
Del resto lo vediamo tutti i mesi col rilascio dei Driver Ati che vanno ad elastico, fra supporto corretto e regressioni.
Se aspiri al mercato (e Canonical non è l'Opus Dei) ti devi dare una calmata, tanto distro di confine esistono ed esisteranno sempre per tutti quelli che proprio non possono stare senza le ultime glibc...
Poi Mark può chiamarli come vuole i suoi rilasci, ma sotto, sotto...
E,sia chiaro, non ci vedo proprio nulla di male.

Ciao

UN ALTRO: è maschile e io sono ignorante! :P

Queste considerazioni mi sembrano giuste e condivisibili e unite a quelle che fà Arthens confermano la necessità degli snapshot periodici con supporto a lungo termine. Mi piacerebbe una distribuzione flessibili e modulare a tal punto da essere preziosa per tutte le esigenza ma credo anche io come te che probabilmente andremo verso una 'specializzazione' di distro per scopi e esigenze diverse.

fra i commenti al post di MS c'è una proposta interessante, secondo me:
alternare (ogni sei mesi) major releases (focalizzate ad aggiungere features) a minor releases (focalizzate al bugfixing). ogni due anni, si fa coincidere una LTS alla minor releases.
questo consentirebbe di tenere costantemente alto l'interesse, senza perdere l'affidabilità necessaria... la domanda, a quel punto, sarebbe: che senso avrebbero le minor releases? non basterebbero i soliti aggiornamenti settimanali per il bugfixing?

una sorta di service pack. Se l'ultima major è uscita da molto allora per le nuove installazioni usi l'ultima minor

concordo con omar, mi piacerebbe che ubuntu diventasse rolling release, un po alla archlinux... un repo bello stabile e uno testing, chi vuole lo attiva e ha una distro super aggiornata, mentre chi la vuole stabile abilita quel repo...sarebbe fico...IMHO

archlinux non è l'unica a proporre una cosa del genere.
Da un po di tempo anche SabayonLinux, da quando è diventata una rollingrelease, ti da la possibilità di viaggiare con due repo.
Quello officiale, e 2 repo testing(uno a 64 bit e uno a 32-64)
...giusto per la cronaca:-)

a me pare che la soluzione più ragionevole sia un'unica release stabile di 2 anni con soli aggiornamenti di SICUREZZA per le parti vitali (kernel, xorg, gcc..) a fianco di major UPDATES per programmi e utilities sopra l'os (gimp, ooo, gthumb, pidgin, netmanager..gnome?).
una specie di LTS + backports estesi

go debian! ;P

..il problema è che in questo modo il supporto hardware sarà più carente.. se una nuova scheda madre è supportata solo dall'ultima versione del kernel e mi tocca tenermi il kernel di 2 anni fa non è il massimo della vita..

si torna ai tempi di mandrake :/

se invece gli aggiornamenti saranno anche delle parti vitali dell'os come appunto il kernel e le librerie principali tipo libc, glibc, python, etc. su cui si basano le ultime versioni dei software rilasciati allora invece potrebbe andare bene ma sarebbe piu' facile mantenere rilasci ogni 6 mesi e festa finita. O sennò seguire il modello Arch Linux... ovvero rilasci di aggiornamenti costanti (ma testati e stabili) e continua evoluzione con le varie versioni che altro non sono che degli "snapshot"..

ciao

Una release stabile mantenuta per un tempo ragionevole di 2/3 anni apre le porte a scenari inediti, che la tua riflessione non contempla.
Produttori che volessero dotarsi di una distribuzione del genere da allegare insieme alle loro macchine saprebbero che quella piattaforma (di sviluppo) manterrebbe la piena compatibilità con gli applicativi scritti per un ciclo molto superiore ai canonici 6 mesi.
Chiunque volesse estendere il supporto ai propri componenti, scriverebbe driver (anche chiusi) che non necessiterebbero di modifiche sostanziali ogni tot mesi, perchè le API del kernel o di Xorg, vengono rivoluzionate dallo sviluppo continuo e incessante della comunità.
6 mesi sono troppo pochi per captare l'interesse di nuovi sviluppatori e sono sempre troppo pochi per pensare di svilupparci suite professionali e garantire un adeguato supporto.
Come farebbe Adobe ad indagare perchè un ipotetico Photoshop Elements non parte dopo l'aggiornamento del sistema, se l'aggiornamento ha cambiato le carte in tavola per l'ennesima volta in 3 mesi?
Come fai ad ottimizzare le prestazioni, se ogni 6 mesi devi sostanzialmente ricominciare da capo?
Lo sviluppo continuo può indubbiamente portare benefici sulla porzione di codice oggetto di revisione, resta sempre da capire come questi miglioramenti "impattano" su un sistema che è la collezione di tanti altri software che reagiscono ai cambiamenti in modi spesso imprevedibili.
Non sarà certo un caso se, leggevo su Phoronix qualche tempo fa, Ubuntu ha progressivamente perso in performance da una release all'altra.
Da cosa dipende? Maggiore complessità e completezza del sistema? Idiosincrasie fra librerie? Driver non all'altezza dei cambiamenti?
il tempo di venirne a capo, che tutti gli sforzi potrebbero essere vanificati dal rilascio di una nuova release.
Se il tuo obiettivo è provare, provare, provare sempre e comunque quello che passa la comunità, allora hai tutte le ragioni del mondo nel pretendere una distribuzione sempre in movimento, ma se l'utente medio sente solo il bisogno di lavorarci e/o divertisi col suo personal, probabilmente è il caso di non costringerlo a fare da beta-tester ad intervalli regolari.
E' il caso di non costringerlo a vagare di forum e forum perchè la webcam che prima funzionava ha smesso di farlo dopo il cambio del kernel.
Non facciamoci ingannare tutte le volte dall'idea che tanto se funziona internet e il lettore multimediale allora hai coperto l'80% delle attività del sempre fantomatico utente medio.
L'open source può generare nei suoi supporter l'illusione di una "illimitatezza" di risorse che non trova alcun riscontro oggettivo nella realtà.
Il fatto che sia gratis e che potenzialmente può contare sul supporto di tutti, non vuol dire automaticamente che tutti si interesseranno al tuo progetto.
Per qualcuno potrebbe essere semplicemente "strumento per" od "opportunità per".
Parafrasando Eco, per il quale non è vero che tutto può essere messo in relazione con tutto, il fatto che si possa fare, non vuol dire che si debba fare.
Illimitato è un termine privo di significato.
Un progetto senza limiti non approda a niente e rischia di perdere progressivamente il focus sui suoi obiettivi, bruciando semplicemente le sue risorse.
Se hai la velleità di diventare un prodotto di massa e una alternativa credibile per il mercato, devi anche fare delle scelte e decidere cosa mettere dentro e cosa lasciare fuori in attesa di maggiore concretezza.

Ciao

ciao,
in effetti hai ragione.. il tuo ragionamento non fa una piega e lo so bene perche' comunque uso ubuntu anche per lavoro.. anche se da un lato per le esigenze che hai sottolineato vedevo già sufficiente la LTS.

Però è anche vero che potrebbe essere di stimolo a chi scrive software closed. Però in questo caso il problema son gli aggiornamenti delle librerie che "cambiano le carte in tavola" .. in questo senso un problema di linux per il desktop è un po' la volontà di tenere a tutti i costi le librerie linkate dinamicamente..

Voglio dire.. sicuramente molti dei file di base di windows son immutati da molti anni però convivono tranquillamente librerie con runtime vecchissime insieme a librerie piu' nuove etc. perche' si tiene sempre conto della retrocompatibilità (anche a discapito delle prestazioni) cosa che in linux accade meno..

Il punto che mi preoccupa maggiormente sono i driver. se prendi ad esempio le tavolette grafiche.. dipendono sia dai driver video che dal supporto di Xorg stesso.. e solo ultimamente si installano con meno problemi.. quindi e' importante avere non solo i driver ed il kernel aggiornati ma anche Xorg e cosi' via per supportare l'hardware nuovo.. però appunto se da un lato supporti cose nuove o migliori le prestazioni dall'altro rischi di rompere la compatibilità con quei programmi che hanno bisogno di esser ricompilati per funzionare.

Per fortuna ultimamente han inserito nel kernel la possibilità di non dover ricompilare ogni volta i moduli ad ogni aggiornamento del kernel (se non sbaglio) proprio per agevolare i produttori di hardware a rilasciare driver propri anche closed..

ciao

ubuntu stable;
ubuntu testing;
ubuntu unstable.

mi ricorda qualcosa che inizia per d e finisce per ..ebian! (:

Leggendo questo post e i commenti stò in parte rispondendo ed in parte mi sorgono altre domande. Leggerò anche il post di MS perchè la questione posta mi sembra interessante e merita approfondimenti.

Dal punto di vista dell'utente desktop, la scelta di una distribuzione rolling release la capisco bene anche perchè è la mia.
Capisco molto bene dal punto di vista aministratore server la scelta di una LTS.

Mi chiedo, non retoricamente:
- Perchè un utente dovrebbe preferire una distro ad aggiornamenti di 6, 9 o 1 anno ecc..
- Cosa comporta in termini di differenze di lavoro per un gruppo di mantainer di una distro la scelta rolling rispetto agli aggiornamenti periodici? E che differenza c'è, da questo punto di vista, tra brevi e lunghi?
- Ci sono risvolti politico-economici rispetto a queste scelte? Quali sono i vantaggi e svantaggi di una 'sincronizzazione tra distribuzioni? E tra distro e DE?

Caro Stefano, la risposta alla domanda "Perchè un utente dovrebbe preferire una distro ad aggiornamenti di 6, 9 o 1 anno ecc" è molto molto semplice:
_STABILITA'_

Le rolling release sono una figata (sono un mezzo utente archlinux), ma non stabili quanto un rilascio fisso.
Ad esempio io sul laptop che uso per lavorare ho ancora installata Ubuntu 8.04 e non credo la aggiornerò a breve... il motivo è semplicemente che non posso permettermi che qualche imprevisto mi faccia perdere ore prezione. La versione che ho installato funziona bene, mi permette di lavorare senza perdere tempo... per quale motivo dovrei voler provare le nuove versioni dei programmi?

Discorso diverso è per il computer che uso per il tempo libero. In quel caso uso archlinux, perchè se anche dopo un aggiornamento non mi funziona più l'audio (come è successo un paio di settimane fa) o non mi trovo bene con una nuova versione del software... chissene frega, mica ci perdo dei soldi.

Se ubuntu diventasse una rolling release probabilmente passerei ad un'altra distribuzione, per il computer che utilizzo per lavoro.

OK. Mi sono reso conto subito dopo (vedi post sotto) che vedevo la cosa in modo parziale. Quello che sostieni mi torna... ma giusto per provocazione ti butto là un paio di considerazioni:

- Tra un dist-upgrade ogni 6 mesi e un quotidiano pacman -Syu ognuno sceglie quello che preferisce e che gli mette meno ansia. Uno può scegliere di continuare ad usare il pc senza fare nulla. Tra l'altro ho avuto il tuo stesso identico problema. Propio perchè ho scelto e preferisco usare il secondo ho potuto isolare meglio e risolvere in fretta. La stabilità dipende molto dall'uso che se ne fà.
- A volte mi sembra che per risolvere un dolore al ginocchio ci amputiamo la gamba! Un sistema di snapshot (immagini disco) collegato al gestore di pacchetti progettato per essere facile e bello stile TimeMachine? Ci consentirebbe di avere allo stesso tempo un sistema aggiornato e 'stabile' (o sicuro!) senza perdite di tempo e/o lauree in informatica applicata.

Dopo aver letto il post e i commenti, più che le risposte alle domande che mi ponevo prima, mi rimane molto entusiasmo per un bellissimo e molto significativo esempio di quello che amo dell'open source. Forse sarò ingenuo ed illuso ma sento nel tono e nei contenuti del post un sincero, onesto, fiducioso e ambizioso tentativo di fare crescere una comunità di individui e organizzazioni. Ci sono delle vere considerazioni 'a voce alta' e domande aperte tese a raccogliere altri pareri per farne davvero tesoro e, considerando chi le pone, prendere delle decisioni di conseguenza. Fantastico. Grazie Felipe della segnalazione.

Sono così entusiasta del metodo che nel merito mi vengono di getto solo poche considerazioni che partono, mi rendo conto, solo dall'esperienza da utente, e ancano totalmente di quella da sviluppatore/mantainer:
- Specialmente uno dei commenti mi ha ricordato che quando ero responsabile IT di un'azienda di soli 10 postazioni/utenti quello che cercavo non era, come con il mio attuale desktop di casa, il 'bleading edge' ma stabilità e supporto. Figurati in aziende con più utenti!
- Insisterei sul Rolling release con l'adozione di 'Tag' o forse meglio degli 'Snapshot' dei repository, a cadenze 'tendenzialmente' regolari di 2 anni con LTS a 4 anni.
- Per LTS sceglierei, quando possibile, l'ultima release prima di una major upgrade (es. KDE 3.9). Solo una situazione a lungo debuggata e consolidata offre quella garanzia di distabilità di cui sopra.

Tutto questo perché le distro gnu/linux maggiori, sono maturate abbastanza. Fino ad ora i rilasci brevi sono serviti a far crescere velocemente un prodotto che fosse realmente usabile da tutti introducendo sempre golose novità ma anche bug e difetti dovuti dalla "fretta". Allo stato attuale un "rallentamento" permetterà di evitare errori grossolani al passaggio da una version all'altra e di concentrarsi sui bugfix, ora più necessari che mai. Ok. Concordo e mi auguro che Ubuntu, RH e SuSe collaborino per un maggiore passaggio di codice tra loro. E perché no? anche Mandriva (chi ha k3b_orecchie per capire capisca ^^)...

Sono tendenzialmente d'accordo con Arthens e Stefano, con le dovute eccezioni.
Ci sono momenti in cui una politica troppo rigida può creare problemi agli utenti soprattutto in termini di driver o di applicazioni per internet come i browser ecc.. dove il non stare al passo con "i tempi" può rendere inutilizzabili alcuni servizi o costringere ad un più "rischioso" upgrade.

Forse bisognerebbe creare una sorta di struttura organizzata a strati, con la possibilità di upgradare (o all'occorrenza downgradare) solo certe componenti.
cya