Ubuntu: Shuttleworth dà spunti sul ciclo di sviluppo

Mark-Shuttleworth

Mentre la tempesta Mir sembra abbia concesso qualche giorno di bonaccia, Mark Shuttleworh torna a parlare della seconda grande questione che interessa Ubuntu e i suoi utenti: rolling release o no?

L’articolo di Shuttleworth, che potete leggere integralmente nel suo blog, sembra aprire qualche spiraglio e propone soluzioni interessanti per mantenere allo stesso tempo i vantaggi del modello LTS attuale e la possibilità di avere software sempre aggiornato.

Il punto fondamentale della questione gira attorno ad un concetto molto semplice: separare il software dal core del sistema. Risolvere così l’annosa questione che costringe a scegliere fra software datato e stabile e software aggiornato ma pronto ad abbandonarci dietro l’angolo. Il fondatore di Canonical a tale proposito propone tre punti per le prossime release.

Il primo riguarda proprio le LTS. L’idea è di permettere aggiornamenti opzionali per numerosi parti del lato applicativo del sistema lasciando inalterata la base (ad eccezione di un opzionale aggiornamento del kernel). In pratica avremo la possibilità di aggiornare alle ultime major release per tutte le applicazioni (similmente a come succede ora per Firefox), permettere l’ingresso delle ultime versioni del kernel (pur mantenendo il supporto ai kernel precedenti) e l’aggiornamento di pezzi importanti del sistema a patto che non rompano le API con la versione precedente. Un caso concreto per questi punti riguarda ad esempio la versione di Unity presente in Ubuntu 12.04. Tale versione è notoriamente più lenta e meno performante di quella che troveremo installata in Ubuntu 13.04 ma gli utenti della LTS si troveranno costretti ad utilizzarla ancora per un anno. Questo punto si propone come soluzione al problema.

Il secondo punto riguarda le cosiddette release intermedie. Qui la soluzione è semplice e consiste nel ridurre il supporto per queste versioni da 18 a 7 mesi. Questo permetterà di snellire il processo di development dirottando risorse allo sviluppo della nuova release piuttosto che a supportare versioni che, da sempre, sono minoritarie all’interno degli utenti di Ubuntu.

Ultimo punto: considerare la versione in sviluppo come se fosse una rolling release. Il nuovo modello di testing (il Daily Quality) sembra stia dando ottimi risultati e la versione di sviluppo (come possono confermare coloro i quali hanno provato la 13.04) non soffre quasi mai di grosse regressioni e raggiunge picchi di stabilità persino superiori ad Ubuntu 12.10. A questo punto basterebbe un piccolo sforzo ulteriore per rendere tale versione una rolling-release a tutti gli effetti. Mark propone infatti di cambiare il nome degli archivi di tale versione o in modo tale che non sia più necessario “aggiornare” per rimanere sul ramo di sviluppo in modo simile a come accade per Sid nel mondo Debian.

Le proposte sono interessanti e vengono in contro alle richieste degli utenti che da anni chiedono un cambiamento nel ciclo di sviluppo a 6 mesi tipico di Ubuntu.

Tag: ,

Commenti

  1. [1]

    Spunti interessanti? Uno pseudo half-rolling sarebbe uno spunto interessante?
    A me sembrano gli ennesimi sproloqui di uno in perenne fattanza.
    .
    Ma possibile che questi “geni” non capiscano che le relase SEMESTRALI non servono a niente ad un sistema operativo che punta al desktop domestico e al settore enterprise?
    .
    Di tutti i miei amici che usano Ubuntu a casa, NON CE N’È UNO che formatta ogni sei mesi per aggiornare alla ultima release.
    Alla gente comune interessa che i programmi per ritoccare la foto fatta ad una festa, i programmi per visualizzare tale foto, il lettore multimediale ed il browser FUNZIONINO sempre. A questa gente non interessa formattare per avere l’ultimissima versione della distro che se non passano almeno due mesi dal rilascio, c’è da buttarla nel cesso per i bug, frutto di una politica scellerata che mette al primo posto il rispetto di date di rilascio fatte a caz*o invece della qualità.
    .
    Quello che oggi SERVE davvero è:
    - Fase di sviluppo costantemente rolling e bleeding-edge, da EVITARE come la peste in produzione;
    - Rilascio STABILE ogni due anni (ma senza cadenza programmata), mantenuto per cinque anni con possibilità di prolungarlo fino ad un mnassimo di altri DIECI, previo pagamento di un supporto tecnico, per clienti enterprise (soprattutto lato server);
    .
    Ogni sei mesi si rilascia un minor upgrade (ad es. XX.YY.1, XX.YY.2 ecc….cosa che avviene nelle attuali LTS) che porti bugfix, backport se fondamentali (come qualche driver più recente) e miglioramenti prestazionali.
    .
    STOP
    Non serve altro.
    Per farla breve, il rilascio LTS non dovrebbe essere un aggiunta, ma lo STANDARD.

  2. [2]

    non vedo come questi spunti possano portare a separare le applicazioni dal core
    come al solito si parla di aria fritta

  3. [3]

    Che poi se una nuova lib rompe le api, basta cambiare il soname e può coesistere con la vecchia ed ogni soft userà quella corretta.

  4. [4]

    “non vedo come questi spunti possano portare a separare le applicazioni dal core”
    Infatti NON parlano di quello i 3 punti, ma di come intercettare il desiderio degli utenti di un sistema simil rolling. Per riuscirci serve separare la parte core dalle applicazioni.
    Come al solito si parla senza aver capito. Anzi, a giudicare dai commenti precedenti della stessa persona è ovvio che ha capito ma scrive giusto per innescare inutili polemiche.

  5. [5]

    “non vedo come questi spunti possano portare a separare le applicazioni dal core”
    Infatti NON si parla di quello. Si parla di realizzare il desiderio di molti utenti di avere una distro simil-rolling e per riuscirci serve separare le applicazioni dalla parte core; hai letteralmente invertito il fine e il mezzo.
    .
    Come al solito c’è qualcuno che non legge bene e non capisce.
    Anzi, a giudicare dai precedenti commenti della stessa persona sembra plausibile che faccia apposta a seminare zizzania sul nulla. Strano che quando si parla di un argomento che non interessare i primi a commentare siano sempre ma sempre i troll…

  6. [6]

    @atomix600:

    Non ci avevo mai pensato, ma devo dire che non sarebbe male come idea di sviluppo!

  7. [7]

    @atomix600
    hai descritto grosso modo il modello di rilascio di RedHat, con RHEL che anzi è supportato fino a 13 anni e con la “rolling release sconsigliata per gli ambienti di produzione” che si chiama rawhide. ;-)

  8. [8]

    ahahah saggia decisione

    rolling release: per i fissati dell’ultima novità a tutti i costi
    rilasci semestrali: per tutti quelli che comunque vogliono il sistema aggiornato
    LTS: per tutti quelli che non vogliono rogne (incluso io)

  9. [9]

    L’idea sembra interessante, bisogna solo vedere se e come verrà messa in pratica.

    L’unica certezza è che l’attuale politica dei rilasci intermedi di Ubuntu è fallimentare…

  10. [10]

    “Infatti NON si parla di quello. Si parla di realizzare il desiderio di molti utenti di avere una distro simil-rolling e per riuscirci serve separare le applicazioni dalla parte core; hai letteralmente invertito il fine e il mezzo.”
    I sogni son desideri…di felicità…
    Quelle di Shuttleworth sono l’ennesime sparate ad capzum, sulla stessa onda dei 200 milioni di utenti.
    Solo chi non sa nulla di Unix/Linux può cascarci su questi proclami da quattro soldi.
    Quello che lui dice non è TECNICAMENTE possibile a meno che non si fa un freeze di componenti VITALI come la libc o si va di pacchetti statici.
    Questo pseudo-modello si chiama half-rolling ed è quello che usa FreeBSD con i ports: applicazioni sempre aggiornate su un core stabile.
    È fattibile su Linux? NO.
    Non lo è perché per fare una cosa del genere, bisognerebbe mantenere un tree apposito del kernel e dello userland, per svilupparli in maniera propria.
    Cosa che Canonical non fa, visto che prende i contributi in upstream di Debian e che non potrebbe fare, visto che non è nelle condizioni per farlo.
    .
    I primi a commentare potranno anche essere troll, ma di sicuro sanno di cosa parlano.

  11. [11]

    @atomix600
    Sanno di cosa parlano?
    http://www.oneopensource.it/05/03/2013/ubuntu-14-04-unity-next-nuova-interfaccia-di-ubuntu-in-qt-e-qml/#comment-138684
    Secondo te uno che scrive commenti come fosse in astinenza da Xanax sa di cosa parla? Oppure spara la prima c@cchiata che pensa e qualche volta becca il bersaglio per caso? :D

  12. [12]

    @atomix600 Seriamente invece, perchè per te non è possibile un modello half-rolling di quel tipo? Chakra, Arch e altre disto rolling o semi-rolling non sembrano utopie.

  13. [13]

    @abba
    Perchè non è possibile fare ciò che fa FreeBSD?
    Uno dei problemi di Linux che sono imputati dagli utenti è il concetto di dipendenza e di compilazione dinamica.
    Se da un lato, infatti, ne benefici in termini di memoria è evidente che dall’altro ti obbliga a rimanere con una versione specifica della libreria, a meno di hack particolari (compilazioni statiche delle versioni successive o installazioni in PATH differenti con conseguente aggiustamento delle variabili LDFLAGS, CFLAGS e CXXFLAGS in compilazione. E ti posso assicurare che quest’ultima soluzione è un caos immondo che non si può nemmeno immaginare).
    .
    Oltre a questo c’è da dire che le distro GNU/Linux non sono un OS integrale come FreeBSD, ma un insieme di prodotti presi da altri e mantenuti separatamente, con tempistiche differenti e modi di sviluppo differenti.
    Ciò implica che un aggiornamento della libc, potrebbe portare alla rottura di moltissime applicazioni.
    Idem l’aggiornamento di un kernel.
    Anche il solo aggiornare il compilatore può portare a pesanti conseguenze (incongruenze con versioni diverse di libgcc_s.so.1 ad esempio).
    Quando tempo fa parlai dell’API breakage di Linux, il riferimento era anche a questo.
    Su FreeBSD kernel e userland sono sviluppati nello stesso tree con uguali tempistiche.
    Di conseguenza, è molto più facile mantenere aggiornato il tree di applicazioni di terze parti.
    Anzi, puoi persino aggiornare da una minor release all’altra senza ricompilare nulla (eccetto i driver, anche se puoi usare comunque gli stessi senza problemi).
    .
    Su Arch non ti è mai capitato di risolvere a mano potenziali problemi (come ad esempio la directory /lib durante il merge di /usr), come indicato sulle “note di rilascio” dei vari aggiornamenti?
    Arch ha un target differente.
    Non è paragonabile con Ubuntu.
    .
    .
    Chakra, tra l’altro è un pessimo esempio di half-rolling. Mezzi pacchetti statici (bundle) e mezzi dinamici.

  14. [14]

    Ti faccio un esempio più chiaro, in modo da farti capire meglio cosa voglio dire.
    .
    Dall’articolo:
    “Il primo riguarda proprio le LTS. L’idea è di permettere aggiornamenti opzionali per numerosi parti del lato applicativo del sistema lasciando inalterata la base (ad eccezione di un opzionale aggiornamento del kernel).”
    .
    Ora già da questo capisci che è impossibile.
    Il lato applicativo molte volte richiede aggiornamenti del core.
    Ad esempio: mplayer ha bisogno per alcune funzioni importanti del GCC 4.6+.
    Mettiamo il caso che Ubuntu LTS abbia GCC 4.4. Come fai ad aggiornare il lato applicativo senza toccare il core? Non puoi.
    .
    Allora l’unica soluzione che ti rimane è: passare al modello di Mac OS X.
    Le applicazioni di terze parti le distribuisci staticamente ed il core lo mantieni come ti pare e piace.
    In quel caso la situazione diventa molto meno caotica.
    Unity lo sviluppi in casa, quindi lo puoi adattare facilmente alla distribuzione.
    E tutti i software di terze parti, essendo bundle statici possono essere usati senza problemi.
    .
    Ovviamente le applicazioni saranno di dimensioni mastodontiche, ma almeno funzioneranno sempre e comunque.
    .
    Chiaro ora? :)

  15. [15]

    Chiunque sia il prossimo DPL, personalmente vorrei mettesse nero su bianco le risposte alle seguenti.

    1. In casa Fedora è in atto una “semplificazione” del Filesystem Hierarchy Standard: pensi anche tu che le cartelle /bin, /usr/bin, /sbin, /usr/sbin, /lib, /usr/lib, /lib64, /usr/lib64, /opt, pur sottendendo una logica pulita e ferrea, siano troppe?

    2. Allo stato attuale Debian è “ferma” ad un boot di tipo sysv, dependency based: quali saranno le scelte future? Credi che, al fine di avere un sistema di init moderno, sia preferibile l’utilizzo di Upstart o systemd, o che altro?
    Per confronto, Windows 8 sembra promettere molto bene in questo senso (inizializzazione parallela dei driver, start dei servizi a trigger, ibernazione della “session 0″).

    3. Debian è tornata ad essere la distribuzione più usata sui server web e, data anche la perdurante fama di stabilità della stessa, immagino che tu ne sia molto fiero. Non trovi però che l’attuale supporto nel tempo di ogni versione stabile sia troppo breve e penalizzante per le aziende che utilizzino Debian quale sistema server?

    4. I package manager sono “la più grande invenzione di Linux”, e per i sistemi server sono quanto di meglio possa esistere: update puntuali, sicuri, testati.
    Per i sistemi desktop, tuttavia, non finiscono per risultare una “gabbia dorata”?
    Alcune distribuzioni diventano “rolling”, altre accelerano i rilasci o “costringono” gli utenti ad installare repository backport o PPA terzi. Non credi che, limitatamente appunto ad un uso desktop, dovrebbe esser possibile – a lato della gestione via package manager – installare un programma “alla Macintosh” o “alla Windows”, al di là della “ragnatela” delle dipendenze? Quale metodo preferisci?

  16. [16]

    (che noia questa formattazione… riscrivo)
    .
    1. In casa Fedora è in atto una “semplificazione” del Filesystem Hierarchy Standard: pensi anche tu che le cartelle /bin, /usr/bin, /sbin, /usr/sbin, /lib, /usr/lib, /lib64, /usr/lib64, /opt, pur sottendendo una logica pulita e ferrea, siano troppe?
    .
    .
    2. Allo stato attuale Debian è “ferma” ad un boot di tipo sysv, dependency based: quali saranno le scelte future? Credi che, al fine di avere un sistema di init moderno, sia preferibile l’utilizzo di Upstart o systemd, o che altro?
    Per confronto, Windows 8 sembra promettere molto bene in questo senso (inizializzazione parallela dei driver, start dei servizi a trigger, ibernazione della “session 0″).
    .
    .
    3. Debian è tornata ad essere la distribuzione più usata sui server web e, data anche la perdurante fama di stabilità della stessa, immagino che tu ne sia molto fiero. Non trovi però che l’attuale supporto nel tempo di ogni versione stabile sia troppo breve e penalizzante per le aziende che utilizzino Debian quale sistema server?
    .
    .
    4. I package manager sono “la più grande invenzione di Linux”, e per i sistemi server sono quanto di meglio possa esistere: update puntuali, sicuri, testati.
    Per i sistemi desktop, tuttavia, non finiscono per risultare una “gabbia dorata”?
    Alcune distribuzioni diventano “rolling”, altre accelerano i rilasci o “costringono” gli utenti ad installare repository backport o PPA terzi. Non credi che, limitatamente appunto ad un uso desktop, dovrebbe esser possibile – a lato della gestione via package manager – installare un programma “alla Macintosh” o “alla Windows”, al di là della “ragnatela” delle dipendenze? Quale metodo preferisci?

  17. [17]

    @atomix600#14, perché tirare in ballo Mac OSx quando abbiamo “in casa” chakra con i bundle?

  18. [18]

    #17
    Perché è stata NeXT prima ed Apple poi a tracciare la strada delle applicazioni distribuite via bundle.
    Questo NeXT lo faceva già dieci e più anni fa. Apple ha acquistato NeXT ed ha portato la tecnologia OpenStep su quello che poi è stato chiamato Cocoa.
    .
    Nomino OSX per pura onestà intellettuale e soprattutto perchè Chakra non è una distro orientata al bundle, ma una distro che usa pacchetti normali + bundle per applicazioni GTK+. Mac OS X usa esclusivamente bundle per gli applicativi.
    Anzi, OSX usa bundle ovunque. Anche nel core dell’OS.

  19. [19]

    #15
    Vorrei portare una mia opione in merito a questi interessantissimi punti.
    .
    1) C’è da dire che in parte hanno ragione quando dicono che è un modello broken-by-design.
    Avere una /usr separata oggi non vedo a cosa possa servire, dato che non esiste separazione tra pacchetti core e di terze parti nelle distro Linux.
    Se ci fosse una separazione come su FreeBSD, con la /usr/local usata SOLO per applicativi non dell’OS, allora non vorrei che un merge avvenisse.
    Ma ormai, al di là, di puri riferimenti storici alla hier UNIX, è del tutto indifferente.
    .
    2) Il problema IMHO non è essere preferibile o meno, ma SI POTRÀ preferire qualcosa di diverso in futuro?
    Debian non potrà mai usare systemd. Non finchè ci saranno GNU/Hurd e GNU/kFreeBSD come port ufficiali.
    Il problema però resta udev. Quest’ultimo è ormai integrato.
    Ed il fork chiamato eudev è fatto da gente che ha ammesso (e non sto scherzando) di non saperne nulla a riguardo, ma che vogliono cercare di portare avanti qualcosa di non mantenuto.
    Già questo dovrebbe far capire in che situazione volge il mondo che non accetta systemd.
    .
    3) Completamente d’accordo.
    Tuttavia è impensabile che la sola community mantenga per 13/15 anni un OS. Il lavoro di patching è un lavoro paradossalmente più pesante dello sviluppo dell’OS.
    Servirebbe una partnership con una azienda che fornisca assistenza a pagamento dopo l’EOL della community sulla versione, permettendo lato server un mantenimento di infrastrutture Debian-based anche a lungo termine.
    Qui potrebbe entrare in gioco Canonical. Sarebbe una ghiotta opportunità in termini di profitti, ma la vedo dura.
    .
    4) Completamente d’accordo.
    Sul desktop il modello basato su pacchetti e dipendenze è broken-by-design.
    Il desktop evolve molto più rapidamente rispetto al server. La gestione in stile Mac OS X, oggi è la migliore.
    Pulita, efficiente e facile da usare.
    Oggi IMHO il concetto di (DIS)INSTALLAZIONE di un software è impensabile.
    Oggi bisognerebbe prendere un bundle, lanciarlo con un doppio click ed eliminarlo come un normale documento quando non lo si vuole più usare.
    Mac OS X ha tracciato la strada.
    E le soluzioni ci sono anche su Linux. Esiste un framework chiamato AppImageKit (se non sbaglio) che crea binari portable.
    Se lo si usasse di default, ognuno di noi potrebbe prendere il binario di GIMP e lanciarlo ovunque, senza badare alla distro o alle dipendenze.
    Sarebbe la panacea per un sistema variegato come le distro Linux.

  20. [20]

    @atomix600
    il sistema dei bundle è sicuramente vincente su sistemi desktop.
    Il punto che i bundle dovrebbero essere il metodo di distibuzione principale dei programmi terzi, quindi gli stessi programmatori dovrebbero fornire oltre al sorgente anche il bundle statico per linux 32/64 che possa essere usato su ogni distribuzione a fronte di pochissime dipendenze (gcc/libc6).
    Quindi sarebbe ora di strappare di mano la distribuzione di tutti gli applicativi terzi dalle distro, come appunto avviene su tutti gli altri sistemi operativi e finirla con questa follia delle mille dipendenze.
    Mozilla, blender e altri già fornisco archivi compilati che funzionano senza installare nulla, dovrebbero tutti fare cosi e lascire alle distro solo il core del sistema ed il DE.
    Anche gli stessi DE dovrebbero smettere di fornire decine di programmi doppioni e limitarsi ai pochi essenziali, lasciando all’utente la scelta di editor di testo, lettori pdf, lettori video, audio, immagini che più gli aggradano.
    Si fa troppa roba, troppi doppioni, e troppe compilazioni della stessa cosa, con enorme spreco di risorse già scarse, che potrebbero essere convogliate sullo sviluppo “vero”.

  21. [21]

    telperion, mi trovi completamente d’accordo.
    Analisi ineccepibile.

  22. [22]

    Non so se i miei occhi, il mio cervello o qualcosa qui non quadra…
    Ho dato il mio commento circa il post sul Debian Project Leader e lo ritrovo qui (??!!).
    Ora se possibile lo posto dove deve stare! :)

  23. [23]

    @atomix600
    Eccellente spiegazione, grazie :D

  24. [24]

    @abba a volte quando non si capisce che si viene presi per i fondelli, è meglio tacere
    se non altro per non aggravare la situazione

  25. [25]

    maaa com ‘ e’ che non siete tutti project leader di linux ?? ma si dai incasiniamo linux di lib come fa windows cone le dll , magari utilizziamo ntfs e il registrodi sistema . gli altri os stanno facendo come linux ha sempre fatto , con gestione integrata del soft con gli app store , e noi torniamo indietro ? notevole !!

  26. [26]

    @apu veramente questo è un problema noto delle distro.
    Per i pacchetti, si potrebbe benissimo fare come OS X e Android.
    Lo store ti scarica e ti va a mettere il bundle dove serve in automatico. In sostanza però si tratterebbe di utilizzare un formato comune. E non so perchè ma penso che ad alcuni non piacerebbe molto.
    Dall’altra parte il rischo sarebbe perdere parecchio in sicurezza ed esporsi ai problemi tipici degli altri OS. Quindi andrebbe proposta come alternativa (ergo, i dev delle distro mettono i pacchetti nei repo se sono affidabili).
    .
    @telperion “Si fa troppa roba, troppi doppioni, e troppe compilazioni della stessa cosa, con enorme spreco di risorse già scarse, che potrebbero essere convogliate sullo sviluppo “vero”.”
    .
    D’accordissimo. E IMHO la cosa migliore sarebbe anche rallentare un pochino lo sviluppo del kernel. Mi sembra che ormai stiamo arrivando a degli eccessi paurosi. Non è possibile che una volta l’anno esce sempre fuori qualche problema di sorta, e tutto per avere una nuova release del kernel ogni 8/10 settimane.
    IMHO la cosa migliore sarebbe fare un sistema come i Jail per FreeBSD e lasciare che i vari produttori rilascino i driver dei dispositivi che poi i dev delle distro vanno ad inserire il tutto nell’initrd e aggiornano il kernel alla x.y.z-numeroacasaccio+1. E i potrebbero benissimo aggiungere il supporto nel kernel nativo nella release successiva.
    In questo modo i kernel hacker avrebbero un tempo molto più ampio per apportare modifiche e nel frattempo potrebbero tranquillamente fare bugfix del vecchio kernel, in modo da evitare robe tipo “Linux 3.8 non sarà LTS perchè ci sono già le 3.0 e 3.4 LTS, e supportarle per due anni ognuna è un’impresa mastodontica”.
    Ma mi sa tanto che un sistema Jail like sarebbe troppo pesante da sviluppare e forse richiederebbe un lavoro secondo solo al supporto in-kernel dei thread (che se non erro è arrivato con Linux 2.6). Quindi finchè non lo riterranno realmente necessario non ci penseranno nemmeno.

  27. [27]

    #22
    “ma si dai incasiniamo linux di lib come fa windows cone le dll”
    È quanto mai evidente che non sai di cosa parli.
    Fatti un giro in /usr/lib, poi dai un ldd su molti binari in /usr/bin e poi torna qui a dirci se la situazione di Linux/BSD/metti_qualunque_nix_ti_piaccia_eccetto_OSX è diversa da Windows.
    .
    Anzi, Microsoft, a dirla tutta, ha messo una *piccola* pezza con .NET, che riduce le DLL creando codice managed basato su una class library comune.
    .
    .
    Comunque l’obbiettivo non è una gestione Windows-like, che nonostante il .NET è comunque simile ai vari Unix tradizionali, ma una gestione OSX-like, basato su bundle statici (anzi, sarebbe più corretto dire MONOLITICI) che in un solo binario contengono direttamente tutto il necessario per eseguire il software, eliminando il concetto di dipendenze che è broken nel mondo desktop. Ciò permetterebbe agli utenti di utilizzare applicativi su qualsiasi distro.
    Ergo, niente installazione. Scarichi ed esegui.
    .
    Per dirla alla Java maniera
    “Download once, run everywhere”
    .
    .
    “maaa com ‘ e’ che non siete tutti project leader di linux ?? ”
    A parte che Linux è un kernel e quindi non c’entra nulla.
    Non c’è bisogno di essere project leader.
    Le soluzioni non sono campate in aria. Il framework da me citato, esiste DAVVERO e qui trovi tutte le app che vuoi:
    http://portablelinuxapps.org/
    .
    Le soluzioni caro il mio apu ci sono. Il problema sono coloro che devono applicare.
    Si preferisce spendere risorse in porcate come Unity e GNOME Shell e non ci si rende conto che al posto di perder tempo con icone e pulsanti tablettosi, andrebbero risolti tanti problemi più seri, come l’assurdo inferno della compilazione dinamica.
    .
    Fino ad oggi, apu, si è evitato di ricorrere alle soluzioni da me citate per un semplice motivo: “Linux deve girare anche sulla macchina da scrivere del 1930″.
    È vero. Linux ha quel vantaggio.
    Ma parliamoci chiaro (e senza trollate). Dimmi, apu, OGGI può minimanente pensare di installare Ubuntu sulla macchina da scrivere del 1930? Io dico di no.
    Quindi essendo che Ubuntu ha bisogno di hardware recente, il problema della compilazione statica è un NON-problema.
    Quindi, cosa si aspetta? Quando decideranno di mandare fan*ulo queste menate e cominceranno a fare cose più serie?
    .
    Non ti piace AppImageKit? C’è GNUstep che è un derivato di OpenStep esattamente come Cocoa.
    Pensa che se scrivi applicazioni GNUstep le puoi portare persino facilmente su OSX (e viceversa).
    .
    C’è una comunità (étoilè) che sta sviluppando un DE basato sulla tecnologia GNUstep. Certo è ancora alpha e piuttosto incompleto.
    Ma offre tutto il meglio che la NeXT ha creato nel campo delle GUI.
    .
    Apu le soluzioni esistono. Non è che se non le applicano vuol dire che sono necessariamente brutte. È che a volte in nome della cosiddetta “priorità” si smette di pensare a tutto ciò che c’è “under the hood” e sviluppare temi e wallpaper nuovi. Poi fa niente se si continua a nascondere la polvere sotto il tappeto. Tanto l’utente non se ne accorge.
    .
    .
    “magari utilizziamo ntfs”
    Tranquillo tanto il Btrfs ha gli stessi problemi di frammentazione.
    .
    “e il registrodi sistema”
    Arrivi tardi. Mai sentito parlare di quelle porcherie di GConf e dconf?
    .
    “con gestione integrata del soft con gli app store , e noi torniamo indietro ? notevole !!”
    L’appstore non c’entra nulla con quanto ha detto telperion.
    L’appstore è solo un frontend ad un server che ospita applicazioni.
    La licenza è GPL? Bene, prendi l’applicativo, mettilo sul server, fai una GUI ed eccoti l’appstore.

  28. [28]

    siii e si vede , 60 mb per un applicazione ! il problema e ‘ che siete bravi con i bla bla bla a fare i saputi , ma poi tirate in ballo solo gli aspetti ” positivi ” di una soluzione , quelli negativi ?? questa e ‘ la differenza tra chi lavora per linux e ” voi ” …… in questo caso ad es . i problemi sono : ridondanza , pessima gestione risorse , scarsa sicurezza , ecc . guarda caso java ad es. e ‘ sempre stata una debolezza per linux .. oltre ad essere ingordo di risorse !

  29. [29]

    #28
    “60 mb per un applicazione !”
    Quindi?
    Se installi LibreOffice quanto pensi che “pesi” il pacchetto sul tuo hard disk? 5 MB?
    Ripeto: su hardware moderno ciò è del tutto *irrilevamente*
    .
    ” il problema e ‘ che siete bravi con i bla bla bla a fare i saputi ,”
    Non so te, ma io sono un packager per un repository e SO di cosa sto parlando.
    Non faccio il saputo. Io su compilazioni dinamiche, dependency hell ci passo le giornate.
    Forse tu non lo sai, ma ci sono molte motivazioni TECNICHE che fanno si che la compilazione dinamica sia un problema serio.
    Te ne dico una:
    Su FreeBSD hai mai provato ad usare portupgrade? Quando lo usi ed una libreria viene ricompilata, se questa viene usata da un software allora portupgrade la copia in /usr/local/lib/compat e con un ldconfig rilinka il software che la usava nel nuovo path.
    Se questa libreria ha una falla di sicurezza in una funzione, il software che la usa ancora continuerà ad essere vulnerabile, ANCHE se portupgrade ha aggiornato tale libreria. Perchè? Perchè quel software è stato compilato con QUELLA specifica versione della libreria.
    Come fai a risolvere? Semplice ricompili TUTTI i software che fanno capo a quella libreria.
    Sai cosa significa questo? Che se 100 software usano quella libreria devi ricompilarli TUTTI e 100.
    .
    Con la compilazione statica NO, perchè la libreria fa parte del software.
    Quindi ti basta ricompilare (o fare una patch binaria) per il software in questione ed hai risolto il problema.
    100 contro 1.
    .
    ” ma poi tirate in ballo solo gli aspetti ” positivi ” di una soluzione , quelli negativi ??”
    Aumento della dimensione dell’applicazione ed un necessario innalzamento dell’allocazione in memoria.
    Sono cose che ho scritto qualche post fa. Non penserai davvero che debba riperterle ogni volta, spero…
    .
    “questa e ‘ la differenza tra chi lavora per linux e ” voi ” …… in questo caso ad es . i problemi sono : ridondanza , pessima gestione risorse , scarsa sicurezza , ecc .”
    Scarsa sicurezza? Ne sei sicuro? Guarda che la scarsa sicurezza è tipica della compilazione dinamica, non statica…sai?
    E ti ho fatto un esempio poco più sopra.
    .
    “guarda caso java”
    Java cosa? Ad oggi le falle principali sono imputabili al plugin web, non alla VM.
    Se tu usi il plugin web è un problema tuo. Io da tempo l’ho eliminato (uso OpenJDK ed il plugin icedtea-web non lo installo nemmeno se mi pagano oro).
    .
    “ad es. e ‘ sempre stata una debolezza per linux .. oltre ad essere ingordo di risorse !”
    Java è ingordo di risorse per motivi che sono ben diversi dalla compilazione statica.
    Java è ingordo di risorse perchè una applicazione DESKTOP deve richiamare, oltre alla VM, una quantità spopositata di classi per poter girare.
    Java non è una soluzione lato desktop. Java è un ottimo linguaggio lato server per web application, embedded e servlet varie.

  30. [30]

    *
    *irrilevante*

  31. [31]

    va bene ………. e come risolveresti questi problemi ? specialmente quello dell ‘ allocazione della memoria ? con 8 gb di ram per pc ?? da cio’ che dici pare che i bundle siano ” vietati ” su linux . . . . linux li permette , e infatti esistono anche , ma sono gli sviluppatori del soft a doversene preoccupare ( se vogliono ) e non l ‘ intero sistema a doversi ” convertire ” . . . va bene per i soft proprietari , giochi , ma per la maggior parte del software di linux ( opensource ) non serve . A un ‘ altra cosa …… che c’ entra ubuntu con tutto cio ‘ ? dovrebbe rivoluzionare il sistema di gestione di pacchetti quando tutti gli altri ( anche la vostra amata debian ) usano il modo ” classico ” …… gia’ immagino i soliti ” criticoni ” !!

  32. [32]

    a ….. poi per aggiornare il soft ?? ti riscarichi tutto da capo … ottimo , anche spreco di banda ! integrazione col sistema ? scordatevelo . Ora come ora se ho bisogno di una singola cosa vado nel package manager e la installo . Ripeto : vanno bene i bundle , ma devono essere una ” scelta ” ( come avviene per firefox ) e non obbligo !.

  33. [33]

    @apu ai tempi a dire il vero su Linux potevi considerare Java anche come vantaggio. Volevi usare i thread? Fino a Linux 2.6 non potevi perchè il kernel non li supportava. E quindi se volevi usarli DOVEVI usare Java, ovviamente contando che avendo un kernel che supportava solo processi appena un thread andava in stallo (per qualsiasi motivo) per il kernel era in stallo tutto il programma. Ma a livello implementativo Java è stato il pioniere in tutti gli ambiti ad usare i thread.
    E in termini di sicurezza Java è sempre stato una debolezza di qualsiasi OS. Guarda caso Apple ha rimosso la JVM dall’installazione di default per questo. Oltre ad avere diversi bachi di sicurezza (e in questo periodo escono fuori come funghi) ha anche dei problemi by deisgn, difficilmente risolvibili se non con una completa reingerizzazione quantomeno della VM.

    “siii e si vede , 60 mb per un applicazione !”
    .
    Quello continuerebbe ad essere un problema del programma. Non è certamente una novità.
    .
    In ogni caso si potrebbe passare alla compressione xz del bundle, dato che al giorno d’oggi è risaputo che i grandi problemi di caricamento sono dovuti alla velocità dei dischi. Infatti Poettering proprio per questo vuole sostituire tutti gli algoritmi di compressione che usa in systemd proprio con xz per quello.
    .
    “i problemi sono : ridondanza , pessima gestione risorse , scarsa sicurezza , ecc”.
    .
    La sicurezza non sarebbe scarsa. Magari potresti anche aggiungere Sandbox all’avvio di qualsiasi processo. Niente lo impedisce.
    .

    @atomix600 “Tranquillo tanto il Btrfs ha gli stessi problemi di frammentazione.”
    .
    Se non erro i problemi di frammentazione sono solo con gli inode. E in ogni caso il problema è minore del previsto, almeno in ambito consumer. Ormai si tende a mettere memorie flash dappertutto (ad esempio con gli SSD) e un sistema che frammenta i file non è dannoso per le prestazioni delle NAND. Il problema sarebbe parecchio annoso sui server e sulle workstation. Se è vero che i file sono frammentati, hanno fatto una ca.ga.ta. colossale.
    .
    Comunque, notare che ZFS è del 2005 e su Linux, nel 2013 (!) ancora un concorrente reale di ZFS non lo abbiamo nemmeno in sviluppo, nonostante BTRFS doveva essere proprio “ZFS sotto GPL”. Bello.
    .
    “C’è una comunità (étoilè) che sta sviluppando un DE basato sulla tecnologia GNUstep. Certo è ancora alpha e piuttosto incompleto.”
    .
    È un progetto interessante. Molto interessante.

  34. [34]

    @apu
    Minchia.
    O sei un troll o non ci arrivi.
    non si può non quotare Atomix600 e Telperion.
    Si perde tempo con le fesserie quando invece una distribuzione attraverso bundle statici risolverebbe veramente un sacco di problemi.
    E l’interesse aumenterebbe esponenzialmente quando improvvisamente l’installazione di un’applicazione ti costa zero.
    Veramente. È chiaro che non hai MAI compilato nulla per sproloquiare in questo modo.

  35. [35]

    #31
    “e come risolveresti questi problemi ? specialmente quello dell ‘ allocazione della memoria ? con 8 gb di ram per pc ??”
    Il più economico PC del supermercato ha minimo 2GB di ram, quindi di che parliamo?
    Su Mac questo problema non ce lo si pone da anni.
    Hai un PC di vecchia data con poca RAM? Nulla ti vieta di compilare dinamicamente.
    .
    “da cio’ che dici pare che i bundle siano ” vietati ” su linux . . . .”
    Chi l’ha detto? Ma quando mai…
    .
    “linux li permette , e infatti esistono anche , ma sono gli sviluppatori del soft a doversene preoccupare ( se vogliono ) e non l ‘ intero sistema a doversi ” convertire ” . . .”
    Ed è qui che ti sbagli.
    Il bundle ha bisogno di framework adatti.
    Il binario statico è ad oggi la soluzione che la maggior parte degli sviluppatori usa per distribuire applicazioni.
    Vedasi, Firefox, Eclipse ecc.
    .
    “va bene per i soft proprietari , giochi , ma per la maggior parte del software di linux ( opensource ) non serve .”
    Ah si? Guarda che il problema del dependency hell affligge proprio i software open compilati dinamicamente, sai?
    .
    “A un ‘ altra cosa …… che c’ entra ubuntu con tutto cio ‘ ?”
    Ho citato Ubuntu perchè è questa è una delle distro che punta al desktop e alle masse ed è questa che sulla macchina da scrivere del 1930 non la si installa nemmeno a spinta.
    Ergo, la compilazione statica non influirebbe per nulla su una installazione Ubuntu.
    Ovviamente al posto di Ubuntu ci puoi mettere Fedora, OpenSUSE e quello che ti pare.
    L’importante è che non mi citi distro non desktop, che non c’entrano nulla in questo contesto.
    .
    “dovrebbe rivoluzionare il sistema di gestione di pacchetti quando tutti gli altri ( anche la vostra amata debian ) usano il modo classico ” …… gia’ immagino i soliti ” criticoni ” !!”
    Ma che stai dicendo?
    Ma se prima ho scritto che il pregio è di poterlo usare dovunque senza problemi di dipendenze.
    Ma leggi almeno prima di commentare? O scrivi solo per muovere le dita sulla tastiera?

  36. [36]

    @winebar
    “Se è vero che i file sono frammentati, hanno fatto una ca.ga.ta. colossale.”
    Però se non sbaglio il Btrfs lo puoi deframmentare.
    Anche lo ZFS ha problemi di frammentazione. Però non nel file system in sè, ma nella ZIL (il journal).
    Solo che qui non c’è un defrag.
    .
    “Comunque, notare che ZFS è del 2005 e su Linux, nel 2013 (!)”
    In realtà lo ZFS è nato dieci anni fa e passato in produzione in OpenSolaris nel 2005.
    E nell’epoca in cui fu sviluppato c’era grande scettismo su di lui.
    Venne definito come un’inutile FS.
    Poi sappiamo come è andata a finire…. :)
    .
    ” ancora un concorrente reale di ZFS non lo abbiamo nemmeno in sviluppo, nonostante BTRFS doveva essere proprio “ZFS sotto GPL”. ”
    Il problema è che lo ZFS è stato progettando partendo da un Volume Manager che facesse anche da FS.
    Il Btrfs è nato come un FS che faccia anche da Volume Manager.
    Questo la dice lunga sul perchè il Btrfs non sarà mai un concorrente dello ZFS.
    Inoltre, non solo è partito male, ma è anche mantenuto peggio.
    .
    Tu pensa che se hai formattato la pool con Btrfs versione X e compili un nuovo kernel che ha la versione del formato X+1, il formato cambia irreversibilmente al primo boot col nuovo kernel.
    E di conseguenza il vecchio kernel non è più in grado di leggerlo.
    E questa è una cagata pazzesca.
    Con lo ZFS sei tu a decidere QUANDO e a CHE versione del file system upgrade, non il kernel.

  37. [37]

    @winebar
    dimenticavo di aggiungere…
    il problema non è il btrfs o lo zfs.
    Il problema è il modello Copy On Write che ha tra gli svantaggi la frammentazione del file system.

  38. [38]

    @ stufo : cominciamo ad usare i nomi veri ……. dopo vediamo chi e ‘ il troll !! magari sei proprio il caro telpirlon che si auto-quota da solo ! ah ah ah ! @atomix : be se io scrivo solo per muovere le dita tu hai problemi di comprendonio ! ecco che parte il rosik , tranquillo non scendo ai livelli di offendere ! cio ‘ che volevo dire con quella frase e ‘ che se ubuntu basasse tutto il software dei terzi sui bundle avrebbe sicuramente ” critiche ” , quindi non capisco cosa vuol dire la tua risposta ! be ” guarda caso ” hai scelto ubuntu come esempio . .. to’ , coincidenza ! che fai lanci il sasso e nascondi la mano ? ma va bene , e’ poco rilevante . Comunque linux e’ famoso per avere software che gira pure su pc con 200 mb di ram , adesso secondo te dovremmo avere tutti minimo 2 gb ? E poi , guarda caso tralasci questioni a convenienza di quelle che ho citato ( aggiornamento , integrazione , ecc. ecc. ) ……. ripeto la differenza tra ” VOI ” opinionisti e la gente che lavora per linux da anni , e’ che loro devono considerare ogni pro e contro perche’ hanno responsabilita’ , voi lasciate qualche ” commentino ” su one opensource e’ il massimo danno e’ l’inquinamento di queste pagine !!

  39. [39]

    #32
    “a ….. poi per aggiornare il soft ?? ti riscarichi tutto da capo … ottimo , anche spreco di banda !”
    Si può anche gestire l’aggiornamento attraverso patch binarie.
    .
    “integrazione col sistema ?”
    Uso Eclipse statico scaricato dal sito e non ho il minimo problema.
    Su OSX si usano bundle statici da una vita e non esiste il problema.
    Te lo ripeto: non sai di cosa parli.

  40. [40]

    #38
    “be se io scrivo solo per muovere le dita tu hai problemi di comprendonio !”
    Da quando è cominciata la discussione credo che sia abbastanza evidente che quello che ha problemi di comprendonio non sono io, ma sei tu che dici cose senza averne la minima idea.
    .
    “cio ‘ che volevo dire con quella frase e ‘ che se ubuntu basasse tutto il software dei terzi sui bundle avrebbe sicuramente ” critiche ” , quindi non capisco cosa vuol dire la tua risposta !”
    Ma che me ne frega di questo…
    Non mi importa di chi critica tanto per farlo. Qua si discute d’altro.
    .
    ” be ” guarda caso ” hai scelto ubuntu come esempio . .. to’ , coincidenza ! che fai lanci il sasso e nascondi la mano ? ma va bene , e’ poco rilevante .”
    ROTFL
    Mi sa tanto che stai arrampicando sugli specchi.
    .
    “Comunque linux e’ famoso per avere software che gira pure su pc con 200 mb di ram , adesso secondo te dovremmo avere tutti minimo 2 gb ?”
    Peccato che le distro che girino su 200MB di RAM esulano dal discorso fatto, visto che si parla di distro DESKTOP e non di distro per ambienti specifici.
    .
    “E poi , guarda caso tralasci questioni a convenienza di quelle che ho citato ( aggiornamento , integrazione , ecc. ecc. ) …….”
    Quel post non l’avevo visto poichè quando stavo scrivendo non avevo letto nemmeno il commento di winebar.
    Difatti ti ho risposto non appena l’ho notato.
    .
    “ripeto la differenza tra ” VOI ” opinionisti e la gente che lavora per linux da anni , e’ che loro devono considerare ogni pro e contro perche’ hanno responsabilita’ , voi lasciate qualche ” commentino ” su one opensource e’ il massimo danno e’ l’inquinamento di queste pagine !!”
    Ripeto: la differenza tra me e te è che io in questo campo ci sto dentro.
    Tu mi sa di no.

  41. [41]

    be la differenza e’ anche che io non ” attacco ” gli altri quando non so cosa dire , pensando di sapere chi siano e cosa facciano ……. mentre tu vuoi parere quello che sa tutto ! a pacchettizare non ci vuole niente , e te ne fai questo grande vanto ? a tal punto da dire ” ci sto dentro ” ! uao , roba grossa !! ah ah ah ! io ho inviato un bug report , cosa sono , un hacker ? ah ah !
    be che dire , se per te ” io non ho mai avuto problemi ” e’ un’ argomentazione valida , tanto di cappello ! mi immagino i kernel hacker che al primo bug dicono ” ma io non ho mai avuto problemi ” ! ah ah ! non serve essere esperti comunque , basta che provi il bundle di firefox e vedi che non si integra con niente per es . Oppure prova chakra e vedi quanto sono lenti i bundle ….. prova ad aggiornare la maggior parte dei bundle e vedi se sono efficenti . va bene comunque e’ inutile insistere , perche’ avere un dibattito con certa gente e’ come parlare al muro ! adesso di pure che non ho argomentazioni , perche’ solo quello sai ripetere ! il fatto e’ che pazienza di discutere con chi non cerca il dibattito ma vuole solo avere ragione non c’ e’! arrivati dal nulla pensate di avere la verita ‘ in mano ! quando poi per 20 anni c’ e’ gente che lavora a linux e lo ha fatto sempre allo stesso modo . be’ che dire , tutti gli altri sbagliano e voi avete ragione ! fatevi un os tutto vostro allora geniacci . saluti.

  42. [42]

    ” Mi sa tanto che stai arrampicando sugli specchi. ” : come vedi ripeti sempre stesse frasi fatte , cerchi di screditare gli altri con frasi senza logica ! accusando come fanno i bimbi . Sai almeno che vuol dire ” arrampicarsi sugli specchi ” ? direi che non c’ entra nulla . fai un paragrafo di accusa ad ubuntu e appena uno te lo evidenzia dici ” ho detto ubuntu ma vale per tutti ” . e adesso non sai cosa dire quindi sono io che mi sto ” arrampicando sugli specchi ” . ba … fiato sprecato .

  43. [43]

    @atomix600,
    [...] gestione OSX-like, basato su bundle statici (anzi, sarebbe più corretto dire MONOLITICI) che in un solo binario contengono direttamente tutto il necessario per eseguire il software, eliminando il concetto di dipendenze che è broken nel mondo desktop.
    .
    Non sono completamente d’accordo: pur essendo assolutamente favorevole ad un cambiamento – come si è capito dal mio intervento – non ritengo che i binari monolitici (ma anche più semplicemente i programmi distribuiti in cartelle conteneti “tutto il necessario”, come già Firefox) possano sostituire i package manager in tutto.
    .
    I package manager sono “la più grande invenzione di Linux”, e per i sistemi server sono quanto di meglio possa esistere: update puntuali, sicuri, testati. Questo è un fatto.
    .
    Come dici però, i p.m. nel loro complesso sono “broken by design” nel mondo desktop. Ben inteso: non è il package manager a essere broken, ma l’assurdità di come vengono scelte le dipendenze. Commettendo un abuso sto identificando le sue cose, passatemi i termini, è tardi ;)
    .
    Ebbene, per parte mia sono sempre a suggerire un connubbio tra le due realtà, UNICAMENTE NEL MONDO DESKTOP:
    .
    1) package manager che tengano in pugno le sorti del sistema operativo, cioè di tutti quei programmi che la distribuzione decide di includere.
    .
    2) un qualsivoglia sistema “scarica, clicca, esegui” per i programmi che l’utente, non trovandoli nella distro, decide di scaricare. E l’utente li mette dove vuole.
    Un sistema unificato però, non diverso di volta in volta, tipo portable app, bundle e diavolerie simili…

  44. [44]

    @apu
    A me sembra che qua l’unico che non sappia cosa dire sei tu.
    Hai scritto quanti post? 10? 20? E in tutti questi hai portato uno straccio di argomentazioni TECNICHE che smentiscano le mie? NO.
    Nemmeno una. Solo post pieni aria fritta.
    Solo pseudo-teorie tutte smentite con fatti.
    Su OSX si usano bundle da dieci anni. I software vengono tutti distribuiti staticamente. Alcuni persino in fat binary per poter essere eseguiti sia su intel che su ppc. E NESSUNO ha mai lamentato i problemi che vaneggi.
    Problemi che non sono nemmeno provati, ma solo frutto di tue strampalate teorie che non stanno nè in cielo nè in terra.
    .
    Puoi scrivere tutti gli sproloqui che vuoi. Siamo in un paese libero. Ma se speri che io mi abbassi al tuo livello di conversazione ti sbagli di grosso.
    .
    Non mi sono mai definito un kernel hacker.
    Ho detto che sono un packager. Non ho nessuna vanità. Ho detto solo la verità. Se ti crea qualche problema e se ti piace abbassare il livello della discussione, mi dispiace ma è una cosa che riguarda te. Non riguarda certo me.
    .
    Io mi limito a parlare di ciò che so. E ciò che dico lo si può constatare facilmente.
    Può non starti bene. Puoi non essere d’accordo. Ma se non lo sei, esprimi motivazioni tecniche.
    Delle tue stupidaggini ne ho davvero abbastanza.
    .
    .
    @Marco
    “Ben inteso: non è il package manager a essere broken, ma l’assurdità di come vengono scelte le dipendenze.”
    Allora, per esperienza ti posso dire che quando si pacchettizza per un repository, la dipendenza di un pacchetto da un altro varia a seconda di ciò scegli di compilare.
    Mi spiego: se un pacchetto X richiede Y e Z, ma opzionalmente anche W, solitamente si sceglie di compilarlo con tutte le opzioni disponibili, per permettere un utilizzo a 360° del software.
    Ovviamente non è raro trovare a volte opzioni inutili che portano solo ad un aumento della capillarità delle dipendenze.
    Questo porta inevitabilmente a trovare MOSTRI come VLC, gstreamer e simili che si portano una marea di dipendenze che solo ad elencarle tutte passiamo una giornata.
    Per questo ho detto che il modello pacchetto + dipendenze è broken by design su di un desktop.
    Perché fondamentalmente? Perchè il problema della compilazione dinamica è che ti lega mani e piedi ad uno specifico repository.
    Se tu installi X che richiede Y e Z, devi installare Y e Z dallo stesso repository di X, perchè se lo installi da un’altra fonte c’è il rischio di incompatibilità, date da opzioni diverse passate al configure/cmake ecc.
    Questo è quantomai evidente su Ubuntu a causa dei PPA. Quante volte si sente di gente che dopo tre o quattro PPA si ritrova con una Ubuntu “fuori uso”, proprio perchè i pacchetti hanno creato incompatibilità?
    Questo problema si verifica anche e soprattutto quando si ha a che fare con roba GNOME, che solitamente è una ragnatela di dipendenze assurda.
    .
    Ad oggi è IMHO improponibile un sistema desktop basato sui vecchi PM. Non è mantenibile da chi il computer lo usa a livello domestico.
    Il package manager è uno strumento che garantisce flessibilità è vero, ma è utile solo a chi ha il tempo/voglia per districarsi in questo ambiente tortuoso.
    .
    Se andiamo a vedere la maggiorparte dei problemi che si verificano dopo un’avanzamento della distribuzione (parlo di Ubuntu) sono quasi tutti derivati da applicativi che non fanno parte del core, ma di componenti di terze parti.
    .
    Ecco perchè sono dell’idea che il PM in una distro desktop serve solo per il sistema operativo, mentre per le applicazioni bisogna andare di bundle.
    Anche perchè il concetto di Pacchetto-dipendenze porta con sè uno dei tanti problemi che non si risolvono con un semplice clic su “disinstalla” nel package manager: il rimuovere le dipendenze di un pacchetto rimosso.
    L’utente medio di Ubuntu rimuove il pacchetto che non gli serve tramite il Software Center, tuttavia ciò che era dipendente da esso rimane nel sistema. E questo è inconcepibile.
    C’è gente che una volta mi rispose “ma negli HD moderni che hanno tanto spazio non è un problema se rimangono librerie”. Questo è assurdo sia in termini di sicurezza (ogni pezzo di software è sempre un potenziale rischio per la sicurezza. A maggior ragione se è software inutilizzato) sia in termini logici.
    Se io rimuovo aMule, voglio che tutto ciò che aMule si è portato dietro venga eliminato con esso.
    .
    È vero che con APT, RPM, con gli script di Slackware puoi fare tutto. Va bene. Siamo d’accordo. Non c’è niente che non si possa fare.
    Tuttavia, rimane il fatto che se non ci si mette mano, non si ha mai un OS pulito e che abbia solo il necessario.
    .
    Su OSX questi problemi non esistono.
    Non vuoi più aMule? Bene. Trascini l’icona nel cestino e hai chiuso.
    Niente GeoIP, libupnp, wxgtk ecc.
    Niente spazzatura che rimane nell’OS. Il software viene rimosso senza lasciar traccia.
    Inoltre, è anche un punto in più per la sicurezza.
    I package manager installano il software da ROOT. Ma ogni pacchetto contiene script post-installazione (solitamente che sincronizzano /usr/share/applications o fanno altre operazioni specifiche). Chi assicura all’utente che quando installi un pacchetto, lo script post-installazione non faccia roba indesiderata, come cambiare i permessi di una directory? Anche solo per errore del packager, non per forza per manomissione. Sono cose che succedono Marco.
    Un bundle invece lo scarichi e non ha bisogno di installazione.
    Lo esegui da utente normale ed eviti potenziali rischi.
    Ad oggi, Marco, non trovo una ragione che sia una per preferire i pacchetti con le dipendenze su di un sistema desktop, piuttosto che dei bundle statici.
    Sono solo complicazioni inutili che portano frammentazione ed incompatibilità di una applicazione tra una distro e l’altra ed anche tra una versione di una distro e l’altra.
    Se io aggiorno il sistema, non devo ricompilarmi i pacchetti per farli funzionare di nuovo.
    Mi dovrei aspettare che una volta aggiornato posso tornare subito al lavoro e riprendere le mie attività quotidiane.
    Questi sono limiti reali in ambito desktop.
    In ambito server è un’altro paio di maniche. I repository facilitano di molto il deploy di applicativi in una rete.
    E su questo non ci piove.
    Ma sul desktop IMHO è oggi una vera aberrazione.

  45. [45]

    Una volta ero più cauto su questo argomento. Oggi, dopo un anno di sbattimenti a basso livello e l’approfondimento della vastità di questo argomento nel mondo informatico devo ammette che sono giunto alla stessa conclusione di atomix600. Il modello pacchetto-dipendenze su un OS desktop (in senso lato, includendo anche il mobile) è una schifezza.

    È da tempo che ho maturato questa convinzione e mi fa piacere che se ne stia discutendo in questi commenti.

  46. [46]

    atomix,
    Ecco perchè sono dell’idea che il PM in una distro desktop serve solo per il sistema operativo, mentre per le applicazioni bisogna andare di bundle.
    .
    I nostri pensieri quasi coincidono, solo ti chiedo: qual è la linea di demarcazione tra un’”applicazione” e “il sistema operativo”? Qui andiamo ad aprire decenni di discussioni.
    .
    Non sarebbe quindi accettabile ciò che io dico? Ovvero:
    .
    1) package manager che tenga in pugno le sorti del sistema operativo, cioè di tutti quei programmi che la distribuzione decide di includere.
    .
    2) un ben definito ed univoco sistema “scarica, clicca, esegui” per i programmi che l’utente, non trovandoli nella distro, decide di scaricare. E l’utente li mette dove vuole.

    .
    In tal caso la distribuzione fa ciò che vuole, e l’utente pure. Si crea una “convivenza pacifica” tra mantainer e utenti.
    .
    La differenza con ciò che dici è che -nessuno- decide cosa l’altro deve fare: il mantainer decide cosa inserire nel sistema operativo e l’utente cosa scaricare.
    Ci sarà un piccolissimo overlap? E chissene?

  47. [47]

    @marco
    “1) package manager che tenga in pugno le sorti del sistema operativo, cioè di tutti quei programmi che la distribuzione decide di includere.”
    .
    pero a quel punto di “tutti quei programmi che la distribuzione decide di includere” avrai sempre solo la versione che la distribuzione decide di includere, il che è assurdo.
    Perchè ad esempio se uso un ubuntu 10.4 non posso installarmi un bundle gimp 2.8.4 su quella macchina, che magari con ubuntu 12.10 gira di m3rda?
    Perchè per usare un soft (che poi è quello che mi interessa) devo essere costretto ad aggiornare sempre il s.o. con tutte le “paturnie” del caso, quando magari il so anche vecchio, va benissimo sul mio hw e non mi può fregar di meno dell’aggiornamento del medesimo?
    I continui aggiornamenti del s.o. convengono solo al distributore per testare le nuove “paturnie” del caso, all’utente che non ha cambiato hardware aggiornare il so non comporta alcun vantaggio, anzi.
    Perchè esistono ancora milioni di utenti XP su hw vecchio?
    Perchè funziona su quel hw, e per assurdo funzionano anche moltissime ultime versioni dei soft di produttività.

  48. [48]

    Perchè per esempio non posso usare un “vecchia” distro con gnome2 che magari “mi garba” e non posso installarci i prg di produzione all’ultima versione?
    Devo usare il pc per “fare cose” o devo testare le nuove versioni di kernel/xorg/gnome/kde/stic4xxi/vari?
    La base dovrebbe servire a “far girare PROGRAMMI” allo stato attuale le discussioni vertono quasi esclusivamente su kernel, display server, DE, UI e cippe varie, i PROGRAMMI (il fine ultimo di tutto l’ambaradan) son sempre in secondo (terzo piano), sembra che “l’utente linux deesktop” sia fiero di accendere il pc con l’ultima versione della x distribuzione, e l’unica attività seguente sia “menarsi l’augello” per il compiacimento.
    Questo è il principale “difetto di progettazione”, forse perchè “l’utente linux deesktop comune” col pc non ci deve fare un qu4zzo, è solo l’ennesima estensione simbolica dell’augello.

  49. [49]

    La differenza di filosofia tra utente desktop gnu/linux e mac osx è tutta li. Al primo interessano kernel/de/mir/soyouz al secondo far girare programmi per “fare cose”
    A ragione chi dice se OSX fosse un s.o. da 100€ installabile su ogni pc, userebbero tutti quello come *NIX.

  50. [50]

    *Ha ragione
    asd

  51. [51]

    @Marco
    La linea di demarcazione è semplice:
    Il package manager gestisce: kernel, userland e DE (senza applicazioni di corredo, eccetto il file manager e qualche applicazione vitale per il desktop).
    I bundle: tutto il resto. Dall’editor di testi a GIMP. Da MPlayer a a Firefox. E così via.
    .
    In questo modo, si permette anche all’utente di personalizzare il proprio OS molto più facilmente, eliminando ad esempio software di cui non ha bisogno, lasciando pulito il sistema.

  52. [52]

    Non vorrei apparire profano e la mia è una domanda molto umile. Le librerie scaricate insieme al bundle non potrebbero fare chiamate a componenti del sistema operativo, ed avere comunque problemi di compatibilità? Voglio dire, la distinzione tra applicativo e sistema operativo, nonostante Linux sia molto modulare, non è assoluta. Mettiamo il caso di avere una versione di Ubuntu vecchia e un applicativo nuovo, scaricato in bundle, le librerie che si porta appresso potrebbero aver bisogno comunque di componenti del sistema aggiornatissime, che sia il kernel o il DE, e quindi il problema c’è lo stesso, o sbaglio? Ad esempio un gioco in bundle, che usa driver Nvidia, che si collega al kernel.

  53. [53]

    @Marco
    vedi blender:
    Blender 2.66a (63 MB)
    Requires glibc 2.11, includes Python 3.3, FFmpeg
    Suits most recent Linux distributions
    l’unica dipendenza è glibc 2.11 o superiori.
    Certo poi se vuoi usare Opengl, Cuda, Cycles devi ovviamente avere hw e driver che li supportino.
    Già solo avere integrati Python e FFmpeg, di cui esistono miriadi di versioni (ffmpeg 0.11 1.1 1.2 – Libav fork di ffmpeg usato da debian ubuntu 0.7.7 0.8.6 9.3, python 2.6 2.7 3.x eccetera) riduce il caos delle dipendenze in modo ENORME.

  54. [54]

    Marco
    no. non ci sarebbero problemi.
    Sono rarissimi i problemi con gli applicativi statici, per lo più derivati da usi di librerie obsolete (ma stiamo parlando di librerie vecchie che più vecchie non si può).
    .
    I binari statici non hanno fondamentalmente di questi problemi perché non linkano le librerie di sistema, ma fanno riferimento a versioni statiche di tali librerie incluse nello stesso pacchetto dell’applicativo.
    .
    In sostanza ogni applicativo statico porta le sue librerie. Ecco perchè, ad esempio, Firefox distribuito da Mozilla gira indistamente su qualsiasi distro.

  55. [55]

    guarda blender:
    http://uppix.net/a/7/8/449929760527f72e9f62a21f9e461.png
    scompattato l’archivio ./blended, pronti via.
    Cancellata la cartella scompattata, rimosso blender ..

  56. [56]

    guarda la differenza del pacchetto Blender ubuntu
    http://packages.ubuntu.com/quantal/blender
    versione vecchia (2.63a) 30 dipendenze della rava e la fava, 21,637.1 kB contro i 63 MB della 2.66a.tar.bz2.
    Ma davvero per una 40 di MB mi devo fracassare gli zebedei per aspettare la build della distro con le lib condivise. e che funziono solo su quella?
    2.66a.tar.bz2 la ESEGUO su qualsiasi distro senza nessuna paturnia.
    Non è lavoro sprecato fare la build Ubuntu?
    Fai un pacchetto deb dal tar.bz2 statico e ficcalo in /opt e distribuiscilo dal SC/synaptic/apt …

  57. [57]

    “In sostanza ogni applicativo statico porta le sue librerie. Ecco perchè, ad esempio, Firefox distribuito da Mozilla gira indistamente su qualsiasi distro.”
    .
    infatti uso quello da sempre (su qualsiasi distro) e non ho mai avuto problemi di sorta, rallentamenti, crash eccetera.

  58. [58]

    Lasciando stare qualcosa di enorme come un DE, chi non ha mai provato a compilare un pacchetto complesso almeno come ffmpeg e le sue librerie o come gstreamer, da cui dipendono centinaia di applicazioni, non potrà mai capire cosa significhi star dietro alle dipendenze e quindi apprezzare un bundle.
    .
    Facendo uso di ppa, si rischia di sbracare il sistema in pochissimo tempo (ho visto personalmente un sacco di gente con le mani nei capelli per questo), quantomeno di creare delle anomalie apparentemente inspiegabili (applicazioni che funzionavano correttamente cominciano a sollevare eccezioni su eccezioni) per via di librerie che cominciano ad accatastarsi e a collidere senza controllo visto che non c’è alcuna integrazione fra i ppa. I ppa sono comodi ma mortali.
    .
    Personalmente ho sempre ritenuto i package manager una grandissima risorsa. Però comportano una serie di vincoli che effettivamente per un sistema desktop sono inaccettabili: l’estrema dipendenza dal package manager, l’impossibilità (almeno per per il non power-user) di fruire di un’applicazione se non è presente nel suddetto package manger, infine, ma non per importanza, tutta la serie di problematiche legate alla sicurezza che avete già sollevato.
    .
    D’altro canto, il package manager costringe a pensare ad un sistema gnu/linux come un qualcosa di organico, in cui, concettualmente, non vi è distinzione fra kernel e applicazioni, in cui il package manager filtra ogni possibile cambiamento. Tutto ciò che è all’interno di un package manager deve (o meglio dovrebbe) garantire un funzionamento corretto dell’INTERO sistema. Ogni applicazione deve essere testata al fine di evitare anomalie e il cambiamento (in termini di upgrade) di una di essere, soprattutto quando va a toccare parti veramente sensibili, rischia di compromettere seriamente questo equilibrio. Alla luce di tutto questo è normale che una debian stable sia rocciosa ma obsoleta. La comodità è data dal fatto che l’utente viene sollevato dal problema dell’aggiornamento (un click) ma questa comodità (se rimangono valide le premesse di prima) si paga con una serie di applicazioni che risultano eccessivamente datate.
    .
    A conti fatti, la compilazione dinamica e quindi il package manager, era sicuramente una buona soluzione in passato. Oggi che lo spazio su disco è notevolmente aumentato perde parecchia della sua importanza.
    Una soluzione mista come quella proposta da @Atomix600 sarebbe l’ideale e chissà che un giorno non ci si arrivi.

    @atomix600
    A proposito del problema delle dipendenze, ma su Debian, con “apt-get –purge autoremove applicazione” non è sufficiente per rimuovere tutte le dipendenze? Non mi pare di aver mai avuto problemi in questo modo e sono abbastanza maniacale in questo. O forse ho capito male e intendevi le gui.

  59. [59]

    @stufo
    Intendevo proprio le GUI.
    Infatti avevo scritto che richiamando direttamente il package manager il problema lo si risolve, tuttavia non lo si risolve quando si usa un front-end.

  60. [60]

    @stufo,
    sì, io uso anche apt-get –purge remove $(deborphan).

  61. [61]

    @stufo
    “Lasciando stare qualcosa di enorme come un DE, chi non ha mai provato a compilare un pacchetto complesso almeno come ffmpeg e le sue librerie o come gstreamer, da cui dipendono centinaia di applicazioni, non potrà mai capire cosa significhi star dietro alle dipendenze e quindi apprezzare un bundle.”
    Per questo ho detto ad apu che non aveva la minima idea di quello che farneticava.
    .
    E poi mi viene a dire “a fare il packager non ci vuol niente”.
    .
    Non ci vuol niente il cazzo!
    Faccio una breve panoramica su cosa vuol dire essere un packager, tanto per chiarire.
    Nel caso qualche altro troll senza cultura venga a sproloquiare.
    .
    Devi replicare il sistema in chroot, o una VM on un container, perchè NON DEVI MAI compilare sul sistema nativo.
    Compili una libreria, poi compili un pacchetto che richiede tale libreria.
    Vai a testarlo e ti rendi conto che va in crash per motivi a volte ignoti.
    Vai quindi di strace per tracciare le chiamate del software per vedere cosa ha causato tale problemi, per poi scoprire che la libreria da cui dipende ha problemi.
    Cerchi problemi simili su google per capire se è un bug noto oppure un qualcosa che dipende dal compilatore o dalla libc. E s’! La rottura delle API su GCC e GlibC è cosa nota, tanto che a volte i software non compilano.
    Anche con le QT c’è lo stesso problema. Con le GTK2 meno. Con le 3 non so. Per ora non mi sono capitati software che le richiedono.
    Con le WXWIDGETS devi stare attento, perchè se un pacchetto richiede wx 2.8 devi trovare un modo per non farlo cozzare con pacchetti come aegisub che richiedono wx 2.9.
    Se poi scopri che il problema della libreria è un bug noto, controlli se qualche altra distro ha creato una patch, se c’è la prendi e te la studi per verificare che vada bene (non è si applicano le patch a cazzo di cane…perchè una patch può anche compromettere la stabilità di un software). Se non c’è LA SCRIVI.
    .
    .
    Per non parlare di software come MPlayer, FFMPEG e GMP che hanno lo STRAMALEDETTO vizio di prendere i flag del processore NATIVI, a meno che il packager non imponga i propri CFLAGS, CXXFLAGS e triplette (che non tutti hanno nella variante linux generica i686/x86_64-pc-linux-gnu, ma alcuni come slackware e suse hanno la loro).
    Se il packager compila senza dare queste cose il pacchetto rischia di non funzionare su altri PC, anche se l’architettura è la stessa.
    Questo problema non si verifica con i 64 bit, ma soprattutto con i 32bit, dove c’è il rischio che uno di questi pacchetti possa prendere flag come SSE2/3/4, MMX, PowerNow! e via dicendo.
    Flag che non supportati da tutti i processori, anche se magari tutti sono i686.
    .
    .
    Oppure se un pacchetto richiede un servizio di INIT, devi scrivertelo da ZERO, se ad esempio hai distro come Slackware e Gentoo, che non usano il normale SysV.
    .
    .
    Ancora, se hai bisogno di fare il debug devi ricompilarlo senza lo strip dei binari per avere la symtab da poter usare con debugger.
    .
    .
    Se compili RPM devi imparare il linguaggio degli SPEC file. Se usi Slackware devi imparare BENE il bash per scrivere SlackBuild.
    Se usi Gentoo devi imparare a scrivere ebuild e conoscere le cosiddette USE.
    .
    .
    Su molte community i packager dei repository vengono definiti “Developer” proprio perchè la modularità di Linux fa si che costruire un pacchetto per un repository è lo stesso che pacchettizzare la distribuzione.
    .
    .
    .
    Qua c’è gente come apu che pensa che fare un pacchetto per un repository sia come quando te lo compili per cazzi tuoi.
    E poi mi viene a dire “siamo bravi tutti”.
    Sì! A parole siete bravi tutti!
    Se siete così sapienti venitele a fatele voi.
    Come diceva Torvalds “Talks is cheap. Show me the code!”

  62. [62]

    io per ffmpeg di sistema uso quello di debian multimedia, poi compilo ed impacchetto l’ultima versione statica da usare da riga di comando chiamandolo ffmpeg2, con i binari ffmpeg2,ffplay2,ffprobe2 e basta installati in /usr/bin completi di tutto filtri postproc aac++ aac xvid x264 eccetera:
    .
    mc@debian64:~$ ffmpeg2
    ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
    built on Mar 15 2013 14:14:00 with gcc 4.7 (Debian 4.7.2-5)
    configuration: –extra-cflags=’-Wall -g -O3 -march=core2 -mtune=core2′ –prefix=/usr –enable-libmp3lame –enable-gpl –enable-nonfree –enable-libvorbis –enable-pthreads –enable-libfaac –enable-libxvid –enable-postproc –enable-x11grab –enable-libgsm –enable-libtheora –enable-libopencore-amrnb –enable-libopencore-amrwb –enable-libx264 –enable-libspeex –enable-nonfree –disable-stripping –enable-libschroedinger –disable-encoder=libschroedinger –enable-version3 –enable-libopenjpeg –enable-libvpx –enable-librtmp –enable-avfilter –enable-frei0r –enable-libopencv –enable-libfreetype –enable-libvo-aacenc –disable-decoder=amrnb –enable-libvo-amrwbenc –enable-libaacplus –enable-libdc1394 –disable-altivec –disable-armv5te –disable-armv6 –disable-vis –enable-filter=delogo –enable-filter=boxblur –enable-filter=frei0r –enable-filter=drawtext –enable-filter=gradfun –disable-ffserver –disable-shared –enable-static –enable-vdpau
    libavutil 52. 18.100 / 52. 18.100
    libavcodec 54. 92.100 / 54. 92.100
    libavformat 54. 63.104 / 54. 63.104
    libavdevice 54. 3.103 / 54. 3.103
    libavfilter 3. 42.103 / 3. 42.103
    libswscale 2. 2.100 / 2. 2.100
    libswresample 0. 17.102 / 0. 17.102
    libpostproc 52. 2.100 / 52. 2.100
    Hyper fast Audio and Video encoder
    usage: ffmpeg [options] [[infile options] -i infile]… {[outfile options] outfile}…
    .
    entrambi sono nel sistema senza alcun casino

  63. [63]

    Io di solito i binari statici li metto tutti in /opt.
    .
    Non mi piace metterli in /usr.
    Preferisco seguire la hier Unix e mettere tutto ciò che è statico in una directory separata.
    .
    .
    In PATH poi ho:
    “/opt/sfw/bin:….”
    .
    Metto /opt al primo posto in modo da usare quelli compilati da me, qualora dovessero esserci due versioni.

  64. [64]

    bravo marco buratto !! soluzione molto piu’ ragionevole ! e ‘ impossibile per un programma bundle avere tutte le librerie incluse … quindi un fallimento ! il problema di linux non sono i package manager , sono i soldi che non girano sul mercato desktop …….se ci fossero interessi commerciali altro che , nessuno si farebbe tutti sti problemi di pacchettizzare ecc. ecc. . L ‘ha dimostrato valve ! A ma … giusto una cosa …..se non vi piace linux , che venite a fare su one opensource a criticare ogni cosa ? secondo me vi piace stare al centro dell ‘ attenzione facendo quelli che vanno contro ………

  65. [65]

    Ehm… guarda che Valve distribuisce in bundle… o credi che i giochi si installino tirandosi dietro le dipendenze dal package manager?

  66. [66]

    Vedi apu, c’è chi parla a ragion veduta e con cognizione di causa e chi continua a collezionare figure marroni.
    Se avessi letto almeno mezzo post della ventina che stanno più su, l’avresti capito.
    Buona fortuna.

  67. [67]

    seeeee ……….. richiede : curl , jockey-common , libcurl3 , nvidia-common …..che fa se le tira dietro ? ? e se ho un ubu vecchio che faccio ? @stufo : ma non sai fare altro che lagnarti come una femminuccia ? non sai parlare da solo invece che ” aggrapparti ” agli altri ? lasci che gli altri parlino e tu dai solo ragione perche’ non hai argomenti . Bravo .

  68. [68]

    Al solito, parli solo per consumare ossigeno.
    Io non mi aggrappo a nessuno, a differenze di te che ti aggrappi al nulla e non sei in grado di formulare una minima considerazione tecnica. Quando ci provi, vieni dileggiato perché credo sia chiaro a tutti che di esperienza ne hai veramente poca.
    Ripeto: se ti fossi degnato di leggere i commenti altrui, avresti notato anche il mio, con tanto di motivazioni, a differenza dei tuoi dove vedo solo ignoranza e supponenza.
    Non prendertela, ma come interlocutore vali veramente poco.

  69. [69]

    #64
    “e ‘ impossibile per un programma bundle avere tutte le librerie incluse … quindi un fallimento !”
    Hai ragione. Infatti su OSX si installano i pacchetti con il package manager, vero?
    Ma LOL.
    L’ignoranza di per sè è un brutta cosa. Ma lo diventa ancora di più quando chi non sa cerca di spacciarsi per qualcuno che sa, pur non portando prove valide a sostegno di tesi strampalate.
    .
    “il problema di linux non sono i package manager , sono i soldi che non girano sul mercato desktop …….”
    Tu sì che hai capito tutto…
    .
    “se ci fossero interessi commerciali altro che , nessuno si farebbe tutti sti problemi di pacchettizzare ecc. ecc.”
    È evidente che non hai idea di ciò che dici.
    Te l’ho detto e te lo ripeto.
    .
    “L ‘ha dimostrato valve !”
    Valve cosa?
    Steam è pacchettizzato/compilato per UNA distribuzione. Il resto è segato.
    Mentre con i bundle si risolverebbero tutti i problemi.
    Basta vedere OSX che è supportato da LEOPARD (2007) in poi.
    Ma di che parli?
    Semmai Valve ha dimostrato che la compilazione dinamica è broken sul desktop e che questo porta a frammentazione inutile e problemi di vario genere. Soprattutto in software closed source che non possono essere ricompilati.
    Lo ripeto per l’ennesima volta: su OSX non esistono da anni questi problemi. Anzi, non sono MAI esistiti.
    .
    ” A ma … giusto una cosa …..se non vi piace linux , che venite a fare su one opensource a criticare ogni cosa ?”
    E tu che non hai argomenti che ci vieni a fare?
    Quella nostra è pura onestà intellettuale. Mettiamo in evidenza problemi.
    Proprio perchè ci piace Linux, cerchiamo di analizzare quelli che si rivelano essere i suoi punti deboli e pensare a possibili soluzioni.
    Ma è evidente che tu, che parli senza cognizione di causa, pensi che sia denigrazione.
    Quando uno non ha a che fare con certe cose è più che naturale che non capisca certi discorsi.
    Fondamentalmente non c’è nulla di male in questo. Nessuno sa tutto di tutto. Sarebbe impensabile.
    Io, ad esempio, non so nulla di agricoltura. Ma proprio per questo non mi permetterei di andare su un forum di agricoltura e mettermi in mezzo ad una discussione in cui non ho la minima preparazione, per poi prendere posizione senza nemmeno capire quello che si sta dicendo.
    .
    “secondo me vi piace stare al centro dell ‘ attenzione facendo quelli che vanno contro ………”
    “Le persone vedono negli altri i difetti che in realtà appartengono a loro stessi” (cit.)
    .
    .
    .
    #67
    “e se ho un ubu vecchio che faccio ?”
    Ti attacchi. Non ti piace la compilazione dinamica? Adesso attaccati al tram e ringrazia chi porta avanti queste politiche fallimentari.

  70. [70]

    “seeeee ……….. richiede : curl , jockey-common , libcurl3 , nvidia-common …..che fa se le tira dietro ? ? e se ho un ubu vecchio che faccio ? @stufo : ma non sai fare altro che lagnarti come una femminuccia ?”
    .
    Se hai Ubuntu vecchio t’attacchi al quazzo. Valve dice apertamente che supporta da Ubuntu 12.04 in poi. O te lo sei scordato?.
    .
    Comunque, sono i GIOCHI ad essere simil bundle (o meglio, compilati staticamente).
    .
    “e ‘ impossibile per un programma bundle avere tutte le librerie incluse … quindi un fallimento !”
    .
    Ma che hazzo vai dicendo???
    Firefox, blender e tantissimi altri. Sono compilati staticamente, scarichi l’archivio, lo estrai e funzionano senza rotture di balle varie. Da questo punto ad un bundle la differenza non è tantissima, anche perchè fondamentalmente i bundle non sono altro che archivi.
    Qui il problema è che i team delle distro non si mettono d’accordo a creare un formato comune per i bundle da usare sul desktop.
    Volendo si potrebbe tranquillamente far si che se vuoi usi i pacchetti precompilati che ci sono sui repo. Altrimenti ti scarichi i bundle e vivi felice.

  71. [71]

    @stufo : invece le tue considerazioni tecniche ? sono le stesse che hanno gia ‘ scritto altri ma formulate in un altro modo ! Sei solo bravo a cercare di ” parlare bene ” . @atomix : fai tanto il saputello e ti vanti dei tuoi ” tecnicismi ” , ma poi cadi come una pera cotta ! un bundle non ha tutte le dipendenze assieme , come vedi lo dice pure il tuo amico telperion ! …………………. maaaa , comunque , perche’ anziche gli informatici non fate gli psicologi ? siete ridicoli , a cercare di ” analizzare ” gli altri ! pensate a ” pacchettizzare ” va …..

  72. [72]

    @apu
    Quindi sono un bravo paroliere?
    Almeno hai letto qualcosa ma vedo che hai compreso poco.
    Hai mai pensato che le mie considerazioni siano simili solo perché ho avuto esperienze comuni a quelle di Telperion o atomix600 che, a differenza tua, è gente che sa?
    Bene. Aspetto le tue di considerazioni tecniche che non siano le solite arrampicate sugli specchi.
    Io continuo a leggere i tuoi post ma non vedo nulla. Solo farneticazioni e dimostrazioni evidenti di inadeguatezza.
    Non continuare su questo piano, ti stai solo rovinando la reputazione futura (ammesso che tu ne possa mai avere una).

  73. [73]

    #71
    “fai tanto il saputello e ti vanti dei tuoi ” tecnicismi ” , ma poi cadi come una pera cotta !”
    Continui a menarla con sta storia delle vanità.
    Certo che ad argomenti sei proprio messo male, eh?
    .
    “un bundle non ha tutte le dipendenze assieme ,”
    Te lo ripeto. Tu non sai ciò di cui parli.
    .
    “come vedi lo dice pure il tuo amico telperion ”
    Veramente ha scritto un post riguardante un applicativo che richiedeva la glibc 2.11+ (libc uscita a NOVEMBRE 2009), mentre integrava TUTTE le sue dipendenze.
    Il che è normalissimo. L’ho fatto intendere anche io nel post #54
    .
    Mi autocito:
    “Sono rarissimi i problemi con gli applicativi statici, per lo più derivati da usi di librerie obsolete (ma stiamo parlando di librerie vecchie che più vecchie non si può).”
    .
    Per una ennesima volta, hai dimostrato (pur cercando di fare il contrario) quanto le compilazioni statiche ed i bundle siano la soluzione su Linux desktop.
    Un’applicativo open source che supporta 3 anni e 4 mesi di distro contemporaneamente? Se considerassimo la situazione attuale delle distribuzioni, ciò lo si definirebbe una chimera.

  74. [74]

    Aggiungo, prima che trolli di nuovo.
    3 anni e 4 mesi contando da *adesso*. Ovviamente, visto che dice 2.11+, vuol dire che tra un anno quel pacchetto continuerà a funzionare alla stregua di come funziona oggi. E quindi avrà 4 anni e 4 mesi di supporto assicurato e via dicendo…
    .
    D’altronde, il videogioco UPLINK è uscito nel 2001 (12 anni fa).
    E funziona ancora oggi.

  75. [75]

    a proposito di blender visto oggi:
    http://forum.ubuntu-it.org/viewtopic.php?f=73&t=553356
    ti scarichi il pacchetto compilato dalla distro e oltre che vecchio è pure bacato.
    Ditemi se non è follia pura …

Inserisci il tuo commento