Da parecchi anni si pone l’esigenza di un sistema universale per gestire i pacchetti nelle principali distribuzioni GNU/Linux, senza che si sia mai raggiunto il minimo accenno di soluzione condivisa.
I sistemi attuali sono equivalenti, pur variando in funzionalità e utilizzo: RPM e DEB si contendono la scena come motori principali, mentre varie interfacce utente hanno il compito di nascondere all’utente tutto il lavoro sporco da essi svolto.
Ci sono stati parecchi tentativi di semplificazione, tra soluzioni precarie, tradizionaliste, rivoluzionarie, sperimentali o semplicemente insostenibili. Nomi come Autopackage, PackageKit, Klik/Glick e vari strumenti che ogni distributore è stato obbligato ad escogitare di volta in volta.
Adesso, in quella che potrebbe essere una svolta storica, finalmente sembra aprirsi uno spiraglio di luce in fondo al tunnel affettuosamente denominato “dependency hell”…
Il problema
Installare software è un compito abbastanza complesso in ogni sistema operativo. Idealmente si tratta solo di copiare qualche file, e in alcuni casi non ci si scosta troppo da questa semplice operazione; nella realtà però una gestione dei pacchetti deve tenere conto di molte esigenze:
- Installazione, rimozione e aggiornamento dei pacchetti
- Gestione di un database di pacchetti installati/installabili/aggiornabili
- Risoluzione di eventuali (inter)dipendenze e/o conflitti
- Esecuzione di script di autoconfigurazione e/o d’avvio
- Già detto “Risoluzione di eventuali (inter)dipendenze e/o conflitti”?
Tali esigenze rendono difficoltosa l’idea di affidarsi ad una semplice copia dei file da installare, specialmente se consideriamo che nei sistemi unix è tradizione suddividere e spargere il contenuto di ogni pacchetto per tutto il filesystem, in base al tipo di file: i binari vanno in /bin, /usr/bin /usr/share/bin e altro ancora, le librerie in /lib, /usr/lib, ecc, secondo un complicato sistema di precedenze e di criticità delle singole componenti.
Se consideriamo che ogni distributore si è sempre trovato a creare un’albero delle directory leggermente diverso dall’altro, un sistema di script di init leggermente diverso dall’altro, un sistema di configurazione leggermente diverso dall’altro, un naming scheme dei pacchetti leggermente diverso dall’altro, una politica di aggiornamento dei pacchetti leggermente diversa dall’altro… capirete bene come si sia arrivati alla situazione attuale, in cui praticamente non esistono due distribuzioni compatibili.
Le soluzioni tradizionali
Ogni distributore ha dunque sviluppato un sistema di gestione dei pacchetti, magari storicamente legato al nome della distribuzione o dell’azienda sviluppatrice, magari con corredo di spunti per garantire anni di ferocissime, intense e inutili dispute su quale sia il migliore, più tecnologicamente avanzato, veloce, affidabile, sicuro, eccetera.
Ciascuno di noi ha le sue preferenze, che – come tutte le religioni – non è il caso di mettere in dubbio, possiamo però ostentatamente ignorare i gestori di pacchetti più casalinghi o legati a distribuzioni minori ed evidenziare i due principali sistemi, gli unici contemplati dalla idealmente importante quanto in pratica inutile Linux Standard Base: RPM e DEB. Il primo viene da Red Hat ed è adottato da distribuzioni quali Fedora, openSUSE, Mandriva/Magiea e altre; il secondo da Debian ed è adottato da Debian stessa e dalle innumerevoli distribuzioni derivate, tra cui Ubuntu.
Anche annullando il motivo d’esistere di ogni buon troll e ponendo che RPM e DEB siano equivalenti (grosso modo lo sono), per tutta la serie di motivi elencati più su, ugualmente non esistono due distribuzioni che usano lo stesso gestore esatto, in quanto molto raramente un pacchetto rpm per openSUSE potrà essere installato su Fedora, o allo stesso modo un deb di Debian su Ubuntu. Dunque due principali tecnologie, usate per creare decine di implementazioni leggermente incompatibili, quel che basta a non permettere l’uso di uno stesso pacchetto su più di una distribuzione. Ma non è questo il punto.
Per rendere meno anale la gestione dei pacchetti da parte dei semplici utenti che vogliono semplicemente installare Firefox, fregandosene bellamente di librerie e dipendenze, sono stati escogitati varie interfacce ad RPM e DEB. Da APT a Synaptic, da YAST a YUM alle decine di altre utilità create con questo scopo. Un primo tentativo sensato di unificare tutte queste piccole divergenze sotto un ombrello che garantisse delle API un’esperienza d’uso uguali e coerenti, a prescindere dal funzionamento reale del motore, è stato PackageKit, tuttora non del tutto implementato.
Le soluzioni sperimentali
Oltre a questo, molto oltre a questo, c’è sempre stato un impulso al rinnovamento, da parte di utenti e sviluppatori insoddisfatti da alcuni aspetti della gestione dei pacchetti in GNU/Linux, principalmente dalla intensa frammentarietà che porta alla compatibilità suddetta. Sono dunque nati diversi sistemi alternativi, ma sempre complementari, per gestire pacchetti in maniera più omogenea e pratica per tutte le distribuzioni o quasi.
Uno degli esempi più riusciti, ma sempre largamente fallimentare, è/era Autopackage, un gestore che offre un leggero strato di compatibilità con il gestore della distribuzione, e ponendosi come gestore ulteriore, da usare per quei pochi progetti che nel tempo hanno fornito versioni autopackage dei loro software. Non è mai stato nemmeno ufficiosamente supportato da alcun distributore, che io sappia.
Se Autopackage è stato largamente ignorato, pur essendo forse il migliore esempio, potete immaginare gli altri. Un progetto che ho seguito con molta attenzione è stato Klik, che a differenza di Autopackage e dei sistemi tradizionali, si rifà al concetto di app bundle tipico di Mac OS e implementa un paradigma di 1 file = 1 app, nell specifico si tratta di una immagine in cramfs contenente un piccolo albero di directory con tutte le librerie e i binari dell’applicazione, che in quel modo non vengono sparsi per il filesystem ma rimangono appunto contenute nel file. In maniera simile funziona(va) anche Glick e così pure un progetto italianissimo: SpatialBundle di Luca Cappelletti.
LA soluzione?
Tutte queste soluzioni sono sempre state caratterizzate dall’assoluta mancanza di coordinazione tra i distributori: quelle tradizionali per motivi che a mio avviso, ripetuto in varie occasioni, possono solo essere visti come la mancanza di prospettiva di chi imbriglia soluzioni aperte in strategie chiuse; quelle sperimentali perché semplicemente non interessavano davvero a nessuno.
Oggi però Frafra ha segnalato una notizia che non esito a definire storica. Sviluppatori di Red Hat, Fedora, Debian, Ubuntu, openSUSE, Mandriva e Mageia si sono incontrati per discutere le caratteristiche di un nuovo gestore di pacchetti universale. Al momento si chiamerebbe AppStream e sarebbe basato sull’interessante progetto Bretzn, presentato dal team di KDE, per quanto riguarda le funzionalità multipiattaforma e multiarchitettura, e idealmente su Ubuntu Software Center per quanto riguarda l’interfaccia utente. Funzionalità molto interessanti, quali la possibilità da parte degli utenti di attribuire e condividere votazioni o commenti ai pacchetti sarebbe prevista tramite Open Collaboration Services.
La parte più interessante è che l’intero progetto non sarà un sistema per distribuire i tanto temuti et famigerati Universal Binaries From Hell, ma si limiterà a fornire metadati, che saranno interpretati da cliente per scaricare i bit necessari. Questo significa che il sistema di installazione dei pacchetti rimarrà di tipo tradizionale, e che dunque le parti che verranno innovate saranno solo quelle che permetteranno di avere un installer universale per tutte le distribuzioni.
Nessuna rivoluzione, ok, ma una benvenuta evoluzione all’insegna della razionalità.
Un gestore pacchetti per domarli tutti ? XD
Buona idea: spesso tanti newbie non si raccapezzano a capire cosa vuol dire .deb o .rpm e perchè va su una distro e sull’altra no.
Interessante idea. Speriamo che vada in porto e che sia effettivamente adottata da tutte le più diffuse distribuzioni. Del resto è da tempo che si parla di unire le forze nel mondo GNU/Linux. Questo ne è un esempio concreto.
Ben venga, ma che nome poco l33t.
È una cosa /troppo/ sensata, non può andare in porto. ;)
Comunque non mi è ben chiaro se il fine è fornire un motore di ricerca unico (con un front-end grafico basato su Ubuntu Software Center) per installare gli stessi variegati pacchetti che oggi selezioniamo con apt/yum/yast/ecc., o se invece si cerca di sviluppare un formato condiviso per le applicazioni da installare *al di fuori del packet manager*, dopo averle scaricate da un sito.
O forse entrambe le cose? Comunque questa – se ce la fanno – è veramente la rivoluzione copernicana che stavamo aspettando, che rimuove uno degli ostacoli più grossi per chi vuole supportare commercialmente Linux, ammesso che si riesca a stabilire (e rispettare con disciplina ferrea) una baseline di librerie che si DEVONO trovare in tutte le distro.
Che notizia! :)
mmm, da come felipe lo descrive non mi semba “la soluzione”, essendo un front end per i pacchetti già esistenti non cambierebbe molto rispetto alla situazione attuale.
Francamente a me non interessa se l’interfaccia per scaricare le applicazioni è la stessa su tutte le distro. Quello che mi interessa è andare sul sito di $applicazione_cool e non vedere una pagina con i pacchetti per tutte le distro tranne la mia. Che è opensuse eh, mica ddwrt.
eh
Forse mi sono spiegato male ma intendevo dire che è assurdo che software disponibile e pacchettizzato per linux non sia installabile su tutte le distro. Lo strumento di cui stiamo parlando in questo post non sembra risolvere il problema dato che citando felipe: “si limiterà a fornire metadati, che saranno interpretati da cliente per scaricare i bit necessari”.
Scaricare da dove? Dai repository della propria distribuzione suppongo, quindi funzionerà solo per i pacchetti che supporta la tua distribuzione.
Quello che invece servirebbe invece sarebbe proprio “i tanto temuti et famigerati Universal Binaries From Hell”, naturamente questo per le applicazioni non per il software “core” che continuerebbe a essere installato con i sistemi tradizionali.
No, “eh” = “infatti”.
ah
Un gestore di pacchetti universale a mio modesto avviso sarebbe una cosa che agevolerebbe moltissimo la diffusione di gnu/linux, altro che correre dietro ai giochi e a versioni native di autocad o photoshop per linux. Secondo me sarebbe una cosa meravigliosa, troppo………. quindi….. non si farà mai.
Felipe, mi aspettavo accennasi allo Smart Package Manager, bel progetto che però non ha mai preso piede. Ci illudiamo che da qui a pochi anni avvenga una rivoluzione dei Package Manager?
Riusciranno gli sviluppatori di ben 7 distro a mettersi d’accordo? Riusciremo a vedere qualcosa di anche solo lontanamente funzionante prima della fine dei tempi?
Già il fatto che si sia scelto ubuntu software center come base per l’interfaccia è un grande passo in avanti. Solo pochi mesi fa si sarebbe bocciato qualunque progetto “made in Canonical”.
Segno che:
– Canonical ha imparato a farsi rispettare (e magari a distribuire codice più “pulito”)
– Gli altri hanno iniziato a rispettarla un pò di più (dopotutto le cose non le stanno andando male!)
Veramente è il contrario: hanno scelto di importare la GUI di USC su PackageKit (cosa che non dovrebbe fare felicissimi gli utenti DEB, visti i noti problemi tra PackageKit e Apt).
Dubito ci sia travaso di codice, la utilizzeranno più come mockup…
e scommetto che non farà neanche contenti i ragazzi di Canonical visto che per avevano deciso di non aderire a packagekit per fare il loro ubuntu software center…
Per i già citati problemi con APT (che sono colpa di APT). Chiarisco perché così pare che siano malvagi e vogliano dominare il mondo. Semplicemente Debian dovrebbe passare a RPM, Ubuntu seguirebbe a ruota e si risolverebbero tanti problemi. Per APT, dovrebbe esserci già un apt-rpm (anche se non ho idea di come funzioni o se funzioni), nel caso basterebbe scriverlo e fare in modo che sia compatibile con Package-Kit, poi portare le applicazioni (Synaptic e USC) a Package-Kit… Finché Debian non passa, dubito che Canonical si sogni di ripacchettizzare tutto il software :/
Nota: No, non mi va di fare l’avvocato del diavolo e sì, per me dovrebbero farlo dalla prossima LTS. Però è bene non dimenticarsi anche dei problemi tecnici, tutto qua.
Per quanto possa suonare come una proposta eretica, sono d’accordo con te.
Chiarimento per chiarimento: i già citati problemi con Apt non impediscono però che ci sia Kpackagekit su Kubuntu.
Probabilmente la verità sta nel mezzo: sono malvagi, vogliono dominare il mondo E apt ha i suoi difettucci… :D :D
Ironia a parte, concordo con te sul passaggio obbligato ad RPM. Sarebbe già un bel passo avanti. Ovviamente il sogno è l’intercompatibilità dei pacchetti su tutte le distro.
PS: apt-rpm lo trovi su PcLinuxOS, e non è proprio il massimo…
considerando che si sta parlando di standard, sono d’accordo anch’io. Se proprio devono farlo però che non sprechino tempo con un nuovo formatto. Alla fine, basterebbe che si adeguassero agli standard che ci sono già invece di crearne dei nuovi.
“si limiterà a fornire metadati, che saranno interpretati da cliente per scaricare i bit necessari”: un po’ criptica come frase (ma non è colpa di felipe, è così anche nella notizia in inglese…).
Per come la vedo io, un modo per superare le innumerevoli versioni della struttura delle directory fra le varie distro ci sarebbe: ogni file ha una sua funzione e un tipo, ovvero un file è una libreria, un eseguibile, un file di help, un file di configurazione, un file di risorse (immagine, audio, video, testo), un file di traduzione.
Una volta che ogni file è stato identificato in questo modo, la distro penserà a installarlo nell’apposita directory secondo le sue personali preferenze.
Semplice, no?
Ma infatti io sono anni che propendo per questa ipotesi: un xml con indicazioni come “questo va in librerie, questo in bin, questo in pr0n” e il sistema che si mette a smistare il tutto.
Però è troppo semplice, si perderebbe il brivido del “Secondo te questa volta funzionerà?”
A me non sembra proprio la soluzione finale. Ciò che rallenta (e non di poco) lo sviluppo di GNU/Linux a mio parere non è un sistema generalizzato di scaricamento, installazione, aggiornamento, risoluzione dei pacchetti/dipendenze/conflitti,… Il problema è che se qualcuno fa un app per GNU/Linux, la metà del lavoro è scriverla, la seconda è pacchettizzarla per Debian, Ubuntu, Fedora, Opensuse, Mandriva, Gentoo, Arch, Slackware,… e siamo solo a un pugno scarso delle distribuzioni (e quindi come Felipe ha sottolineato, di sistemi di gestione dei pacchetti) più importanti.
Quando questi distributori si metteranno d’accordo per un unico, standardizzato e, soprattutto, correttamente implementato formato per la distribuzioni dei pacchetti, allora saremo a un punto di svolta epocale. Per il momento credo che stiamo “soltanto” navigando nella direzione (a mio parere giustissima, per carità) di fornire all’utente un’esperienza desktop coerente, semplice, professionale.
Sì, ma con questo sistema uno sviluppatore/distribuzione deve comunque pacchettizzare il suo pacchetto…
Scusa, ho letto male e ho saltato un “non” e ho capito tutto il contrario :)
Concordo.
Ma… e io che ho letto anche l’introduzione per pregustarmi uno sconvolgimento epocale…
Non sono un esperto in materia, ma visto l’ultimo paragrafo, se ho capito bene si potrebbe riassumere l’articolo nella frase “soccia arriva un’altra interfaccia grafica per installare software!”, giusto? ;)
L’idea del file cramfs a me sembrerebbe la migliore..
Non voglio essere polemico, ma se rpm e apt fossero così simili, forse il backend di packagekit per apt non sarebbe così indietro per motivi di incompatibilità strutturale :)
@Daniele
No, non si parla di una nuova interfaccia grafica (fortunatamente)
offtopic ma in tema …di qualche giorno fa per chi se l’era persa :D
http://pollycoke.com/amonpaike/socialbox/18261
divento eccentrico quando capitano queste premunizioni .. muhahaha
:P
h+
un AppStore insomma…
L’ora è tarda, io sono stanco e non ho voglia di leggere con attenzione e controllare meticolosità. Però una nota: il meeting non era rivolto alla ricerca di un sistema di packaging univoco (per dire ammazziamo RPM e teniamoci DEB), ma solo alla definizione interfaccia utente unica di un ipotetico “App Store” condiviso dalla varie distribuzioni Linux. Cfr http://distributions.freedesktop.org/wiki/Meetings/AppInstaller2011
Comunque mi pare di capire che nessun vantaggio giungerebbe a una software house che volesse commercializzare un software per Linux: dovrebbero sempre smazzarsi una mole di lavoro non indifferente per pacchettizzarlo correttamente per tutte le distribuzioni, oppure usare i tristissimi tar.
La soluzione ci sarebbe, semplice e alla portata di tutti e senza complicazioni tecniche, e si chiama klik. Ogni distro potrebbe continuare a mantenere il proprio file system “personalizzato” e nessuno dovrebbe piu’ preoccuparsi di dipendenze. Possibile che si debba sempre ricorrere a soluzioni contorte e cervellotiche quando ne esistono di semplici?
Il fatto che ogni distribuzione debba curarsi del filesystem virtuale non è complicarsi la vita? Inoltre, l’immagine generata non può essere usata su computer diversi, e la quantità di bytes scaricati tende ad essere ben maggiore rispetto al metodo qui presentato, perché non bisogna tenere dozzine di librerie uguali per altrettante applicazioni. Klik non viene sviluppato da circa cinque anni, e il suo successore (klik2, che doveva risolvere problemi come il non poter avviare più di 8 applicazioni), non s’è più visto.
Qui stiamo parlando di una infrastruttura completa, indipendente dalla distribuzione, che si integra con validi strumenti già esistenti, una scelta condivisa da tutte le maggiori distribuzioni: ben venga :)
Mmmmm ma dare un po’ di amore a http://portablelinuxapps.org/ invece? Io le trovo fenomenali ( e a differenza di molte altre cose… funzionano!!! )
Chiaramente applicazione portable != applicazione installata ma in un mondo Linux in cui un utente non puo’… cioe’ proprio non puo’ … installarsi un applicazione nella propria Home, e’ una ventata d’aria fresca.
Secondo me la parola “invece” non si dovrebbe usare. Non sono progetti alternativi :)
qualcosa di semplice semplice (ma anche fittizio, visto che credo sia poco che un maquilage) tipo quello usato in gobolinux,questo almeno solo per l’utente finale?
abbiate compassione per la niubbiagine
Quello di GoboLinux non è un maquillage, la struttura delle directory è stata effettivamente stravolta. Poi sono state creati dei link simbolici nelle posizioni “classiche”, in modo che le applicazioni coi percorsi inchiodati possano comunque trovare le risorse di cui hanno bisogno. Infine, questi link simbolici sono stati nascosti con una patch al codice del file system all’interno del kernel, ma sono comunque accessibili con “cd” e affini.
Non è una cosa complicata IMHO, e neanche una cosa troppo utile: idealmente l’utente non dovrebbe *mai* mettere le mani direttamente fuori dalla propria home. A mio avviso è molto più importante sistemare il modo in cui le applicazioni salvano preferenze, dati e cache nella nostra home, che è del tutto fuori controllo, nonostante esistano degli standard (che quasi nessuno implementa, purtroppo).
infatti chiedevo per questo
ma non c’è un modo più semplice per farlo e senza che si superino i confini della home?
Articolo davvero interessante ! Complimenti :)
Solo un appunto:
alla fine del paragrafo “Le soluzioni tradizionali” c’e’ un refuso (“Per rendere meno anale la gestione dei pacchetti da parte dei semplici utenti[…] “) ;-) .
Ci sono troppi integralisti nel mondo Gnu/Linux con una smisurata voglia di stare a fare a chi ce l’ha piu’ grosso, per affrontare veramente un problema del genere con serietà. Si darà spazio per un po’ a qualche “progetto minore” ( ;) ), che un periodo potrà anche dare l’idea di parvenza che ci possa essere qualche speranza, per poi andare in stallo, senza aver morso abbastanza per farsi rimpiangere da tutto il resto dell’ambiente che continuerà ancora a girare con magliette “RPM” “DEB” “TAR”, con magari tornei di calcetto….
Io resto del parere che un gestore di pacchetti/app store universale debba essere svincolato dalla distribuzione.
Un soggetto come sourceforge o la stessa FSF potrebbero, per esempio, rilasciarne uno proprio, magari multipiattaforma.
Sarebbe senz’altro un’ottima vetrina per il software libero in generale, rendendondolo più competitivo rispetto a quanto lo sia adesso, gli utenti apprezzerebbero un archivio dove trovare software gratis o a prezzi equi e renderebbe (forse) meno necessaria l’esclusività di certi sistemi operativi proprietari a discapito di altri.
I tempi sono maturi, se scorriamo i volumi di certe iniziative già in circolazione.
E’ un progetto così difficile da sostenere?
Non comprendo la tua domanda. Un gestore di pacchetti è diverso da un software store, anche perché il progetto di cui stiamo parlando di questa pagina rientra più nella seconda categoria che nella prima, ed è indipendente dalla distribuzione. Se invece intendevi rpm/deb/ecc., io credo sia sbagliato buttare via tutto per fare un nuovo metodo di gestione dei pacchetti.
Ogni distributore fa come gli pare per un motivo molto semplice: non esiste una infrastruttura a monte e se esiste nasce dall’iniziativa del suddetto che è spesso in competizione con gli altri.
Che sia una competizione monetaria o tecnica nessuno sarà disposto a cedere terreno al proprio avversario.
Per questo mi pare del tutto ragionevole che un sistema di distribuzione dei pacchetti universale possa nascere solo dalla sintesi di chi questi pacchetti li scrive che, in teoria, non ha interesse per sostenere un distribuzione piuttosto che un’altra, ma solo che la sua applicazione possa funzionare sul maggior numero di sistemi.
Cito wikipedia: “Sourceforge è un sistema per la gestione dello sviluppo di software di tipo collaborativo”.
Penso sia una evoluzione naturale se arrivassero a fornire all’utente finale anche un servizio di pacchettizzazione e download dei progetti ospitati, gestibile comodamente attraverso un software con la facciata di appstore e il cuore da gestore di pacchetti.
Non esiste .deb .rpm .exe, .dmg o .pkg ma un binario per Linux, uno per Windows e l’altro per MAC, gestito dall’appstore, ovviamente sotto al cofano.
Il peso, in termini di volume di traffico, dovrebbe per forza di cose impattare sulle cifre ben più modeste che possono vantare i singoli gestori di applicazioni delle distribuzioni, spingendole de-facto ad adottare una soluzione più visibile e popolare.
Ciao
Perchè dici che “nessuno sarà disposto a cedere terreno al proprio avversario.”
Francamente penso che DEBIAN, che in quanto comunità dovrebbe essere superpartes su questioni meramente economiche, potrebbe e dovrebbe fare l’unica scelta sensata:
ABBANDONARE DEB in FAVORE di RPM (che è pure LSB).
Non ci sono ragioni tecniche per non farlo, anzi, esisterebbero ragioni tecniche per farlo, e come qualcuno diceva nei commenti più sopra gli altri (ubuntu in primis) si adeguerebbero al volo
Come ho detto, non è una questione di soldi o solo di soldi. La frammentazione delle distribuzioni ci dice, in primis, che ognuno si cucina la propria ricetta.
Come hanno scritto, gli standard esistono basterebbe adottarli senza ammucchiare astrazioni, su astrazioni, su astrazioni, su astrazioni…:)
Ciao
Creare l’ennesimo gestore pacchetti è un’operazione secondo me inutile e dispendiosa. Come dice arzigogolato lo standard c’è già, è tecnicamente superiore agli altri, e non è questione di mercato secondo me: si parla solo del formato. Se Debian adottasse rpm, oltre ai vantaggi intrinsechi del formato, avrebbe finalmente dei tool mantenuti e sviluppati attivamente, e potrebbe continuare a fare la sua politica, in completa autonomia.
viva l’illuminismo e l’europa del diciottesimo secolo
xD
Per eliminare il gestore di pacchetti, e magari anche qualche centinaia di distro si dovrebbe includere il sistema di pacchettizzazione nel kernel.
Anzi meglio, si fa come in gobolinux, si modifica il filesystem.
Così molti programmatori, invece di fare i pacchettini, potrebbero, giusto per fare un esempio, scrivere programmi.
Ben venga, ma preferivo l’idea di klik. 1 application 1 file. devi disinstallare un’applicazione? cancelli un file.
Sempre contento di constatare come la gente visionaria di KDE riesca a far la differenza ;-)
Ok, te l’hanno fatto già notare: “Per rendere meno anale la gestione dei pacchetti”…
Forse volevi dire “meno viscerale”? Cosa si cela dietro questo lapsus?
Direi che sarebbe arrivato pure il momento :)