Newsgroup: it.comp.os.dibattiti
Titolo: semplificare installazione programmi in GNU/Linux

Ciao a tutti.
Spero di non generare un flame inutile con questo post.
Sono un utente Linux da ormai qualche anno. Mi trovo molto bene e considero
questo sistema superiore a Windows. Tuttavia quest'ultimo è preferito da
molte persone per la sua (apparente) semplicità. Purtroppo alcune cose in
Windows, effettivamente, sono più semplici per un utente medio (quindi uno
che di pc non ne capisce una mazza), anche se nel complesso Linux in quanto
a semplicità si difende bene (utenti che non conoscevano Windows o Mac,
messi ad usare Linux e Windows, hanno preferito il primo per la facilità).
Il discorso, comunque, rimane come semplificare alcuni aspetti. Uno che
sembra stare a cuore a molti è l'installazione delle applicazioni.
L'attuale sistema con i pacchetti e la risoluzione delle dipendenze complica
troppo le cose. Non solo all'utente, ma anche a chi costruisce e
distribuisce un programma, che per semplificare l'installazione si trova a
dover creare molti pacchetti, magari uno per ogni distribuzione. Una cosa,
a mio parere, insostenibile, tanto che in molti casi viene fornito solo il
sorgente.
E' vero che nei repository si trovano, spesso, i programmi che si cercano,
ma molte volte capita che non sono l'ultima versione disponibile. Quando il
programma poi è poco diffuso nemmeno si trovano, e bisogna cercarli in
internet sperando che qualcuno li abbia creati e resi disponibili. Per non
parlare di tutte quelle persone non raggiunte dall'adsl (in Italia,
ricordo, lo è la metà della popolazione) che non possono contare sulla
risoluzione automatica delle dipendenze, perché si scaricano l'rpm o il deb
da qualche altra parte e poi l'installano a casa.
A mio parere si dovrebbe rivedere, in parte, la politica del costruire un
programma con le librerie lincate dinamicamente. Secondo me, ai sistemi
attualmente usati, si dovrebbe affiancare la possibilità dell'utente di
installare un programma compilato in modo statico, così da evitare
qualunque problema di dipendenze. Così come avviene, ad esempio, con
Firefox. Basta scaricare l'archivio compresso, scompattarlo, ed eseguire
l'applicazione. Senza ulteriori complicazioni. Se questo fosse fatto con un
pacchetto si potrebbero semplificare ulteriormente le cose, lasciando che
sia il gestore (rpm, apt ecc) ad occuparsi di dove installarlo, di evitare
che vi siano due versioni diverse (o meglio ancora chiedere all'utente cosa
fare), di creare un link nei menu ecc.
Voi cosa ne pensate?
Mattia Adami
--
per inviarmi email il dominio corretto è email punto it
www.sessosublime.it
 (non è un sito porno, ma d'informazione)
vedi cosa fanno in Cina agli animali (le immagini sono terribili):
nonlosapevo.com

 qualunque problema di dipendenze.
Puntualmente la questione si ripropone, e puntualmente ripropongo questa 
argomentazione.
Supponiamo che la cosa sia ristretta alle dipendenze da librerie, e che 
prenda piede.
Che succede quando si scopre un buco in una delle librerie molto 
popolari (per fare un esempio realmente successo: zlib)?
Se la politica generale è quella di linkare dinamicamente, uno installa 
la zlib patchata a dovere ed i programmi che la usano sono a posto.
Se la politica generale è quella di linkare staticamente, uno deve 
scoprire quali sono e poi aggiornare tutti i programmi che la linkano 
staticamente, supponendo che tali aggiornamenti siano disponibili.
Probabilmente la via "giusta" sta nel mezzo (mi pare che con MacOS X si 
faccia così): definire un set di librerie popolari da linkarsi 
dinamicamente, ed il resto statico. Mi pare che sia quello che si cerca 
di fare con la Linux Standard Base (
http://www.linuxbase.org/
).
Oppure la via "giusta" potrebbe anche essere quella di port e portage, 
che tuttavia taglia fuori il software proprietario.
+++
Rimangono comunque tutte le dipendenze che non sono librerie: ad 
esempio, K3B dipende da cdrecord, mkisofs, cdrdao, etc.
Dovrebbero essere inclusi direttamente nel pacchetto di K3B?
-- 
   |   \    \  | ___|_  |_  |  ianezz a casa sua... :-)
   |  _ \  | \ | _|    /   /   Verba volant, scripta
  _|_/  _\_|  _|____|___|___|  manent, data corrupted

 Voi cosa ne pensate?
Distinguerei le 2 cose:
1) Programmi autocontenuti tipo Firefox
Sono comodissimi (apparentemente) ma hanno anche dei difetti di 
integrazione con la distribuzione.
Ad esempio sotto la Suse 10.0 ho usato per un po' il Firefox 1.5 
installato a mano ma non funzionavano ne Java ne l'Mplayer-plugin, oltre 
naturalmente a mancare il link nel menu di kde e le associazioni dei 
file html. Dopo un breve periodo di prova mi sono procurato la versione 
Rpm dove ovviamente funziona tutto.
2) Pacchetti con i programmi compilati staticamente
Risolvi il problema sopra ma ti ritrovi con una versione per ogni disto 
o quasi visto che hanno tutte strutture diverse.
Speriamo che la tendenza alla standardizzazione continui in modo da 
risolvere questo problema ma per ora ci sono troppe diversità.
Inoltre prima di tutto il programma diventa più grosso (ma vabbe, con i 
dischi attuali...) poi se si scopre una vulnerabilità in una liberia 
occorre sostituire tutti i programmi che la usano al posto di sostituire 
la sola liberia.
PS: Controlla il delimitatore della firma, lo standard è "-- " meno meno 
spazio e il tuo ha solo i meno, questo crea problemi ai news-reader.
-- 
Un saluto, John Fredersen
Per validare l'indirizzo sostituire "server.invalid" con "
gmail.com
"

 Voi cosa ne pensate?
Interessante, ma... la risposta probabilmente sarà... "perché, visto che
col packet manager vengono già risolte tutte le dipendenze?"
"perché ho il 56k"
mi sa che non è abbastanza :(
Oltretutto, compilare staticamente significa maggiore uso di memoria. Utile
nell'immediato per "chi non può risolvere le dipendenze", ma effettivamente
è un po' uno spreco :(
-- 
___/\/o\/\/here/\/\an___
"Vagisil migliora 
la tua vita intima"
http://www.vagisil.com/teencenter.shtml

 con un 'chmod +x pacchetto && ./pacchetto' ?
Si potrebbero rivedere i formati dei pacchetti per fare in modo che il 
loro header sia in realtà un piccolo eseguibile che vada ad invocare un 
package manager per installare il pacchetto in questione.
Ma questa possibilità personalmente non mi piace molto, perché invita ad 
eseguire codice arbitrario su una macchina senza possibilità di 
controlli preventivi automatizzati.
Un package manager può normalmente verificare se le firme GPG di un 
pacchetto gli quadrano prima di eseguire gli script di pre/post 
installazione del pacchetto, mentre con questo sistema ci sarebbe la 
possibilità di lasciare al pacchetto stesso la responsabilità di avviare 
il package manager *o qualsiasi altra cosa*.
Di fatto si offrirebbe un'opportunità di ridurre le verifiche 
preliminari possibili a "da dove l'hai scaricato?", che IMHO è molto 
limitante.
Insomma, la vedrei più che altro come un offrire alla gente una 
possibilità in più di impiccarsi con le proprie mani.
Molto meglio configurare i vari file manager in modo che all'azione 
dell'apertura del pacchetto corrisponda l'avvio del package manager.


 Voi cosa ne pensate?
Che pian piano si sta arrivando al punto, grazie a varie iniziative,
che bene o male si sa che mettendo il file .desktop in questo percorso
tutti i DE lo vedranno bene, o che mettendo la libreria in questo
percorso non ci saranno problemi con nessuna distro.
IMo una soluzione "temporale" per i 56k sarebbe un'opzione nel package
manager che gli dici "voglio installare questo programma però non
posso scaricarlo ora, dimmi che fare", e ti genera uno script che ti
puoi mettere su una chiavetta USB, andare su un altro PC con wget/curl
installati e ADSL e ti scarica automaticamente tutti i pacchetti
necessari, riesegui lo script sulla tua macchina e ti installa il
programma che volevi come avevi richiesto "offline".
Domanda: non è che apt faccia già qualcosa di simile? :D

 Voi cosa ne pensate?
La risposta e`: L'installazione in linux e` piu` semplice che in tutti
gli altri os. Si tratta di educare utenti che sono abituati a fare altre
cose, piu` difficili.
Inoltre il mantenimento e` estremamente piu` semplice, gli altri OS
neanche lo prevedono questo.
Qualsiasi discussione che inizia dando per scontato che il problema di
linux e` l'installazione dei programmi e` fallata in partenza.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

 
http://guide.debianizzati.org/index.php/Apt-zip:_aggiornamenti_senza_una_connessione_veloce
Non ho il tempo di leggerlo ma mi sembra interessante.
Alessandro.

 gestirli. Quattro risate me le faccio volentieri.
Scusa ma che c'entra? Lo hai letto tutto il suo post?
Lui parlava delle difficoltà di un utente alle prime armi nel trovare ed 
installare il software sulla sua distro, non di come il sistema gestisce 
una moltitudine di programmi.
Ti assicuro che per i niubbi è davvero un problema sentito e IMHO non 
solo per loro!


 gestirli. Quattro risate me le faccio volentieri.
Quello che ho detto è completamente diverso, non c'entra. So benissimo che
Linux è in grado di gestire una grande quantità di programmi meglio di
Windows (non saprei di Mac perché non l'ho mai usato). La questione è
rendere semplice all'utente (ed al programmatore), l'installazione di
un'applicazione.


 neanche lo prevedono questo.
Si, ma questo non centra nulla con il lincaggio statico delle librerie.
Il mio non è un attacco ai pacchetti, ma una critica sul fatto che qualunque
programma usi tutte le librerie dinamiche, anche quelle usate molto
raramente.


 che tuttavia taglia fuori il software proprietario.
Ripensandoci: non è affatto vero che taglia fuori il software proprietario.


 Domanda: non è che apt faccia già qualcosa di simile? :D
Mattia Adami


 effettivamente è un po' uno spreco :(
Credo sia un limite trascurabile.


 spazio e il tuo ha solo i meno, questo crea problemi ai news-reader.
Grazie. Sistemato. 


 Dovrebbero essere inclusi direttamente nel pacchetto di K3B?
Secondo me si. Magari si potrebbe fare un superpacchetto che include questo
tipo di dipendenze.


 Voi cosa ne pensate?
In generale e per l'uso di programmi per uso desktop posso darti
ragione. Effettivamente poterbbe essere comodo installare un xmms et
simila da un semplice eseguibile come l'esempio di firefox che hai
preso. Ma per il resto è un discorso improponibile. Ci sono software
che devono essere configurati "a dovere". Esempio: Apache. Se dovessimo
utilizzare solo versioni compilate staticamente di apache perderemo la
sua modularità che è il suo pregio migliore. Non dimentichiamo la
sicurezza: sempre parlando di apache non lo puoi lasciare compilato 20
moduli dei quali ignori le funzioni. Se viene scoperta una
vulnerabilità nelle librerie chessò di phyton, oppure perl oppure
quello che ti pare.. saresti nella merda. Invece con un caricamento
dinamico dei moduli sei tu a decidere cosa deve fare sto web server. Mi
serve che interpreti il php.. bene carico il modulo per la sua
interpretazione, altrimenti mi basta commentare una direttiva per fare
in modo che quella funzionalità venga disattivata. QUESTO è IL VERO
PREGIO DI UN SISTEMA UNIX LIKE.
linkando staticamente le librerie perdersti semplicemente il grande
vantaggio di usare linux. 
saluti ribbed

 C'entra, c'entra. Se tutto e' gia' presente cosa installi a fare?
Non capisco se tu stia cercando di fare un flame o meno.


 vantaggio di usare linux.
Beh.. credo che Linux abbia ben altri vantaggi da vantare. ;)


 programma e scaricarmi l'eseguibile.
Perchè tu sei abituato con Windows, semplice.
-- 
Vide
"Rock'n'roll is just rock'n'roll" (AC/DC)
NP: Nulla

 Non ho il tempo di leggerlo ma mi sembra interessante.
E' quasi quello che avevo in mente io, a parte la reinstallazione sulla
macchina che è IMO troppo complicata perchè devi crearti il repository
locale. Basterebbe che andasse a colpi di dpkg, no?


 Perchè tu sei abituato con Windows, semplice.
In realtà no. Comunque, qual'è il punto? Perché in Windows si fa così allora
non va bene?


 Non ho il tempo di leggerlo ma mi sembra interessante.
E' interessante si, ma troppo macchinoso. Non è alla portata di tutti. E non
risolve tutti i problemi che può creare l'attuale sistema di dipendenze.


 senza preoccupazioni.
Poi si scopre che quel programma ha un baco in una libreria che gestisce
le jpg, o che gestisce la connessione a internet, o che gestisce la
crittografia dei file salvati e mentre sei in vacanza alle maldive devi
tornare indietro con ancora l'asciugamano attorno alla vita per
cambiarli a tutti i tuoi amici e conoscenti.
Le distribuzioni senza librerie condivise invece di occupare qualche
centinaio di MB come ora occuperebbero 1-2GB come avviene con OSX o
Windows XP. Con l'installazione normale, mica mega transformer super
extra (cit).
Lo dico e lo ripeto:
Se c'e` un punto dove linux (ma anche i bsd) NON ha problemi e`
l'installazione/disinstallazione/mantenimento del sistema operativo. E`
estremamente resistente al chaos e in modo estremamente semplice.
Mettere in discussione i sistemi esistenti lo si puo` fare solo partendo
da determinate condizioni, ad esempio parlando di come renderli ancora
migliori.
Io ho 60GB di disco su sto ibook. Senza nulla di esagerato installato.
Ho una home da 2 GB. Pero` in totale, in questo momento, ho 10GB liberi.
Per fare un esempio... Calculator.app occupa 1.6MB. Una calcolatrice!!
Colloquy.app (un client irc) occupa 23MB. Emacs.app occupa 160MB.
Dico... Ora capisco perche` non ho piu` spazio.


 allora non va bene?
E allora qual'è il punto? Perchè in Windows si fa così allora va bene?
Quando poi per installare il 90% di questi setup.exe ci vogliono i
privilegi di amministratore, facendo così che la stragrande maggioranza
degli utenti debbano girare come amministratori con tutto il rischio che
ciò comporta?


 Dico... Ora capisco perche` non ho piu` spazio.
Ora arriverà ginopilotino dicendo che tanto i dischi al giorno d'oggi
costano poco. Specie se te li vende Apple. <g>


 programma e scaricarmi l'eseguibile.
E non solo tu. Ma ogni volta che scarichi qualche pezzo di software da 
installare sul tuo computer fai un atto di fede.
Che consiste nel fidarsi che quel pezzo di software faccia 
effettivamente quello che afferma di fare, nulla di meno e nulla di più.
Il fatto che la gente sia incline a fare parecchi di questi atti di fede 
è noto, e di pari passo viene sfruttato.
Con quello che gira di questi tempi, meno di questi atti di fede debbo 
fare, meglio è.


 migliori.
Beh.. ognuno ha una propria idea di cosa sia migliore.


 ciò comporta?
Tu, invece, quando installi qualcosa in Linux non diventi root, vero?


 fare, meglio è.
Perché, quando scarichi i sorgenti e li compili non fai un atto di fede?
L'unico modo per evitare questo problema è quello di affidarsi unicamente a
progetti molto conosciuti, diffusi ed a codice aperto. E, comunque, non si
è in una botte di ferro.


 dell'apertura del pacchetto corrisponda l'avvio del package manager.
Intendevo qualcosa del genere. Ma anziché il package manager una "shell" al
package manager con annesso wizard, che piace molto a chi arriva da Windows
;)
-- 
___/\/o\/\/here/\/\an___
"Vagisil migliora 
la tua vita intima"
http://www.vagisil.com/teencenter.shtml

 programma che volevi come avevi richiesto "offline".
Uhh! Carina come idea... forse forse non sarebbe troppo complicato fare uno
shell script che generi a sua volta uno script che faccia quanto dici. Non
sono ancora cosě esperto, ma scommentto che č altamente fattibile!
Shell-guru, fatevi avanti :)


 Tu, invece, quando installi qualcosa in Linux non diventi root, vero?
Reimmetto la mia password di utente e seleziono il programma che voglio
installare dalla lista presente, che comprende migliaia di programmi di
tutti i tipi. E no, il mio Firefox/Konqueror non gira coi permessi di root.



Part of the inhumanity of the computer is that, once it is competently 
programmed and working smoothly, it is completely honest. (Isaac Asimov)

 gestirli. Quattro risate me le faccio volentieri.
Ammazza che idiozie... gestire che? E` un file system, che sia in 
/usr/bin, /applications oppure in /boot/apps non c'entra nulla.


mi intrometto nella discussione, linkandovi un progetto, che appare 
abbastanza valido, guardate le animazioni in flash, che mostrano come 
funziona.
http://autopackage.org/gallery.html
ma soprattutto sappiate, che questo e' un sistema di package 
*indipendente dalla distribuzione* !!!
Leggete questo, e' moooooolto interessante, sono i programmi futuri del 
progetto
http://autopackage.org/ui-vision.html
Leggete, leggete !!!, magari se non siete tanto ferrati con l'inglese, 
usate google e il suo sistema di traduzione....(meno di niente...)
http://translate.google.com/translate?u=http%3A%2F%2Fautopackage.org%2Fui-vision.html&langpair=en%7Cit&hl=it&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools
-- 
Ascoltate il ballodisanvito !!!!
solo su Podcast di Itunes
http://phobos.apple.com/WebObjects/MZStore.woa/wa/com.apple.jingle.app.store.DirectAction/viewPodcast?id=79931924

 *indipendente dalla distribuzione* !!!
Non č male, l'avevo anche provato, mi sembra :)


 qualunque OS.
No e poi no. Non e` un problema e non lo e` qualsiasi cosa tu dirai.


 Beh.. ognuno ha una propria idea di cosa sia migliore.
Dato che i maggiori OS esistenti attualmente li ho provati tutti e
conosco gente che li usa tutti e sono ai 'massimi livelli' nella loro
piattaforma penso di poter dire di avere un pochino di esperienza
riguardo a cosa significa installare roba sui vari sistemi operativi.


 Perché, quando scarichi i sorgenti e li compili non fai un atto di fede?
Altroché. E non solo verso gli autori di quei sorgenti, ma anche verso 
coloro che hanno preparato tutti gli strumenti di build. :-)
Ma quantomeno, per entrar nel repository di una distribuzione, un 
pacchetto passa per tutta una serie di controlli sul campo da parte di 
gente diversa dagli autori del software che riducono grandemente la 
possiblità che contenga codice malevolo.
Non che siano chissà che controlli, per carità, ma sono comunque un 
certo insieme di controlli che un utente finale non farebbe.
Se prendiamo ad esempio il repository Debian, esso è tenuto in piedi da 
un insieme di persone che hanno costruito una rete di fiducia reciproca, 
con delle regole per estendere tale insieme che dovrebbe tagliar fuori 
eventuali malintenzionati. E visto che le cose le pacchettizzano, le 
hanno anche un po' provate.
Ciò non esclude che un pacchettizzatore debba fidarsi in una certa 
misura degli autori del software, e che quindi non sia matematicamente 
impossibile che nel repository di una distribuzione entri software 
malevolo. Tuttavia ciò riduce grandemente il rischio che accada qualcosa 
del genere.
Da qui l'idea: meno atti di fede debbo fare, meglio sto. Ne faccio uno 
piuttosto grande verso chi prepara il repository della mia 
distribuzione, e bene o male dovrei essere ragionevolmente a posto.
Preferirei non doverne fare proprio, ma ciò è ovviamente impossibile.


 root.
Io, da Windows, clicco col tasto destro sull'installer, seleziono esegui
come, immetto sysadmin e la password, ed l'installazione parte, anche se il
mio utente è limitato (XP Home, quindi particolarmente limitato).
Però, per installare il programma, in entrambi i sistemi il processo che se
ne occupa deve avere potere di amministratore.


 Preferirei non doverne fare proprio, ma ciò è ovviamente impossibile.
Tutto quello che hai detto è giusto, ma è più un confronto tra open source o
closed source.


 riguardo a cosa significa installare roba sui vari sistemi operativi.
come detto sopra, probabilmente hai poco a che fare con gli utenti medi.


 Voi cosa ne pensate?
Quello che hai detto e` un nonsense. Stai facendo le cose ancora piu` 
difficili per nulla.
Gia` ora installare un programma su una distribuzione linux e` di una 
facilita` disarmante e non serve semplificarlo ulteriormente.
Se un programma e` gia` nel repository per avere la versione successiva 
devi solo attendere che venga pacchettizzata. Nulla di piu` semplice e 
funziona davvero bene come sistema.
Per i software commerciali e` differente. Non possono essere 
pacchettizzati dalle distribuzioni non tanto per il sorgente chiuso 
(avendo i file binari si puo` fare benissimo) quanto per il fatto che il 
software deve essere venduto e quindi deve essere distribuito in un 
canale differente.
In questo caso la soluzione migliore e` compilare tutto staticamente in 
modo tale da non dover dipendere da librerie di versioni differenti. Il 
file che si scarica puo` essere benissimo un programma autoinstallante 
che si posiziona interamente in una directory (ad esempio 
/opt/nome_programma). Non e` un sistema integrato nella distribuzione 
ma, per i pochi programmi commerciali che ci sono adesso su linux, e` 
altrettanto semplice.
Nulla vieta a chi programma un software opensource a rilasciare un 
binario come ho appena descritto in modo tale da poter essere installato 
ovunque. Saranno poi le distribuzioni a prendere il sorgente ed a farne 
un pacchetto ottimizzato.
-- 
| Massimo ;-) -> 
http://maq.altervista.org
        | (o-  POWERED  |
|- BABYLON 5  -> 
http://babylon5.altervista.org
   | (/)_ BY LINUX |
|- STARGATE   -> 
http://sg1screw.altervista.org
   | And the sky   |
|- USSTRIBOLO -> 
http://usstribolo.altervista.org
 | full of stars |

 semplice e funziona davvero bene come sistema.
Rileggendo il messaggio mi sembra di non aver reso bene esplicito il mio 
pensiero: bisogna usare i pacchetti della distribuzione il piu` 
possibile. Se c'e` da impegnarsi e` proprio su questo punto, fare in 
modo che tutto il software possibile sia installabile via gestore 
pacchetti e repository.
I sitemi alternativi (compilare staticamente o altro) sono da fare in 
casi eccezionali e solo come ultima soluzione.
Oltre a questo, i software proprietari ma gratuiti possono essere 
pacchettizzati senza problemi vedi driver schede video.


 mio utente è limitato (XP Home, quindi particolarmente limitato).
Peccato che poi, in buona parte dei casi, l'applicazione non funziona 
con i privilegi limitati, a cominciare dai giochi (che sono l'ultima 
cosa che dovrebbe girare in un account privilegiato).
saluti,
daniel

 Voi cosa ne pensate?
C'è una cosa che va considerata prima di qualsiasi altra.
Sotto Windows c'è qualcosa che Linux non ha.
L'architettura.
Sotto Windows molte cose funzionano perchè si applica il
principio che le applicazioni devono basarsi tutte su API
comuni e standardizzate, ed avere tutte il medesimo
comportamento. Allora, se io voglio stampare su Win95
devo passare dal Print Manager: anche se in WinXP lo
aggiornano con nuove funzioni possono comunque
garantire la retrocompatibilità perchè la vecchia API è
nota, e perchè so già che le vecchie applicazioni Win95
passeranno richiameranno tutte il vecchio Print Manager
per stampare.
Sotto Linux questa architettura non c'è (salvo qualche eccezione).
Linux è un kernel, sul quale le distribuzioni mettono dei servizi
ed un sistema di installazione/configurazione. Ma queste cose
non sono del tutto standardizzate e di conseguenza non si può
garantire l'interoperabilità dei pacchetti.
Supponiamo di volere fare ciò che dici. Intanto bisognerebbe
creare un formato comune, la cui sigla diventi comune tra gli
utenti come .mp3 o divx. Per esempio, un formato LinuxSetup:
la gente deve sapere che se fai doppio clic su questi LinuxSetup
si installa la relativa applicazione. Ok.
Facciamo un pò di astrazione. Questi LinuxSetup non dovrebbero
funzionare solo se c'è una connessione ad Internet: questo perchè
io potrei volere lavorare anche off-line o forse (ed è facile) non ho
i drivers del modem ADSL per Linux, o per qualsiasi motivo. Se
questi LinuxSetup possono funzionare sia in remoto che in locale
(cioè, contengono tutto quello che serve per fare funzionare la tale
applicazione), io posso fornire le applicazioni che servono anche su
un cd-rom che si compra in edicola (che è molto più comodo che
scaricare gb di roba, giusto?), od ancora, posso fornire applicazioni
commerciali su cd-rom che si comprano nei negozi specializzati.
Quindi, ritengo, sarebbe opportuno che sti LinuxSetup possano lavorare
sia in remoto che in locale. Inoltre, ritengo, questi LinuxSetup non
dovrebbero semplicemente essere degli archivi (e qui .RPM e .DEB
già non vanno più bene), ma dovrebbero contenere il codice per
eseguire il wizard di configurazione del programma (perchè magari io
voglio installare il componente X dell'applicazione, ma non il componente
Y).
E qui nascono i primi problemi. Per scrivere questi LinuxSetup, che quindi
hanno un'interfaccia grafica (come i setup di Windows), che toolkit per
X uso? QT o GTK? Nota che non c'è nessun documento che stabilisca che
ogni distribuzione linux debba comunque installare sempre le librerie QT
e le librerie GTK, cosicchè, già questo è un ostacolo alla creazione di
questi LinuxSetup. Il problema è talmente sentito, che anche grossi nomi
(Matrox, Nvidia) installano i loro drivers con dei meravigliosi script .sh
(nel 2005 e con un sistema operativo grafico, ciò è molto, molto bello
ed elegante.....:((). Ma, comunque, io posso anche pensare di linkare
staticamente le librerie GTK o QT nel codice del LinuxSetup, e quindi
supponiamo di potere superare questo problema.
Secondo problema. Che cosa installo? E' ovvio che i pacchetti non possono
essere completamente autocontenuti per evidenti ragioni di spazio. La
soluzione migliore è stabilire un insieme di librerie ufficiali che devono 
essere
installate in ogni distribuzione obbligatoriamente. E qui nascono i primi
guai. Chi può obbligare ogni distribuzione a seguire certi standard? L'unico
che detiene i diritti sul kernel, che potrebbe imporre questo come requisito
per potere continuare ad usare il kernel sui propri prodotti. Sennonchè,
quel personaggio non ne ha la benchè minima intenzione (però parla di
usabilità...).
Risultato: non esiste nessun insieme di librerie che debbano
obbligatoriamente essere installate su ogni distribuzione. Se tale
set di librerie esistesse, allora non avremmo nessun bisogno
di linkare statico: il LinuxSetup dovrebbe contenere solo i 2,3,4
componenti che sono non definiti nello standard (e quindi potrebbero,
in teoria, non essere già installati), mentre gli altri non dovrebbero 
essere
contenuti nel LinuxSetup, perchè tanto siamo sicuri che sono già
installati essendo previsti dallo standard.
Ciò porterebbe a LinuxSetup piccoli, autocontenuti,
e con linking dinamico.
Sembrerebbe la soluzione ottimale. Supponiamo di fare così?
Credi che abbiamo risolto?
No, purtroppo, perchè c'è un'altro problema: la name-consistenza. Questo
è un problema così grave che nessun produttore è riuscito a creare
finora la tecnologia di cui discutiamo.
Cerco di spiegarti. Supponiamo che io stia installando il programma
Gimp e che il LinuxSetup di Gimp sappia che quella versione del programma
richiede la libreria Rosso-2.3.4.lib.
Nel sistema, è presente la libreria Rosso-2.5.2.lib.
Nota che LinuxSetup non può semplicemente eseguire un fopen su
Rosso-2.3.4.lib, perchè **non si tratta** solo di sapere se un
*file* chiamato Rosso-2.3.4.lib sia presente o meno in /lib.
Per esempio, anche se il file Rosso-2.3.4.lib **non** è presente in /lib,
LinuxSetup non deve installarlo, se è presente Rosso-2.5.2.lib e questa
dichiara in un header che essa è compatibile anche con Rosso-2.3.4.lib.
Sono stato chiaro?
Come si risolve? Semplice: si dice che da domani, anno di grazia 2006, tutte
le librerie hanno un nuovo formato, e devono dichiarare in un header
con quali versioni sono retrocompatibili. In questo modo, un API di sistema
in fase di installazione dice a LinuxSetup una cosa tipo: "guarda, tu vuoi
sapere se ho Rosso vers. 2.3.4. come libreria. No, però ho Rosso vers. 2.5.2
che si dichiara retrocompatibile con la vers. 2.3.4. Non c'è bisogno che
installi nulla", oppure "Rosso? Mai sentito dire niente di simile. Installa 
la
tua Rosso lib vers. 2.3.4 ed io aggiorno il mio database di sistema."
E' anche necessario un nuovo formato per i programmi eseguibili che 
sostituisca
l'ELF. Le applicazioni **non** possono più vedere in /lib se una tale
libreria è presente: sono costrette a passare per l'API di sistema. Non
possono provare una fopen su Rosso-2.3.4.lib (se non è presente, ed
è presente una Rosso-2.5.2.lib, il software fallirebbe; è la cosa che 
succede in
molte distribuzioni quando non hai l'RPM specifico per la tua distribuzione
e devi usare quello di una distribuzione diversa: spesso non corrispondono
i nomi delle librerie e gli utenti si dovrebbero fare i link simbolici a 
mano,
sennò il programma non funziona).
Le applicazioni vengono invece linkate dinamicamente alla libreria di
sistema corretta (l'ultima versione che si dichiara compatibile con la
libreria per la quale è stato progettato l'eseguibile), e tutti i controlli
avvengono a run-time ed in modo trasparente all'applicazione.
Bene. Indovina perchè nessuno ha mai pensato ad una soluzione di
questo genere?
Perchè i vecchi script e le vecchie applicazioni Linux restano fuori. Da 
quel
momento la compatibilità binaria con le vecchie applicazioni Linux cessa
di essere garantita.
Sfortunatamente, sotto Unix le applicazioni hanno la bruttissima
abitudine di richiamare script (vedi il successo che hanno avuto
TCK e TK ad esempio). Ed hanno la brutta abitudine di far fare
al file system praticamente tutto (è un retaggio delle illuminate
filosofie KISS e Anything is file).
Pertanto, i programmi che per vedere se c'è una libreria Pippo-2.7.8
guardano in /lib se c'è il file Pippo-2.7.8 (cogli la sottigliezza, e
capisci perchè è una cazzata), ce ne sono troppi.
Linux non può essere semplificato con il software di pacchettizzazione X,
con la pezza Y, con lo strato di casino Z. Prova ne è che dopo decine
di tentativi di chi fa le distribuzioni, siamo ancora al punto di partenza.
Servono dei cambiamenti strutturali radicali in quel sistema, a costo
di perdere la compatibilità con le vecchie applicazioni.
Ulteriore problema: l'integrazione del programma con il resto
dell'ambiente.
Per esempio: se io ho installato un ipotetico WinAmp per Linux, poi desidero
che quando faccio clic con il tasto destro su un .MP3 mi appaia una
voce "Open with WinAmp". Per fare questo, il codice del LinuxSetup
dovrà andare a scrivere questa voce da qualche parte.
Sotto Windows è facile: il registry ha le sue voci CLSID ed ha un API
che consente di inserire dei nuovi menù contestuali nella GUI.
Sotto Linux? Naturalmente non c'è un API standard e spuntano casini.
Devo scrivere due pezzi di codice diverso a seconda che sia installato
Gnome o che sia installato KDE? E se domani Gnome sposta il
file dove si mettono le voci del menù contestuale in un altro posto?
Il mio pezzo di codice (e quindi il mio installer) cessano di funzionare?
Ancora una volta, la mancanza di API unificate (e quindi di astrazione)
ha effetti nefasti. Se KDE e Gnome poggiassero su un substrato
comune di API, allora non ci sarebbero problemi. Il codice di LinuxSetup
richiamerebbe una certa funzione e questa installarebbe una voce
nel menù contestuale, *indipendentemente* dal fatto che sia installato
Gnome, KDE, o un nuovo mirabolante DE sviluppato in seguito.
Oppure, supponi di volere installare un pacchetto per vedere i .divx.
Ok, installo un codec. Ma dove va installato? Qual è l'API che gestisce
queste cose? Non c'è. Quindi, *ipotizzando* che sia installato
XMMS o Xine, i codec vanno qui e speriamo bene (ed addirittura, siccome
manca una architettura per sfruttare le accelerazioni video per la
visione dei filmati (DRI è del tutto insufficiente), si sfruttano codec
di Windows non nativi, roba da ridere).
Ultimo punto: la struttura del file system (oggi per fortuno standardizzato
un poco con la LSB). Sotto Windows, le directory critiche del sistema
sono contenute dentro delle voci del registry. Le applicazioni non vanno
a scrivere in C:\Programmi (scritto staticamente nel codice come 
C:\Programmi),
ma vanno a scrivere nella directory che è contenuta dentro al registry,
voce X.Y.
Che poi questa sia C:\Programmi in Win98,
o C:\Windows LongHorn\I miei programmi, poco importa: ed infatti, con
questa tecnica, anche le vecchie applicazioni si integrano perfettamente
nel nuovo ambiente senza bisogno di essere riscritte. Basta introdurre dei
nuovi valori come identificatori di directory di sistema.
Sotto Linux?
Saluti
Pegasus

 diversa.
Strumenti di amministrazione/Gestione computer.
Saluti
Pegasus

 Strumenti di amministrazione/Gestione computer.
Troppo difficile, l'utente normale continuera` ad usare le lettere. Le 
cose furbe bisogna metterle di default altrimenti non sapra` mai che 
esistono.



Questo è un problema del gioco e dei dementi che l'hanno creata, l'installer 
non c'entra una mazza.
Comunque se mi fai qualche esempio...
Saluti. 

 miei occhi.
Se dici così, hai dei pregiudizi, e contro quelli ragion non vale.


 procedura per mettere le cose a posto.
Un bel po' più lunga: come fai a ad avere un elenco dei i binari che 
hanno linkato staticamente una libreria?
IMHO qualsiasi cosa che complichi la risoluzione di un problema di 
sicurezza è in sè un problema di sicurezza, perché scoraggia la gente 
dall'installare le patch necessarie.
E poi ci si ritrova con exploit vecchi di mesi che fanno ancora danni.
+++
Mi par di capire che su Windows i service pack e le patch generali al 
sistema non siano molto ben viste perché dopo la loro installazione 
succede non di rado che alcuni applicativi (probabilmente non molto ben 
fatti) non funzionino più correttamente.
Per cui comprendo che ci sia un certo desiderio di poter patchare gli 
applicativi individualmente.
Però su altri sistemi non mi pare sia così.


 hanno linkato staticamente una libreria?
Beh... non è affatto necessario che tutto sia compilato staticamente. In
quel caso si ci sarebbero grossi problemi a mantenere il sistema. Se la
cosa fosse circoscritta a pochi programmi i problemi sarebbero molto pochi.
Comunque non credo sia così complicato estendere le attuali utility di
aggiornamento del sistema per verificare se ci sono installati programmi di
questo tipo che devono essere patchati.
La necessità di avere un programma compilato staticamente nasce
dall'esigenza di poter scaricare direttamente dal sito del progetto un
unico file che permetta di avere il programma funzionante sicuramente su
tutte le distribuzioni.
Dovrebbe rimanere un'eccezzione, non la regola.
Concordo sul fatto che non sia la soluzione ottimale. Ma, quale potrebbe
essere l'alternativa? Quel progetto autopackage mi sembra un'ottima idea.
Rimane però il fatto che l'utente dovrebbe cercarsi tutti i package da cui
esso dipende. Serve qualcosa che risolva questo problema.
Se c'è un'alternativa al compilare staticamente ben venga. Secondo te?


 Se c'è un'alternativa al compilare staticamente ben venga. Secondo te?
Se rimane un'eccezione alla regola mi sta anche bene.


 tipo di dipendenze.
Quindi io che uso sia K3b che altri programmi di masterizzazione, dovrei
installare n volte cdrecord e compagnia ?
-- 
-----------------------------------------------------------------------
 (o_        Vinci                     registered Linux User #276630
 //\         " Violence is the last refuge of the incompetent "
 V_/_                     Salvor Hardin, Foundation

 
No. Quando installi k3b viene verificato se i programmi sono già ci sono, se
non lo sono provvede ad instarli.


 CUT di roba che non leggo nemmeno perchè troppo annoiato
Ma invece di scrivere enciclopedie per gente lobotomizzata non potresti
essere conciso?
Alla fine sono 4 idee in croce dette come se tu parlassi a gente che non
ne capisce una minchia
-- 
Dont         |            _             _ 
understimate |   __ _ _ _| |_ __ _ _ _ (_)
the power    |  / _` | ' \  _/ _` | ' \| |
of...        |  \__,_|_||_\__\__,_|_||_|_|

 Quindi per te F: è un concetto più semplice di /media/usbdisk
Certo che lo è: per quale motivo la chiavetta usb dovrebbe stare dentro
una directory dell'hard disk?


 non lo sono provvede ad instarli.
peccato che l'auto di k3b non sia l'autore di cdrecord. sai che casini
quindi? non tanto perche' il software non sia libero, quanto per che' la
gente scasserebbe le balle all'autore di k3d per i problemi di cdrecord.

 nomi.
Non si tratta di mettere insieme i due nomi. Si tratta di capire che un
sistema operativo grafico ha delle precise API comuni e che fanno
parte del sistema operativo grafico (**non** del desktop enviroment),
e su cui semmai si può porre sopra, dopo, un desktop enviroment.
Qui invece c'è un kernel, su cui hanno posto un interfaccia grafica
alquanto inefficiente (X), su cui a sua volta è stata posta una coppia di
programmi (KDE e Gnome), che però si sentono sistemi operativi
grafici e che usano le loro API, le loro utility, i loro metodi di
registrazione della configurazione.... tra poco si mettono a
configurare l'hardware....
.. Peccato che lo facciano in modo incompatibile....
Saluti
Pegasus

 una directory dell'hard disk?
E perché non dovrebbe?
Dopotutto, anche il file manager Windows ti sbatte in faccia una 
cartella dove raccoglie tutti i dispositivi di memoria di massa, solo 
che questa non esiste nel filesystem.
Preconcetti, preconcetti...


 il file-system
No: quella che stai citando è FSB (Filesystem Standard Base).
LSB (Linux Standard Base) è decisamente un'altra cosa
 
http://www.linuxbase.org/
e si propone esattamente di standardizzare diversi aspetti delle 
distribuzioni in modo da facilitare la realizzazione di software 
cross-distribuzione.


 già preparato la foresta di link simbolici in /lib. 
I link simbolici di cui parli non sono fatti "a mano" dalla gente di 
SuSE, ma sono automaticamente generati da ldconfig, che li genera in 
base al soname della libreria (nome+versione interna), che è ciò che il 
linker dinamico ELF usa per determinare se una certa libreria 
corrisponde alle richieste del programma che la linka, indipendentemente 
dal nome della stessa.
Se per esempio fai un "ldd /bin/ls", vedi un elenco a due colonne: 
quello a sinistra è l'elenco dei soname delle librerie richieste, e 
quello a destra è il file che contiene la libreria che specifica quel 
soname. I link servono per aiutare ld.so a trovare le cose più in fretta 
la prima volta, ma poi viene tenuta una cache della corrispondenza 
soname => file in /etc/ld.so.cache
Se noti, il soname include solo il nome e la major version della 
libreria, la quale (la major version) va cambiata se ci sono modifiche 
incompatibili all'indietro.
Funziona in maniera praticamente identica su tutti i sistemi ELF (anche 
su Solaris e HP-UX 64 bit, per intenderci).


 
e per quale motivo dovrebbe stare fuori?

 il caricamento di moduli...
l'interfaccia per caricare i moduli standard esiste gia' da tempo.
forse inetdni abi binaria? quella non ci sara' mai. e non e' nemmeno un
problema visto che ci sono moudli proprietari che vivono benissimo lo
stesso.

 Sotto Linux?
da bsd in poi le directory hanno sempre avuto un senso. ma mi sembra che
te lo abbiano gia' contestato

 e su cui semmai si può porre sopra, dopo, un desktop enviroment.
orsu' definisci queste api. Almeno delle linea di massimo.

 Preconcetti, preconcetti...
Io ho motivato la mia affermazione, dunque non mi pare proprio sia un
preconcetto. Peraltro l'idea di fondo è anche banale: sbaglio o qui si
sosteneva che un sistema per essere intuitivo deve mimare la realtà?


 e per quale motivo dovrebbe stare fuori?
Vedi risposta sotto


 stesso.
Intendevo la definizione di una interfaccia standard permamente alle
minime modifiche del kernel, in modo che un modulo compilato su 2.6.x vada
anche su 2.6.y, e magari anche 2.8.z.


 CUT
Al resto hanno risposto gli altri :)


 - Using Thunderbird

 situazione reale
Quindi, quando ho tre partizioni, ho tre hard disk? :-)
Preconcetti.




Ma questo sono certo che già lo faccia!
-- 
___/\/o\/\/here/\/\an___
"Vagisil migliora 
la tua vita intima"
http://www.vagisil.com/teencenter.shtml

 Preconcetti.
Sono in nutrita compagnia: ho la netta sensazione che quelli di GNOME la
pensino come me. (Vedere voce "computer")



Part of the inhumanity of the computer is that, once it is competently 
programmed and working smoothly, it is completely honest. (Isaac Asimov)

 conto.
Compilare staticamente e` l'unica vera via se vuoi che le cose 
funzionino sempre. Tutti i programmi grossi per linux preferiscono 
linkare statico al posto di produrre N pacchetti. Matlab addirittura ha 
dentro java della sun, immagina un po'...


te lo abbiano gia' contestato
Hai ragione. Adesso scusami, ma la mia applicazione vuole
aprire il cd-rom e leggere dei file.
Il cd-rom и montato in?
(possibilmente, vorrei evitare l'overhead di aprirmi
/etc/fstab, c'и qualche API di sistema che mi dice
dove и montato il cd-rom, nevvero? c'и qualche API
che mi consente di ignorare dove effettivamente sia
montato il cd-rom, e di lavorarci lo stesso, nevvero?)
Saluti
Pegasus

 No e poi no. Non e` un problema e non lo e` qualsiasi cosa tu dirai.
No, dico che e` un problema.


 Potrei spiegartelo ma cui prodest? Non certo a te.
Ripeto: gestire cosa? Cosa c'e` di strano ad avere tutti i sacrosanti 
file in una directory? Magolamagamagia?


 anche su 2.6.y, e magari anche 2.8.z.
Non e` garantito, e non lo sara` mai a meno di cambiamenti radicali 
degli sviluppatori del kernel.


 orsu' definisci queste api. Almeno delle linea di massimo.
- una API che gestisce l'installazione dei componenti (programmi,
librerie, codec ecc. ecc. ecc.)
- una API che gestisce il sottosistema grafico (2d, 3d, accelerazione
video, supporto codec nativi per la piattaforma, senza bisogno di
toolkit esterni)
- una API che gestisce il sonoro;
- una API che gestisce i drives di rete (deve essere integrata nel
sistema, non essere un tool esterno alla samba)
- una API che consenta di astrarre la posizione dei dispositivi
nel file system (trasparenza rispetto ai mount-pount)
- una API che si occupa della stampa (spooling centralizzato,
tutti i processi di stampa passano per il Print Manager);
- una API che si occupa del database di sistema;
- una API che si occupa della inizializzazione, della configurazione,
della disattivazione dei drivers dell'hardware di sistema;
- una API che esegua il name-transform sul file system (in modo
da rendere il namespace più gradevole agli utenti e nascondere
le eventuali differenze nel file system tra una distribuzione e
l'altra);
Per ora non me ne vengono in mente altre.
Saluti
Pegasus

 Comunque se mi fai qualche esempio...
Io la vedo come una questione di cattiva abitudine in cui si è adagiato 
sia l'utente che gli sviluppatori (che non si pongono affatto il problema).
Adesso non so dirti tra le varie demo che ho provato quale va, quale non 
va e quale va in parte, ma posso dirti che dei 3 giochi che uso più 
spesso, ossia TrainZ, Train Simulator e Railroad Tycoon 3 (si, sono 
appassionato di ferrovia), tutti devono girare con l'account privilegiato.
Cmq giorni fa ho scoperto per caso che in un account limitato di XP non 
parte Acrobat Reader (che tenta di installare il Journal Viewer 
(peraltro già installato)), ma non ci ho perso più di tanto.
saluti,
dan

 Con l'attuale architettura di Linux, tu questo non lo vedrai *mai*.
ftp://ftp.idsoftware.com/idstuff/quake4/linux
E lasciamo perdere il resto che tanto non è meglio...

 ha scritto nel messaggio 
news:pan.2005.12.16....@uno.com...

Già. Meglio se lasci perdere.
Ma meglio....
Dunque, qui ID software fa un bellissimo binario per
linux che si appoggia su file di windows (soluzione che
non è detto tu possa usare sempre).
Per installarlo devi copiare roba a mano.....
... e tu mi dici che è una situazione ideale? Ma certo,
eccotela la tua situazione ideale:
http://www.linux-gamers.net/modules/news/article.php?storyid=1031
http://www.fedoraonline.it/modules/newbb/viewtopic.php?topic_id=710&forum=2
Saluti
Pegasus

 Per installarlo devi copiare roba a mano.....
Non lo hanno incluso nel CD e non hanno fatto un installer. E' necessario
scompattarlo e lanciarlo... Esattamente come uno Zip sotto Windows..
Ad ogni modo tu affermavi che non era possibile distribuire binari per
Linux perchè sarebbe stato necessario farne uno per distribuzione. 
E portavi ad esempio proprio Quake 4... Sei stato spernacchiato e hai
ancora qualche cosa da dire ? Facevi più bella figura a nasconderti... 
E, ripeto, per pura pigrizia evito di commentare le restanti tue
affermazioni, visto che sono dello stesso livello...

 Con l'attuale architettura di Linux, tu questo non lo vedrai *mai*.
e perche' no
sopra hanno detto che i pacchetti che si installano come in windows ci sono
e io ci credo perche' tempo fa li ho uasati
-- 
L|EL|E|

 Linux perchè sarebbe stato necessario farne uno per distribuzione.
Ed è possibile, l'esempio è Quake 4?
Oddio, un programma in cui non c'è l'RPM, non c'è il wizard,
non c'è un cazzo, c'è solo l'idea geniale degli sviluppatori di
un file eseguibile da copiare lì, e poi copiare gli altri file dal
cd di quake di windows? E tu credi che questo si possa fare
con qualsiasi applicativo?
Certo, naturale, si può fare, basta fregarsene della compatibilità
con le librerie del sistema preesistenti. Ed infatti:
http://www.linux-gamers.net/modules/news/article.php?storyid=1031
/cite/
The Quake 4 GNU/Linux FAQ has been updated. It now targets crashes with 
Debian (and Debian based distributions) and offers a workaround.
Gamers how use one of those distributions got an error message caused by 
their SDL libraries during startup. To solve the problem you need to install 
libsdl1.2debian-alsa or libsdl1.2debian-oss instead of libsdl1.2debian-all.
/cite/
Ma come?! Io non capisco sta cosa.
Linux ha le librerie standardizzate, ha un ambiente standardizzato,
non ci sono problemi di compatibilità binaria, le API sono standard,
tutto è standard....
... ed ora viene fuori che quel quake4-linux su Mandrake magari
parte mentre su una distribuzione Debian based NON parte perchè
su Debian occorre usare le librerie libsdl1.2debian-alsa e *non*
(udite udite!) le librerie libsdl1.2debian-all !!!!!
Me cojoni, scusatemi tanto eh!!!
Ah vabbè, scusatemi tanto tanto, vuol dire che il problema si risolve
così: prendo un file eseguibile e lo copio.... Di certo lo posso fare
uguale per tutte le distribuzioni e siccome parte su tutte le distribuzioni
(forse parte e va in errore su alcune, ma vabbeeee!!!) ho dimostrato
che posso fare installer (ROFTL!) universali per linux.
Grazie per l'attenzione.
Saluti
Pegasus

 una directory dell'hard disk?
Non è "una directory dell'hard disk". / è il tuo sistema, non il tuo HD.
Ripeto, applichi preconcetti di Windows al mondo Unix, quando al limite
dovrebbe essere il contrario perchè Unix è un attimo più vecchio di
Windows.
E cmq sia con KDE che con Gnome graficamente nel tuo "sistema" vedi la penna
a parte.
-- 
Vide
"Rock'n'roll is just rock'n'roll" (AC/DC)
NP: Nulla

 Shell-guru, fatevi avanti :)
Per debian c'e` apt-zip:
<cite source="apt-cache">
 These scripts simplify the process of using dselect and apt on a
 non-networked Debian box, using removable media like ZIP floppies.
 One generates a `fetch' script (supporting backends such as wget and
 lftp, in a modular, extensible way) to be run on a host with better
 connectivity, check space constraints of your removable media, and
 then install the package on your Debian box.
 .
 Note on current version: space-checking is not done and spanning
 multiple disks is not yet supported.
</cite>
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Eloi, Eloi,
"@'/ ,. \`@"    \|| |     |   Lama Sabachthani !!!
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |

 /cite/
Visto che sei in vena di citazioni, cita quando uno stordito affermava che
non era possibile fare un programma che girava su tutte le distribuzioni.
Il programma, facile o difficile che sia da installare, esiste, e guarda
caso è proprio lo stesso citato per affermare l'opposto, ma questo è
solo un dettaglio. Tutto il resto è alpinismo vitreo.

 solo un dettaglio. Tutto il resto è alpinismo vitreo.
Il programma in questione NON ti gira in tutte le distribuzioni.
In una Debian based ti parte e poi si inchioda.
Devi modificare a manina le librerie della Debian based per
farlo funzionare anche lì. Sennò, non ti funziona.
Non citare cose senza riflettere.
Saluti
Pegasus

 Per installarlo devi copiare roba a mano.....
Ma perché per installare quake4 mi basta scrivere (o clickare qua e là 
su porthole) "emerge quake4-bin" e poi mi ritrovo l'inconcina su Gnome?
Uffa, io voglio copiare i file a mano... dici che posso farlo lo stesso?


Sui computer su cui lavoro l'account è ristretto e acrobat parte.
Saluti.