opinioni su FreeBsd
Francesco Collini
Sono un sistemista amante fortemente di Linux e quel poco che riesco a fare
lo devo, soprattutto, ai colleghi di questi newsgroup (it.comp.os.linux,
ecc.).
Sull'ultimo numero di Linux & CO era presente, in regalo, l'ultima versione
di FreeBSD.
Secondo voi, ne vale la pena di provarlo riuscendomi un attimino a
barcamenare su Linux oppure no?
In quali server-application è più consigliato l'uno oppure l'altro? Gode
anche FreeBSD di supporto hardware a livello di driver come Linux?
Ciao a tutti e grazie per i vostri pareri!
Buona Domenica,
Francesco Collini
Jimmy Olgeni
>Secondo voi, ne vale la pena di provarlo riuscendomi un attimino a
>barcamenare su Linux oppure no?
Beh, visto che ormai te lo hanno regalato... :-)
(e ricordati di abilitare softupdates)
--
disclaimer: not speaking for anybody but me.
Angel Blue
> Ciao a tutti!
> Sono un sistemista amante fortemente di Linux e quel poco che riesco a fare
> lo devo, soprattutto, ai colleghi di questi newsgroup (it.comp.os.linux,
> ecc.).
> Sull'ultimo numero di Linux & CO era presente, in regalo, l'ultima versione
> di FreeBSD.
NON usare quel CD, e` rovinato - nella mailing list del GUFI
(Gruppo Utenti Italiani FreeBSD) tutti quelli che l'han provato
l'han trovato guasto.
> Secondo voi, ne vale la pena di provarlo riuscendomi un attimino a
> barcamenare su Linux oppure no?
Vale la pena ma non con quel CD.
> In quali server-application è più consigliato l'uno oppure l'altro? Gode
> anche FreeBSD di supporto hardware a livello di driver come Linux?
Per me e` consigliabile in tutte le server-application - almeno
quelle solite.
Io non ho mai fatto prove ma la vox populi dice che FreeBSD sia
piu` affidabile quando i carichi diventano pesanti - in una
roba casalinga non si apprezzeranno differenze.
Per me il vantaggio sta anche nel fatto di non avere distro, di
avere uno sviluppo centralizzato ma comunque aperto
(relativamente) e nell'ottimo sistema dei ports per l'update
dei sistemi installati (dal kernel sino al programmillo xyz).
Oltre a un "flavour" da vero unix (BSD naturalmente) che non
trovo piu` in Linux: come, fai conto, se la conosci, la
Slackware sino alla 4.0 (l'ultima che conosco per esperienza)
ma piu' complessa e completa - e naturalmente non SysV oriented
come Slackware... :-)
E poi non mette la GUI di default neppure se installato come
workstation... ;-)
Il supporto driver e` piu` scarso rispetto a quello di Linux ma
tutto l'hardware "normale" e diffuso e` supportato, sino
all'usb. Su www.freebsd.org o su www.gufi.org trovi le
informazioni anche su questo.
--
Yours truly, | PCC on a FreeBSD box E-mail: ab...@mclink.it
Angel Blue |-------------------------------------------------------------
_*_ | "Percorrero` le strade del bandito
| | Amato dalla gente - ucciso dallo Stato" (Timoria)
thorin_...@durin.khazad-dum.net
> Io non ho mai fatto prove ma la vox populi dice che FreeBSD sia
> piu` affidabile quando i carichi diventano pesanti - in una
> roba casalinga non si apprezzeranno differenze.
Si questo l'ho sentito anche io, devo ammetterlo, anche se ho delle
obiezioni per qualcosa che dici piu' giu'..
> Per me il vantaggio sta anche nel fatto di non avere distro, di
> avere uno sviluppo centralizzato ma comunque aperto
> (relativamente) e nell'ottimo sistema dei ports per l'update
> dei sistemi installati (dal kernel sino al programmillo xyz).
Mi rendo conto che la presenza di piu' distro puo' essere fuorviante ma
nessuno e' obbligato a cambiarne una al mese, se te ne piace una usi
quella e basta.
> Oltre a un "flavour" da vero unix (BSD naturalmente) che non
> trovo piu` in Linux: come, fai conto, se la conosci, la
> Slackware sino alla 4.0 (l'ultima che conosco per esperienza)
> ma piu' complessa e completa - e naturalmente non SysV oriented
> come Slackware... :-)
Mah hai preso proprio quella che non ha nemmeno un package manager che
possa definirsi degno di tale nome..
> E poi non mette la GUI di default neppure se installato come
> workstation... ;-)
Non diciamo cazzate, X e la GUI devi essere tu a scegliere di
installarli ;-)
> Il supporto driver e` piu` scarso rispetto a quello di Linux ma
> tutto l'hardware "normale" e diffuso e` supportato, sino
> all'usb. Su www.freebsd.org o su www.gufi.org trovi le
> informazioni anche su questo.
Vedi che qualcosa in piu' Linux ce l'ha? <g>
--
Pierluigi De Rosa (tho...@durin.khazad-dum.net).
<< LINUX: the choice of a GNU generation >>
<< For my real address... ask the Balrog. >>
* Sostenete la Lega per la Soppressione dei Troll *
Stefano Ghirlanda
> Oltre a un "flavour" da vero unix (BSD naturalmente) che non
> trovo piu` in Linux: come, fai conto, se la conosci, la
> Slackware sino alla 4.0 (l'ultima che conosco per esperienza)
Non e' cambiato nulla nella impostazione della Slackware da 4.0 ad
oggi.
> ma piu' complessa e completa - e naturalmente non SysV oriented
> come Slackware... :-)
Mi spieghi come Slackware e' "SysV oriented"? Per esempio:
$ ls /etc/rc.d
init.d/ rc.K rc.atalk rc.gpm rc.keymap rc.samba rc.xfstt~
rc.0 rc.M rc.cdrom rc.httpd rc.local rc.serial rc3.d/
rc.4 rc.M~ rc.font rc.inet1 rc.local~ rc.sysvinit rc6.d/
rc.6 rc.S rc.font.sample rc.inet2 rc.modules rc.xfstt
Come vedi la struttura init e' BSD. Poi c'e' rc.sysvinit per
aggiungere compatibilita' per qualche software a cui piace essere
lanciato in quel modo.
Comunque non ho eseperienza diretta di *BSD, per cui accetto
spiegazioni su come perche' Slackware sia SysV oriented (e del perche'
sia un male).
--
Stefano - Hodie pridie Nonas Apriles MMI est
Sidewinder
con l'oscuro sigillo di ab...@mclink.it,
scritta da Angel Blue con il proprio sangue, dal titolo:
"Re: opinioni su FreeBsd", e lo mise sul tavolo di marmo nero...
>Francesco Collini <f.co...@questonoinwind.it> wrote:
>
>> Ciao a tutti!
>
>> Sono un sistemista amante fortemente di Linux e quel poco che riesco a fare
>> lo devo, soprattutto, ai colleghi di questi newsgroup (it.comp.os.linux,
>> ecc.).
>
>> Sull'ultimo numero di Linux & CO era presente, in regalo, l'ultima versione
>> di FreeBSD.
>
>NON usare quel CD, e` rovinato - nella mailing list del GUFI
>(Gruppo Utenti Italiani FreeBSD) tutti quelli che l'han provato
>l'han trovato guasto.
vero gia provato sulla pelle :-(
Ho installato un freeBSD in ufficio per gli sistemisti, perche devono
fare pratica con i routing per poi mettere mano sui nuovi minirouter via
satellite della UDCast che si bansano su FreeBSD 3.4
Comunque, era la prima volta per me installarlo uno, l'ho trovato
veramente molto interessante. Concordo sul setup che e' fatto molto bene,
anzi meglio di slackware (che era stata la mia prima distriuzione linux
all'epoca del kernel 1.2.8)
Devo solo am,bientarmi un po, nel frattempo mi sono scaricato il pdf del
FreeBSD Handbook.
>
>E poi non mette la GUI di default neppure se installato come
>workstation... ;-)
Meglio :-)
--
Sidewinder
---------------------------------------------------------------------
Make it idiot-proof, and someone will breed a better idiot.
-- Oliver Elphick
---------------------------------------------------------------------
Jimmy Olgeni
> NON usare quel CD, e` rovinato - nella mailing list del GUFI
> (Gruppo Utenti Italiani FreeBSD) tutti quelli che l'han provato
> l'han trovato guasto.
Che problema ha? Per curiosita': ci vuole un mese di test prima di una
release e mi chiedo dove abbiano potuto sbagliare a masterizzare un
semplice file .iso (!)
> Per me e` consigliabile in tutte le server-application - almeno
> quelle solite.
Io ho un desktop che e' una pacchia :-)
> Per me il vantaggio sta anche nel fatto di non avere distro, di
> avere uno sviluppo centralizzato ma comunque aperto
E soprattutto poter fare i commit senza aspettare che qualcuno dall'altra
parte del mondo tiri fuori qualche rpm/deb aggiornato...
> (relativamente) e nell'ottimo sistema dei ports per l'update
> dei sistemi installati (dal kernel sino al programmillo xyz).
Come dicevo, portupdate domina l'universo :-)
Marco Vannini
>
> $ ls /etc/rc.d
> init.d/ rc.K rc.atalk rc.gpm rc.keymap rc.samba
rc.xfstt~
> rc.0 rc.M rc.cdrom rc.httpd rc.local rc.serial rc3.d/
> rc.4 rc.M~ rc.font rc.inet1 rc.local~ rc.sysvinit rc6.d/
> rc.6 rc.S rc.font.sample rc.inet2 rc.modules rc.xfstt
>
> Come vedi la struttura init e' BSD. Poi c'e' rc.sysvinit per
> aggiungere compatibilita' per qualche software a cui piace essere
> lanciato in quel modo.
fa..) non mi sembra che quella riportata sopra sia una struttura tipica di
BSD (ne' del suo derivato più famoso, il glorioso SunOs 4.1.x), che
utilizzava l'rc.boot, l'rc.single e l'rc.local, senza quindi le strutture
rc.<initlevel>..
Stefano Ghirlanda
> premesso che la mia esperienza su BSD si ferma al 2.1 (quindi tanto
> tempo fa..) non mi sembra che quella riportata sopra sia una
> struttura tipica di BSD (ne' del suo derivato più famoso, il
> glorioso SunOs 4.1.x), che utilizzava l'rc.boot, l'rc.single e
> l'rc.local, senza quindi le strutture rc.<initlevel>..
Ok, io mi riferivo al fatto che SysV usa init.d con gli script e rc*.d
con dei symlink agli script in init etc., e consideravo tutto il resto
"BSD"...
--
Stefano - Hodie Nonis Aprilibus MMI est
gh...@spazio.sub.uniroma2.it
<ab...@mclink.it> ha scritto:
> NON usare quel CD, e` rovinato - nella mailing list del GUFI
> (Gruppo Utenti Italiani FreeBSD) tutti quelli che l'han provato
> l'han trovato guasto.
E io che pensavo di essere cretino ....
> Per me il vantaggio sta anche nel fatto di non avere distro,
Beh' se vui la distro unica c'e' sempre uindoos :))
Scusa ma il fatto che ci siano diverse distro secondo me' e' uno dei
punti di forza di linux: ognuna deve per forza migliorare
*sostanzialmente* e non solo apparentemente per non essere superata.
Guardate il caso redhat: con tutti i bug della 7.0 ha perso ( a torto o a
ragione ) un parte di clientela; che si e' potuta rivolgere su altre
distro... Andatelo a spiegare agli utenti uindoos....
Jimmy Olgeni
> Scusa ma il fatto che ci siano diverse distro secondo me' e' uno dei
> punti di forza di linux: ognuna deve per forza migliorare
> *sostanzialmente* e non solo apparentemente per non essere superata.
<rant>
Cosi' ognuna mette i suoi piccoli patch nel kernel: una ha il reiserfs,
l'altra ha il controllo sulla temperatura della motherboard, l'altra ancora
parte col framebuffer per default, un'altra ha gli RPM senza dependencies,
l'altra ha le dependencies ma quando aggiorni rpm dalla versione 3 alla 4,
gli rpm creati con il 4 non si installano sul 3. E quando alla fine trovi
l'ultimo rpm che ti serve sull'ultimo sito in basso a destra, e scopri che
c'e' qualcosa da sistemare, ti dicono che non c'e' il .src.rpm perche'
l'hanno creato con "alien" partendo da un package ".deb". Mandrake fra poco
avra' l'installazione con le ballerine nude, sponsored by Playboy.
Peccato che in redhat 6 c'era /usr/doc e nella 7 invece c'e'
/usr/share/doc, cosi' tutti gli rpm custom vanno rifatti da capo.
Per non parlare del download di 220 mega di patch (vedi redhat 7).
Oltretutto questi personaggi vorrebbero SOLDI per accedere a "Red Hat
Network", la copia autistica di Windows Update. Se non riesco a far
correggere gli errori sulle pagine web dal webmaster, figurati se gli
faccio mettere mano ai server con rhnsd (quello che si mangiava i file
descriptor...)
Ora in redhat 6.2 hanno messo rpm 4 come aggiornamento. Naturalmente non
hanno rilasciato un ISO aggiornato, gli costava troppo, quindi il CD lo
devo fare io da bravo cane che non ha altro di meglio da fare. Usando
"genhdlist" che non e' documentato da nessuna parte. Poi il potente
programma di installazione ("anaconda") non riconosce le dependencies di
alcuni rpm nuovi e si inchioda per chiedere conferma. L'installazione con
DHCP ancora non funziona. Tutto questo per rimanere ancora col python 1.5.2
a cui fra poco spunteranno le ragnatele. Peccato che a me serviva il 2.0.
Come premio per tutto cio', ho anche la GPL in mezzo ai piedi.
</rant>
<hope>
Almeno in FreeBSD se qualcosa mi fa girare le palle mi attacco al CVS e la
rimetto a posto. Almeno i package sono aggiornati piu' di due volte l'anno.
</hope>
Vedremo cosa combinera' Wind River...
Renato 'Hitman' Salzano
in forma ridotta per venire incontro alle capacita` mentali di Marco :)
Le rc.<initlevel> sono script lanciati da rc.sysvinit, e del tutto
opzionali fra l'altro. Slackware e` BSD pura con l'aggiunta di una
compatibilita` SysV opzionale.
--
Renato "Hitman" Salzano - http://spazioweb.inwind.it/hitman/
e-posta : sonicblast (at) inwind.it / Xena:TWP fan
Webdesigner / indegno sysadmin di www.italservicesnc.it
Powered by Debian 2.x (Woody) on a K6/2 box - 100% Wintel free
Balu - Marco Verdecchia
l'OpenBSD ed il NetBSD. Per quante distribuzioni linux esistano in fin dei
conti esistono tre grosse aree, Debian (deb), Slackware (tgz), RedHat e
derivate(rpm). 3 contro 3, con tutti i loro pregi e difetti e virtu'.
Daltronde e' proprio per questo motivo che mi piace l'open source, piu' modi
di vedere le cose.
--
\|||/
---------------------------oOOo--@ @--oOOo----------------------------
Marco Verdecchia <ba...@ELIMINAMI.katamail.com>
togli ELIMINAMI per potermi rispondere in email
Stefano Ghirlanda
> <rant>
Allora, mi trovo a dover rettificare alcune cose riguardo a Slackware
:-) Tanto per chiarezza visto che non era chiaramente il bersaglio di
Jimmy...
> Cosi' ognuna mette i suoi piccoli patch nel kernel
Niente patch del kernel su Slackware, solo quello ufficiale.
> Mandrake fra poco avra' l'installazione con le ballerine nude,
> sponsored by Playboy.
Il setup di slackware sono script bash con dialog.
> Per non parlare del download di 220 mega di patch (vedi redhat 7).
Slackware deve rilasciare pochissimi aggiornamenti. Per esempio le
statistiche di www.securityfocus.com dicono (in breve):
Number of OS Vulnerabilities by Year
OS 1997 1998 1999 2000 2001
AIX 21 38 10 15 2
Debian 3 2 32 45 12
FreeBSD 4 2 17 36 5
HP-UX 8 5 13 28 3
Mandrake - - 2 46 18
NetBSD 1 4 10 20 0
OpenBSD 1 2 4 17 1
RedHat 6 10 49 85 20
Slackware 4 8 11 10 1
^^^^^^^^^
Solaris 24 33 36 23 6
SuSE - - 23 30 8
Windows NT/2000 10 10 83 126 12
Come si vede, solo OpenBSD e' stato meno vulnerabile. Notare anche che
alcuni UNIX free (NetBSD, OpenBSD, Slackware) fanno meglio degli UNIX
proprietari.
Ah, il numero per WindowsNT/2000, *non* me lo sono inventato, e' vero.
> Come premio per tutto cio', ho anche la GPL in mezzo ai piedi.
Be', questa e' questione di gusti. Io preferisco GPL, ma non c'entra
con la qualita' del software.
> Almeno in FreeBSD se qualcosa mi fa girare le palle mi attacco al
> CVS e la rimetto a posto.
Qui forse e' meglio FreeBSD di Slackware. Ci sono le directory
slackware-source ma non un CVS (che io sappia).
> Almeno i package sono aggiornati piu' di due volte l'anno.
Be' dipende anche dal perche' devono essere aggiornati, vedi sopra.
"If it ain't broken, don't fix it"
> Vedremo cosa combinera' Wind River...
Che cos'e'?
Il tutto, per la precisione.
--
Stefano - Hodie septimo Idus Apriles MMI est
Pardo
>hai ragione, ma nel mondo BSD non esiste soltanto il FreeBSD, ma anche
>l'OpenBSD ed il NetBSD.
mmmh, c'e` anche PowerBSD ;-)
--
Pardo
http://pardo.cjb.net
http://pardo.tsx.org
Marco Costamagna
"Jimmy Olgeni" <olg...@uli.it> ha scritto nel messaggio
news:slrn9cmshf....@olgeni.localdomain.net...
> On Tue, 3 Apr 2001 19:40:52 +0200, Angel Blue wrote:
> > Per me il vantaggio sta anche nel fatto di non avere distro, di
> > avere uno sviluppo centralizzato ma comunque aperto
>
> E soprattutto poter fare i commit senza aspettare che qualcuno dall'altra
> parte del mondo tiri fuori qualche rpm/deb aggiornato...
Guarda che se non ti piacciono gli RPM o DEB puoi sempre scaricarti le
tarpalle in formato sorgente e compilartele direttamente sulla tua macchina.
A me gli RPM piacciono, li trovo ben strutturati e comodi da usare, e per
quanto ne so anche i file DEB sono pressochč analoghi (forse con qualche
funzione in piů).
Non capisco dove stia il male in questi formati.
Ciao,
Marco
Marco Costamagna
> On Fri, 06 Apr 2001 17:20:00 +0200, krei...@earthling.net.antispam wrote:
>
>. E quando alla fine trovi
> l'ultimo rpm che ti serve sull'ultimo sito in basso a destra, e scopri che
> c'e' qualcosa da sistemare, ti dicono che non c'e' il .src.rpm perche'
> l'hanno creato con "alien" partendo da un package ".deb".
Ma hai provato ad usarlo? Ti stai lamentando della sua flessibilità (alien)
il che a me non pare un difetto.
Inoltre se proprio vuoi scaricare dei pacchetti prova su rpmfind.net.
La mancanza di alcuni file negli RPM (solitamente le librerie) è poi dovuta
a problemi di licenze e non dei pacchetti
>Mandrake fra poco
> avra' l'installazione con le ballerine nude, sponsored by Playboy.
Caldera ha il tetris da un bel po' di tempo...
> Peccato che in redhat 6 c'era /usr/doc e nella 7 invece c'e'
> /usr/share/doc, cosi' tutti gli rpm custom vanno rifatti da capo.
Un problema di quella distro, per fortuna ce ne sono altre che puoi
scegliere
> Oltretutto questi personaggi vorrebbero SOLDI per accedere a "Red Hat
> Network", la copia autistica di Windows Update. Se non riesco a far
> correggere gli errori sulle pagine web dal webmaster, figurati se gli
> faccio mettere mano ai server con rhnsd (quello che si mangiava i file
> descriptor...)
Per mangiare devono avere soldi, se non ti piacciono i servizi che ti
vendono o ne trovi di migliori altrove e gratis puoi sempre non darglieli
quei soldi.
...
> Come premio per tutto cio', ho anche la GPL in mezzo ai piedi.
> </rant>
E che fastidio ti da'? Un sacco di gente scrive applicazioni closed source
per il pinguino
...
Jimmy Olgeni
> Guarda che se non ti piacciono gli RPM o DEB puoi sempre scaricarti le
> tarpalle in formato sorgente e compilartele direttamente sulla tua macchina.
> A me gli RPM piacciono, li trovo ben strutturati e comodi da usare, e per
> quanto ne so anche i file DEB sono pressochč analoghi (forse con qualche
> funzione in piů).
> Non capisco dove stia il male in questi formati.
Il male in RPM 3 (quello utilizzato in redhat 6.2) e' che se installo 30
package tutti in fila ad un certo punto mi dice "package Makefile not in
file index", quando tristemente e' ovvio che Makefile non e' un package.
Bisogna fare "rpm --rebuilddb" per *sperare* che si sistemi da solo...
bellascoperta.
Il male in RPM 4 e' che se creo un nuovo RPM e cerco di installarlo con il
3, qualche volta da' casini. E' l'ideale quando devi supportare vari
clienti con entrambe le versioni: ti devi tenere una macchina con l'rpm 3
per fare i package... anche qui, bellascoperta. RPM 4 oltretutti si tira
dietro db3 come dependency, una cosa molto leggera e facile da aggiornare
via modem.
Il male dei file .deb e' che funzionano solo in Debian. Se passo da Debian
a BogusLinux li posso gettare tutti in mare. Oltretutti a me serve
installare in kickstart partendo da un floppy e un CD, il che riduce
parecchio la scelta delle distribuzioni (oggi piu' che il kickstart vanno
di moda le installazioni amiche dell'utente col tetris).
Formati a parte, se a me serve Bogus-2.5 e nel mondo tutti hanno l'rpm di
Bogus-0.99.2001.05.01pre4ac77, mi tocca fare l'rpm a mano. Dove li metto i
documenti, in /usr/doc o /usr/share/doc? RPM 3 oppure 4? Non posso rifare
sempre lo stesso pallosissimo e inutile lavoro ogni volta che mi tocca
cambiare distribuzione perche' qualcosa va storto.
A quel punto uno getta veramente tutto in mare e si installa un pezzo di
BSD...
Jimmy Olgeni
>> Cosi' ognuna mette i suoi piccoli patch nel kernel
> Niente patch del kernel su Slackware, solo quello ufficiale.
Cosa buona e giusta. Niente reiserfs e compagnia pero'.
Per il resto, mi sono preso gli ISO e andro' a vedere che cosa c'e' dentro
:o)
>> Vedremo cosa combinera' Wind River...
> Che cos'e'?
www.windriver.com, quelli di VxWorks, che si sono comprati BSDi e che
dovrebbero fornire supporto, accessori & C per FreeBSD.
Jimmy Olgeni
>> l'hanno creato con "alien" partendo da un package ".deb".
> Ma hai provato ad usarlo? Ti stai lamentando della sua flessibilità (alien)
> il che a me non pare un difetto.
Io ho un'installazione Linux che usa RPM. Mi viene fornito un package
binario RPM che a me non piace perche' non funziona. Normalmente vado a
prendere il .src.rpm per sistemarlo, ma in questo caso non c'e': l'rpm e'
stato creato da un .deb, e per modificarlo dovrei mettere mano al .deb e
poi riconvertire il .deb compilato a .rpm. Oppure faccio prima a rifare
l'rpm a mano. Alla faccia della flessibilita'.
Oppure lascio perdere rpm e i suoi amici, faccio "cd
/usr/ports/picco/pacco; make package" e ho finito.
> Inoltre se proprio vuoi scaricare dei pacchetti prova su rpmfind.net.
Provato, trovo 15 package della stessa versione di software, peccato che e'
4 release indietro rispetto al tarball dei sorgenti :-)
Faccio prima a modificare il Makefile in /usr/ports/XXX, e dopo un bel
commit il problema e' risolto per tutti.
> Caldera ha il tetris da un bel po' di tempo...
Speriamo che almeno abbia un'installazione unattended che funziona... ce
l'ha il reiserfs o ha solo il tetris? :o)
> Un problema di quella distro, per fortuna ce ne sono altre che puoi
> scegliere
Rifacendo tutti i package custom ogni volta che cambio: proprio qui sta il
problema. Poi scopro che nei "pristine sources" della glibc di redhat c'e'
un core dump di timeconfig, e mi sorgono alcuni dubbi sul "pristine".
> Per mangiare devono avere soldi, se non ti piacciono i servizi che ti
> vendono o ne trovi di migliori altrove e gratis puoi sempre non darglieli
> quei soldi.
Per mangiare devono vendere _servizi_, non mi devono vendere una stronzata
come Red Hat 7 e poi farmi pagare per scaricare a mie spese 220 mega di
patch. Oggi, 30 mega di glibc, domani, altri 30. "Oops". Oltretutto, come
si fa a rimasterizzare i 2 CD di installazione con gli aggiornamenti? C'e'
un pezzo di documentazione a proposito del file "comps", di anaconda e di
genhdlist? "Servizio" non e' far pagare quello che tutti gli altri fanno
gratis. Debian si aggiorna gratis e senza protestare.
E cosa succede quando copiando i patch sul CD si supera la dimensione
massima del CD stesso? E soprattutto, era proprio necessario dare il
dizionario esperanto di Aspell nell'installazione piuttosto che nei
powertools? McFly?!
Non mi resta che sperare in Slackware (ammesso che mi rimanga una macchina
Linux da qualche parte).
>> Come premio per tutto cio', ho anche la GPL in mezzo ai piedi.
> E che fastidio ti da'? Un sacco di gente scrive applicazioni closed
> source per il pinguino
E poi ti da' l'rpm che si installa solo su redhat. (vedi lo scempio di Sun JDK)
Soprattutto i sistemi embedded con mezzo kernel ribaltato, quelli vengono
benissimo in GPL :o)
thorin_...@durin.khazad-dum.net
>> Guarda che se non ti piacciono gli RPM o DEB puoi sempre scaricarti le
>> tarpalle in formato sorgente e compilartele direttamente sulla tua macchina.
>> A me gli RPM piacciono, li trovo ben strutturati e comodi da usare, e per
>> quanto ne so anche i file DEB sono pressochč analoghi (forse con qualche
>> funzione in piů).
>> Non capisco dove stia il male in questi formati.
> Il male in RPM 3 (quello utilizzato in redhat 6.2) e' che se installo 30
> package tutti in fila ad un certo punto mi dice "package Makefile not in
> file index", quando tristemente e' ovvio che Makefile non e' un package.
> Bisogna fare "rpm --rebuilddb" per *sperare* che si sistemi da solo...
> bellascoperta.
A me non e' mai successa una cosa del genere: che RPM faccia ogni tanto
dei casini con le dipendenze e' vero ma che installando un tot di
package si rovini il database e' una cazzata: chissa' cosa avrai
installato, magari degli RPM non per la RH 6.2 ma per qualche altra
distro quindi e' colpa tua, non della RH.
> Il male in RPM 4 e' che se creo un nuovo RPM e cerco di installarlo con il
> 3, qualche volta da' casini. E' l'ideale quando devi supportare vari
> clienti con entrambe le versioni: ti devi tenere una macchina con l'rpm 3
> per fare i package... anche qui, bellascoperta. RPM 4 oltretutti si tira
> dietro db3 come dependency, una cosa molto leggera e facile da aggiornare
> via modem.
E chi ti ha prescritto come medicina di mescolare RPM di differente
tipo? Ma che bella storia.. non ti sfiora che RPM 3 ed RPM 4 potebbero
per prima cosa richiedere versioni differenti di librerie e quindi
mescolarli nella stessa macchina potrebbe essere un po' pericoloso? Ma
no, via..
> Il male dei file .deb e' che funzionano solo in Debian. Se passo da Debian
> a BogusLinux li posso gettare tutti in mare. Oltretutti a me serve
> installare in kickstart partendo da un floppy e un CD, il che riduce
> parecchio la scelta delle distribuzioni (oggi piu' che il kickstart vanno
> di moda le installazioni amiche dell'utente col tetris).
Se ti serve portare applicazioni da una distro all'altra prendi i
tarball e compila, punto. Se fai casini non prendertela con Debian o con
RPM perche' i package manager vanno saputi usare con accortezza ed
infatti a me il db degli RPM non si e' _MAI_ rovinato in tanti anni di
uso.
> Formati a parte, se a me serve Bogus-2.5 e nel mondo tutti hanno l'rpm di
> Bogus-0.99.2001.05.01pre4ac77, mi tocca fare l'rpm a mano. Dove li metto i
> documenti, in /usr/doc o /usr/share/doc? RPM 3 oppure 4? Non posso rifare
> sempre lo stesso pallosissimo e inutile lavoro ogni volta che mi tocca
> cambiare distribuzione perche' qualcosa va storto.
Prendi i ca&&o dei sorgenti e compila, cosi' non devi preoccupartene:
li' dove li mettera' 'make install' andra' bene ovunque !
> A quel punto uno getta veramente tutto in mare e si installa un pezzo di
> BSD...
Ho come l'impressione che troveresti da ridire anche su BSD, poi..
Stefano Ghirlanda
> Il male dei file .deb e' che funzionano solo in Debian. Se passo da Debian
> a BogusLinux li posso gettare tutti in mare. Oltretutti a me serve
> installare in kickstart partendo da un floppy e un CD, il che riduce
> parecchio la scelta delle distribuzioni (oggi piu' che il kickstart vanno
> di moda le installazioni amiche dell'utente col tetris).
C'e' un filo su alt.os.linux.slackware al proposito in queti
giorni. Forse ne viene fuori qualcosa di interessante... e'
teoricamente fattibile usando il meccanismo dei TAGFILE, che
contengono la lista di quel che deve essere installato, am che io
sappia non l'ha ancora fatto nessuno. Pero' anche a me potrebbe
servire, per cui chissa'...
--
Stefano - Hodie tertio Idus Apriles MMI est
Pardo
>> Peccato che in redhat 6 c'era /usr/doc e nella 7 invece c'e'
>> /usr/share/doc, cosi' tutti gli rpm custom vanno rifatti da capo.
>
>Un problema di quella distro, per fortuna ce ne sono altre che puoi
>scegliere
per la cronaca, e` sufficente:
cd /usr
mv share/man/* man
mv share/doc/* doc
rmdir share/man share/doc
ln -s /usr/man /usr/share/man
ln -s /usr/doc /usr/share/doc
;-)
problemi con gli rpm non ce ne sono, non si accorgono di nulla
cmq sono dei disordinati...
Jimmy Olgeni
> A me non e' mai successa una cosa del genere: che RPM faccia ogni tanto
> dei casini con le dipendenze e' vero ma che installando un tot di
> package si rovini il database e' una cazzata: chissa' cosa avrai
> installato, magari degli RPM non per la RH 6.2 ma per qualche altra
> distro quindi e' colpa tua, non della RH.
Gli RPM sono gli aggiornamenti della RH6.2, che RedHat stessa raccomanda, e
si _suppone_ abbia verificato prima di distribuirli. Basta un semplice "rpm
-Uvh *.rpm" per beccarsi il "package Makefile not in file index". O ancora
peggio, un "corrupt freelist error bla bla". L'hardware e' buono, il kernel
si compila 50 volte senza dire bah, "make release" funziona, niente signal
11. Lo stesso accade su tutte le macchine. Con RH7, sulle stesse macchine,
non accade: immagino quindi che se RPM4 ora usa db3 come database
dev'esserci stato un motivo alla base. Poi, quando scarico un RPM da
internet, devo pormi il problema: sara' per Suse, Mandrake, o quale RedHat?
Lo stesso problema si pone quando devi ricompilare il .src.rpm, che ogni
distribuzione fa come meglio crede.
Giochino 1: prendi un CD della RH6.2. Copia sul CD tutti gli update
"ufficiali". Eventualmente modifica il file "comps" per aggiungere i nuovi
rpm (come db3, ad esempio). Usa il documentatissimo comando "genhdlist",
nascosto da qualche parte in misc/src/anaconda/bla/bla sul CD, per
rigenerare l'indice degli rpm (era troppo complicato leggere gli RPM sul CD
con le opportune librerie? Dovevano proprio mettere un indice "binary"
senza documentarne la procedura di generazione?). A questo punto crei il
file .ISO, che fara' il boot e si installera'[0].
Ripeti il procedimento per ogni gruppo di update che saltano fuori sul sito
degli update. Tutto funzionera' a meraviglia. *Ma* ad un certo punto, a
partire da un certo giorno in avanti, il programma di installazione sul CD
aggiornato si fermera' dicendo che per alcuni RPM mancano delle dipendenze:
ad esempio e' il caso di tcsh. Ora, se sono update ufficiali, come possono
mancare delle dipendenze sul CD di installazione? Non sara' forse che il
formato degli RPM e' cambiato in qualche modo e il programma di
installazione non riesce a capire che cosa c'e' dentro? Com'e' che questo
accade per quasi tutti gli ultimi upgrade, da tcsh in poi? Com'e' possibile
che come semplice "aggiornamento" di RH6.2 mi venga dato addirittura un
RPM4 incompatibile con il 3?
Giochino 2: installa RH6.2, e aggiorna RPM alla versione 4. Poi fai un CD
custom con altri aggiornamenti, sempre Red Hat Official, e prova ad
utilizzare il suo upgrade. Risultato: l'installazione in grafica si pianta
senza dire neanche "Aieee!"[1], mentre quella in testo da un'exception in
Python. Forse le librerie dell'rpm nel programma di installazione non sono
compatibili con rpm4? E allora che senso ha avere un database dei package
binario che non e' compatibile con se stesso dopo un semplice upgrade?
E' solo un "aggiornamento", o faremo la fine dei service pack di NT, con 1
bugfix e 15 "feature enhancements?" E' un aggiornamento *utile* o serve
solo ad agganciare RedHat Network, insieme a rhn_register e agli altri
"aggiornamenti?"
> E chi ti ha prescritto come medicina di mescolare RPM di differente
> tipo? Ma che bella storia.. non ti sfiora che RPM 3 ed RPM 4 potebbero
> per prima cosa richiedere versioni differenti di librerie e quindi
> mescolarli nella stessa macchina potrebbe essere un po' pericoloso? Ma
> no, via..
Se RedHat mi dice che RPM4 e' un "official update" per RH6.2, mi viene da
pensare che vada ovviamente a sostituire RPM3, tirandosi dietro DB3 e un
altro paio di cose. Non si tratta di mescolare, ma semplicemente
aggiornare: dopo un "rpm --rebuilddb" ti trovi una RH6.2 con RPM4, come da
manuale. Oltretutto non e' possibile "mescolarli" perche' il database e'
comunque uno.
> Se ti serve portare applicazioni da una distro all'altra prendi i
> tarball e compila, punto.
Questo lo posso fare su un desktop da cazzeggio, non sui prodotti che si
devono installare da soli con il loro bravo CD (leggi: prodotti che si
vendono a dei clienti). Tempo di riscrivere le procedure di installazione a
causa dell'altrui incompetenza, non ne ho. Prendere i tarball e compilare
perche' RPM fa cazzate nega istantaneamente l'utilita' del package manager.
Dove sta scritto nel tarball quali file vengono installati, e dove?
Almeno Debian ha la decenza di avere il database in ASCII, mi pare.
> Se fai casini non prendertela con Debian o con
> RPM perche' i package manager vanno saputi usare con accortezza ed
> infatti a me il db degli RPM non si e' _MAI_ rovinato in tanti anni di
> uso.
Neanche a me, se faccio un rebuilddb ogni 3 rpm. Ho trovato altri 2
testimoni del fattaccio, sempre su rh6.2 :o)
La morale della storia e' che di cazzate ce ne sono dappertutto. Pensare
che tutto sia perfetto e negare il problema non porta alcun progresso, anzi
non fa che allontanare la gente da Linux. Il fatto che RedHat sia una delle
distribuzioni piu' diffuse non fa che peggiorare la situazione. Dispiace a
me per primo, visto che andavo a installare Linux ai clienti quando ancora
tutti ti guardavano storto perche' non avevi NT coi pupazzi. Nel caso in
cui non fosse chiaro, non ce l'ho con Linux in se', piuttosto con RedHat
(con cui ho combattuto per lavoro) e con le puttanate che la
commercializzazione di Linux si sta portando dietro.
Se si vuole diffondere Linux deve esistere un prodotto piu' o meno esente
da boiate eclatanti e con una certa quantita' di software pronto per essere
installato senza dover lottare contro le cazzate dei package manager. Una
certa quantira' significa piu' o meno
# cat /usr/ports/INDEX | wc -l
4900
e non 2 cd di installazione dove manca meta' della roba che server, oppure
manca il KDE perche' "la licenza non era abbastanza free".
Altrimenti e' ovvio che microsoft continuera' a mangiarsi il mercato
desktop. Pero' c'e' il dizionario esperanto...
MacOS X, nella sua follia, e' un _prodotto_, non e' frammentato in 100
versioni, ha un'implementazione decente di java (pare) e avra' delle
applicazioni _serie_ a livello utente _oltre_ a quello che gia' gira su Unix.
> Prendi i ca&&o dei sorgenti e compila, cosi' non devi preoccupartene:
> li' dove li mettera' 'make install' andra' bene ovunque !
Peccato che ogni tanto manca il "make deinstall".
>> A quel punto uno getta veramente tutto in mare e si installa un pezzo di
>> BSD...
> Ho come l'impressione che troveresti da ridire anche su BSD, poi..
Certo: "All software sucks". E' per questo che danno l'accesso al CVS, per
sistemare le cose che non funzionano come dovrebbero. Almeno il database
dei package e' fatto in ASCII.
# ls /var/db/pkg/png-1.0.10
+COMMENT
+CONTENTS
+DESC
+REQUIRED_BY
[0] Nota a parte, come si fa a chiamare "anaconda" un programma di
installazione? E' come chiamare "audiomatic" un news server. Bisognerebbe
scegliere dei nomi almeno leggermente legati alla realta' (vedi ad esempio
KUDZU che "rileva il nuovo hardware", prova ad indovinarlo dal nome). In
FreeBSD, al fatto che sysinstall sia la procedura di installazione uno ci
arriva senza piegarsi in 8 dalle risate.
[1] A proposito di "Aieee!" nei messaggi del kernel ci sarebbe da fare un
altro discorso che tratta di core dump e gdb :o)
thorin_...@durin.khazad-dum.net
>> A me non e' mai successa una cosa del genere: che RPM faccia ogni tanto
>> dei casini con le dipendenze e' vero ma che installando un tot di
>> package si rovini il database e' una cazzata: chissa' cosa avrai
>> installato, magari degli RPM non per la RH 6.2 ma per qualche altra
>> distro quindi e' colpa tua, non della RH.
> Gli RPM sono gli aggiornamenti della RH6.2, che RedHat stessa raccomanda, e
> si _suppone_ abbia verificato prima di distribuirli. Basta un semplice "rpm
> -Uvh *.rpm" per beccarsi il "package Makefile not in file index". O ancora
Sei sicuro che fossero per la 6.2? A me delle cose del genere non sono
mai capitate, eppure sono sempre stato _molto_ attento, scaricando
gli RPM, a prendere quelli giusti, per la 6.2 e non per la 6.2 o la
7 o una 5.x
> Giochino 1: prendi un CD della RH6.2. Copia sul CD tutti gli update
> "ufficiali". Eventualmente modifica il file "comps" per aggiungere i nuovi
> rpm (come db3, ad esempio). Usa il documentatissimo comando "genhdlist",
> nascosto da qualche parte in misc/src/anaconda/bla/bla sul CD, per
Non capisco l'utilita' di questi giochini che fai: premettiamo che io
aggiorno solo cio' che mi serve non cio' che mi passa per la testa, ne'
modifico alcun file, prendo l'RPM e poi vado di 'rpm -ivh' oppure 'rpm -Uvh'
se devo aggiornare, tutto qui.
[..]
> Giochino 2: installa RH6.2, e aggiorna RPM alla versione 4. Poi fai un CD
> custom con altri aggiornamenti, sempre Red Hat Official, e prova ad
Spiegami prima perche' dovrei farlo, poi si puo' proseguire. Per il prurito
anale di installare magari degli RPM della RH 7? O di Mandrake o qualsiasi
altra distro RPM-based? E grazie allora che ti si sputtana il database se
fai di queste schifezze.
> utilizzare il suo upgrade. Risultato: l'installazione in grafica si pianta
> senza dire neanche "Aieee!"[1], mentre quella in testo da un'exception in
> Python. Forse le librerie dell'rpm nel programma di installazione non sono
Ripeto, sono _anni_ che uso RH e non mi e' *MAI* successa una cosa del
genere: sara' perche' le installazioni le ho fatte rispettando le dipendenze
delle librerie e non mescolando la mia RH con package imbastarditi di altre
distro?
[..]
>> E chi ti ha prescritto come medicina di mescolare RPM di differente
>> tipo? Ma che bella storia.. non ti sfiora che RPM 3 ed RPM 4 potebbero
>> per prima cosa richiedere versioni differenti di librerie e quindi
>> mescolarli nella stessa macchina potrebbe essere un po' pericoloso? Ma
>> no, via..
> Se RedHat mi dice che RPM4 e' un "official update" per RH6.2, mi viene da
> pensare che vada ovviamente a sostituire RPM3, tirandosi dietro DB3 e un
> altro paio di cose. Non si tratta di mescolare, ma semplicemente
Beh se tu fai come quelli che usano Uindous che vanno ad installare la prima
cosa che gli si dice sono cazzi tuoi. Io mi sono sempre ben guardato dal
fare di queste cose e casualmente, ripeto, non mi si e' mai rovinato nulla.
>> Se ti serve portare applicazioni da una distro all'altra prendi i
>> tarball e compila, punto.
> Questo lo posso fare su un desktop da cazzeggio, non sui prodotti che si
> devono installare da soli con il loro bravo CD (leggi: prodotti che si
> vendono a dei clienti). Tempo di riscrivere le procedure di installazione a
> causa dell'altrui incompetenza, non ne ho. Prendere i tarball e compilare
> perche' RPM fa cazzate nega istantaneamente l'utilita' del package manager.
> Dove sta scritto nel tarball quali file vengono installati, e dove?
Al tempo, se installi gli RPM per RedHat 6.2 su una RH 6.2 non succede un
cazzo di niente.
> Almeno Debian ha la decenza di avere il database in ASCII, mi pare.
Beh ti sei lamentato pure di quella quindi non mi pare tu sia molto
coerente.
>> Se fai casini non prendertela con Debian o con
>> RPM perche' i package manager vanno saputi usare con accortezza ed
>> infatti a me il db degli RPM non si e' _MAI_ rovinato in tanti anni di
>> uso.
> Neanche a me, se faccio un rebuilddb ogni 3 rpm. Ho trovato altri 2
> testimoni del fattaccio, sempre su rh6.2 :o)
E' colpa tua e solamente tua: io rebuilddb non ne ho mai fatti, pensa un
po'.
> La morale della storia e' che di cazzate ce ne sono dappertutto. Pensare
> che tutto sia perfetto e negare il problema non porta alcun progresso, anzi
> non fa che allontanare la gente da Linux. Il fatto che RedHat sia una delle
> distribuzioni piu' diffuse non fa che peggiorare la situazione. Dispiace a
RedHat avra' pure le sue colpe, sicuramente RPM non e' un fiore di package
manager ma mi pare che anche tu faccia la tua buona parte per peggiorare
ulteriormente la situazione.
> Se si vuole diffondere Linux deve esistere un prodotto piu' o meno esente
> da boiate eclatanti e con una certa quantita' di software pronto per essere
> installato senza dover lottare contro le cazzate dei package manager. Una
> certa quantira' significa piu' o meno
Si, anche le boiate degli utenti, soprattutto.
> # cat /usr/ports/INDEX | wc -l
> 4900
> e non 2 cd di installazione dove manca meta' della roba che server, oppure
> manca il KDE perche' "la licenza non era abbastanza free".
Questo non e' mica colpa di RedHat ne' di nessun'altra casa produttrice di
una qualsiasi altra distro ma di chi ha deciso di usare le Qt che non erano
freem, che cosa c'entra? Che poi, alla fine, dopo tante tribolazioni,
Trolltech abbia rilasciato una versione simil-free e' incidentale.
> Altrimenti e' ovvio che microsoft continuera' a mangiarsi il mercato
> desktop. Pero' c'e' il dizionario esperanto...
Non mi pare proprio, specie negli ultimi tempi: io vedo sempre piu' gente
che abbandona Uindous perche' stanca di un sistema inaffidabile.
> MacOS X, nella sua follia, e' un _prodotto_, non e' frammentato in 100
> versioni, ha un'implementazione decente di java (pare) e avra' delle
> applicazioni _serie_ a livello utente _oltre_ a quello che gia' gira su Unix.
Questo e' ancora tutto da vedere, come si comportera' a livello di
applicazioni UNIX. E bisognera' vedere anche che stabilita' offrira'.
>> Prendi i ca&&o dei sorgenti e compila, cosi' non devi preoccupartene:
>> li' dove li mettera' 'make install' andra' bene ovunque !
> Peccato che ogni tanto manca il "make deinstall".
E ti perdi per cosi' poco? Se proprio ti pesa cosi' tanto fai un 'make -n
install >/tmp/LOG' e poi prendi da LOG quello che devi disinstallare. Troppo
difficile, eh? ;-)
>>> A quel punto uno getta veramente tutto in mare e si installa un pezzo di
>>> BSD...
>> Ho come l'impressione che troveresti da ridire anche su BSD, poi..
> Certo: "All software sucks". E' per questo che danno l'accesso al CVS, per
> sistemare le cose che non funzionano come dovrebbero. Almeno il database
> dei package e' fatto in ASCII.
Gia' peccato che ti sei lamentato anche di Debian che - tue parole - ha il
database pure in ASCII. Cerca la tua coerenza e torna di nuovo quando
l'avrai ritrovata.
> [0] Nota a parte, come si fa a chiamare "anaconda" un programma di
> installazione? E' come chiamare "audiomatic" un news server. Bisognerebbe
> scegliere dei nomi almeno leggermente legati alla realta' (vedi ad esempio
> KUDZU che "rileva il nuovo hardware", prova ad indovinarlo dal nome). In
Kudzu e' una delle prime cose che ho sempre disabilitato: le cagate alla
Uindous non le sopporto.
> FreeBSD, al fatto che sysinstall sia la procedura di installazione uno ci
> arriva senza piegarsi in 8 dalle risate.
Nessuno ti obbliga ad usarlo (e quindi a farti cacca addosso dalle risate).
Jimmy Olgeni
> Sei sicuro che fossero per la 6.2? A me delle cose del genere non sono
> mai capitate, eppure sono sempre stato _molto_ attento, scaricando
> gli RPM, a prendere quelli giusti, per la 6.2 e non per la 6.2 o la
> 7 o una 5.x
Gli RPM arrivano direttamente da updates.redhat.com, grazie al potente
comando sitecopy, e gli aggiornamenti della redhat 6.2 sono nella
directory... 6.2!
Se con la 5 non succedeva, e non succede neanche con la 7, evidentemente e'
un problema della 6.2. E nel caso in cui i package non fossero stati
compatibili, perche' vengono installati guastando il database, invece di
segnalare un semplice errore? :o)
Anche se l'rpm fosse di Mandrake, ad esempio, il *formato* del file e'
sempre RPM. Come potrebbe mai guastare il database? O il file e'
riconosciuto, oppure non lo e'.
> Non capisco l'utilita' di questi giochini che fai: premettiamo che io
> aggiorno solo cio' che mi serve non cio' che mi passa per la testa, ne'
> modifico alcun file, prendo l'RPM e poi vado di 'rpm -ivh' oppure 'rpm -Uvh'
> se devo aggiornare, tutto qui.
Come ben sai, l'utente (il tizio che compra, per intenderci) ha gia'
abbastanza problemi a respirare e contemporaneamente mantenere coscienza di
se': se gli dicessi di fare a mano "rpm -Uvh" si dimenticherebbe di
esistere e scomparirebbe all'istante. Se e' vero che in Linux il sysadmin
macho e cazzuto deve poter compilare i sorgenti scaricati da internet con
una stringa delle scarpe bagnata, e' altrettanto vero che gli strumenti a
disposizione devono rendere possibile la creazione di un prodotto _finito_
e vendibile. Cioe', io devo fare lo sporco lavoro dell'utente. Gli
strumenti nel complesso esistono (vedi rpm, almeno in principio, e il
kickstart di redhat). Il problema e' che nell'uso presentano problemi
fastidiosi e facilmente evitabili se qualcuno si fosse sprecato a fare _due
test_ in piu' invece di rilasciare in fretta la distribuzione "perche'
Mandrake era gia' alla 7 e noi eravamo solo alla 5", o qualche altra scusa
"da commerciale". Non ho mai avuto problemi con la 5.2, la 6.2 ha
cominciato a scricchiolare e la 7 mi e' parsa una boiata. Mi pare un gran
brutto trend per il futuro.
> Spiegami prima perche' dovrei farlo, poi si puo' proseguire.
Perche' vuoi un CD che si installi con tutti i patch. Non vuoi scrivere a
mano "rpm -Uvh" andando personalmente presso ogni sede di ogni singolo
cliente. Non vuoi neanche dare il CD senza patch, altrimenti i bug restano
e non hai concluso nulla. Non puoi un CD con i patch sperando che l'utente
faccia il mount ed esegua lo shell script che hai preparato. Nessuno ha mai
parlato di installare rpm della 7 sulla 6.2, cosa assolutamente folle.
> Per il prurito anale di installare magari degli RPM della RH 7? O di
> Mandrake o qualsiasi altra distro RPM-based? E grazie allora che ti si
> sputtana il database se fai di queste schifezze.
A questo punto mi pare di capire che "il formato RPM" praticamente non
esiste.
Esiste l'RPM per redhat, quello per Suse, quello per Mandrake. Quello che
di solito si trova in giro e' quello per redhat. Se io uso Mandrake (non
sia mai!) devo aspettare quello per Mandrake. Stessa cosa per Suse. Diventa
una lotteria. Se redhat lo chiamasse RPM e Suse invece "PiccoPackage",
sarebbe la stessa cosa e si eviterebbe l'inutile confusione e soprattutto
la pia illusione di interoperabilita'. Aggiungiamo Suse ha il reiserfs,
redhat ha qualche altro patch, Mandrake ha il frame buffer appena
installata, e poi vediamo se qualcuno si convince che "Linux non e'
frammentato". Certo, il Linux in casa di Torvalds, il grande tarball che
non ha mai visto un CVS neanche di striscio, quello non e' frammentato.
Nelle distribuzioni ognuno fa quello che vuole per sembrare piu' spacchioso
degli altri, a costo di rifilare kernel e glibc beta per poi "aggiornarli"
con i famosi rpm di update.
> Ripeto, sono _anni_ che uso RH e non mi e' *MAI* successa una cosa del
> genere: sara' perche' le installazioni le ho fatte rispettando le dipendenze
> delle librerie e non mescolando la mia RH con package imbastarditi di altre
> distro?
Le dipendenze delle librerie vengono rispettate, altrimenti RPM se ne
accorgerebbe. Non ho mai installato 200 RPM di Mandrake su una RedHat con
--force e --nodeps, ovviamente :o)
> Beh se tu fai come quelli che usano Uindous che vanno ad installare la prima
> cosa che gli si dice sono cazzi tuoi. Io mi sono sempre ben guardato dal
> fare di queste cose e casualmente, ripeto, non mi si e' mai rovinato nulla.
E' chiaro che se RPM3 fa cazzate, e mi dicono che il 4 e' un aggiornamento,
mi vado ad installare il 4 di corsa, visto che e' "Official". Dovrebbero
anche scrivere che non e' compatibile all'indietro. Cosa succede quando
ucd-snmp aggiornato richiede rpm4 come dependency? Ora e' stato aggiornato
solo per essere compatibile con RPM4, al prossimo bugfix sarei comunque
costretto a passare a RPM4.
> Al tempo, se installi gli RPM per RedHat 6.2 su una RH 6.2 non succede un
> cazzo di niente.
Se ne installi 50 con -Uvh arriva il botto. Io ho una RedHat "Official
Boxed Set", quella con il manuale in italiano, purtroppo, quello tradotto
con i piedi. Per fortuna ho trovato i PDF in inglese scritti da un
cristiano.
>> Almeno Debian ha la decenza di avere il database in ASCII, mi pare.
> Beh ti sei lamentato pure di quella quindi non mi pare tu sia molto
> coerente.
Non mi lamento del fatto che abbia il database in ASCII, anzi. Ma
ovviamente se scelgo di usare .deb per distribuire il software sono
costretto a usare Debian. Se cambo debian, devo rifare da capo tutti i
package. Questo preferirei evitarlo.
>> Neanche a me, se faccio un rebuilddb ogni 3 rpm. Ho trovato altri 2
>> testimoni del fattaccio, sempre su rh6.2 :o)
> E' colpa tua e solamente tua: io rebuilddb non ne ho mai fatti, pensa un
> po'.
E' colpa mia e di altre 10 persone che conosco. 6 sono passate a FreeBSD,
me incluso.
Dubito che siano diventate dei geni in una settimana, sta di fatto che
cazzate con i package non ne hanno piu' avute. Ora si potrebbe discutere su
quando fossero o non fossero "utonti", ma resta il fatto che, tecnicamente,
"Linux ha perso 6 utenti". Ora, visto che in libreria non mi pare di aver
visto libri su FreeBSD con la scimmia che sorride, mi viene da pensare che
non fossero del tutto utonti e che forse un qualche problema alla base ci
doveva essere. Soprattutto perche' redhat 5.2 funzionava.
Se gli utenti scappano da Windows perche' combina troppe cazzate, arrivano
in Linux, vedono un "package Makefile not found" che fa il botto _e_
oltretutto non trovano le applicazioni che a loro servono, torneranno a
Windows e non si sara' concluso niente. Il problema e' che mentre Windows,
a modo suo, cerca di diventare almeno un po' piu' decente, RedHat mi rifila
rhnsd che pianta la macchina perche' si installa da solo senza che nessuno
glielo abbia chiesto. Windows cerca di fare Unix e ci riesce male, RedHat
cerca di fare Windows e ci riesce benissimo.
Aggiungi il fatto che in Windows (ahime'!) posso create un oggetto COM in
Python (sviluppato sotto unix) e farlo usare all'utonto in visual basic. O
in ruby. O in erlang (!). Per utilizzare le librerie del CPAN invece mi
tocca usare per forza il perl, che personalmente mi fa venire le bolle.
Quindi, le domande: dov'e' il "component model" per Unix? Richiedera' gnome
o kde? e funzionera' senza X?
> RedHat avra' pure le sue colpe, sicuramente RPM non e' un fiore di package
> manager ma mi pare che anche tu faccia la tua buona parte per peggiorare
> ulteriormente la situazione.
Sono invece convinto che il problema sia solo per il 10% colpa di RPM: come
qualunque software si puo' correggere. Il 90% del problema e' la gestione
delle release di RedHat, e gli upgrade gestiti con i piedi. Vai a vedere
dentro il .src.rpm della glibc, guarda bene e dimmi cosa trovi :-)
La gestione delle release e degli aggiornamenti non e' una lotteria. Cosa
succede quando Redhat Network (pagato[0]) mi installa RPM4?
> una qualsiasi altra distro ma di chi ha deciso di usare le Qt che non erano
> freem, che cosa c'entra? Che poi, alla fine, dopo tante tribolazioni,
> Trolltech abbia rilasciato una versione simil-free e' incidentale.
Il fatto che l'aspetto "licenze" sia stato considerato piu' importante
dell'aspetto "risultati" ha portato ad avere due ambienti per i fatti
propri, ognuno con il suo piccolo modello ad oggetti. Per quale ambiente
sviluppare? KParts? Bonobo? Paradossalmente sono contento dell'esistenza di
Gnome, visto che KDE2.1 e' piu' lento a partire dello stesso StarOffice in
emulazione Linux... un bel mattone. Poi non lamentiamoci che Windows
"richiede sempre piu' risorse".
Io poi lavoro sempre in console e scrivo in LaTeX. Ma l'eventuale "Xilinx
for Linux" non funzionera' in console, e li' bisognera' inventare qualcosa.
> Non mi pare proprio, specie negli ultimi tempi: io vedo sempre piu' gente
> che abbandona Uindous perche' stanca di un sistema inaffidabile.
Ho visto parecchia gente abbandonare Windows per Linux. Quelli che riescono
a campare senza alcune applicazioni, restano, altri tornano indietro, pur
bestemmiando in aramaico. Esempio: mi server Xilinx. Non esiste per Linux.
Che fare?
E' anche vero che sulle mailing list di FreeBSD vedo secchiate di utenti
che scappano da Linux, e finora non ne ho visto uno solo tornare indietro.
Questo nonostante la risposta piu' frequente alle domande sia RTFM: ovvio,
quando i file di configurazione sono nello stesso posto, per tutti.
Poi ci sono quelli che devono modificare pesantemente il kernel per qualche
applicazione proprietaria: sono i primi a scappare, causa GPL.
> Questo e' ancora tutto da vedere, come si comportera' a livello di
> applicazioni UNIX. E bisognera' vedere anche che stabilita' offrira'.
Visto che siamo alla _prima_ release e si parla gia' di applicazioni Unix,
compatibilita' con Classic e nuove applicazioni, mi pare abbastanza
incoraggiante. Ricordiamoci la _prima_ redhat e il _primo_ windows NT: c'e'
una differenza.
Staremo a vedere chi per primo avra' un browser decente e un office degno
di tale nome.
> E ti perdi per cosi' poco? Se proprio ti pesa cosi' tanto fai un 'make -n
> install >/tmp/LOG' e poi prendi da LOG quello che devi disinstallare. Troppo
> difficile, eh? ;-)
Buonanotte, lo faccio installare dove vuole e poi vado a vedere che cosa ha
fatto. Faccio prima ad installarlo in un altro prefix e fare due "find".
"mtree and comm are my friends". In realta' ho fatto lo script in ruby che
lo fa da solo. Questa e' la dura vita del maintainer.
Dopo averlo fatto tiro fuori la PLIST, faccio "make package" e ho finito.
Joe Random Luser si aggiorna la ports collection con cvsup e scrive
"porteasy -b PiccoPacco", e ha finito anche lui senza interrogarsi sulle
turbe mentali di RPM.
La differenza e' che qui il "package" e' un semplice file .tgz.
(ehi: come in slackware :-))
> Kudzu e' una delle prime cose che ho sempre disabilitato: le cagate alla
> Uindous non le sopporto.
Questa e' la direzione che sta prendendo RedHat, a quanto pare. Posso
capire che faccia l'autodetect alla scheda video per far piacere a X. Non
capisco perche' faccia l'autodetect ai CD ATAPI che sono tutti
maledettamente uguali. Lo stesso vale per gli hard disk.
>> FreeBSD, al fatto che sysinstall sia la procedura di installazione uno ci
>> arriva senza piegarsi in 8 dalle risate.
> Nessuno ti obbliga ad usarlo (e quindi a farti cacca addosso dalle risate).
Cosa, anaconda? Infatti oggi e' stato il mio ultimo giorno a lottare con
anaconda. Niente piu' risate: sysinstall, al contrario di anaconda, e'
documentato nella sua brava man page. E non devo rifare tutto ad
ogni nuova release.
[0] ehi, non l'ho mica pagato, era cosi' per dire :^)
Andrea Capriotti
>Non mi lamento del fatto che abbia il database in ASCII, anzi. Ma
>ovviamente se scelgo di usare .deb per distribuire il software sono
>costretto a usare Debian. Se cambo debian, devo rifare da capo tutti i
>package. Questo preferirei evitarlo.
:-OO
>Dubito che siano diventate dei geni in una settimana, sta di fatto che
>cazzate con i package non ne hanno piu' avute. Ora si potrebbe discutere su
>quando fossero o non fossero "utonti", ma resta il fatto che, tecnicamente,
>"Linux ha perso 6 utenti". Ora, visto che in libreria non mi pare di aver
>visto libri su FreeBSD con la scimmia che sorride, mi viene da pensare che
>non fossero del tutto utonti e che forse un qualche problema alla base ci
>doveva essere. Soprattutto perche' redhat 5.2 funzionava.
La chiave sono le persone, loro hanno incontrato te e tu li hai guidati
verso FreeBSD. Se avessero incontrato me gli avrei mostrato dpkg, apt,
dselect, aptitude, deity o addirittura red-carpet.
Aggiornare, installare e disinstallare software diventa un semplice
click del mouse o una riga di comando per i piu' smaliziati.
(Io, e i miei colleghi, lanciamo l'aggiornamento durante la pausa caffe'
e al ritorno ci ritroviamo la macchina perfettamente in ordine)
>Ho visto parecchia gente abbandonare Windows per Linux. Quelli che riescono
>a campare senza alcune applicazioni, restano, altri tornano indietro, pur
>bestemmiando in aramaico. Esempio: mi server Xilinx. Non esiste per Linux.
>Che fare?
Un bel brindisi di buon "vino" e si parte:
http://www.polybus.com/xilinx_on_linux.html
:-)
>Poi ci sono quelli che devono modificare pesantemente il kernel per qualche
>applicazione proprietaria: sono i primi a scappare, causa GPL.
Ti sembrera' strano ma _l'unica_ cosa che non mi piace di FreeBSD e'
proprio la licenza. :)
Saluti
--
Andrea Capriotti
thorin_...@durin.khazad-dum.net
>> Sei sicuro che fossero per la 6.2? A me delle cose del genere non sono
>> mai capitate, eppure sono sempre stato _molto_ attento, scaricando
>> gli RPM, a prendere quelli giusti, per la 6.2 e non per la 6.2 o la
>> 7 o una 5.x
> Gli RPM arrivano direttamente da updates.redhat.com, grazie al potente
> comando sitecopy, e gli aggiornamenti della redhat 6.2 sono nella
> directory... 6.2!
[..]
> Anche se l'rpm fosse di Mandrake, ad esempio, il *formato* del file e'
> sempre RPM. Come potrebbe mai guastare il database? O il file e'
> riconosciuto, oppure non lo e'.
Forse ti sfuggono i concetti di dipendenza e di versioning delle
librerie. Faccio un esempio:
[root@durin /root]# rpm -q --requires mutt
slang >= 0.99.38
smtpdaemon
urlview
krb5-libs
ld-linux.so.2
libc.so.6
libcom_err.so.3
libgssapi_krb5.so.2
libk5crypto.so.2
libkrb5.so.2
libm.so.6
libslang.so.1
/bin/sh
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
ora, se tu facessi un upgrade di Kerberos o slang ad una versione piu'
recente come pretenderesti che _quel_ mutt continui a funzionare bene?
>> Non capisco l'utilita' di questi giochini che fai: premettiamo che io
>> aggiorno solo cio' che mi serve non cio' che mi passa per la testa, ne'
[..]
> Come ben sai, l'utente (il tizio che compra, per intenderci) ha gia'
> abbastanza problemi a respirare e contemporaneamente mantenere coscienza di
> se': se gli dicessi di fare a mano "rpm -Uvh" si dimenticherebbe di
> esistere e scomparirebbe all'istante. Se e' vero che in Linux il sysadmin
Siamo d'accordo che lo sporco lavoro dell'utente debba farlo tu se
l'utente non e' capace ma farlo rispettando le versioni relative a
_quella_ release della RH mi pare il minimo. Oh se poi il cliente ti
dice di mettere un package che a te risulta non essere per la RH 6.2 e
ti si sputtana tutto allora sono cazzi del cliente, non tuoi.
>> Spiegami prima perche' dovrei farlo, poi si puo' proseguire.
> Perche' vuoi un CD che si installi con tutti i patch. Non vuoi scrivere a
> mano "rpm -Uvh" andando personalmente presso ogni sede di ogni singolo
> cliente. Non vuoi neanche dare il CD senza patch, altrimenti i bug restano
Mah io ho sempre fatto i CD con gli updates e fatto 'rpm -Uvh *' (o al
massimo 'rpm -F' che va ad installare la versione piu' recente del
package) e non ho mai avuto problemi.
>> Per il prurito anale di installare magari degli RPM della RH 7? O di
>> Mandrake o qualsiasi altra distro RPM-based? E grazie allora che ti si
>> sputtana il database se fai di queste schifezze.
> A questo punto mi pare di capire che "il formato RPM" praticamente non
> esiste.
> Esiste l'RPM per redhat, quello per Suse, quello per Mandrake. Quello che
> di solito si trova in giro e' quello per redhat. Se io uso Mandrake (non
Continuano a sfuggirti i concetti di cui sopra: se tu ritieni che RH
6.1, RH 5.x, RH 7 (per rimanere solo nel campo delle RH) e poi SuSE,
Mandrake, Caldera usino per ognuna delle proprie release sempre le
stesse versioni di librerie e non cambino mai, auguri.
> Nelle distribuzioni ognuno fa quello che vuole per sembrare piu' spacchioso
> degli altri, a costo di rifilare kernel e glibc beta per poi "aggiornarli"
> con i famosi rpm di update.
Nelle distribuzioni ognuno installa la versione appropriata e cio' vale
per _qualsiasi_ distribuzione. Anche con Debian, immagino, non si puo'
infilare un .deb per la SID in una potato in modo indolore.
>> Ripeto, sono _anni_ che uso RH e non mi e' *MAI* successa una cosa del
>> genere: sara' perche' le installazioni le ho fatte rispettando le dipendenze
>> delle librerie e non mescolando la mia RH con package imbastarditi di altre
>> distro?
> Le dipendenze delle librerie vengono rispettate, altrimenti RPM se ne
> accorgerebbe. Non ho mai installato 200 RPM di Mandrake su una RedHat con
> --force e --nodeps, ovviamente :o)
Sarei curioso a questo punto di sapere dove tu prenda i tuoi RPM perche'
io ho da sempre scaricato da rufus.w3.org _per 6.2_ e vedo che in base
alle differenti versioni didistribuzione mettono anche dei colori
differenti per far notare la differenza alla gente. Certo, ho sempre
preso i package per 6.2 ma qualche volta ho dovuto usare --force e
--nodeps (per esempio facendo gli upgrade, prima da 5.2 a 6.0 e poi da
6.0 a 6.2) ma il database non mi si e' mai sputtanato lo stesso.
>> Beh se tu fai come quelli che usano Uindous che vanno ad installare la prima
>> cosa che gli si dice sono cazzi tuoi. Io mi sono sempre ben guardato dal
>> fare di queste cose e casualmente, ripeto, non mi si e' mai rovinato nulla.
> E' chiaro che se RPM3 fa cazzate, e mi dicono che il 4 e' un aggiornamento,
> mi vado ad installare il 4 di corsa, visto che e' "Official". Dovrebbero
Beh io no. Se non mi fido non lo faccio. Eppure continuo a tenere
aggiornata la mia 6.2 con tutti gli aggiornamenti di sicurezza (che sono
la cosa che mi interessa di piu') man mano che seguo Bugtraq. Ora non so
cosa tu debba avere necessita' di installare per esserti trovato
costretto pure ad un upgrade di rpm. Per precisione aggiungo che io ho
rpm-3.0.5-9.6x.
> anche scrivere che non e' compatibile all'indietro. Cosa succede quando
> ucd-snmp aggiornato richiede rpm4 come dependency? Ora e' stato aggiornato
> solo per essere compatibile con RPM4, al prossimo bugfix sarei comunque
> costretto a passare a RPM4.
Non so quale ucd-snmp tu sia andato a trovare, io avrei lasciato quello
del CD o al massimo preso l'update per 6.2 se segnalato.
>> Al tempo, se installi gli RPM per RedHat 6.2 su una RH 6.2 non succede un
>> cazzo di niente.
> Se ne installi 50 con -Uvh arriva il botto. Io ho una RedHat "Official
MAI avuto nessun botto.
>>> Almeno Debian ha la decenza di avere il database in ASCII, mi pare.
>> Beh ti sei lamentato pure di quella quindi non mi pare tu sia molto
>> coerente.
> Non mi lamento del fatto che abbia il database in ASCII, anzi. Ma
> ovviamente se scelgo di usare .deb per distribuire il software sono
> costretto a usare Debian. Se cambo debian, devo rifare da capo tutti i
> package. Questo preferirei evitarlo.
Allora usa Slackware ma saranno cazzi tuoi, senza un package manager.
>>> Neanche a me, se faccio un rebuilddb ogni 3 rpm. Ho trovato altri 2
>>> testimoni del fattaccio, sempre su rh6.2 :o)
>> E' colpa tua e solamente tua: io rebuilddb non ne ho mai fatti, pensa un
>> po'.
> E' colpa mia e di altre 10 persone che conosco. 6 sono passate a FreeBSD,
> me incluso.
Io no, continuo a non fare casini con RPM, come mai? Mi pare la solita
storia di quelli che fanno casini e se la prendono con lo strumento
invece che con se' stessi. Se il tuo cliente e' contento con FreeBSD
bene ma se e' passato a FreeBSD per i motivi che hai esposto e' una
cazzata immane !!
[..]
> Se gli utenti scappano da Windows perche' combina troppe cazzate, arrivano
> in Linux, vedono un "package Makefile not found" che fa il botto _e_
Per fortuna gli utenti Linux che trovano "package Makefile not found"
finora sono molto pochi <g>
> oltretutto non trovano le applicazioni che a loro servono, torneranno a
> Windows e non si sara' concluso niente. Il problema e' che mentre Windows,
Auguri, chi li segue guadagnera piu' soldi ma anche piu' mal di fegato
<g>
> a modo suo, cerca di diventare almeno un po' piu' decente, RedHat mi rifila
> rhnsd che pianta la macchina perche' si installa da solo senza che nessuno
> glielo abbia chiesto. Windows cerca di fare Unix e ci riesce male, RedHat
> cerca di fare Windows e ci riesce benissimo.
Si ma per fortuna alcuni utenti l'aiutano benissimo in questo <g>
[..]
>> RedHat avra' pure le sue colpe, sicuramente RPM non e' un fiore di package
>> manager ma mi pare che anche tu faccia la tua buona parte per peggiorare
>> ulteriormente la situazione.
> Sono invece convinto che il problema sia solo per il 10% colpa di RPM: come
> qualunque software si puo' correggere. Il 90% del problema e' la gestione
> delle release di RedHat, e gli upgrade gestiti con i piedi. Vai a vedere
> dentro il .src.rpm della glibc, guarda bene e dimmi cosa trovi :-)
Non ho mai usato .src.rpm, a questo punto, sapendo di dover usare i
sorgenti ho sempre fatto prima a compilare il tarball.
> La gestione delle release e degli aggiornamenti non e' una lotteria. Cosa
> succede quando Redhat Network (pagato[0]) mi installa RPM4?
Cosa e' Redhat Network ed a cosa serve? Perche' l'hai installato?
>> una qualsiasi altra distro ma di chi ha deciso di usare le Qt che non erano
>> freem, che cosa c'entra? Che poi, alla fine, dopo tante tribolazioni,
>> Trolltech abbia rilasciato una versione simil-free e' incidentale.
> Il fatto che l'aspetto "licenze" sia stato considerato piu' importante
> dell'aspetto "risultati" ha portato ad avere due ambienti per i fatti
Proprio per questo molti sviluppatori hanno preferito buttarsi su Gnome.
> propri, ognuno con il suo piccolo modello ad oggetti. Per quale ambiente
> sviluppare? KParts? Bonobo? Paradossalmente sono contento dell'esistenza di
> Gnome, visto che KDE2.1 e' piu' lento a partire dello stesso StarOffice in
> emulazione Linux... un bel mattone. Poi non lamentiamoci che Windows
> "richiede sempre piu' risorse".
Appunto e poi per il fatto che ricordi cosi' tanto Uindous ho preferito
da tempo oramai abbandonarlo ed usare sempre e solo Gnome.
> Io poi lavoro sempre in console e scrivo in LaTeX. Ma l'eventuale "Xilinx
> for Linux" non funzionera' in console, e li' bisognera' inventare qualcosa.
Non si puo' mica pretendere che per Linux esista tutto il SW che si e'
abituati ad usare su Uindous, per esempio. Se cio' purtroppo accade c'e'
gente che continua ad essere costretta ad usare Uindous per quell'unico
programma. Si lo so che non e' il massimo ma o ti accontenti di qualche
programma analogo con meno cazzilli volanti e ficiures oppure usi
quello su Uindous, non c'e' alternativa.
>> Non mi pare proprio, specie negli ultimi tempi: io vedo sempre piu' gente
>> che abbandona Uindous perche' stanca di un sistema inaffidabile.
> Ho visto parecchia gente abbandonare Windows per Linux. Quelli che riescono
> a campare senza alcune applicazioni, restano, altri tornano indietro, pur
> bestemmiando in aramaico. Esempio: mi server Xilinx. Non esiste per Linux.
> Che fare?
Gia' detto sopra.
> E' anche vero che sulle mailing list di FreeBSD vedo secchiate di utenti
> che scappano da Linux, e finora non ne ho visto uno solo tornare indietro.
> Questo nonostante la risposta piu' frequente alle domande sia RTFM: ovvio,
> quando i file di configurazione sono nello stesso posto, per tutti.
E poi non dimentichiamo che i *BSD non hanno la stessa quantita' di SW
che c'e' per Linux.
>> Questo e' ancora tutto da vedere, come si comportera' a livello di
>> applicazioni UNIX. E bisognera' vedere anche che stabilita' offrira'.
> Visto che siamo alla _prima_ release e si parla gia' di applicazioni Unix,
> compatibilita' con Classic e nuove applicazioni, mi pare abbastanza
Gia' quando si inizia a parlare di compatibilita' all'indietro mi si
iniziano a rizzare i peli.. sappiamo bene che problemi abbia causato a
Uindous la compatibilita' all'indietro.
> incoraggiante. Ricordiamoci la _prima_ redhat e il _primo_ windows NT: c'e'
> una differenza.
Continui ad insistere su RedHat come se Linux = RedHat..
>> E ti perdi per cosi' poco? Se proprio ti pesa cosi' tanto fai un 'make -n
>> install >/tmp/LOG' e poi prendi da LOG quello che devi disinstallare. Troppo
>> difficile, eh? ;-)
> Buonanotte, lo faccio installare dove vuole e poi vado a vedere che cosa ha
> fatto. Faccio prima ad installarlo in un altro prefix e fare due "find".
Quindi come vedi, una soluzione c'e', non sara' comoda magari ma c'e'.
D'altro canto pur di non usare un RPM non appropriato (ergo vecchio o
non adatto per la mia distro) preferisco quello, personalmente.
[..]
> La differenza e' che qui il "package" e' un semplice file .tgz.
<