Fedora 11 in ritardo: causa, sintomo e cura.
In News il 20/05 @ 15:43 trackback
A causa di una manciata di problemi in attesa di essere sistemati, il rilascio di Fedora 11 sarà ritardato di una settimana.
Una cosa simile accadde per Ubuntu 6.06: rilasciata a giugno invece che aprile. Oggi come allora la cosa mi fa pensare per due motivi1 : il primo è che qualcuno non troverà di meglio da fare che criticare Fedora per l’attesa protratta, il secondo è che non riesco a non pensare che i rilasci a scadenza fissa sono solo un limite arbitrario e un po’ superato che ci siamo auto-imposti anni fa quando i principali progetti avevano altri numeri e altri tempi.
Per dire, senza questa isteria magari non avremmo Ubuntu 9.10 alpha1 che funziona meglio di Jaunty, che nonostante sia splendida ci ha fatto fare qualche figuraccia.
|
|
— Note all'articolo:
- Che poi sono le due medaglie della stessa faccia …eh? [↩]
— Pagine forse correlate:
Commenti »
“Esce quando è pronta.”
Un esempio da imitare?
Direi di si, o rolling, o release con un “senso”,
non rilasciate “a muzzo” tanto per rispettare una data che nessuno hai mai imposto.
E dovrebbe valere anche per gnome kde eccetera.
Faccio bene io allora a restare con Fedora :-)
In realtà non è un “Esce quando è pronta”, semplicemente quelli di fedora hanno adottato il metodo degli stoppers, ovvero bug che devono essere risolti per poter rilasciare la release. Lo stesso metodo lo usa pure OpenOffice.
il problema è più complesso e avendo spesso a che fare con programmatori, sistemisti e tecnici vari so bene che non dare scadenze fisse e rigide significa non ottenere quello che si vuole.
Provate a chiedere a uno sviluppatore di completare un lavoro entro 2 settimane beh fino a 3 giorni prima della scadenza non farà una mazza per poi correre come un pazzo nei 3 giorni rimanenti. Non avere obblighi e imposizioni da parte di 'dirigenti' porta ad avere migliaia di programmi messi male. La comunità dietro a gnome è forse l'unica che sviuppa in modo decente software seguendo la politica dei piccoli passi.
Quel che dici è vero in parte: se da un lato i rilasci a scadenza fissa risultano essere un limite nello sviluppo (vedi Intrepid rilasciato senza Openoffice 3 o hardy rilasciato con la beta di Firefox 3), d'altra parte l'avere un obiettivo per gli sviluppatori è un qualcosa di utile per ottenere dei risultati ottimali.
Penso infatti che senza un obiettivo ci sono due rischi:
1) rallentamenti perchè un essere umano senza un obiettivo.. se la prende comoda ;)
2) beta continue (manco fossimo google :P), dato che per uno sviuppatore è + divertente la fase di sviluppo che quella di debug
La soluzione, secondo me, dovrebbe essere quella di avere dei rilasci a scadenza fissa flessibile (1-2 mesi al max di flessibilità) in modo da potersi prolungare quando risulta necessario.
Ritengo che questo sia un buon compromesso.
I programmatori hanno una scadenza, e quindi non se la prendono comoda… e si evitano le figuracce… :-)
La quantità di bug (sia in Fedora, che in Ubuntu, che in altre distro) non è legata tanto al fatto del rilascio “fisso”, quando piuttosto ad una scelta deliberata di adottare nuove tecnologie, in barba ai rischi che queste comportano. Questo porta a far maturare più rapidamente le nuove tecnologie forzando (io credo consciamente) gli utenti a diventare dei costanti beta tester, ma porta ad indispettirne degli altri.
Nonostante il manipolo di indispettiti (che hanno tutto il diritto di esserlo) io sono dell'opinione che così com'è Linux non è adatto all'uso su tutti i desktop e pertanto meglio qualche figuraccia adesso che siamo in pochi che avere una roba antiquata che fra qualche anno, sebbene stabile, non sarà più in grado di reggere il passo degli altri a livello di tecnologie.
I driver Intel al momento faranno pure schifo, ma introducono tutta una serie di novità che promettono faville nel prossimo futuro.
D'altronde nessuno vi ha chiesto di fare l'upgrade all'ultima versione. Potevate benissimo usare Slackware, CentOS, Debian o Ubuntu LTS…
Sul “d'altronde nessuno” avrei da ridire, basta leggere ogni annuncio di nuovo rilascio di qualsiasi progetto :D
Secondo me le applicazioni desktop devono essere rilasciate appena sono pronte, mentre kernel e driver DOVREBBERO essere rilasciati quando sono sufficientemente stabili e senza ALCUNA REGRESSIONE.
Purtroppo di regressioni sia di funzionalità che di prestazioni ce ne sono stati. Ne cito 2 che mi hanno toccato e sono tuttora irrisolte (per completezza):
Radeon 4850: https://bugs.launchpad.net/ubuntu/+source/fglrx...
P5Q Audio: https://bugs.launchpad.net/ubuntu/+source/alsa-...
Scheda Ethernet: https://bugs.launchpad.net/ubuntu/+source/netwo...
..e menomale che sono versioni cosidette “stabili”!
Allineandomi con barra ed Antonio Mangiameli volevo però aggiungere altre osservazioni.
Non c'è dubbio che il rilascio forzato a scadenze cicliche prestabilite, come siamo stati abituati negli ultimi anni, ha la conseguenza che se si fa il passo più lungo della gamba si rischia di rilasciare un softwareprodotto non pienamente rodato e quindi potenzialmente pieno di bug.
In tutto questo però c'è da dire ed osservare una cosa,
le distribuzioni non sono una entità che sviluppa per conto proprio l'intero sistema (DE, kernel, browser, librerie fondamentali, etc… etc…) ma sono degli assemblatori che cercano di combinare tecnologie opensource, per lo più indipendenti l'une dalle altre e dalla stessa distribuzione, nel migliore dei modi, magari portando (e condividendo poi) migliorie, innovazioni, etc…
Quindi, prendendo per esempio come parametro Gnome, se questo non avesse una tabella certa con date certe dei cicli di rilascio, le varie distribuzioni si troverebbero in una situazione dove si correrebbe il rischio di rilasciare un prodotto assemblato da componenti già superate e magari mal supportate da chi li ha prodotti.
I cicli di rilascio invece danno la possibilità a chi assembla una distribuzione di poter programmare il lavoro.Ed a maggior ragione proprio in questo momento dove Linux sta suscitando l'interesse di alcune case produttrici di hardware. Senza una tabella di marcia certa e sicura non puoi dare certo garanzie a questi.
Quindi la situazione è molto più amplia e complessa. In un mondo ideale sarebbe bello avere dei prodotti quando sono pronti ma in un contesto attuale è molto difficoltoso.
Magari, la butto li, creare una sorta di mega consorzio dei principali progetti dove decidere una sorta di tabella di marcia comune o comunque orientativa…ma anche questa situazione è abbastanza opinabile e con ovvie ragioni.
Personalmente credo che al momento la migliore soluzione è quella che una volta che un prodotto ha raggiunto la sua maturazione o meglio che le sue parti fondamentali siano state completate, andare avanti di cicli in cicli con tempistica certa.
Il mondo GNULinux è fatto di varie componenti indipendenti che se legate ad arte l'una con le altre danno una prodotto finito eccellente ed altamente competitivo.
Il rovescio di questa medaglia è il rischio di avere progetti slegati in termini di innavazione…quello che serve è trovare sinergie che fanno si che non si creino sbilanciamenti eccessivi…al momento l'unica soluzione è quella di avere cicli certi di rilascio.
Lo so…e Debian allora? Slackware? Infatti loro hanno il rovescio della medaglia di non essere distribuzioni vendibili…che poi siano delle rocce e non ti lascino mai a piedi è un altro discorso ma di certo non sono adatte all'utente, chiamiamolo, normale.
giuseppe
sono assolutamente daccordo
Ovviamente non mi riferivo a fedora, ma a un “concetto” ben noto.
Cavolo un pò di elasticità mentale, vai oltre il “titolo” e il “naso” …
lol, questo articolo mi fa sorridere perchè uso debian… in particolare, mi ricordo di quando abbiamo organizzato una festa per il rilascio di debian etch, dopo 3 anni di ritardi… :)
Vale sempre la massima “se qualcuno vi dice di buttarvi da un ponte…”.
Quanta gente ha veramente detto “WOW” quando ha provato Vista? Una cosa è il marketing, un'altra la realtà… la prima volta che trovo una pubblicità che dice: “il nostro prodotto fa schifo, ma noi almeno abbiamo l'onestà di dirvelo in faccia” giuro che quel prodotto lo compro!
Come sempre bisogna pensare con la propria testa, chi non lo fa (per pigrizia o altro motivo) deve anche essere pronto a pagarne le conseguenze.
Macché «limite arbitrario autoimposto»! Ma siamo matti? Una comunità di sviluppatori non vuol dire necessariamente «facciamo le cose per la gloria, quindi lasciateci tutto il tempo che vogliamo!», c’è un ciclo di sviluppo dietro, ci sono determinati passi di processo da seguire e tutti limitati da un preciso tempo e milestone!
Scusatemi, ma questi discorsi in cerca di sensazionalismo non sapendo come funzionano veramente le cose mi stanno un po’ qui… E non è il fatto di opinioni o non opinioni, lo sviluppo di una qualsiasi applicazione segue dei determinati formalismi e questo vale per le grandi società che anche per i team di sviluppo di Fedora, Ubuntu e tutti gli altri. A mio avviso è irrispettoso nei loro confronti dire che «ehi non preoccuparti ti lasciamo un po’ di tempo in più, mica abbiamo fretta», perché loro ci mettono impegno e tempo in quello che fanno e come programmatori sanno che le deadline sono importanti, non raggiungere uno scopo entro un certo periodo per loro non è piacevole.
Ma poi come si fa a dire che è un «limite superato»? Cosa diamine vuol dire? Lo sviluppo e il ciclo produttivo del software è qualcosa di superato? Ma sappiamo qui di cosa stiamo parlando, o ci piace tanto fare articoli pensando di dire qualcosa di sensato e razionale?
Si però è giusto aspettarsi che una nuova release (di qualsiasi cosa) sia meglio di quella precedente. Per questo motivo chi ha i driver intel che fanno la moviola si indispettisce, cosiì come si indispettì chi provò vista due anni fa
Sembra di sentire le criteche a Microsoft.
“Installo dopo l'uscita della SP1. E' piu' sicuro”
E' un discorso che non ha senso, ne' se mi chiamo Microsoft, ne' se mi chiamo Canonical o KDE.
Se rilascio una versione stabile questa deve essere considerata stabile e l'aggiornamento consigliato.
Ehi ok: la pensiamo in maniera differente, però non ti agitare :'D
Si vede che non ne capisci eh… dovresti limitarti a fare guide e renderti conto che non ci sono solo “bimbominkia” a leggere blog. Non puoi fare l'opinionista se non conosci la metà delle cose di cui parli, tanto per capirci :'D
ehm, non era una critica!! Ho solo preso lo spunto per parlare di una metodologia interessante. :)
Ci sono tanti modi per esprimere dissenso, stai scegliendo il più sterile. Se vuoi argomentare civilmente posso tentare di farti capire :)
si, ma ci vorrebbe anche un modo per imporre, ad un certo punto, che certi bug millenari diventino stopper. Infatti questo è un buon metodo ma può esser truffato non accettando determinati bug. Magari per le distro non è un grosso problema, ma per OpenOffice ci sono bug storici!!!
In effetti vorrei gli stopper per kde e per (k)ubuntu (che senso ha farla uscire con knetworkmanager o pulse non funzionante?)
Non è così semplice, la corsa alla nuova release è dovuta spesso all'assenza di importanti feature in quella precedente. L'esempio dei driver video è magistrale.
Anch'io sono un programmatore, e so qual'è l'importanza di avere delle scadenze. Però se per rispettare le date previste mi trovassi 1/3 dei clienti con il pc inservibile, dovrei passare un pomeriggio in ginocchio sui ceci. Ci vuole buon senso nelle cose, il danno d'immagine subito è considerevole. In questo caso la situazione è abbastanza grave. I problemi erano noti ed andavano gestiti meglio. Così, invece, ci sono utenti che hanno da scegliere tra
1. Installare un kernel e/o driver diversi, con risultati incerti. Ridicolo.
2. Fare l'upgrade all'alpha 1. Ridicolo.
3. Downgrade alla 8.10. Ridicolo.
E dire che sono un utente Ubuntu dalla 6.06 e difendo quasi quotidianamente questa distribuzione dagli attacchi che le vengono rivolti da utenti di altre distibuzioni… Ma Ubuntu se ne esce con una cosa veramente indifendibile. Imho avevano due opzioni possibili, fare un passo indietro con le future e lasciare il kernel della 8.10, oppure attendere qualche settimana e rilasciare la 9.04 con il kernel 2.6.30. Entrambe le soluzioni non avrebbe causato tutto questo casino.
non si parlava di fedora qui?
non capisco se sei un fanboy delle distro linux, o semplicemente ti è andata male la giornata…qual'è il tuo problema amico?
nessuno ti obbliga ad aggiornare, purtroppo non tutto l'hardware è testabile pertanto è bene informarsi su cosa si sta facendo e magari provare un livecd prima di aggiornare..
Rolling forever XD
PS. questo sito sta diventando pesantissimo!
Beh io nn farei tante polemiche su questo ritardo di fedora..ok,sicuramente non è proprio il massimo della professionalità ritardare il rilascio di un progetto,ma sinceramente preferisco avere un prodotto finale pronto ed efficiente piuttosto che avere “immediatamente” un prodotto finale pieno di regressioni ed evidenti problemi architetturali..
Ubuntu 9.04 purtroppo è l'esempio lampante di quanto sia stata accantonata questa filosofia di sviluppo..Il sottoscritto ha dovuto fare un upgrade forzato alla alpha 1 della karmic pur di avere i propri driver video intel funzionare “decentemente”!
Ok ok,è un procedura per certi versi anche ammissibile,ma poi nn ci lamentiamo se gli utonti vedono il mondo linux come un mondo ancora fin troppo immaturo..Loro nn si sognerebbero mai di fare un “update-manager -d”! XD
cito: “Ma poi come si fa a dire che è un «limite superato»? Cosa diamine vuol dire? Lo sviluppo e il ciclo produttivo del software è qualcosa di superato? Ma sappiamo qui di cosa stiamo parlando, o ci piace tanto fare articoli pensando di dire qualcosa di sensato e razionale?”
Vuol dire che è utilizzato male, molto male. Forse non avrai avuto problemi, ma io ad ogni versione nuova di Ubuntu, è uno stillicidio di problemi. Xorg che non va, Radeon HD = problemi certi, ad ogni release. Il rilascio a tempo non deve diventare onanismo puro, altrimenti succede che poi, per perdere tempo a risolvere i problemi, preferisco stare su Vista64, e tanti saluti. Ormai è da una release e più che ubuntu lo accendo solo per passatempo.
Il rilascio a tempo non è una buona scusa per non risolvere i problemi, che siano colpa tua o meno, non mi interessa, e non deve interessarmi, ma se la versione prima funzionava, beh, in quella successiva non ci devono essere regressioni.
Altrimenti ciao..
Io non rilascio mica il mio software quando è scaduto il limite, se ci sono problemi, dicendo “Li risolvo domani…” Pensa alla felicità del cliente…
non tutto si può provare col livecd e non tutte le regressioni sono scritte
Da un punto organizzativo avere la data di consegna è sempre un bene. Si ha modo di pianificare tutto lo sviluppo del progetto e delineare una tabella di marcia da rispettare poi con, possibilmente, un margine di errore ridotto all'osso.
Sono d'accordo cmq con il ritardare la data di rilascio di qualche tempo se il sistema presenta dei bugs. Anche se, per ipotesi, li risolvessero in 1-2 giorni dal rilascio della cosiddetta “stabile” la frustrazione e il malcontento degli utenti e il passaparola (parolaccia?) sul web porterebbe ad un danno d'immagine della distribuzione.
Detto questo, sono sempre più dell'idea che l'ideale (per molti, non per tutti) sia la rolling-release (e lo dico usando Kubuntu). Nel momento in cui un nuovo pacchetto è stato testato e viene definito stabile può tranquillamente ad andare ad aggiornare quello vecchio senza problemi. Sarebbe bene se il tempo di testing del pacchetto non fosse però nè quasi nullo come in Archlinux nè biblico come in Debian.
Consideriamo poi che alla fine la maggior parte dell'utenza aggiorna ad una nuova release della propria distribuzione solo per avere la nuova versione del DE e poco altro. Con una rolling-release si potrebbero rendere più o meno subito disponibili queste feauteres e con calma, mai troppa, gli sviluppatori potrebbero lavorare al resto da un'intregrazione decente di pulseaudio fino ai vari ritocchi alle gui e ai tool (se parliamo di distribuzioni semplici) per migliorare l'usabilità.
Mi auguro che quest'ultima versione di fedora sia di mio gradimento…
cosa non si può provare col livecd? mica siamo su windows..le regressioni, se documentate dai tester, sono scritte..altrimenti siamo al solito punto: non tutto l'hardware è testabile e nessuno obbliga ad aggiornare.
Aggiungo un'altra massima allora: “chi abbandona la strada vecchia per la nuova…”.
Aspettarsi che per magia vada sempre tutto bene è un po' pretenzioso visto come funziona al momento attuale l'ecosistema Linux…
Fedora ha supporto 13 mesi, Ubuntu normale 18 mesi.
Nessuna persona comprerebbe mai un sistema operativo che “scade” dopo meno di un anno e mezzo. Chi li usa, per quanto siano belle le parole che spende chi rilascia queste versioni, è implicitamente (e in varia misura) un beta tester.
Mettiamoci nell'ordine di idee che Linux non è ancora per le masse: nessuna altra categoria di utenti di sistemi operativi è abituata (né dovrebbe esserlo) ad aggiornare molto frequentemente.
Il nome Nerone è un'ottima scelta per “flammare” gli animi in questo modo!… :)
le versioni tls hanno un supporto piu' lungo e si rivolgono ad utenze aziendali.
I rilasci programmati sono molto utili in alcuni casi, sono di impiccio per altrettanti.
La ragione alla base della pianificazione è la stessa di sempre: aiutare ad organizzarsi il tempo sapendo che ci sono delle scadenze da rispettare. Per me “fissare una data” è fondamentale per tutti i progetti coordinati (gnome, kde ad esempio) che contengono altrettanti pezzi, sviluppati da persone diverse. Pensate cosa succederebbe se gnome non avesse una pianificazione: a marzo, prima di rilasciare la nuova versione, se ne esce il maintainer di nautilus che ha bisogno di un'altra settimana per aggiungere la super-feature-mega-figata-innovativa, poi uno sviluppatore di un altro programma gnome, e non è più finita… quali sono i software che hanno la possibilità di far slittare la data e quali no? una data pianificata garantisce equità fra tutti i software di quel progetto.
La data pianificata deve essere praticamente incontestabile, altrimenti tornano i problemi di nautilus o meno di poco sopra.
Nel caso di distribuzioni invece, che devono mettere insieme programmi e software che giustamente non sono sincronizzati fra di loro (gnome nuovo, xorg con i driver più veloci, kde, il nuovo kernel che supporta la nuova scheda wifi…), è bene che le date siano elastiche: non è possibile imporre una scadenza a tutti i software, e allo stesso tempo è quasi sempre meglio aspettare un po' di più per aggiungere la versione sistemata di un software piuttosto che rilasciare alla svelta (ubuntu insegna con i suoi rilasci quasi mai esenti da cazzate).
Vero, ma dopo l'abbuffata di nuove funzionalità adesso è il turno di un po' di alleggerimento ;)
Concordo specialmente con la distinzione tra software e distribuzioni
> D'altronde nessuno vi ha chiesto di fare l'upgrade all'ultima versione.
> Potevate benissimo usare Slackware, CentOS, Debian o Ubuntu LTS…
> Ubuntu normale 18 mesi.
Infatti già 3 anni di supporto è molto più accettabile. D'altro canto già il kernel 2.6.24 inizia già a sentire il peso dell'età… alcune schede wireless o webcam richiedono kernel più nuovi e non sempre il pacchetto kernel-backport è in grado di sopperire a tutto.
Insomma il supporto all'hardware recente costringe implicitamente ad avere un kernel recente, avere un kernel recente richiede una distribuzione recente. E aggiornare frequentemente il proprio OS non è una cosa produttiva. Insomma, una cane che si morde la coda…
Una volta si preferiva inserire qualcosa leggermente piu' vecchia ma stabile, nelle “stable” piuttosto che nuova o instabile. cio' da un po' non lo fanno piu' neanche alla canonical, dove vantano “synaptic” come IL mezzo per l'aggiornamento. Oggi, checchè ne dicano, corrono al momento del rilascio, pur di rilasciare, includono versioni instabili o non ottimizzate di componenti , pur di non sviluppare polemiche tipo “possibile che dalla precedente ad adesso non è cambiato nulla????”, spacciandole per stabili…
In una distro a rilasci regolari, la responsabilita' è relativamente dei vari team di sviluppo, rispetto alla mancanza di buonsenso degli “assemblatori”, come ho piacevolmente letto qualche post fa
per la legge dei grandi numeri, dato che le distro sono “raccoglitori” di software nati da progetti indipendenti in modo che possano interoperare correttamente, prima o poi uscirà una distro 100% compatibile con sè stessa, coi suoi aggiornamenti e con l'hardware (quindi i driver) su cui gira.
fino alla prossima release s'intende.
[...] Fedora 11 salire anziche’ scendere. E quindi non posso che essere d’accordo con Felipe quando afferma che il modello a rilasci fissi sia quantomeno imperfetto. Insomma, tutto sommato mi piace [...]