Per Ubuntu aggiornamenti più frequenti da Canonical

[shodan]

Originariamente inviato da riva.dani

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/20...g-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!

[riva.dani]

Ma vi pare, no problem.

[AleLinuxBSD]

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).

[shodan]

Originariamente inviato da AleLinuxBSD

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.

[AleLinuxBSD]

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.

[zappy]

Originariamente inviato da shodan

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.

è 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

[riva.dani]

Originariamente inviato da AleLinuxBSD

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]

Originariamente inviato da AleLinuxBSD

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.

[shodan]

Originariamente inviato da zappy

è 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.

[AleLinuxBSD]

Originariamente inviato da riva.dani

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.

Originariamente inviato da shodan

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.

[shodan]

Originariamente inviato da AleLinuxBSD

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.

[zappy]

Originariamente inviato da shodan

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.

[shodan]

Originariamente inviato da zappy

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

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

Ciao.

[zappy]

Originariamente inviato da shodan

Mmm si, capisco
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