Link alla notizia: http://www.hwfiles.it/news/per-ubuntu-aggiornamenti-piu-frequenti-da-canonical_34539.html

Canonical vuole rivedere la cadenza con la quale distribuisce gli aggiornamenti per Ubunte: l'attuale ciclo di aggiornamenti ogni 6 mesi non pare più adeguato

Click sul link per visualizzare la notizia.

Piu' conosco Ubuntu e meno mi piace. Il peggio di un ambiente Windows Style, il peggio dell'open source..penso che cambierò distribuzione.

il mondo è bello perchè è vario

io invece, dopo aver provato tre o quattro diverse distribuzioni di linux, sono approdato ad ubuntu e mi trovo benissimo pur dovendo sempre conoscere ed usare windows in tutte le versioni per motivi di lavoro

Anche a me è capitato di usare Windows per lavoro, fortunatamente posso scegliere. Delle altre distro che ho provato, mi son trovato particolarmente bene con Open Suse, un buon compromesso tra qualità di documentazione, allineamento alle ultime novità e soprattutto stabilità.
Mi sono rotto di fare il beta tester per Canonical.

Premetto che scrivo da una Ubuntu 10.04 LTS x86_64, man anche per me non ci siamo.

Penso che già allo stato attuale le versioni XX.10 vadano considerate poco più che beta: ad esempio, l'attuale 10.10 non permette di scrivere su share Windows file più grandi di 48KB (per un problema di GVFS). Appena uscita, GIMP crashava non appena si provava a fare un'anteprima del salvataggio di un'immagine JPEG. E via dicendo...

Quindi, piuttosto che pensare a maggiore frequenza di rilascio di nuove release, io penserei a allungare il tempo di rilascio (ne basta una l'anno), ma testandola per bene. Le XX.04 ad esempio in genere sono decisamente più stabili, e le LTS sono dei piccoli gioielli.

Non è che Fedora sia meglio eh, anzi... non avendo versioni LTS il loro ciclio di rilascio mi piace ancora meno.

Spero che le intenzioni di Canonical siano in realtà non quelle di avvicinare tra loro il rilascio di nuove versioni, ma solo quello di offrire più tempestivamente aggiornamenti di sicurezza per i pacchetti installati... altrimenti tanto vale creare un branch rolling-release (tipo debian sid) e via...

Ovviamente è solo la mia opinione eh... non voglio creare flame.

Ciao. :)

Premetto che scrivo da una Ubuntu 10.04 LTS x86_64, ma anche per me non ci siamo.
....
Quindi, piuttosto che pensare a maggiore frequenza di rilascio di nuove release, io penserei a allungare il tempo di rilascio (ne basta una l'anno), ma testandola per bene.

assolutamente d'accordo.
ogni 6 mesi vengono sostituiti i programmi anzichè concentrarsi sul loro miglioramento.
Come si fa a pensare di diffondersi se l'utente deve continuamente reimparare da capo il funzionamento dei sw, afflitto per di più da sempre nuovi bug?

Canonical e l'intera comunità opensource dovrebbero meditare attentamente sul perchè XP continua ad avere un immenso successo su Vista e 7 nonostante abbia 10 ANNI sul groppone. Forse perchè MS ha deciso di stravolgere la GUI e mettersi a seguire proprio linux?

Quindi, piuttosto che pensare a maggiore frequenza di rilascio di nuove release, io penserei a allungare il tempo di rilascio (ne basta una l'anno), ma testandola per bene. Le XX.04 ad esempio in genere sono decisamente più stabili, e le LTS sono dei piccoli gioielli.
Quoto. Meglio una all'anno o anche una ogni due anni ma testata bene. Anche perché una distro non diventa certo obsoleta dopo appena sei mesi...

Piu' conosco Ubuntu e meno mi piace. Il peggio di un ambiente Windows Style, il peggio dell'open source..penso che cambierò distribuzione.

Non si capisce bene cosa vuoi dire... Nonostante ciò, trovo ancora più approssimativo l'articolo rispetto al tuo commento... Gli utenti Ubuntu già oggi ricevono aggiornamenti quotidianamente (non è certo Canonical a rilasciare i bug fix, anche critici, una volta al mese...). Semplicemente Mark ha dichiarato che, nei prossimi 5 anni, lui e il suo team lavoreranno affinchè Ubuntu possa diventare una rolling-release (stile Arch) anzichè rilasciare una nuova versione ogni 6 mesi:
Today we have a six-month release cycle, in an internet-oriented world, we need to be able to release something every day. That’s an area we will put a lot of work into in the next five years. The small steps we are putting in to the Software Center today, they will go further and faster than people might have envisioned in the past.
Chi non sa cos'è una rolling-release può leggere su Wikipedia: http://en.wikipedia.org/wiki/Rolling_release

In pratica, non sarà più necessario ogni 6 mesi scaricare una nuova ISO e fare l'aggiornamento, ma avverrà tutto via repository. Ipoteticamente, aggiornando giorno per giorno i programmi man mano che sono pronte le nuove versioni, chi attualmente ha una 10.10 arriverebbe, ad Aprile 2011, ad avere tutti i pacchetti aggiornati alla versione 11.04, senza bisogno di scaricare la ISO per aggiornarli tutti in blocco. Tutto qui. ;)

Tra l'altro la situazione odierna non è tanto distante. Credo che un po' tutti aggiungano repo esterni per avere i programmi aggiornati. Ad esempio, se domani uscisse Firefox 4 stabile, credo sarebbero in pochi a rimanere a Firefox 3.6, che è la versione inclusa in Ubuntu 10.10, aspettando una nuova versione di Ubuntu che lo includa di default...

Premetto che scrivo da una Ubuntu 10.04 LTS x86_64, man anche per me non ci siamo.

Penso che già allo stato attuale le versioni XX.10 vadano considerate poco più che beta: ad esempio, l'attuale 10.10 non permette di scrivere su share Windows file più grandi di 48KB (per un problema di GVFS). Appena uscita, GIMP crashava non appena si provava a fare un'anteprima del salvataggio di un'immagine JPEG. E via dicendo...

Quindi, piuttosto che pensare a maggiore frequenza di rilascio di nuove release, io penserei a allungare il tempo di rilascio (ne basta una l'anno), ma testandola per bene. Le XX.04 ad esempio in genere sono decisamente più stabili, e le LTS sono dei piccoli gioielli.

Non è che Fedora sia meglio eh, anzi... non avendo versioni LTS il loro ciclio di rilascio mi piace ancora meno.

Spero che le intenzioni di Canonical siano in realtà non quelle di avvicinare tra loro il rilascio di nuove versioni, ma solo quello di offrire più tempestivamente aggiornamenti di sicurezza per i pacchetti installati... altrimenti tanto vale creare un branch rolling-release (tipo debian sid) e via...

Ovviamente è solo la mia opinione eh... non voglio creare flame.

Ciao. :)

Credo sia proprio per questo che Ubuntu voglia passare ad un approccio rolling. Da quanto ho capito, le LTS verrebbero mantenute. Ma tra una LTS e l'altra, anzichè prevedere rilasci prestabiliti ogni 6 mesi, chi abiliterà i repository "rolling" ci arriverà mediante aggiornamenti graduali. Questo è più o meno quanto avviene con Arch già oggi. Credo ci guadagnerebbero anche in immagine, proprio perchè anzichè dire "questa versione di Ubuntu sembra una beta ed è buggata" si dirà "questo nuovo pacchetto è poco più di una beta, meglio se rimanete con quello vecchio". Non si tratta di aumentare il ritmo dei rilasci, si tratta di dividere gli utenti tra chi vuole una LTS (e allora disabiliterà i repo "instabili"), e chi vuole sempre l'ultima novità, e allora è inutile farlo aspettare 6 mesi...

My 2 cents. ;)

PS: Ad esempio di Arch dicono:
Arch Linux adopera un sistema a "rolling release" che funziona più o meno in questo modo: abbiamo sempre due versioni del nostro set di pacchetti "core", Current e Release. Il repository Current contiene sempre l'ultimissima versione dei pacchetti. Non appena un pacchetto viene aggiornato fa parte del repository Current, e così questo è il repository che dovete seguire se volete rimanere molto aggiornati. Il repository Release segue i rilasci ("snapshot") semiregolari e non viene aggiornato fino a quando il successivo snapshot/ISO non venga rilasciato. Per esempio, il repository Release conterrà i pacchetti presenti nell'ISO della versione 0.5 fino a quando non sarà rilasciata la 0.6; in quel momento conterrà i pacchetti della 0.6 fino al rilascio della 0.7. Questo risulta utile se intendete aggiornare il sistema solo quando una nuova release di Arch Linux è disponibile.
Credo sarà qualcosa di simile...

Concordo sul punto di vista espresso secondo cui le .10 siano in effetti versioni sperimentali utili allo studio su ampia scala delle problematiche.
L'unica di queste a piacermi fu la 7.10 Gutsy Gibbon.

Se si esclude la 8.04 che includeva un firefox 3 beta come browser (poi fu refreschata), le LTS sono ottime release. La 10.04 mi è piaciuta moltissimo (non parlo di Kubuntu perchè KDE non riesce mai a soddisfarmi nonostante gli dia sempre moltissime possibilità perchè potenzialmente è migliore di gnome, ma è come se avesse il freno a mano tirato, e regna un po' di disordine).

@riva.dani
Intendo dire che è perfettamente inutile regalare tante caratteristiche in piu' rispetto alle tradizionali distro Linux per poi pagare il tutto in un sistema instabile. L'utente Linux (quello di vecchia data) preferisce meno cose ma perfettamente funzionanti, per intenderci stile Debian.
A sto punto per scegliere una distro che scimmiotta Windows, tanto vale optare per l'originale e buonanotte al secchio.

Non è che Fedora sia meglio eh, anzi... non avendo versioni LTS il loro ciclio di rilascio mi piace ancora meno.

Le versioni LTS di Canonical sono un po' aleatorie: 4 anni di supporto, ma senza backport di features, con solo bugfixing e patch di sicurezza. Se prendo l'attuale 10.04 LTS che ha un kernel vecchio di 4 release è facile trovare qualcosa di non supportato OGGI, figuriamoci tra 2 anni.

Con Fedora hai vantaggi e svantaggi: durante il ciclo di vita delle releases supportate (12 mesi) hai comunque sempre disponibili le ultime versioni stabili dei programmi ed anche il kernel può cambiare di versione (2.6.33>2.6.34).
In più hai il vantaggio di poter usare preupgrade per un SICURO salto ad una nuova release, se interessati a farlo.

Credo sia proprio per questo che Ubuntu voglia passare ad un approccio rolling. Da quanto ho capito, le LTS verrebbero mantenute. Ma tra una LTS e l'altra, anzichè prevedere rilasci prestabiliti ogni 6 mesi, chi abiliterà i repository "rolling" ci arriverà mediante aggiornamenti graduali. Questo è più o meno quanto avviene con Arch già oggi. Credo ci guadagnerebbero anche in immagine, proprio perchè anzichè dire "questa versione di Ubuntu sembra una beta ed è buggata" si dirà "questo nuovo pacchetto è poco più di una beta, meglio se rimanete con quello vecchio". Non si tratta di aumentare il ritmo dei rilasci, si tratta di dividere gli utenti tra chi vuole una LTS (e allora disabiliterà i repo "instabili"), e chi vuole sempre l'ultima novità, e allora è inutile farlo aspettare 6 mesi...

My 2 cents. ;)

PS: Ad esempio di Arch dicono:

Credo sarà qualcosa di simile...

Ah ecco, quindi puntano a una versione rolling release, come immaginavo (dall'articolo non si capiva bene).

Allora ci può stare, ma l'importante è che sia una cosa abilitabile / disabilitabile a piacimento. Personalmente, pur avendole utilizzate per molto tempo, tengo ora a evitare le rolling release: dato che uso Linux non solo a casa ma anche al lavoro, la stabilità di sistema (intesa anche come propensione dei normali programmi al crash) è un requisito fondamentale.

Ciao. :)

Le versioni LTS di Canonical sono un po' aleatorie: 4 anni di supporto, ma senza backport di features, con solo bugfixing e patch di sicurezza. Se prendo l'attuale 10.04 LTS che ha un kernel vecchio di 4 release è facile trovare qualcosa di non supportato OGGI, figuriamoci tra 2 anni.

Con Fedora hai vantaggi e svantaggi: durante il ciclo di vita delle releases supportate (12 mesi) hai comunque sempre disponibili le ultime versioni stabili dei programmi ed anche il kernel può cambiare di versione (2.6.33>2.6.34).
In più hai il vantaggio di poter usare preupgrade per un SICURO salto ad una nuova release, se interessati a farlo.

Vero, infatti non volevo dire che il ciclo di aggiornamento di Ubuntu sia meglio di quello Fedora o viceversa.

Comunque, personalmente preferisco rimanere con gil stessi programmi + bugfix che non avere backport o avanzamenti che possono comunque "rompere" la compatibilità con qualcos'altro.

Ciao. :)

Per fortuna che c'è Debian.

Ah ecco, quindi puntano a una versione rolling release, come immaginavo (dall'articolo non si capiva bene).

Allora ci può stare, ma l'importante è che sia una cosa abilitabile / disabilitabile a piacimento. Personalmente, pur avendole utilizzate per molto tempo, tengo ora a evitare le rolling release: dato che uso Linux non solo a casa ma anche al lavoro, la stabilità di sistema (intesa anche come propensione dei normali programmi al crash) è un requisito fondamentale.

Ciao. :)

Si può disabilitare dal gestore aggiornamenti qualsiasi cosa, al limite tieni solo gli aggiornamenti per i bugfix.

Secondo voi perchè Ubuntu è la distro più diffusa in assoluto?

@riva.dani
Intendo dire che è perfettamente inutile regalare tante caratteristiche in piu' rispetto alle tradizionali distro Linux per poi pagare il tutto in un sistema instabile. L'utente Linux (quello di vecchia data) preferisce meno cose ma perfettamente funzionanti, per intenderci stile Debian.
A sto punto per scegliere una distro che scimmiotta Windows, tanto vale optare per l'originale e buonanotte al secchio.

Capito. Il fatto è che puoi benissimo tenerti una LTS con solo i repo di default, e allora avrai per le mani una roccia!

Comunque, la notizia è già stata smentita:
Ubuntu is not changing to a rolling release. We are confident that our customers, partners, and the FLOSS ecosystem are well served by our current release cadence. What the article was probably referring to was the possibility of making it easier for developers to use cutting edge versions of certain software packages on Ubuntu. This is a wide-ranging project that we will continue to pursue through our normal planning processes.

...

I do like the idea of making it easier for developer and enthusiasts to use daily builds of software that they really care about, and maybe even have them discover this capability through the software center. Currently you have to find PPAs or maybe activate backports to do this. But having a stable release with a six month cadence plus the option to stay cutting edge on certain packags (at your own risk) is not really a rolling release.

Fonte: http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-moving-to-rolling-release.html

Cioè Mark intendeva solo dire che, visto che molti utenti amano avere le ultimissime versioni dei software, quelli di Ubuntu lavoreranno per rendere più facile l'utilizzo di versioni instabili dei programmi a chi lo desidera.

Tutte queste novita' sono sorprendenti per i nuovi utenti di linux, chi usa questi sistemi da tempo sa' che c'e' debian sid che viene aggiornata quotidianamente e si usa sulle workstations / portatili da 10 anni senza particolari esplosioni.

Mi sono rotto di fare il beta tester per Canonical.
Faceva cosi schifo tenere la LTS?

Grazie mille riva.dani per aver (doppiamente) chiarito la situazione. Fra la notizia e i commenti, le informazioni stavano diventando estremamente fuorvianti. :)

Capito. Il fatto è che puoi benissimo tenerti una LTS con solo i repo di default, e allora avrai per le mani una roccia!

Comunque, la notizia è già stata smentita:

Fonte: http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-moving-to-rolling-release.html

Cioè Mark intendeva solo dire che, visto che molti utenti amano avere le ultimissime versioni dei software, quelli di Ubuntu lavoreranno per rendere più facile l'utilizzo di versioni instabili dei programmi a chi lo desidera.

Ah ok, allora tutto a posto :)

Grazie della segnalazione! ;)

Ma vi pare, no problem. ;)

Io credo da tempo che il tallone d'Achille per potere avere in un'unico sistema le ultime versioni senza possibili problemi di stablità sia dato dall'abbondanza d'uso di librerie condivise, considerando che da diversi anni la capacità degli hdd è molto grande, sarebbe possibile fare diversamente.
Così, male che vada, il problema sarebbe limitato solo ai programmi di questo tipo, senza correre rischi di comortamenti strani da parte di altri applicativi che fino ad un momento prima non avevano problemi.
Mentre l'idea che mi sono fatto che si insiste nel cercare di puntellare un qualcosa di fragile.

Nota:
Per il resto, con i PPA, mi pare che già sia possibile avere software più aggiornato (anche se questo non evita possibili problemi con il resto del sistema).

Io credo da tempo che il tallone d'Achille per potere avere in un'unico sistema le ultime versioni senza possibili problemi di stablità sia dato dall'abbondanza d'uso di librerie condivise, considerando che da diversi anni la capacità degli hdd è molto grande, sarebbe possibile fare diversamente.
Così, male che vada, il problema sarebbe limitato solo ai programmi di questo tipo, senza correre rischi di comortamenti strani da parte di altri applicativi che fino ad un momento prima non avevano problemi.
Mentre l'idea che mi sono fatto che si insiste nel cercare di puntellare un qualcosa di fragile.

Nota:
Per il resto, con i PPA, mi pare che già sia possibile avere software più aggiornato (anche se questo non evita possibili problemi con il resto del sistema).

Mha, non penso che tornare al software monolitico (tutto compilato all'interno dell'eseguibile) possa risolvere il problema. Le librerie condivise sono una bella comodità: se c'è un errore in una libreria, lo correggi una volta e tutti i programmi che linkano quella libreria sarebbero "magicamente" corretti.

Io penso che il problema stia nell'approccio che gli sviluppatori hanno verso il software che loro stessi scrivono: spesso non si fanno scrupoli a mandare alle ortiche la retrocompatibilità e amano reinventare millemila volte soluzioni allo stesso problema, facendo poi pochissimo testing.

Faccio un paio di esempi: devfs e pulseaudio. Il primo doveva correggere la classica "staticità" dei device in /dev. Il risultato è che fu prima sviluppato devfs, messo in mainline, adottato da tutti e poi, di punto in bianco, puf -> deprecato. Si passa a udev, con doppio hook (nel kernel e in userspace, con un demone apposta), Ora il sistema funziona discretamente, e giustamente (?!?!) leggevo che si pensa di rimpiazzarlo con un altro.

Altro esempio: pulseaudio, che doveva fornire servizi audio avanzati per singola applicazione. Bella idea, ma dato che è stato adottato sia da ubuntu che da fedora quando le applicazioni non erano pronte, molte di essere non avevano più output sonoro! Lo stesso sviluppatore di pulseaudio lo descrisse come "the software that break your audio".

E potrei continuare, citanto DRI/DRI2/GEM, oppure il sistema di avvio dei servizi (upstart) o ancora gli spash screen grafici realizzati mentre il sistema carica (attualmente plymount via KMS, ma ce ne sono stati tanti in passato).

Insomma, a me pare manchi un po' di organizzazione...
Ciao. :)

shodan tu hai evidenziato un'altro punto dolente che tuttavia è un po' intrinseco nel sistema non centralizzato open-source, a cui sarebbe possibile rimediare se le distribuzioni principali si mettessero d'accordo su certi standard.

Riguardo al problema accennato, più che all'uso di un'unico eseguibile con tutte le librerie statiche, pensavo all'uso di librerie dinamiche, però messe nella stessa directory dove è installato il programma.

Concettualmente l'idea di avere librerie condivise ha diversi vantaggi, la correzione di un'errore vale per tutti, minore occupazione di spazio ma l'uso di librerie più recenti, meno testate oppure in fase di testing, comporta pure la propogazione d'errori, i più insidiosi dei quali sono quelli che rimangono invisibili.

Mha, non penso che tornare al software monolitico (tutto compilato all'interno dell'eseguibile) possa risolvere il problema. Le librerie condivise sono una bella comodità: se c'è un errore in una libreria, lo correggi una volta e tutti i programmi che linkano quella libreria sarebbero "magicamente" corretti.

Io penso che il problema stia nell'approccio che gli sviluppatori hanno verso il software che loro stessi scrivono: spesso non si fanno scrupoli a mandare alle ortiche la retrocompatibilità e amano reinventare millemila volte soluzioni allo stesso problema, facendo poi pochissimo testing.

Faccio un paio di esempi: devfs e pulseaudio. Il primo doveva correggere la classica "staticità" dei device in /dev. Il risultato è che fu prima sviluppato devfs, messo in mainline, adottato da tutti e poi, di punto in bianco, puf -> deprecato. Si passa a udev, con doppio hook (nel kernel e in userspace, con un demone apposta), Ora il sistema funziona discretamente, e giustamente (?!?!) leggevo che si pensa di rimpiazzarlo con un altro.

Altro esempio: pulseaudio, che doveva fornire servizi audio avanzati per singola applicazione. Bella idea, ma dato che è stato adottato sia da ubuntu che da fedora quando le applicazioni non erano pronte, molte di essere non avevano più output sonoro! Lo stesso sviluppatore di pulseaudio lo descrisse come "the software that break your audio".

E potrei continuare, citanto DRI/DRI2/GEM, oppure il sistema di avvio dei servizi (upstart) o ancora gli spash screen grafici realizzati mentre il sistema carica (attualmente plymount via KMS, ma ce ne sono stati tanti in passato).

Insomma, a me pare manchi un po' di organizzazione...
Ciao. :)

:doh:
è un po' il discorso che facevo io a proposito della GUI (scusate, ma al livello dei casini "sotto il cofano" io non arrivo).
Questo rifare sempre tutto da capo e non concludere mai nulla è il motivo principale per cui l'opensource non funziona come dovrebbe.

Giustamente, tu parli di organizzazione (ed io aggiungo linee guida sensate ed univoche) mancante.
La mia sensazione è che i singoli progetti "forti" (gimp, OO, vlc e qualche altro) funzionano perchè c'è un migliore coordinamento.
VLC lo trovo migliorato di vers in vers
OO lo installo ma preferisco grandemente MSoffice che è molto meglio
gimp continua ad avere quella cazzo d'interfaccia idiota che tutto il mondo detesta
FF non lo uso ne lo installo
TB mi sembra sia fatto per essere detestato dagli ex utenti di OE, ed è pieno di dettagli sommamente idioti... lo sto usando ma lo detesto.
gnome lo trovo invece ondulatorio ed anche regressivo.
kde4 (4.4 x la verità) lo trovo ancora un po' buggato.

forse i progetti troppo grandi (desk environnement) o troppo "partecipati" (FF, TB) soffrono proprio di troppe teste e poca organizzazione

shodan tu hai evidenziato un'altro punto dolente che tuttavia è un po' intrinseco nel sistema non centralizzato open-source, a cui sarebbe possibile rimediare se le distribuzioni principali si mettessero d'accordo su certi standard.

Riguardo al problema accennato, più che all'uso di un'unico eseguibile con tutte le librerie statiche, pensavo all'uso di librerie dinamiche, però messe nella stessa directory dove è installato il programma.

Concettualmente l'idea di avere librerie condivise ha diversi vantaggi, la correzione di un'errore vale per tutti, minore occupazione di spazio ma l'uso di librerie più recenti, meno testate oppure in fase di testing, comporta pure la propogazione d'errori, i più insidiosi dei quali sono quelli che rimangono invisibili.

Io sono d'accordo con shodan. Non è che siccome lo spazio su disco c'è allora la distro debba prenderselo tutto. Il fatto di avere librerie condivise ha molti vantaggi, alcuni dei quali elencati anche da te, ai quali non rinuncerei. Inoltre la propagazione degli errori, come la chiami tu, peggiorerebbe se ogni app avesse la sua cartella con le librerie che le servono. E poi, chi manterrebbe tali librerie? Lo sviluppatore del programma? Invece, l'uso di un unico file all'interno del quale sono presenti, oltre all'eseguibile del programma, tutte le librerie del caso è una strada che si sta già battendo. Lo si sta sfruttando soprattutto per i classici programmi avviabili da chiavetta USB, molto diffusi su Win. Ma io sarei favorevole a questo approccio anche per testare software instabile. Così ad esempio uno potrebbe provare Firefox 4 beta con un doppio click, senza toccare nulla dell'installazione di Firefox 3.6 stabile che ha sul PC. Ripeto, lo si sta già facendo, tuttavia questo non risolverebbe i problemi segnalati da shodan.

shodan tu hai evidenziato un'altro punto dolente che tuttavia è un po' intrinseco nel sistema non centralizzato open-source, a cui sarebbe possibile rimediare se le distribuzioni principali si mettessero d'accordo su certi standard.

Riguardo al problema accennato, più che all'uso di un'unico eseguibile con tutte le librerie statiche, pensavo all'uso di librerie dinamiche, però messe nella stessa directory dove è installato il programma.

Concettualmente l'idea di avere librerie condivise ha diversi vantaggi, la correzione di un'errore vale per tutti, minore occupazione di spazio ma l'uso di librerie più recenti, meno testate oppure in fase di testing, comporta pure la propogazione d'errori, i più insidiosi dei quali sono quelli che rimangono invisibili.

Ciao,
quello che dici è in teoria già possibile: basta che l'applicazione imposti la variabile d'ambiente LD_LIBRARY_PATH e a quel punto può leggere le librerie da dove vuole.

Il punto è che usare questo tipo di approccio estesamente (librerie personali per ogni applicazione) è, a mio avviso giustamente, evitato quando possibile. Faccio un esempio. immagina di avere una libreria per la codifica JPEG con un bug grave che dia possibilità di buffer overflow. Se la libreria di decodifica è condivisa per tutto il sistema, basta correggerla una sola volta. In caso contrario, bisognerà fare la correzione per ogni versione della libreria, usata a sua volta da ogni differente programma -> caos totale.

Anche perchè, in quest'ultimo caso, chi sarebbe il responsabile della libreria? Il team che c'è dietro il progetto della libreria o quello che ne esegue il fork per il proprio programma? E se le modifiche della libreria sono state tanto profonde da rendere non applicabile la patch così com'è? Come vedi ci sarebbero delle belle gatte da pelare...

Non voglio dire che l'approccio di mettere delle librerie nella directory del programma non sia mai utilizzato: a volte lo si fa per caricare vecchie versioni di librerie, senza per questo doverle installare sistem-wide. Però in genere si evita...

Ciao. :)

:doh:
è un po' il discorso che facevo io a proposito della GUI (scusate, ma al livello dei casini "sotto il cofano" io non arrivo).
Questo rifare sempre tutto da capo e non concludere mai nulla è il motivo principale per cui l'opensource non funziona come dovrebbe.

Giustamente, tu parli di organizzazione (ed io aggiungo linee guida sensate ed univoche) mancante.
La mia sensazione è che i singoli progetti "forti" (gimp, OO, vlc e qualche altro) funzionano perchè c'è un migliore coordinamento.
VLC lo trovo migliorato di vers in vers
OO lo installo ma preferisco grandemente MSoffice che è molto meglio
gimp continua ad avere quella cazzo d'interfaccia idiota che tutto il mondo detesta
FF non lo uso ne lo installo
TB mi sembra sia fatto per essere detestato dagli ex utenti di OE, ed è pieno di dettagli sommamente idioti... lo sto usando ma lo detesto.
gnome lo trovo invece ondulatorio ed anche regressivo.
kde4 (4.4 x la verità) lo trovo ancora un po' buggato.

forse i progetti troppo grandi (desk environnement) o troppo "partecipati" (FF, TB) soffrono proprio di troppe teste e poca organizzazione

Sicuramente per i progetti più importanti c'è un coordinamento migliore.
In tal senso GNOME mi sembra meglio organizzato di KDE, così come le componenti core kernel vengono gestite in maniera eccellente.

Sarebbe bello però avere coordinazione e una pianificazione precisa su un po' su tutti i progetti...

Ciao. :)

ad esempio uno potrebbe provare Firefox 4 beta con un doppio click, senza toccare nulla dell'installazione di Firefox 3.6 stabile che ha sul PC. Ripeto, lo si sta già facendo, tuttavia questo non risolverebbe i problemi segnalati da shodan.
Firefox è uno dei pochi programmi portabili, disponibili pure per linux, che segue l'approcio a cui accennavo in precedenza.
Ti prendi il file da mozilla, scompatti tutto all'interno di una certella, e funziona tranquillamente senza toccare niente del sistema.;)

Ciao,
Il punto è che usare questo tipo di approccio estesamente (librerie personali per ogni applicazione) è, a mio avviso giustamente, evitato quando possibile. Faccio un esempio. immagina di avere una libreria per la codifica JPEG con un bug grave che dia possibilità di buffer overflow. Se la libreria di decodifica è condivisa per tutto il sistema, basta correggerla una sola volta. In caso contrario, bisognerà fare la correzione per ogni versione della libreria, usata a sua volta da ogni differente programma -> caos totale.

Si potrebbe attenuare in parte il problema usando questo approccio solo per programmi in fase di testing.
E veramente seccante dovere aggiornare un sistema operativo perché alcuni versioni di programmi non sono disponibili in una certa versione della distro e non è possibile metterli perché gli strumenti di sviluppo non sono sufficientemente recenti.
Es. un gimp in vers. portabile (quindi pre-compilata) come accade con firefox (tutto scompattato in una unica directory), per me sarebbe una bella cosa.

Firefox è uno dei pochi programmi portabili, disponibili pure per linux, che segue l'approcio a cui accennavo in precedenza.
Ti prendi il file da mozilla, scompatti tutto all'interno di una certella, e funziona tranquillamente senza toccare niente del sistema.;)


Si potrebbe attenuare in parte il problema usando questo approccio solo per programmi in fase di testing.
E veramente seccante dovere aggiornare un sistema operativo perché alcuni versioni di programmi non sono disponibili in una certa versione della distro e non è possibile metterli perché gli strumenti di sviluppo non sono sufficientemente recenti.
Es. un gimp in vers. portabile (quindi pre-compilata) come accade con firefox (tutto scompattato in una unica directory), per me sarebbe una bella cosa.

Bhe si, diciamo che come versione alternativa potrebbe essere un'idea, almeno per i programmi più diffusi.

Un deploy su larga scala però lo vedo problematico...

Ciao. :)

Sicuramente per i progetti più importanti c'è un coordinamento migliore.
In tal senso GNOME mi sembra meglio organizzato di KDE, così come le componenti core kernel vengono gestite in maniera eccellente.

Sarebbe bello però avere coordinazione e una pianificazione precisa su un po' su tutti i progetti...

Ciao. :)

di gnome detesto il fatto che le modifiche siano applicate al volo. E' un approccio molto pericoloso e che molto spesso determina problemi quando ci sono vari sw che controllano gli stessi parametri (tipo config. di compiz: basta aprire uno dei 10000 tool che configurano "qualcosa", anche solo per vedere che opzioni ha, e ti ritrovi delle modifiche fatte contro la tua volontà).
inoltre nautilus è molto poco efficace.

di gnome detesto il fatto che le modifiche siano applicate al volo. E' un approccio molto pericoloso e che molto spesso determina problemi quando ci sono vari sw che controllano gli stessi parametri (tipo config. di compiz: basta aprire uno dei 10000 tool che configurano "qualcosa", anche solo per vedere che opzioni ha, e ti ritrovi delle modifiche fatte contro la tua volontà).
inoltre nautilus è molto poco efficace.

Mmm si, capisco :p

Però direi che quello è più un problema di design che di coordinamento nello sviluppo. ;)

Ciao. :)

Mmm si, capisco :p
Però direi che quello è più un problema di design che di coordinamento nello sviluppo. ;)
Ciao. :)

beh, si. vero :)
ma il mettere e togliere opzioni, anzichè migliorare il funzionamento, è un problema di coordinamento :)