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.
> (ehi: come in slackware :-))
Gia', bella roba.. infatti la differenza si vede nella Slackware quando
devi fare gli aggiornamenti di roba di sistema e critica come le libc:
ogni volta e' un "pain in the ass", ecco perche' molta gente l'ha
abbandonata e continuano ad usarla pochi nostalgici.
>> 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.
Su questo sono perfettamente d'accordo: trovo inutile che mi faccia
l'autodetect come il maledetto strafottutissimo Plug & Pray di Uindous.
>>> 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'
Appunto.. la vecchia si frega una volta, si dice..
mc100
> Staremo a vedere chi per primo avra' un browser decente e un office degno
> di tale nome.
be, su X c'e' Explorer nativo e mi pare funzioni decentemente, e Office ci
gira decentemente pure lui...
Saluti
Marco
Giambo
>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.
Mai successo. SuSE6.4 (Con RPM3) e ho installato forse 300 pacchetti
di fila, su piu' macchine. Potenza della SuSE ?
--
__
| _ "The Internet is slow, could you reboot it ?"
|__|iambo mailto:gabr...@giambonini.com
thorin_...@durin.khazad-dum.net
>>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.
> Mai successo. SuSE6.4 (Con RPM3) e ho installato forse 300 pacchetti
> di fila, su piu' macchine. Potenza della SuSE ?
No, e' sempre il pezzo di carne che fa la differenza, continuero' a
sostenerlo sempre..
Henryx
Quando? Sun, 08 Apr 2001 21:12:12 GMT
In quale articolo? <slrn9d152d...@linux.tamarropoli>
| >hai ragione, ma nel mondo BSD non esiste soltanto il FreeBSD, ma anche
| >l'OpenBSD ed il NetBSD.
| mmmh, c'e` anche PowerBSD ;-)
E Stampede :)))))))
Henryx
--
===UN*X is SEXY!===
who|grep -i "green eyes"|date; cd ~; apropos fsck; whatis `unzip`|touch;
strip; finger; mount; gasp; yes|more; uptime; umount; sleep
Henryx
Quando? Tue, 10 Apr 2001 22:35:00 +0000 (UTC)
In quale articolo? <slrn9d6ugc....@olgeni.localdomain.net>
| Non mi resta che sperare in Slackware (ammesso che mi rimanga una macchina
| Linux da qualche parte).
Scusa, ma l'hai mai provata una Debian? Non hai i problemi della RH e
hai un package manager degno di questo nome. Non la usi perche` ci sono
pochi pacchetti? Sbagliato. Il sw in formato .deb c'e`, ed e` anche
parecchio. Inoltre, se non trovi il pacchetto .deb vai di alien o te lo
costruisci dai sorgenti (cosa molto semplice). Vuoi aggiornala in modo
semplice? Basta che scrivi "apt-get update && apt-get upgrade" via CLI e
fa tutto da se (senza nemmeno dover riavviare il pc). Vuoi un supporto
che non sia solo a livello web? Ti compri la Progeny (che e`
praticamente la Debian con dietro una ditta che le gestisce il supporto)
e hai tutto il supporto che ti serve. Vuoi un sistema di installazione
simile a kickstart? Basta che dai da CLI il comando
dpkg --get-selections > install-debian.txt
per avere una lista di tutti i pacchetti installati su di una macchina,
che puoi ripristinare con il comando
dpkg --set-selections < install-debian.txt
Inoltre, a differenza delle distro rpm-based, le distro debian-based
hanno tutte la stessa struttura, dalla Progeny, a Linux Espresso[1]
facendoti dimenticare i mal di testa dovuti allo spostamento dei file di
configurazione da una parte all'altra dell'hd. L'unico difetto che
potrei riscontrare nella Debian e` che, nella versione stable, i prg non
sono molto recenti, cosa dovuta piu` che altro alla filosofia della
distro che a mancanza di voglia di aggiornamento
Henryx
[1] oddio, forse Corel Linux aveva una struttura diversa dalle altre
distro debian-based, ma, come si sa, quella distro era molto
proprietaria
Andrea Capriotti
>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.
apt-get install <pacchetto>/sid
Ovviamente installa automaticamente tutti i pacchetti necessari a
soddisfare le dipendenze. :)
Saluti
--
Andrea Capriotti
thorin_...@durin.khazad-dum.net
>>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.
> Veramente con le ultime versioni di apt e' abbastanza semplice:
> apt-get install <pacchetto>/sid
> Ovviamente installa automaticamente tutti i pacchetti necessari a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> soddisfare le dipendenze. :)
Eh, appunto.. :)
Jimmy Olgeni
> Mai successo. SuSE6.4 (Con RPM3) e ho installato forse 300 pacchetti
> di fila, su piu' macchine. Potenza della SuSE ?
O debolezza di Redhat?
Che versione di RPM usi, la 3.0.4 o la 3.0.5?
La Suse utilizza le dipendenze per gli RPM?
Jimmy Olgeni
>> Staremo a vedere chi per primo avra' un browser decente e un office degno
>> di tale nome.
> be, su X c'e' Explorer nativo e mi pare funzioni decentemente, e Office ci
> gira decentemente pure lui...
Invece Netscape si inchioda, Mozilla non si sa quando arrivera' alla fine e
OpenOffice e' ancora work-in-progress. Si vede che qualche volta anche il
closed source serve a qualcosa :o)
Jimmy Olgeni
>>package. Questo preferirei evitarlo.
> alien [--to-deb] [--to-rpm] [--to-tgz] [--to-slp] [options] file [...]
Se sto usando Debian, i package avranno ovviamente dei sorgenti (il tarball
piu' la directory con i vari MD5, le liste dei file, eccetera). Io posso
convertire un package binario da .deb a .rpm a .xyz, ammettendo che le
librerie siano uguali da entrambe le parti, ma posso convertire un sorgente
di .deb al .src.rpm corrispondente, con alien? Speriamo :-)
Se sto cambiando Debian non mi e' di alcun aiuto convertire i .deb binari a
.rpm, perche' non ho piu' modo di creare i .deb binari all'origine :o)
> 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,
Qualcuno ci era gia' arrivato da solo :)
> dselect, aptitude, deity o addirittura red-carpet.
Immagino che fosse piu' facile ricordare che "portupgrade" serve a fare
l'"upgrade" dei "port" (!)
> 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)
Lo stesso si fa in FreeBSD con cvsup e portupgrade. Con cvsup si aggiorna
il sistema operativo, con portupgrade i package aggiuntivi. Per fortuna
c'e' una differenza fra i due, non devo tirare a indovinare come in redhat
per capire se bogotronix-1.0 e' un pezzo di OS o un package opzionale.
Certo potrei sempre fare una mostruosa query sul database RPM cercando
"System Environment/*" :o)
> Un bel brindisi di buon "vino" e si parte:
> http://www.polybus.com/xilinx_on_linux.html
Questo e' di gran conforto e lo passero' al mio collega che si occupa di
hardware :)
>>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. :)
Immagino allora che tu sia familiare con il resto. Fra parentesi, e' da
notare che ormai il dibattito/confronto fra i sistemi operativi si basa
quasi esclusivamente sulle licenze.
Fase 1: ci si accontentava di chiedere specifiche e documentazione sui
formati di file e sui protocolli, il closed source era una cosa ancora
sopportabile purche' fatto bene. Il confronto poteva avvenire su temi piu'
o meno tecnici.
Fase 2: open source a manetta, quello che non e' open source e' spazzatura.
Da quello che ho visto, una buona percentuale di spazzatura effettivamente
c'e', ma qualcosa ancora si puo' salvare, no?
Fase 3: GPL o morte, tutte le altre licenze (anche se benevolmente
approvate dalla self-appointed "Open Source Foundation") non vanno bene,
sono "sbagliate" e tradiscono "la grande comunita' degli hacker". Come se
chi sviluppa software con licenza BSD fosse, in fondo, un sicario di Bill
Gates. Amen! Sia lodata la pistola di Raymond! :o)
Le varie petizioni e richieste di specifiche portano sempre la motivazione
"serve per supportare Linux", ben sapendo che esistono parecchi altri
sistemi operativi oltre il Pinguino. Agli occhi del pubblico, "open source"
diventa "linux". I sorgenti rilasciati dalle societa' che "abbracciano
l'open source" sono spesso sotto GPL, cosa che ovviamente impedisce l'uso
dei software in questione con OS non-GPL.
Per ogni software gia' "free" si sente il bisogno di creare un clone sotto
GPL. Poco tempo fa, ad esempio, ricordo che qualcuno aveva proposto di
realizzare un clone GPL di Darwin, cosa di cui non riesco ad intravedere
l'utilita' neanche sforzandomi. E a pensarci bene, la licenza BSD e' molto
piu' "free" della GPL. Se io aggiungo 1.000.000 di righe a un progetto GPL
di 12.000, la GPL mi toglie la liberta' di utilizzare quella milionata di
righe, da me sviluppata, come meglio credo. A quel punto dovrei
reimplementare anche le restanti 12.000, solo per avere la benevola
comunita' degli hacker pronta a spulciare il codice gridando "aiuto! aiuto!
qualcuno ha violato la GPL!", come se non ci fossero cose piu' importanti a
cui pensare.
E' abbastanza deprimente :-)
Jimmy Olgeni
> Forse ti sfuggono i concetti di dipendenza e di versioning delle
> librerie. Faccio un esempio:
Spero di ricordarmi ancora come funzionano le dipendenze, visto che
passo le ore in mezzo a questa roba:
LIB_DEPENDS= xml.5:${PORTSDIR}/textproc/libxml \
gdk_pixbuf.2:${PORTSDIR}/graphics/gdk-pixbuf
RUN_DEPENDS= ${LOCALBASE}/share/Choices:${PORTSDIR}/x11-fm/rox-base
:o)
> ora, se tu facessi un upgrade di Kerberos o slang ad una versione piu'
> recente come pretenderesti che _quel_ mutt continui a funzionare bene?
Sicuramente _non_ continuerebbe a funzionare, e a ragione: ci sarebbe
il linker che bestemmia in turco. Ma il database degli RPM sarebbe
ancora integro, felice e contento :o)
In realta' non riuscirei neanche ad aggiornarlo, visto che se le
dipendenze non sono soddisfatte l'rpm di turno non si installa.
> 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.
Infatti erano gli update "official" della 6.2, piu' relative di cosi' :)
> 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.
Se proprio mi chiedono una cosa del genere ricompilo il .src.rpm e lo
adatto alla 6.2. Ma di solito mi chiedono di aggiungere un bottone piu'
colorato :(
> 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.
Tu. Prova a darlo in mano a Zimbongo Scimmia del Congo e a Zimbango
Stupido Orango: prima di azzeccare il comando fanno prima a convertire
la partizione ext2 in fat32 scrivendo comandi a caso :o)
> 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,
Non mi resta che riprovare il tutto sotto "script" per ottenere un log del
botto :o)
> Nelle distribuzioni ognuno installa la versione appropriata e cio' vale
> per _qualsiasi_ distribuzione.
Solo che purtroppo una Debian con kernel 2.2.16 sta in piedi, una
redhat con lo stesso kernel (+ vari patch), sulla stessa macchina, va
in kernel panic con loadavg 0. Poi su un'altra macchina ancora funziona.
Anche qui, piu' che problemi di kernel, ci sono problemi dati dallo
spingere fuori dalla porta, in fretta, release che non sono ancora pronte.
Se poi il kernel del pinguino avesse il buon gusto di lasciare un core dump
del kernel quando muore, probabilmente sarebbe piu' utile di AIEEE! killing
interrupt handler! killing idle task! e altre cose.
Se il kernel di FreeBSD decide che e' tempo di morire, almeno lascia
un testamento:
Apr 9 19:20:56 olgeni savecore: reboot after panic: page fault
Apr 9 19:20:56 olgeni savecore: writing core to /var/crash/vmcore.6
Apr 9 19:21:28 olgeni savecore: writing kernel to /var/crash/kernel.6
"gdb -k" is my friend. E' importante morire con dignita' :)
> Anche con Debian, immagino, non si puo' infilare un .deb per la SID
> in una potato in modo indolore.
Forse ricompilando, se non bisogna spostare i file.
> Sarei curioso a questo punto di sapere dove tu prenda i tuoi RPM perche'
> alle differenti versioni didistribuzione mettono anche dei colori
> differenti per far notare la differenza alla gente.
Non e' un problema di _quali_ rpm, ma di _quanti_ tutti insieme. Lo devo
proprio provare e salvarmi il log, e' uno spettacolo :o)
>> 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
Beh, ora neanche io mi fido :-)
Ma visto che la 6.2 ha di serie RPM3, non sarebbe bastato dare come
update un RPM3 che funziona, lasciando il 4 per la redhat 7?
> costretto pure ad un upgrade di rpm. Per precisione aggiungo che io ho
> rpm-3.0.5-9.6x.
Bingooo. Io ho rpm-3.0.4-0.48.i386.rpm. Quello che danno con la 6.2. Dove
hai preso il tuo? Ecco perche' funzionava :-)
>> 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.
lftp updates.redhat.com:/6.2/en/os/i386> ls ucd*
-rw-rw-r-- 1 2220 235 635493 Mar 29 09:24 ucd-snmp-4.1.1-3.i386.rpm
-rw-rw-r-- 1 2220 235 271608 Mar 29 09:24 ucd-snmp-devel-4.1.1-3.i386.rpm
-rw-rw-r-- 1 2220 235 113121 Mar 29 09:25 ucd-snmp-utils-4.1.1-3.i386.rpm
Richiede RPM4 per dare l'elenco dei package installati via SNMP.
>> Se ne installi 50 con -Uvh arriva il botto. Io ho una RedHat "Official
> MAI avuto nessun botto.
Perche' il tuo 3.0.5 funziona :-)
> Allora usa Slackware ma saranno cazzi tuoi, senza un package manager.
Se devo passare da FreeBSD a Slackware per perderci, passo il turno :o)
> 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 !!
Il tutto e' cominciato perche' in FreeBSD avevo piu' software, perche'
la ports collection e' aggiornata piu' frequentemente dei vari
repository di rpm, perche' in FreeBSD al contrario di redhat il
magneto ottico funzionava senza farmi aspettare 3 ore per copiare un
file, e perche' il kernel sulla mia macchina stava in piedi. E,
ribadisco, se deve morire lascia un pezzo di core dump da studiare.
Poi alla Ximian si sono un po' seduti, e io volevo uno gnome aggiornato
prima delle prossima era geologica :)
> Per fortuna gli utenti Linux che trovano "package Makefile not found"
> finora sono molto pochi <g>
Confermo comunque che con RPM4 e' risolto (l'ho appena provato), quindi non
dovrebbe vederlo piu' nessuno.
>> 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>
E' Pasqua e non posso esprimere in dettaglio le mie opinioni su Visual
C++. :o)
>> cerca di fare Windows e ci riesce benissimo.
> Si ma per fortuna alcuni utenti l'aiutano benissimo in questo <g>
L'aumento della "user base" purtroppo porta come effetto collaterale
la creazione di distribuzioni "Barbie Linux - Drooling Retard Edition",
dove si pone piu' attenzione all'interfaccia utente (che alla fine e' il
solito KDE), tralasciando magari qualche altro piccolo dettaglio. C'era una
versione di Mandrake su cui non funzionava un JDK, perche' la glibc era
compilata in qualche modo strano. Brutti ricordi.
> Non ho mai usato .src.rpm, a questo punto, sapendo di dover usare i
> sorgenti ho sempre fatto prima a compilare il tarball.
Il .src.rpm e' quasi come il tarball :o)
>> succede quando Redhat Network (pagato[0]) mi installa RPM4?
> Cosa e' Redhat Network ed a cosa serve? Perche' l'hai installato?
Non l'ho installato, per fortuna. E' una specie di Windows Update
imbastardito. Anzi, fa quello che ha sempre fatto apt-get, solo che
vuole soldi per farlo. No, non ha senso e non mi viene in mente
nessuna giustificazione plausibile per questa "geniale" trovata
commerciale :o)
La redhat 7 installa un daemon (rhnsd) e lo avvia per default. La versione
"stock" del daemon si mangia tutti i file descriptor del sistema, che dopo
un po'... muore. Ed e' il daemon che dovrebbe occuparsi di far funzionare
tutto il resto. Barf-o-rama.
> Appunto e poi per il fatto che ricordi cosi' tanto Uindous ho preferito
> da tempo oramai abbandonarlo ed usare sempre e solo Gnome.
Qualche volta ho l'impressione che la GUI di W2K, pur detestabile, sia
piu' snella del KDE. Io comunque uso rox-filer. :o)
> 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.
VMware is my friend. Almeno se Windows fa il botto non si tira dietro
il master boot. VMware per Linux funziona sotto FreeBSD, in emulazione
Linux (!)
>> bestemmiando in aramaico. Esempio: mi server Xilinx. Non esiste per Linux.
>> Che fare?
> Gia' detto sopra.
In un altro post mi dicono invece che esiste. Sorpresa :)
> E poi non dimentichiamo che i *BSD non hanno la stessa quantita' di SW
> che c'e' per Linux.
Altroche'. Ricordi quando si parlava di 4900 package? Balle:
$ cat /usr/ports/INDEX | wc -l
5003
Sono aumentati nel frattempo. Tutti i software open source funzionano
anche in FreeBSD, con qualche patch al massimo. Ma i patch sono gia'
nella ports collection, quindi non li devi fare tu.
myhost:/usr/ports/x11-toolkits/qt23$ ls files
manpages patch-af
patch-aa patch-designer::Makefile.in
I software closed source funzionano in emulazione. StarOffice funziona
tranquillamente in emulazione. Le uniche cose che non funzionano sono
quelle che richiedono estensioni specifiche di Linux, vedi iptables e
compagnia.
Non devo fare il cane e cercare i software sul web, dato che:
$ ls /usr/ports/x11-toolkits/
FWF guile-gtk py-tkinter
Makefile icegradient py-wxPython
Motif-dummy itk qt145
[snip]
gtkstep-pastel py-kde xview
guile-gnome py-qt xview-clients
e' gia' tutto li'. Dal log di cvsup vedo che cosa viene aggiornato: e'
quasi meglio di freshmeat. Anzi, e' da vedere: http://www.freshports.org.
> 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.
La compatibilita' all'indietro serve a tirarsi appresso la user base.
Senza user base nessuno sviluppa nuovi software nativi per il nuovo OS,
perche' nessun utente compra un nuovo OS che non ha applicazioni. Anche
FreeBSD ha la compatibilita' all'indietro per Linux <g>
>> incoraggiante. Ricordiamoci la _prima_ redhat e il _primo_ windows NT: c'e'
>> una differenza.
> Continui ad insistere su RedHat come se Linux = RedHat..
Non ha senso ricordare il primo Linux, visto che e' solo il kernel,
e dopo aver fatto il boot si pianta li' alla ricerca dell'init che non
c'e'. Lo stesso vale per la "prima" versione di qualunque altra
distribuzione. Purtroppo mi trovo ad insistere su RedHat perche' ci ho
sofferto di piu' :)
> Gia', bella roba.. infatti la differenza si vede nella Slackware
> quando
Solo che nei .tgz di FreeBSD ci sono elencate le dipendenze, non so
come funzioni invece in Slackware.
> devi fare gli aggiornamenti di roba di sistema e critica come le libc:
> ogni volta e' un "pain in the ass", ecco perche' molta gente l'ha
> abbandonata e continuano ad usarla pochi nostalgici.
Qui la 'libc' non arriva come "package", ma dai sorgenti aggiornati
con cvsup: c'e' una differenza fra il sistema operativo (in /usr/) e i
package (in /usr/local o /usr/X11R6). E' abbastanza utile sapere che
cosa e' OS e che cosa sono le aggiunte. Gli RPM si installano tutti in
/usr/* e tutti i file di configurazione sono in /etc/. Bel casino :o)
# cd /usr/src && make update world
> Su questo sono perfettamente d'accordo: trovo inutile che mi faccia
> l'autodetect come il maledetto strafottutissimo Plug & Pray di
> Uindous.
Ma oltretutto fa l'autodetect di cose senza senso: ok la scheda video,
ma farmi vedere la finestrella di dialogo perche' ho cambiato CD mi
sembra demente... McFly??? Per non parlare di linuxconf... ogni volta
faceva partire gpm perche' c'era un bug nell'init script di gpm.
Mai sottovalutare il vantaggio di poter fare i commit al volo quando
qualcosa va storto :o)
Balu - Marco Verdecchia
> Chi ha scritto? Pardo <Pardo@fake_address.do_not_mail>
> Quando? Sun, 08 Apr 2001 21:12:12 GMT
> In quale articolo? <slrn9d152d...@linux.tamarropoli>
>
> | >hai ragione, ma nel mondo BSD non esiste soltanto il FreeBSD, ma anche
> | >l'OpenBSD ed il NetBSD.
> | mmmh, c'e` anche PowerBSD ;-)
>
> E Stampede :)))))))
PowerBSD, Stampede, ma ragazzi, da dove saltano fuori questi due?
Sulla distribuzione NetBSD e' presente un file che contiene tutta la
cronistoria del *BSD e questi due non li ho mai sentiti nominare.
Siete sicuri che esistano?
>
> Henryx
> --
> ===UN*X is SEXY!===
> who|grep -i "green eyes"|date; cd ~; apropos fsck; whatis `unzip`|touch;
> strip; finger; mount; gasp; yes|more; uptime; umount; sleep
>
--
\|||/
---------------------------oOOo--@ @--oOOo----------------------------
Marco Verdecchia <ba...@ELIMINAMI.katamail.com>
togli ELIMINAMI per potermi rispondere in email
thorin_...@durin.khazad-dum.net
>> Mai successo. SuSE6.4 (Con RPM3) e ho installato forse 300 pacchetti
>> di fila, su piu' macchine. Potenza della SuSE ?
> O debolezza di Redhat?
No, colpa _tua_ perche' colme ti ho detto il mio rpm funziona benissimo.
> Che versione di RPM usi, la 3.0.4 o la 3.0.5?
> La Suse utilizza le dipendenze per gli RPM?
Certo che si.
thorin_...@durin.khazad-dum.net
>> Forse ti sfuggono i concetti di dipendenza e di versioning delle
>> librerie. Faccio un esempio:
> Spero di ricordarmi ancora come funzionano le dipendenze, visto che
> passo le ore in mezzo a questa roba:
Beh allora e' strano come solo a te non funzionino le cose. Ripeto, RPM
ha i suoi grossi difetti ma problemi di questo genere non me ne ha mai
dato, basta fare le cose con un certo criterio..
>> ora, se tu facessi un upgrade di Kerberos o slang ad una versione piu'
>> recente come pretenderesti che _quel_ mutt continui a funzionare bene?
> Sicuramente _non_ continuerebbe a funzionare, e a ragione: ci sarebbe
> il linker che bestemmia in turco. Ma il database degli RPM sarebbe
> ancora integro, felice e contento :o)
Si, a patto di usare --nodeps o --force.
> In realta' non riuscirei neanche ad aggiornarlo, visto che se le
> dipendenze non sono soddisfatte l'rpm di turno non si installa.
No puoi forzarlo ma poi devi aspettarti di tutto.
>> 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.
> Infatti erano gli update "official" della 6.2, piu' relative di cosi' :)
E dagli.. potevano essere anche updates ufficiali ma preoccuparsi di
verificare se fossero necessari veramente no, eh? Io ho continuato ad
usare rpm 3.0.5 e non ho avuto problemi. Che cacchio, ci si lamenta che
RH sta diventando come Uindous pero' poi quando si installa la prima
cosa che si chiede di installare, come accade con Uindous, lo si fa
senza pensarci un attimo, mah.
>> 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.
> Se proprio mi chiedono una cosa del genere ricompilo il .src.rpm e lo
> adatto alla 6.2. Ma di solito mi chiedono di aggiungere un bottone piu'
> colorato :(
Anche qui ci sarebbe qualcosa da obiettare visto che quelle rare volte
che ho provato ad usare un .src.rpm sono stati piu' i casini che altro
ed alla fine mi sono sbrigato prima prendendo un tarball ed usando
quello per compilare. Non c'e' nulla da fare, RH per queste cose non mi
e' mai piaciuta.
>> 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.
> Tu. Prova a darlo in mano a Zimbongo Scimmia del Congo e a Zimbango
> Stupido Orango: prima di azzeccare il comando fanno prima a convertire
> la partizione ext2 in fat32 scrivendo comandi a caso :o)
Ritengo che queste non sono cose da lasciar fare ad un utonto, punto.
>> 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,
> Non mi resta che riprovare il tutto sotto "script" per ottenere un log del
> botto :o)
Il log serve a poco se non ho conoscenza di tutto il resto (come e'
configurata quella macchina, che versioni di programmi e librerie ci
sono).
>> Nelle distribuzioni ognuno installa la versione appropriata e cio' vale
>> per _qualsiasi_ distribuzione.
> Solo che purtroppo una Debian con kernel 2.2.16 sta in piedi, una
> redhat con lo stesso kernel (+ vari patch), sulla stessa macchina, va
> in kernel panic con loadavg 0. Poi su un'altra macchina ancora funziona.
Che patch? Per che cosa? Man mano saltano fuori delle cose nuove..
> Se il kernel di FreeBSD decide che e' tempo di morire, almeno lascia
> un testamento:
Anche quello della RH, vedi i problemi di paginazione con il 2.2.17, se
e' per quello. Ma ci guardi ogni tanto in /var/log/messages?
>> Anche con Debian, immagino, non si puo' infilare un .deb per la SID
>> in una potato in modo indolore.
> Forse ricompilando, se non bisogna spostare i file.
Ma devi sempre stare attento alle dipendenze, per fortuna che se usi
apt-get il problema te lo risolve lui, solo che non e' una buona
pratica.
>> Sarei curioso a questo punto di sapere dove tu prenda i tuoi RPM perche'
> updates.redhat.com :o)
Si ma era proprio necessario upgradare ad RPM 4? E' questo che non
riesco ad afferrare? Ho visto che c'e' rpm-4.0.2-6x ma io mi son ben
guardato dall'installarlo non ritenendolo necessario. Ripeto, mi pare
che tu faccia come gli utonti Uindous che installa la prima cosa nuova
che vede e se il cliente mi avesse detto di farlo gli avrei detto che
era una stronzata.
>> alle differenti versioni didistribuzione mettono anche dei colori
>> differenti per far notare la differenza alla gente.
> Non e' un problema di _quali_ rpm, ma di _quanti_ tutti insieme. Lo devo
> proprio provare e salvarmi il log, e' uno spettacolo :o)
Si salvalo perche' direi che e' una cosa unica e rara, considerato che
in un po' di anni che uso RPM non ho mai sentito una cosa del genere <G>
>>> 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
> Beh, ora neanche io mi fido :-)
> Ma visto che la 6.2 ha di serie RPM3, non sarebbe bastato dare come
> update un RPM3 che funziona, lasciando il 4 per la redhat 7?
Il mio _funziona eccome_
>> costretto pure ad un upgrade di rpm. Per precisione aggiungo che io ho
>> rpm-3.0.5-9.6x.
> Bingooo. Io ho rpm-3.0.4-0.48.i386.rpm. Quello che danno con la 6.2. Dove
> hai preso il tuo? Ecco perche' funzionava :-)
Devo averlo preso in base ad una segnalazione su Bugtraq per una
notifica di aggiornaemnto e credo sempre su updates ma ora non ricordo,
ce l'ho da un po' di tempo. Se vuoi te lo mando via e-mail, tanto
dovrei averlo su qualche CD.
>>> 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.
> lftp updates.redhat.com:/6.2/en/os/i386> ls ucd*
> -rw-rw-r-- 1 2220 235 635493 Mar 29 09:24 ucd-snmp-4.1.1-3.i386.rpm
> -rw-rw-r-- 1 2220 235 271608 Mar 29 09:24 ucd-snmp-devel-4.1.1-3.i386.rpm
> -rw-rw-r-- 1 2220 235 113121 Mar 29 09:25 ucd-snmp-utils-4.1.1-3.i386.rpm
> Richiede RPM4 per dare l'elenco dei package installati via SNMP.
Credo non siano queste le versioni presenti sul CD: ora non ce l'ho
sotto mano perche' e' in ufficio ma sono quasi sicuro che sul CD c'erano
versioni inferiori. Di sicuro sono usciti anche degli updates (ricordo
di averli scaricati sempre dopo aver letto delle segnalazioni su
Bugtraq).
>>> Se ne installi 50 con -Uvh arriva il botto. Io ho una RedHat "Official
>> MAI avuto nessun botto.
> Perche' il tuo 3.0.5 funziona :-)
Allora te lo mando consigliandoti ancora una volta di buttare via il
tuo.
>> Allora usa Slackware ma saranno cazzi tuoi, senza un package manager.
> Se devo passare da FreeBSD a Slackware per perderci, passo il turno :o)
Non posso che essere d'accordo: ho abbandonato Slackware anni fa proprio
per questo motivo.
>> 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 !!
> Il tutto e' cominciato perche' in FreeBSD avevo piu' software, perche'
> la ports collection e' aggiornata piu' frequentemente dei vari
Ma provare per esempio Debian invece di RedHat no, eh?
> Poi alla Ximian si sono un po' seduti, e io volevo uno gnome aggiornato
> prima delle prossima era geologica :)
Dovresti essere contento di questo, significa che invece di farlo uscire
quando vogliono gli utenti, come fanno m$ e RH, lo fanno uscire quando
_loro_ ritengono sia pronto.
>> Per fortuna gli utenti Linux che trovano "package Makefile not found"
>> finora sono molto pochi <g>
> Confermo comunque che con RPM4 e' risolto (l'ho appena provato), quindi non
> dovrebbe vederlo piu' nessuno.
Continuo ad avere i miei dubbi sulla utilita' di RPM4.
>>> 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>
> E' Pasqua e non posso esprimere in dettaglio le mie opinioni su Visual
> C++. :o)
Ah io le posso esprimere sintetizzandole con una sola parola di 5
lettere che inizia per 'm' e termina per 'a', e posso dirlo vedendo cio'
che fa patire ad un paio di miei utenti..
>>> cerca di fare Windows e ci riesce benissimo.
>> Si ma per fortuna alcuni utenti l'aiutano benissimo in questo <g>
> L'aumento della "user base" purtroppo porta come effetto collaterale
> la creazione di distribuzioni "Barbie Linux - Drooling Retard Edition",
Per fortuna che non si e' costretti ad usarle e si puo' ancora scegliere
distribuzioni migliori..
>> Non ho mai usato .src.rpm, a questo punto, sapendo di dover usare i
>> sorgenti ho sempre fatto prima a compilare il tarball.
> Il .src.rpm e' quasi come il tarball :o)
Non proprio, il tarball non ha script di pre e post installazione.
>>> succede quando Redhat Network (pagato[0]) mi installa RPM4?
>> Cosa e' Redhat Network ed a cosa serve? Perche' l'hai installato?
> Non l'ho installato, per fortuna. E' una specie di Windows Update
> imbastardito. Anzi, fa quello che ha sempre fatto apt-get, solo che
Non posso che essere d'accordo se non l'hai installato. Mi sa che deve
essere una qualche porcheria alla kudzu che avrebbe fatto piu' danni che
altro.
> La redhat 7 installa un daemon (rhnsd) e lo avvia per default. La versione
> "stock" del daemon si mangia tutti i file descriptor del sistema, che dopo
Continuo a ritenere che RH7 si sia avvicinata a Corel Linux nella mia
personale classifica di distribuzioni Linux modello sterco da evitare.
>> Appunto e poi per il fatto che ricordi cosi' tanto Uindous ho preferito
>> da tempo oramai abbandonarlo ed usare sempre e solo Gnome.
> Qualche volta ho l'impressione che la GUI di W2K, pur detestabile, sia
> piu' snella del KDE. Io comunque uso rox-filer. :o)
Infatti KDE e' _molto_ pesante, ritengo forse (e sottolineo forse) piu'
di Gnome.
>> 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.
> VMware is my friend. Almeno se Windows fa il botto non si tira dietro
Vero, io ci faccio girare un NT4 con SP6 e tanto software, da Linux.
[..]
>> E poi non dimentichiamo che i *BSD non hanno la stessa quantita' di SW
>> che c'e' per Linux.
> Altroche'. Ricordi quando si parlava di 4900 package? Balle:
Non vorrei fare a chi ce l'ha piu' lungo... rimango dell'opinione che
Debian forse ne abbia di piu' ma non ne sono sicuro.
[..]
> I software closed source funzionano in emulazione. StarOffice funziona
> tranquillamente in emulazione. Le uniche cose che non funzionano sono
Se ti sta bene FreeBSD usalo, allora.
> e' gia' tutto li'. Dal log di cvsup vedo che cosa viene aggiornato: e'
> quasi meglio di freshmeat. Anzi, e' da vedere: http://www.freshports.org.
Questo lo puoi fare con Debian con un apt-get update ;-)
>> Gia' quando si inizia a parlare di compatibilita' all'indietro mi si
>> iniziano a rizzare i peli.. sappiamo bene che problemi abbia causato a
[..]
> FreeBSD ha la compatibilita' all'indietro per Linux <g>
Senza la quale non avrebbe tanto SW, per es. StarOffice ;-)
>>> incoraggiante. Ricordiamoci la _prima_ redhat e il _primo_ windows NT: c'e'
>>> una differenza.
>> Continui ad insistere su RedHat come se Linux = RedHat..
> Non ha senso ricordare il primo Linux, visto che e' solo il kernel,
> e dopo aver fatto il boot si pianta li' alla ricerca dell'init che non
Boh, secondo me devi portare il tuo Linux a farsi benedire a Lourdes.
Mai successa una cosa del genere, eppure RH la uso da almeno 2 anni e
mezzo o piu'. Sono partito dalla 4.x per arrivare alla 6.2 e li' mi sono
fermato ma problemi come quelli che stai citando non me ne sono mai
accaduti.
>> Gia', bella roba.. infatti la differenza si vede nella Slackware
>> quando
> Solo che nei .tgz di FreeBSD ci sono elencate le dipendenze, non so
> come funzioni invece in Slackware.
Non ce ne sono ergo ti attacchi. Che vuol dire 'ci sono elencate le
dipendenze'? C'e' un file ASCII che le riporta?
>> devi fare gli aggiornamenti di roba di sistema e critica come le libc:
>> ogni volta e' un "pain in the ass", ecco perche' molta gente l'ha
[..]
> Qui la 'libc' non arriva come "package", ma dai sorgenti aggiornati
> con cvsup: c'e' una differenza fra il sistema operativo (in /usr/) e i
> package (in /usr/local o /usr/X11R6). E' abbastanza utile sapere che
> cosa e' OS e che cosa sono le aggiunte. Gli RPM si installano tutti in
> /usr/* e tutti i file di configurazione sono in /etc/. Bel casino :o)
Beh volendo puoi anche decidere di installarli altrove (man rpm)
>> l'autodetect come il maledetto strafottutissimo Plug & Pray di
>> Uindous.
> Ma oltretutto fa l'autodetect di cose senza senso: ok la scheda video,
> ma farmi vedere la finestrella di dialogo perche' ho cambiato CD mi
Si puo' disabilitare, senza farsi troppi problemi: vai in ntsysv (mi
pare) e lo trombi.
> sembra demente... McFly??? Per non parlare di linuxconf... ogni volta
> faceva partire gpm perche' c'era un bug nell'init script di gpm.
Ti sei preoccupato di vedere se c'era un RPM aggiornato? No dico,
attribuire pure colpe che puoi evitare ad RPM mi pare troppo.
Giambo
> Che versione di RPM usi, la 3.0.4 o la 3.0.5?
giambo@salotto:~ > rpm -qa | grep rpm
rpm-3.0.4-72
> La Suse utilizza le dipendenze per gli RPM?
Uh, credo proprio di si, sarebbe difficile districarsi tra 7CD della
distribuzione 7.1 :-)
Jimmy Olgeni
>> La Suse utilizza le dipendenze per gli RPM?
> Certo che si.
Dove trovo un .src.rpm di Suse per guardarci dentro? Nel sito non ne vedo
neanche uno, probabilmente mi sfugge qualcosa (!), devono pur essere da
qualche parte :)
Jimmy Olgeni
> Beh allora e' strano come solo a te non funzionino le cose. Ripeto, RPM
Infatti non ho mai avuto un problema di dipendenze. Solo di database a
pezzettini.
>> il linker che bestemmia in turco. Ma il database degli RPM sarebbe
>> ancora integro, felice e contento :o)
> Si, a patto di usare --nodeps o --force.
Se non li uso non si installa nemmeno. Se li uso si installa, e nel
database ci saranno dipendenze non soddisfatte, pur continuando a
funzionare. Sicuramente non mi lascera' il db a pezzi :)
>> In realta' non riuscirei neanche ad aggiornarlo, visto che se le
>> dipendenze non sono soddisfatte l'rpm di turno non si installa.
> No puoi forzarlo ma poi devi aspettarti di tutto.
Posso aspettarmi che i singoli programmi (mutt ad esempio) abbiano errori,
ma non che il database stesso di RPM si metta a fare cose strane.
> verificare se fossero necessari veramente no, eh? Io ho continuato ad
> usare rpm 3.0.5 e non ho avuto problemi. Che cacchio, ci si lamenta che
Io avevo il 3.0.4, che e' quello "stock" di redhat 6.2. Il fatto che non
funzionasse (al contrario del tuo 3.0.5 che avrai trovato da qualche altra
parte) era un buon incentivo ad aggiornarlo.
>> Stupido Orango: prima di azzeccare il comando fanno prima a convertire
>> la partizione ext2 in fat32 scrivendo comandi a caso :o)
> Ritengo che queste non sono cose da lasciar fare ad un utonto, punto.
E proprio per questo mi serviva il CD con tutti i patch gia' inseriti :^)
> Il log serve a poco se non ho conoscenza di tutto il resto (come e'
> configurata quella macchina, che versioni di programmi e librerie ci
> sono).
Quelle che installa la 6.2 senza aggiungere niente: proprio qui sta la
sorpresa.
>> redhat con lo stesso kernel (+ vari patch), sulla stessa macchina, va
>> in kernel panic con loadavg 0. Poi su un'altra macchina ancora funziona.
> Che patch? Per che cosa? Man mano saltano fuori delle cose nuove..
Vedi cosa succede a non guardare dentro i .src.rpm? :o)
Giochino: prendi ad esempio il kernel 2.2.17 che danno come aggiornamento
negli updates. Puoi provare anche con il 2.2.16 o con qualsiasi altro
kernel di redhat. Fai cosi':
# rpm -i kernel-bla.bla.src.rpm
# cd /usr/src/redhat/SOURCES
Ora fai un bel respiro, poi:
# ls
README.kernel-sources
drm-2.4.0-test6-pre5.patch
ibcs-2.1-981105.tar.gz
installkernel
ipvs-0.9.16-2.2.17.patch
ipvs-1.0.2-2.2.17.patch
kernel-2.2-BuildASM.sh
kernel-2.2-modulerename.script
kernel-2.2.17-alpha-BOOT.config
kernel-2.2.17-alpha-enterprise.config
[huge snip]
linux-merge-config.awk
linux-merge-modules.awk
linux-rhconfig-22.h
module-info
pcmcia-cs-2.8.8-network.script
pcmcia-cs-3.1.20.tar.gz
rhkmvtag.c
Si', e' effettivamente lungo: sono __157__ file.
Ovviamente tutto quello che finisce con .diff e .patch e' un patch al
kernel "standard" di Linux. Non ho guardato che cosa si nasconda nel loro
kernel "enterprise" (ahah!) ma lo immagino. Non mi pare una buona garanzia
di stabilita'. E se e' necessario compilare un kernel separato per avere le
funzionalita' "enterprise", mi vengono dei dubbi sulla possibilita' di
tuning run-time del kernel. E' un mini kernel-fork? Cosa cambia da standard
a enterprise? Il file system journaled? ext3? reiserfs? o siamo ancora
all'ext2fs async?
Che ci fa tutta quella roba dentro il mio kernel? Certo posso ricompilare
anche il kernel dal tarball, ma a questo punto fra kernel e applicazioni si
comincia ad esagerare. Tanto vale mettere kernel e utility varie in un
pezzo di CVS e andare avanti a colpi di Makefile. Mi ricorda qualcosa <g>
Gia' sento le obiezioni: con il CVS e i committer "lo sviluppo diventa
chiuso". Invece, scambiandosi i patch via mail e aspettando le release di
Torvalds - che poco hanno a che fare con quelle in molte distro - lo
sviluppo e' "aperto". Ogni tanto su slashdot capita di leggere roba di
questo calibro. Poco importa se poi esistono un paio di fork del kernel per
altre piattaforme, ognuna nel suo piccolo CVS.
Il CVS, a volerlo evitare, si moltiplica :o)))
Ora, a parita' di kernel, si capisce perche' una Debian col 2.2.16 potesse
stare in piedi e la RedHat no, sullo stesso hardware: il kernel di RedHat
contiene un miliardo di patch che nulla hanno a che vedere con il kernel
ufficiale. Oltre ad avere 40 distribuzioni probabilmente abbiamo anche 40
kernel diversi, tutto con la stessa etichetta "2.2.x".
Poi... si dice che i BSD sono frammentati. <G>
>> Se il kernel di FreeBSD decide che e' tempo di morire, almeno lascia
>> un testamento:
> Anche quello della RH, vedi i problemi di paginazione con il 2.2.17, se
> e' per quello. Ma ci guardi ogni tanto in /var/log/messages?
... sigh. Quali problemi di paginazione? Questa non la sapevo. Ogni tanto
dice "VM qualcosa killed". E' un problema del kernel o di hardware?
Io per testamento intendo un bel core dump da 128 mega su cui far girare
gdb per ottenere un traceback delle funzioni chiamate prima del panic. Poi
e' chiaro che se qualche processo user da' un signal 11 me lo trovo
segnalato sul kernel. Va bene anche il kernel debugger da attivare con
qualche combinazione di tasti.
Quando il kernel muore, come va a scrivere con il syslog? E' morto pure
quello. Niente kernel, niente scheduler, niente processi. Per questo il
core dump finisce nella partizione di swap (o su un dump device qualsiasi).
Funziona anche se muore il filesystem :)
> Si ma era proprio necessario upgradare ad RPM 4? E' questo che non
> riesco ad afferrare?
Evidentemente, e per esperienza personale, no. Come non e' il caso a questo
punto di continuare ad usare RedHat visto che non sono in grado di gestire
il release engineering, ne' tantomento i patch al kernel. Ora lo so.
E' chiaro che posso installare qualsiasi distribuzione e mantenerla
"stabile" a colpi di sorgenti e compilazioni. E' comunque opportuno evitare
in partenza le distribuzioni che non hanno idea di cio' che stanno facendo
con il loro prodotto.
> Si salvalo perche' direi che e' una cosa unica e rara, considerato che
> in un po' di anni che uso RPM non ho mai sentito una cosa del genere <G>
Appena ritrovo un CD originale della 6.2 lo faccio :)
> ce l'ho da un po' di tempo. Se vuoi te lo mando via e-mail, tanto
> dovrei averlo su qualche CD.
Lo andro' a cercare in giro, per curiosita'.
>> lftp updates.redhat.com:/6.2/en/os/i386> ls ucd*
>> -rw-rw-r-- 1 2220 235 635493 Mar 29 09:24 ucd-snmp-4.1.1-3.i386.rpm
[...]
> di averli scaricati sempre dopo aver letto delle segnalazioni su
> Bugtraq).
Eccoli li'. E gli update di ucd-snmp richiedono RPM4.
Prova ad installarne uno, vedi cosa dice. Non si installera'.
Forse ricompilando dal .src.rpm uno se la scampa.
> Allora te lo mando consigliandoti ancora una volta di buttare via il
> tuo.
Gia' fatto.
>> la ports collection e' aggiornata piu' frequentemente dei vari
> Ma provare per esempio Debian invece di RedHat no, eh?
Ho una debian 2.2r0 da qualche parte che potrei installare appena mi si
libera un hard disk. Devo solo capire come si abilita IPSEC e come si
attivano le callback ppp con il protocollo CBCP.
Devo anche vedere ogni quanto vengono aggiornati i package.
Fra parentesi, la procedura per la generazione degli ISO di Debian e'...
@#$@%@#%.... interessante. <G>
> Dovresti essere contento di questo, significa che invece di farlo uscire
> quando vogliono gli utenti, come fanno m$ e RH, lo fanno uscire quando
> _loro_ ritengono sia pronto.
Nella ports collection di FreeBSD ci sono le ultime librerie di gnome 1.2 e
un sawfish aggiornato, eppure funziona tutto. Forse perche' Ximian deve
fare i test su 5 distribuzioni (se hai la numero 6 sei fregato) e FreeBSD
solo su una :o)
> Continuo ad avere i miei dubbi sulla utilita' di RPM4.
Io pure. Prima o poi diventera' comunque obbligatorio, almeno per RedHat,
se serve a spingere RedHat Network. Gli altri seguiranno, "per essere
compatibili".
> Ah io le posso esprimere sintetizzandole con una sola parola di 5
> lettere che inizia per 'm' e termina per 'a', e posso dirlo vedendo cio'
> che fa patire ad un paio di miei utenti..
Utilizzano per caso opzioni di ottimizzazione??? <g>
>> la creazione di distribuzioni "Barbie Linux - Drooling Retard Edition",
> Per fortuna che non si e' costretti ad usarle e si puo' ancora scegliere
Hai visto gli screenshot di Mandrake 8? Ricorda Windows XP. Meglio la
papera o il pinguino col mattarello pronto per fare la pasta? Entrambi mi
fanno vergognare di usarli.
> Continuo a ritenere che RH7 si sia avvicinata a Corel Linux nella mia
> personale classifica di distribuzioni Linux modello sterco da evitare.
Il guaio e' che dopo redhat 7 arriva redhat 8, e se la tendenza e' questa
la vedo molto male. Casualmente abbiamo Slackware 7.x, Suse 7.x, RedHat
7.x, Mandrake 7.x: anche qui cominciamo a vedere il circo delle release, il
cui numero cambia solo per far vedere di essere un pelo avanti agli altri.
Debian da questo punto di vista si salva :o)
Windows batte tutti: ormai le release non significano piu' un cazzo, si va
avanti a nomignoli in codice. NT 5, Whistler, XP, Blackcomb(?), 2000,
Millennium, Batman, Robin, siamo al livello delle schede video: "Ultra ATI
Rage Pro Revenge Exterminator Vindicator III Rocky IV Green Beret, Desert
Storm's Marine Edition". Il logo? "Cool! It works with Van Damme!".
Con Windows almeno ci si puo' consolare con i build number.
> Infatti KDE e' _molto_ pesante, ritengo forse (e sottolineo forse) piu'
> di Gnome.
Confermo, senza forse, che e' piu' pesante di Gnome. Fra un po' i desktop
dovranno essere piu' grossi dei server.
>> Altroche'. Ricordi quando si parlava di 4900 package? Balle:
> Non vorrei fare a chi ce l'ha piu' lungo... rimango dell'opinione che
> Debian forse ne abbia di piu' ma non ne sono sicuro.
... li contero', non resta altro da fare :o)
>> e' gia' tutto li'. Dal log di cvsup vedo che cosa viene aggiornato: e'
>> quasi meglio di freshmeat. Anzi, e' da vedere: http://www.freshports.org.
> Questo lo puoi fare con Debian con un apt-get update ;-)
portupgrade \* :o)
Che versione mi da' apt-get, l'ultima, la penultima o quella -stable
(leggi, quella di 6 mesi fa, con 2 security patch) ?
Esiste, nei package, un changelog dettagliato? (FIXME)
Posso tenere il "core" -stable e installare package della "-unstable"? Cosa
succede se un package della "-unstable" richiede una glibc nuova per
funzionare, me lo ricompila dai sorgenti su quella vecchia -stable? apt-get
scarica i kernel binari oppure solo i patch, e poi ricompila il tutto?
>> FreeBSD ha la compatibilita' all'indietro per Linux <g>
> Senza la quale non avrebbe tanto SW, per es. StarOffice ;-)
La compatibilita' all'indietro serve solo per quei 4 software
closed-source. Che guarda caso sono quelli che servono per lavorare:
StarOffice, netscape. Poi io uso Emacs, ma non legge certo i file ".xls".
Siamo tutti in attesa di un Office "free" che possa leggere
i file di ms-office, triste necessita'. Speriamo che OpenOffice non faccia
la fine di Mozilla. Speriamo di cavarcela entro il 2010.
> Non ce ne sono ergo ti attacchi. Che vuol dire 'ci sono elencate le
> dipendenze'? C'e' un file ASCII che le riporta?
Dentro il tarball c'e' un file +CONTENTS:
@name rox-1.1.2
@cwd /usr/local
@pkgdep jpeg-6b
@pkgdep rox-base-1.0.0
[...snip...]
@comment ORIGIN:x11-fm/rox-filer
man/man1/rox.1.gz
@comment MD5:205389b7bd3806e6b66ae1bfb7158614
bin/rox
@comment MD5:63a65b05d14998f2491f1234ffcb1d5b
[snip]
@dirrm apps/ROX-Filer/FreeBSD-ix86
@unexec rmdir %D/apps 2>/dev/null || true
eccetera :o)
ORIGIN serve a sapere dove sono i sorgenti, per ricompilare i package
aggiornati.
> Beh volendo puoi anche decidere di installarli altrove (man rpm)
Mica sempre, solo se supportano il "prefix". E dal programma di
installazione non me lo fa scegliere. E quindi dovrei specificarlo a mano
ogni volta, sapendo quali sono i pezzi di OS e quali i package. Sono al
punto di prima :o)
E il software compilato dovrebbe sapere che il suo prefix puo' cambiare, ma
non tutti i "./configure" lo supportano. Un bel casino.
> Si puo' disabilitare, senza farsi troppi problemi: vai in ntsysv (mi
> pare) e lo trombi.
_Se_ sai che rhnsd viene installato per default. Io lo so. Joe Random Luser
no. Ora noi sappiamo che Joe Random Luser non dovrebbe installare una
redhat, ma lui la installa lo stesso perche' "redhat e' facile e ha il
plugghenplei".
La Windows Philosophy si diffonde a colpi di installatori grafici e icone
multimediali...
Dopo 3 settimane va giu' il kernel grazie a rhnsd, e Mr. Luser se ne
ritorna a Windows. Mr. Luser non sa che esistono piu' distribuzioni
perche' ha visto la pubblicita' di RedHat sul corrierino dei luser.
> Ti sei preoccupato di vedere se c'era un RPM aggiornato? No dico,
> attribuire pure colpe che puoi evitare ad RPM mi pare troppo.
Non e' colpa di RPM. Ma dei test che _non_ hanno fatto prima di rilasciare la
distribuzione: un problema che si pone *ogni* volta che si esegue Linuxconf
*deve* per forza essere notato. Se me ne sono accorto io in 5 minuti...
Il fatto che si possa risolvere in 2 secondi non toglie che i test
pre-release siano stati fatti in un modo un po' "allegrotto". (alla fine
bastava aggiungere 2 righe allo script).
Mi sa che alla redhat masterizzano i CD senza guardarci dentro... :)))
Marco d'Itri
>Fase 3: GPL o morte, tutte le altre licenze (anche se benevolmente
>approvate dalla self-appointed "Open Source Foundation") non vanno bene,
>sono "sbagliate" e tradiscono "la grande comunita' degli hacker". Come se
Questo non e` vero. Sia debian che red hat hanno sempre considerato
accettabili licenze open source, che in pratica sono quelle
originariamente definite come libere da debian (definizione accettata
anche da RMS).
E` invece vero il contrario, gli sviluppatori dei *BSD fanno sempre il
possibile per sostituire codice GPLed con codice coperto dalla licenza
BSD (e alla fine aggiungono alla documentazione tre pagine di credits
vari perche` le cinquanta licenze diverse di cinquanta contributori
impongono ciascuna un nome diverso...).
>diventa "linux". I sorgenti rilasciati dalle societa' che "abbracciano
>l'open source" sono spesso sotto GPL, cosa che ovviamente impedisce l'uso
>dei software in questione con OS non-GPL.
Se sei convinto di una cosa simile allora non hai affatto capito come
funziona la GPL e devi correre a rileggerla.
>Per ogni software gia' "free" si sente il bisogno di creare un clone sotto
>GPL.
Non e` affatto vero. Invece molti sviluppatori dei *BSD sono fieri di
tenere il software GPLed fuori dal core OS.
> Poco tempo fa, ad esempio, ricordo che qualcuno aveva proposto di
>realizzare un clone GPL di Darwin, cosa di cui non riesco ad intravedere
>l'utilita' neanche sforzandomi. E a pensarci bene, la licenza BSD e' molto
Dove lo hai letto, su slashdot? <g>
>piu' "free" della GPL. Se io aggiungo 1.000.000 di righe a un progetto GPL
>di 12.000, la GPL mi toglie la liberta' di utilizzare quella milionata di
>righe, da me sviluppata, come meglio credo. A quel punto dovrei
Non e` vero, perche` il detentore del copyright fa comunque quello che
vuole del proprio codice.
Se tu sei felice che il tuo codice possa venire trasformato il software
commerciale (vedi BSDI) fai pure, ma non ti aspettare che questo possa
fare piacere anche a tutti gli altri.
--
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer" -- Dilbert
| (Ri)scoprire fidonet: http://bbs.bofh.it
Marco d'Itri
>Se poi il kernel del pinguino avesse il buon gusto di lasciare un core dump
>del kernel quando muore,
C'e` una patch che lo fa, da tempo.
Il problema e` che al momento di un kernel panic e` anche probabile che
cose come l'accesso ai dischi non funzionino piu`, e quindi potrebbe
succedere che il dump venga fatto in mezzo al file system.
Se gli autori della patch convinceranno Linus che e` sufficientemente
robusta per evitare questi problemi allora mi aspetto di vederla
integrata nei kernel 2.5, oppure che le distribuzioni interessate a
questa feature la aggiungeranno ai loro kernel.
>> Anche con Debian, immagino, non si puo' infilare un .deb per la SID
>> in una potato in modo indolore.
>Forse ricompilando, se non bisogna spostare i file.
Nell'ipotesi che nel frattempo non siano spostati file o cose simili e
che quindi l'unico cambiamento sia nell'ABI allora basta:
apt-get -b source pacchetto/sid
dpkg -i *.deb
(avendo una versione di apt che gestisce /release, altrimenti bisogna
dirgli dove trovare il pacchetto con i sorgenti)
>Il tutto e' cominciato perche' in FreeBSD avevo piu' software, perche'
Di piu`?
root@wonderland:vc/2:~#grep ^Package /var/lib/dpkg/available|egrep -v -- '-(dev|doc)$'|wc -l
5168
root@wonderland:vc/2:~#
>package (in /usr/local o /usr/X11R6). E' abbastanza utile sapere che
>cosa e' OS e che cosa sono le aggiunte. Gli RPM si installano tutti in
Tutto quello che viene installato dal package manager fa parte dell'OS.
Tutto il resto e` roba tua e lo metti in /usr/local.
Marco d'Itri
>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
Beh, non proprio:
ar x archivio.deb
tar xzvvf data.tar.gz
>installare in kickstart partendo da un floppy e un CD, il che riduce
>parecchio la scelta delle distribuzioni (oggi piu' che il kickstart vanno
Progeny, basata su debian. O la prossima debian.
>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?
Questo e` facile, a meno che tu voglia supportare sistemi obsoleti
vanno in /usr/share/doc.
Marco d'Itri
> E se e' necessario compilare un kernel separato per avere le
>funzionalita' "enterprise", mi vengono dei dubbi sulla possibilita' di
>tuning run-time del kernel.
La differenza e` nelle feature come il supporto della RAM oltre i 4 GB.
Tra parentesi linux il tuning a run time lo fa sempre da solo, non
servono mica trenta sysctl come per freebsd... :-)
>Che ci fa tutta quella roba dentro il mio kernel? Certo posso ricompilare
Serve a migliorarne la stabilita` o ad aggiungere feature non presenti
nei kernel ufficiali.
I tree di Linus devono essere considerati solo una reference
implementation, e se non si sa cosa sta facendo e` meglio usare i kernel
delle distribuzioni, o almeno quelli delle distribuzioni decenti.
(Detto questo, io mi sono sempre compilato quelli di Linus e non ho mai
avuto problemi.)
>sviluppo e' "aperto". Ogni tanto su slashdot capita di leggere roba di
>questo calibro.
Forse dovresti leggere linux-kernel@vger invece di slashdot...
>... sigh. Quali problemi di paginazione? Questa non la sapevo. Ogni tanto
Bilanciamento della VM.
>dice "VM qualcosa killed".
Eh gia`. :-)
Passa al .19, che contiene anche altri fix assortiti (il changelog
completo e` passato su linux-kernel).
>segnalato sul kernel. Va bene anche il kernel debugger da attivare con
>qualche combinazione di tasti.
Come e` noto Linus e` contrario ai debugger. Comunque lo stack trace
puoi ottenerlo da qualunque kernel con SysRq, e per avere il debugger
completo c'e` una patch.
>Ho una debian 2.2r0 da qualche parte che potrei installare appena mi si
>libera un hard disk. Devo solo capire come si abilita IPSEC e come si
apt-get install freeswan, credo (non me ne intendo).
>attivano le callback ppp con il protocollo CBCP.
Mai sentito.
>Devo anche vedere ogni quanto vengono aggiornati i package.
Vengono fatte subrelease ogni tre o quattro mesi, e contengono solo fix
di sicurezza o per altri bug critici. Tra una e l'altra puoi scaricare
automaticamente ipacchetti con fix di sicurezza con apt via rete.
Se vuoi le ultime novita` allora installa la distribuzione "testing",
che solitamente non ha problemi gravi (ma appunto, e` un *test*, quindi
non ti lamentare se qualcosa non funziona).
>Che versione mi da' apt-get, l'ultima, la penultima o quella -stable
Quella presente nella distribuzione che gli dici di usare.
>Esiste, nei package, un changelog dettagliato? (FIXME)
zless /usr/doc/package/changelog.gz
zless /usr/doc/package/changelog.Debian.gz
>Posso tenere il "core" -stable e installare package della "-unstable"? Cosa
Puoi aggiornare singolarmente i pacchetti che ti interessa aggiornare.
>succede se un package della "-unstable" richiede una glibc nuova per
>funzionare, me lo ricompila dai sorgenti su quella vecchia -stable? apt-get
Il default e` di risolvere le dipendenze e quindi aggiornare la libc, se
non vuoi basta usare apt-get -b source nomepacchetto && dpkg -i *.deb.
>scarica i kernel binari oppure solo i patch, e poi ricompila il tutto?
Debian e` una distribuzione di binari, quindi il default e` di scaricare
i binari. Se vuoi compilartela da solo fai pure, se ci tieni puoi anche
installare un build daemon che lo fa automaticamente....
Henryx
In quale articolo? <slrn9djtg3....@olgeni.olgeni>
| >> lftp updates.redhat.com:/6.2/en/os/i386> ls ucd*
| >> -rw-rw-r-- 1 2220 235 635493 Mar 29 09:24 ucd-snmp-4.1.1-3.i386.rpm
| [...]
| > di averli scaricati sempre dopo aver letto delle segnalazioni su
| > Bugtraq).
| Eccoli li'. E gli update di ucd-snmp richiedono RPM4.
| Prova ad installarne uno, vedi cosa dice. Non si installera'.
| Forse ricompilando dal .src.rpm uno se la scampa.
Sigh... vi state scannando su di un problema che non puo` esistere.
L'rpm 3.0.5 e` una versione di transizione. In pratica egli supporta
sia gli rpm3 che gli rpm4 mantendo (credo) un db alla 3[1]
Henryx
[1] ovviamente quest'ultima cosa e` da prendere con le pinze. In effetti
non sono sicuro se sia proprio cosi`, fatto sta che l'rpm 3.0.5 e` una
via di mezzo tra il 3.0.4 e il 4.0.0
Henryx
Quando? Sun, 15 Apr 2001 00:30:34 +0200
In quale articolo? <slrn9dhjs...@localhost.localdomain>
| > | mmmh, c'e` anche PowerBSD ;-)
| > E Stampede :)))))))
| PowerBSD, Stampede, ma ragazzi, da dove saltano fuori questi due?
Mmm... il primo dalla Berkley, mentre il secondo da una ditta ;)
| Sulla distribuzione NetBSD e' presente un file che contiene tutta la
| cronistoria del *BSD e questi due non li ho mai sentiti nominare.
| Siete sicuri che esistano?
Si. Cmq Stampede non e` un *BSD, ma una distro linux per pentium, con un
sistema di pacchettizzazione proprio ( .slp )
thorin_...@durin.khazad-dum.net
>>> La Suse utilizza le dipendenze per gli RPM?
>> Certo che si.
> Dove trovo un .src.rpm di Suse per guardarci dentro? Nel sito non ne vedo
> neanche uno, probabilmente mi sfugge qualcosa (!), devono pur essere da
> qualche parte :)
Strano ma vero, rufus.w3.org/linux/RPM
thorin_...@durin.khazad-dum.net
>> Beh allora e' strano come solo a te non funzionino le cose. Ripeto, RPM
> Infatti non ho mai avuto un problema di dipendenze. Solo di database a
> pezzettini.
Che a me (e non solo) non e' mai capitato.. hai letto cio' che ha
scritto Giambo? E per rimanere in dati statistici piu' concreti,
pochi hanno, basta leggere it.comp.os.linux.* per rendersi conto che non
succede mica cosi' spesso che qualcuno che usa RH si ritrovi il db
sputtanato.
>>> il linker che bestemmia in turco. Ma il database degli RPM sarebbe
>>> ancora integro, felice e contento :o)
>> Si, a patto di usare --nodeps o --force.
> Se non li uso non si installa nemmeno. Se li uso si installa, e nel
> database ci saranno dipendenze non soddisfatte, pur continuando a
> funzionare. Sicuramente non mi lascera' il db a pezzi :)
Allora, vediamo di fare chiarezza: questi 2 switch servono proprio a
bypassare i controlli sulle dipendenze quando vuoi installare degli RPM
che non le rispettano. Se lo fai ogni responsabilita' e' tua, non di
RPM, punto.
>>> In realta' non riuscirei neanche ad aggiornarlo, visto che se le
>>> dipendenze non sono soddisfatte l'rpm di turno non si installa.
>> No puoi forzarlo ma poi devi aspettarti di tutto.
> Posso aspettarmi che i singoli programmi (mutt ad esempio) abbiano errori,
> ma non che il database stesso di RPM si metta a fare cose strane.
Dipende da cosa hai fatto tu per farlo arrivare a cio': certamente non
si e' sputtanato da solo.
>> verificare se fossero necessari veramente no, eh? Io ho continuato ad
>> usare rpm 3.0.5 e non ho avuto problemi. Che cacchio, ci si lamenta che
> Io avevo il 3.0.4, che e' quello "stock" di redhat 6.2. Il fatto che non
> funzionasse (al contrario del tuo 3.0.5 che avrai trovato da qualche altra
> parte) era un buon incentivo ad aggiornarlo.
Non l'ho trovato da qualche parte, l'ho preso da updates.redhat.com in
base ad una segnalazione di Bugtraq. Se ora non c'e' piu' perche' e'
stato rimosso non posso farci niente ma sta di fatto che evidentemente
tu Bugtraq non lo leggi.
>>> Stupido Orango: prima di azzeccare il comando fanno prima a convertire
>>> la partizione ext2 in fat32 scrivendo comandi a caso :o)
>> Ritengo che queste non sono cose da lasciar fare ad un utonto, punto.
> E proprio per questo mi serviva il CD con tutti i patch gia' inseriti :^)
A patto che fossero quelli giusti.
>> Il log serve a poco se non ho conoscenza di tutto il resto (come e'
>> configurata quella macchina, che versioni di programmi e librerie ci
>> sono).
> Quelle che installa la 6.2 senza aggiungere niente: proprio qui sta la
> sorpresa.
Bah scusami ma stento a crederci: tu installi versioni (troppo) nuove di
un package e ti lamenti pure che la RH poi non funzioni per niente?
>>> redhat con lo stesso kernel (+ vari patch), sulla stessa macchina, va
>>> in kernel panic con loadavg 0. Poi su un'altra macchina ancora funziona.
>> Che patch? Per che cosa? Man mano saltano fuori delle cose nuove..
> Vedi cosa succede a non guardare dentro i .src.rpm? :o)
> Giochino: prendi ad esempio il kernel 2.2.17 che danno come aggiornamento
> negli updates. Puoi provare anche con il 2.2.16 o con qualsiasi altro
> kernel di redhat. Fai cosi':
[..]
Ma a te tutta quella roba, patches come iBCS servono _veramente_ ? Su un
PC desktop per esempio, mi spieghi a che cosa ti serve pcmcia? Per
occupare solo spazio inutile. Avresti fatto prima a prendere un tarball
dal mirror ufficiale di kernel.org e ricompilarlo. Spero ti renda conto
che porcherie infili in una macchina per poi lamentarti che il sistema
non funziona.
[..]
> Che ci fa tutta quella roba dentro il mio kernel? Certo posso ricompilare
> anche il kernel dal tarball, ma a questo punto fra kernel e applicazioni si
> comincia ad esagerare. Tanto vale mettere kernel e utility varie in un
> pezzo di CVS e andare avanti a colpi di Makefile. Mi ricorda qualcosa <g>
E chi ha pregato di usare _quel_ kernel invece di un tarball ;-) ? Di
solito chi compila un kernel tende ad eliminare roba inutile non ad
aggiungerne.
[..]
> Ora, a parita' di kernel, si capisce perche' una Debian col 2.2.16 potesse
> stare in piedi e la RedHat no, sullo stesso hardware: il kernel di RedHat
Sara' forse perche' Debian non ha kernel con patches e diff? Ma volendo
ci sarebbero per tutte le distro, RH inclusa, basta saperlo ;-)
>>> Se il kernel di FreeBSD decide che e' tempo di morire, almeno lascia
>>> un testamento:
>> Anche quello della RH, vedi i problemi di paginazione con il 2.2.17, se
>> e' per quello. Ma ci guardi ogni tanto in /var/log/messages?
> ... sigh. Quali problemi di paginazione? Questa non la sapevo. Ogni tanto
> dice "VM qualcosa killed". E' un problema del kernel o di hardware?
E' un errore VM che si ha quando cerca di liberare delle pagine di
memoria e non ci riesce.. va avanti cosi' finche' o si congela tutto
oppure intervieni col tasto Magic Sysreq a sbloccare la situazione. Pare
che nel 2.4.x finalmente l'abbiano messo a posto.
> Io per testamento intendo un bel core dump da 128 mega su cui far girare
> gdb per ottenere un traceback delle funzioni chiamate prima del panic. Poi
[..]
Sei veramente sicuro che anche il kernel di Linux non lo faccia? Hai
verificato?
[..]
>> Si ma era proprio necessario upgradare ad RPM 4? E' questo che non
>> riesco ad afferrare?
> Evidentemente, e per esperienza personale, no. Come non e' il caso a questo
> punto di continuare ad usare RedHat visto che non sono in grado di gestire
> il release engineering, ne' tantomento i patch al kernel. Ora lo so.
Che non ho ancora capito se fossero necessari o meno, a questo punto.
> E' chiaro che posso installare qualsiasi distribuzione e mantenerla
> "stabile" a colpi di sorgenti e compilazioni. E' comunque opportuno evitare
[..]
Ho idea che neanche tu abbia idea di cosa stessi facendo, considerato
cio' che hai fatto col database di RPM e con un kernel della RH invece
di uno ufficiale.
[..]
>> ce l'ho da un po' di tempo. Se vuoi te lo mando via e-mail, tanto
>> dovrei averlo su qualche CD.
> Lo andro' a cercare in giro, per curiosita'.
Come preferisci.
>>> lftp updates.redhat.com:/6.2/en/os/i386> ls ucd*
[..]
> Eccoli li'. E gli update di ucd-snmp richiedono RPM4.
Oppure bastava semplicemente la versione che ho io..
> Prova ad installarne uno, vedi cosa dice. Non si installera'.
A parte che non mi serve SNMP, se io vedo che un RPM non si installa non
mi intestardisco a volerlo installare ad ogni costo. Vedi la differenza?
Io al massimo cerco se c'e' un RPM di versione anche leggermemnte
inferiore che possa andare o senno' va a prenderselo nell'impianto di
raffreddamento (Intercooler) e mi cerco un bel tarball. Forse e' proprio
cosi' che ho mantenuto integro il mio database RPM.
>> Allora te lo mando consigliandoti ancora una volta di buttare via il
>> tuo.
> Gia' fatto.
Allelujah ;-)
>>> la ports collection e' aggiornata piu' frequentemente dei vari
>> Ma provare per esempio Debian invece di RedHat no, eh?
> Ho una debian 2.2r0 da qualche parte che potrei installare appena mi si
> libera un hard disk. Devo solo capire come si abilita IPSEC e come si
> attivano le callback ppp con il protocollo CBCP.
Non e' niente di particolarmente complicato. immagino basti guardare
bene fra le opzioni di menuconfig.
> Devo anche vedere ogni quanto vengono aggiornati i package.
Abbastanza di frequente.
> Fra parentesi, la procedura per la generazione degli ISO di Debian e'...
> @#$@%@#%.... interessante. <G>
Magari studiandola meglio... ;-)
>> Dovresti essere contento di questo, significa che invece di farlo uscire
>> quando vogliono gli utenti, come fanno m$ e RH, lo fanno uscire quando
>> _loro_ ritengono sia pronto.
> Nella ports collection di FreeBSD ci sono le ultime librerie di gnome 1.2 e
> un sawfish aggiornato, eppure funziona tutto. Forse perche' Ximian deve
> fare i test su 5 distribuzioni (se hai la numero 6 sei fregato) e FreeBSD
> solo su una :o)
L'importante e' che il prodotto sia ben testato, probabilmente. Non sei
mai contento, e che cazzo ! Ti lamenti di RH perche' dici che non e'
curata e che fa casini (anche se continuo a ritenere che tu ne abbia
fatto parecchi di tuo), ti lamenti di Debian perche' fa aspettare
troppo...
>> Continuo ad avere i miei dubbi sulla utilita' di RPM4.
Bisognava pensarci prima.
[..]
>>> la creazione di distribuzioni "Barbie Linux - Drooling Retard Edition",
>> Per fortuna che non si e' costretti ad usarle e si puo' ancora scegliere
> Hai visto gli screenshot di Mandrake 8? Ricorda Windows XP. Meglio la
Mai vista Mandreik e ne' penso la vorro' usare mai. Gia' mi danno
fastidio in RH cose come kudzu e Linuxconf, figuriamoci una distro cosi'
con le ballerine..
>> Continuo a ritenere che RH7 si sia avvicinata a Corel Linux nella mia
>> personale classifica di distribuzioni Linux modello sterco da evitare.
> Il guaio e' che dopo redhat 7 arriva redhat 8, e se la tendenza e' questa
> la vedo molto male. Casualmente abbiamo Slackware 7.x, Suse 7.x, RedHat
Echissenefrega? Il bello e' che si puo' scegliere.
> Windows batte tutti: ormai le release non significano piu' un cazzo, si va
> avanti a nomignoli in codice. NT 5, Whistler, XP, Blackcomb(?), 2000,
[..]
Infatti, ma tanto le mosche ad ogni nuova rilis si precipitano,
aspettandosi chissa' quale novita' tecnologica ed invece si beccano la
solita carrettata di materiale marrone.
>> Infatti KDE e' _molto_ pesante, ritengo forse (e sottolineo forse) piu'
>> di Gnome.
> Confermo, senza forse, che e' piu' pesante di Gnome. Fra un po' i desktop
> dovranno essere piu' grossi dei server.
Gia', solo per far girare la GUI: finche' se ne ha voglia li usi poi
metti su un window manager liscio e vai tranquillo.
>>> Altroche'. Ricordi quando si parlava di 4900 package? Balle:
>> Non vorrei fare a chi ce l'ha piu' lungo... rimango dell'opinione che
>> Debian forse ne abbia di piu' ma non ne sono sicuro.
> ... li contero', non resta altro da fare :o)
Brao'.
>>> e' gia' tutto li'. Dal log di cvsup vedo che cosa viene aggiornato: e'
>>> quasi meglio di freshmeat. Anzi, e' da vedere: http://www.freshports.org.
>> Questo lo puoi fare con Debian con un apt-get update ;-)
> portupgrade \* :o)
> Che versione mi da' apt-get, l'ultima, la penultima o quella -stable
> (leggi, quella di 6 mesi fa, con 2 security patch) ?
Credo dipenda dagli switch che gli passi.. e da cosa hai nella lista dei
sources ma per default dovrebbe essere l'ultima stable.
> Esiste, nei package, un changelog dettagliato? (FIXME)
Si.
> Posso tenere il "core" -stable e installare package della "-unstable"? Cosa
Si.
>>> FreeBSD ha la compatibilita' all'indietro per Linux <g>
>> Senza la quale non avrebbe tanto SW, per es. StarOffice ;-)
> La compatibilita' all'indietro serve solo per quei 4 software
> closed-source. Che guarda caso sono quelli che servono per lavorare:
> StarOffice, netscape. Poi io uso Emacs, ma non legge certo i file ".xls".
Appunto ma cio' non toglie che per Linux ci siano mentre per BSD no (gne
gne) ma il punto non e' questo, c'e' anche tanto sw free che permette
ugualmente di fare tutto cio' che serve.
> Siamo tutti in attesa di un Office "free" che possa leggere
> i file di ms-office, triste necessita'. Speriamo che OpenOffice non faccia
> la fine di Mozilla. Speriamo di cavarcela entro il 2010.
Per il momento non e' all'altezza di StarOffice, pare.
>> Non ce ne sono ergo ti attacchi. Che vuol dire 'ci sono elencate le
>> dipendenze'? C'e' un file ASCII che le riporta?
> Dentro il tarball c'e' un file +CONTENTS:
Che c'e' pure nei .deb cosi' come nei tarball di Linux.
[..]
>> Beh volendo puoi anche decidere di installarli altrove (man rpm)
> Mica sempre, solo se supportano il "prefix". E dal programma di
> installazione non me lo fa scegliere. E quindi dovrei specificarlo a mano
> ogni volta, sapendo quali sono i pezzi di OS e quali i package. Sono al
> punto di prima :o)
Diciamo che i casi in cui ti serve non installare in /usr sono
abbastanza rari, eh?
> E il software compilato dovrebbe sapere che il suo prefix puo' cambiare, ma
> non tutti i "./configure" lo supportano. Un bel casino.
Mboh finora mai capitato..
>> Si puo' disabilitare, senza farsi troppi problemi: vai in ntsysv (mi
>> pare) e lo trombi.
> _Se_ sai che rhnsd viene installato per default. Io lo so. Joe Random Luser
Gli installatori con tools multimediali ci sono proprio per gli utenti
scimmia che vanno pazzi per le ultime rilis dela Mandreik o della RH: io
sono anni che disabilito Linuxconf, che il collegamento PPP me lo sono
fatto a manina con gli script (tant'e' che ha sempre funzionato)..
questione di manico.
[..]
> Dopo 3 settimane va giu' il kernel grazie a rhnsd, e Mr. Luser se ne
> ritorna a Windows. Mr. Luser non sa che esistono piu' distribuzioni
> perche' ha visto la pubblicita' di RedHat sul corrierino dei luser.
Certo, ma sara' anche perche' Mr. Luser non si preoccupa mica di leggere
newsgroups o cercare su Internet quindi avra' meritato tutto cio'. La
distro ha le sue colpe ma siccome anche il pezzo di carne fra sedia e PC
ha la sua parte di merito la cosa non mi meraviglia affatto. Il mondo
Linux avra' perso un idiota.
> Non e' colpa di RPM. Ma dei test che _non_ hanno fatto prima di rilasciare la
> distribuzione: un problema che si pone *ogni* volta che si esegue Linuxconf
> *deve* per forza essere notato. Se me ne sono accorto io in 5 minuti...
Nessuno ti obbliga ad usare Linuxconf: se il luser si preoccupasse di
capire come funzionano gli *NIX cioe' con i file di configurazione, il
problema non si porrebbe affatto.
> Mi sa che alla redhat masterizzano i CD senza guardarci dentro... :)))
Lo so, ecco perche' sono passato a Debian..
Giambo
> >> La Suse utilizza le dipendenze per gli RPM?
> >
> > Certo che si.
>
> Dove trovo un .src.rpm di Suse per guardarci dentro?
Mi pare siano sotto la "z" ...
Jimmy Olgeni
>>>> La Suse utilizza le dipendenze per gli RPM?
>>> Certo che si.
Su rufus.w3.org vedo solo Suse 6.4 elencata.
Ho preso un paio di file dalla Suse 7.1 "Official", su ftp.suse.com.
Qualcuno per fortuna mi ha detto che i sorgenti sono nella "serie z". Non
oso chiedere perche'. Forse una serie "src" sembrava difficile :-)
Esempio: ho preso kgui.spm (source) e kgui.rpm. Uno a caso.
Domanda 1: perche' nel nome del file non c'e' scritta la versione? Come
faccio a sapere di quale versione si tratta prima di scaricare 10mega
dall'ftp?
Domanda 2: nel file.spec ci sono questi commenti:
# neededforbuild autoconf [snip] libpng
# usedforbuild aaa_base [snip] xf86 xshared
Che differenza c'e' fra "needed" e "used"?
Non vedo i "Requires:" che si trovano sugli rpm di RedHat.
Infatti:
$ rpm -qp --queryformat "%{REQUIRENAME}\n" kgui.rpm
ld-linux.so.2
$
Sembra che siano elencati solo i "require" trovati automaticamente con il
linker. Ha senso specificare le dipendenze in un commento e poi _non_
utilizzarle nell'rpm effettivo? Oppure mi sfugge ancora qualcosa? :o)
Se installo questo kgui e poi non funziona perche' manca ad esempio libpng,
come faccio a saperlo?
$ strings kgui.rpm | grep -i libpng
$
RPM supporta le dipendenze... vanno usate pero'.
...sigh... :o)
Jimmy Olgeni
>>Se poi il kernel del pinguino avesse il buon gusto di lasciare un core dump
>>del kernel quando muore,
> C'e` una patch che lo fa, da tempo.
Ce ne sono tante in giro, di patch. Anche quella del debugger, mi pare
venga da SGI. Ma quelle piu' interessanti non le include nessuno? :)
> cose come l'accesso ai dischi non funzionino piu`, e quindi potrebbe
> succedere che il dump venga fatto in mezzo al file system.
In FreeBSD il dump viene fatto sulla partizione di swap. Sembra
implementato decentemente perche' non si e' mai tirato dietro niente. Certo
magari sono ancora in tempo ad avere sorprese.
> Se gli autori della patch convinceranno Linus che e` sufficientemente
> robusta per evitare questi problemi allora mi aspetto di vederla
Se Linus cominciasse a convincersi che non tutto il mondo lavora come lui,
sarebbe gia' un inizio :)
>>Il tutto e' cominciato perche' in FreeBSD avevo piu' software, perche'
> Di piu`?
Io arrivavo da Red Hat: erano di piu', e piu' aggiornati. Se fra un commit
e l'altro dell'INDEX sono passati da 4900 a 5004, mi pare buono. FreeBSD
sicuramente ha meno sviluppatori, ma in crescita, nonostante il fatto che
in ogni occasione si parli esclusivamente di Linux.
Non parliamo poi dei port un po' troppo "linux-specific" che si portano via
una settimana solo per fare i patch :o)
Vedo che Progeny ne ha addirittura 6000 (dicono). Poi bisogna vedere quanti
package si riescono a tirare fuori da uno solo, fra -server, -client,
-devel, e -libs. I software "importanti" poi si trovano dappertutto, ma a
me servivano le librerie oscure di Ruby.
> Tutto quello che viene installato dal package manager fa parte dell'OS.
> Tutto il resto e` roba tua e lo metti in /usr/local.
Qui l'OS e' quello che esce dal CVS, il resto e' il resto :o)
Jimmy Olgeni
> Beh, non proprio:
> ar x archivio.deb
> tar xzvvf data.tar.gz
Pero' per ricreare i miei ex ".deb" custom devo, ad esempio, riscrivere il
file .spec dell'rpm.
>>parecchio la scelta delle distribuzioni (oggi piu' che il kickstart vanno
> Progeny, basata su debian. O la prossima debian.
A me serviva un po' di mesi fa. Comunque sto aspettando che finisca il
download di (credo) 8 CD fra Progeny e Debian, cosi' le provo.
> Questo e` facile, a meno che tu voglia supportare sistemi obsoleti
> vanno in /usr/share/doc.
Ho secchiate di sistemi obsoleti, da RH4 in poi. La 6.2 e' diventata
obsoleta appena e' uscita la 7... eppure non e' cosi' vecchia. Sara' la
volta buona che mi decido a farli aggiornare? :o)
Come funziona con dpkg? Mi leggera' i .deb di Debian 8?
Jimmy Olgeni
> L'rpm 3.0.5 e` una versione di transizione. In pratica egli supporta
> sia gli rpm3 che gli rpm4 mantendo (credo) un db alla 3[1]
No, non voglio sapere i dettagli. Vade retro. Voglio solo dimenticare RPM e
la sua prole infame :o)
Jimmy Olgeni
> Questo non e` vero. Sia debian che red hat hanno sempre considerato
> accettabili licenze open source, che in pratica sono quelle
> originariamente definite come libere da debian (definizione accettata
> anche da RMS).
Infatti possono tranquillamente distribuire e linkare software BSD.
> E` invece vero il contrario, gli sviluppatori dei *BSD fanno sempre il
> possibile per sostituire codice GPLed con codice coperto dalla licenza
Questo perche' il "core" (kernel + utility) di un BSD deve essere su
licenza BSD, altrimenti non e' BSD. Per le applicazioni, il software GPL
viene usato senza alcun problema. Se mi fai un esempio di 3 pagine di
credits me lo vado a vedere, cosi' mi rallegra la serata :o)
>>l'open source" sono spesso sotto GPL, cosa che ovviamente impedisce l'uso
>>dei software in questione con OS non-GPL.
> Se sei convinto di una cosa simile allora non hai affatto capito come
> funziona la GPL e devi correre a rileggerla.
"l'uso" come applicativi non ne e' certo impedito, visto che sui BSD girano
secchiate di software GPL. Ma "l'uso" a livello di linking di una libreria
sotto GPL (non LGPL?)? o l'uso nel kernel?
> Non e` affatto vero. Invece molti sviluppatori dei *BSD sono fieri di
> tenere il software GPLed fuori dal core OS.
Per forza, se il core OS dev'essere sotto licenza BSD. Qualche volta capita
anche di vedere driver che si possono caricare solo come modulo, e non
compilare staticamente nel kernel. Si puo' fare il linking di un driver GPL
con un kernel BSD, distribuendo solo i sorgenti originali del driver?
>>l'utilita' neanche sforzandomi. E a pensarci bene, la licenza BSD e' molto
> Dove lo hai letto, su slashdot? <g>
Da qualche altra parte, ma sicuramente dello stesso calibro. :o)
> Se tu sei felice che il tuo codice possa venire trasformato il software
> commerciale (vedi BSDI) fai pure, ma non ti aspettare che questo possa
> fare piacere anche a tutti gli altri.
Questo se volessi distribuire il codice con licenza BSD. Cosa succede se
invece devo distribuire in un unico kernel GPL il mio codice (non GPL), ad
esempio in un prodotto embedded?
Jimmy Olgeni
> La differenza e` nelle feature come il supporto della RAM oltre i 4 GB.
Non dovrebbe essere nel kernel "enterprise?" Non mi pare roba da desktop.
E questo e' un patch. Restano gli altri 150 :o)
Capirei se almeno avessero scritto da qualche parte che cosa fa ogni patch,
o se per qualche patch fosse possibile abilitare/disabilitare le funzioni
che include, magari da /proc. Approposito, c'era una volta un patch del
kernel che scriveva in dmesg l'elenco degli altri patch (!)
> Tra parentesi linux il tuning a run time lo fa sempre da solo, non
> servono mica trenta sysctl come per freebsd... :-)
Ne conto 661 sul mio. :-)
Pero' vedo che anche in /proc c'e' un bel po' di roba con cui giocare.
>>Che ci fa tutta quella roba dentro il mio kernel? Certo posso ricompilare
> Serve a migliorarne la stabilita` o ad aggiungere feature non presenti
> nei kernel ufficiali.
Peccato che il kernel superpatch di redhat 7 faceva il botto sul mio
desktop, quello di Debian no. Mi chiedo poi quanti di quei patch siano
effettivamente necessari, e che cosa facciano. Lo avranno documentato da
qualche parte?
> I tree di Linus devono essere considerati solo una reference
> implementation, e se non si sa cosa sta facendo e` meglio usare i kernel
> delle distribuzioni, o almeno quelli delle distribuzioni decenti.
Gli unici problemi che ho mai avuto sono stati a causa di kernel
"migliorati" dalle distribuzioni. Come il supermount di mandrake... uptime
10 minuti :-/
>>sviluppo e' "aperto". Ogni tanto su slashdot capita di leggere roba di
>>questo calibro.
> Forse dovresti leggere linux-kernel@vger invece di slashdot...
Purtroppo molte delle cagate che si leggono su slashdot sono le cagate che
la gente poi ti viene a dire.
... e gia' mi pesano le N mailing list di FreeBSD :o)
>>dice "VM qualcosa killed".
> Eh gia`. :-)
Bingo :-)
> Passa al .19, che contiene anche altri fix assortiti (il changelog
> completo e` passato su linux-kernel).
Passero' al .19, ma non manchero' di commentare altrove sulla genialita'
che redhat ha dimostrato anche in questo caso :)
> Come e` noto Linus e` contrario ai debugger. Comunque lo stack trace
> puoi ottenerlo da qualunque kernel con SysRq, e per avere il debugger
> completo c'e` una patch.
Non sono al corrente sulle preferenze di Linus riguardo ai debugger:
preferisco avere un'opzione per abilitarli se mi servono, senza fare la
caccia al patch.
Linus ha troppe preferenze personali.
Si sente la mancanza di un core team.
<gd&r>
>>attivano le callback ppp con il protocollo CBCP.
> Mai sentito.
E' il protocollo per le callback in ppp che usano i client NT.
"Let us innovate".
> Il default e` di risolvere le dipendenze e quindi aggiornare la libc, se
> non vuoi basta usare apt-get -b source nomepacchetto && dpkg -i *.deb.
Questo mi piace gia' di piu' :)
Jimmy Olgeni
> Che a me (e non solo) non e' mai capitato.. hai letto cio' che ha
> scritto Giambo? E per rimanere in dati statistici piu' concreti,
... che usa Suse?
> pochi hanno, basta leggere it.comp.os.linux.* per rendersi conto che non
> succede mica cosi' spesso che qualcuno che usa RH si ritrovi il db
> sputtanato.
Allora io e i miei colleghi o siamo sfortunati o siamo diventati stupidi
durante il passaggio dalla 5.2 alle 7. :o)
Per riassumere il tutto, compreso l'ovvio:
RPM e' un package manager, installa e rimuove software, e tiene le sue
brave informazioni nel suo bravo database. Io posso installare e rimuovere
i software e lui mi avvertira' se sto cercando di fare un'operazione che non
concorda con le dipendenze dei package. Posso ignorare questi controlli con
--nodeps e --force, come previsto dalla documentazione.
In caso di demenza furiosa posso provare ad installare package di un'altra
distribuzione: in questo caso i package possono essere:
1) riconosciuti in qualche modo ed installati
2) riconosciuti ed installati con --force --nodeps
3) non riconosciuti, in quanto il formato degli RPM non e' compatibile, e
non installati
Non ci sono altri casi.
Ora, e' ammissibile che i software una volta installati possano non
funzionare a causa di dipendenze non soddisfatte, o che non vengano
installati per incompatibilita' di formato del package. Tutto come da
copione.
Ma _se_ l'operazione _viene_ effettivamente eseguita _dopo_ che RPM ha
riconosciuto il formato, il database non si deve sputtanare: ogni
operazione in cui RPM rovina il suo stesso database _e'_ un bug di RPM, che
non e' stato in grado di gestire il proprio database o segnalare che
l'operazione non era possibile.
Io non mi aspetto che installando qualsiasi puttanata questa funzioni, ma
mi aspetto che RPM si gestisca i suoi dati senza andare in pezzi. Il 3.0.4
andava in pezzi. Il 3.0.5 non c'e' piu' negli updates. Il 4 non e'
compatibile. E grazie RedHat.
>> Io avevo il 3.0.4, che e' quello "stock" di redhat 6.2. Il fatto che non
>> funzionasse (al contrario del tuo 3.0.5 che avrai trovato da qualche altra
>> parte) era un buon incentivo ad aggiornarlo.
> Non l'ho trovato da qualche parte, l'ho preso da updates.redhat.com in
> base ad una segnalazione di Bugtraq.
Ora su updates.redhat.com c'e' solo il 4. Non potevano lasciare anche il
3.0.5? Non avevano abbastanza spazio sul server FTP? Ora se volessi
aggiornare a quella versione devo andare a caccia in giro per internet:
www.rpm.org.
> stato rimosso non posso farci niente ma sta di fatto che evidentemente
> tu Bugtraq non lo leggi.
E sta di fatto che redhat non mantiene una history dei patch in modo che io
possa scegliere fino a quale livello aggiornare la mia macchina.
> Ma a te tutta quella roba, patches come iBCS servono _veramente_ ? Su un
> PC desktop per esempio, mi spieghi a che cosa ti serve pcmcia? Per
No, non mi serve a nulla. Ma questo e' il kernel che redhat mi installa, e
guarda caso e' il kernel che poi da' problemi. Non mi ha chiesto se
volessi pcmcia oppure no. Oltretutto pcmcia si spegne da ntsysv. Devo forse
compilare una tarball del kernel dopo ogni installazione della
distribuzione?
No -> la distribuzione e' tenuta a fornirmi un kernel testato e
funzionante, senza patch fantasiosi.
Si' -> la funzione della distribuzione viene a cadere, visto che devo
compilare comunque i tarball a mano. A che mi serve allora la
distribuzione, se non a garantirmi il corretto funzionamento del software
che distribuisce? Come sperano di far soldi alla redhat, se solo per
"accendere" la macchina devo fare 10 modifiche custom "pesanti" come
ricompilare il kernel mettendo i patch che piu' mi aggradano?
Prendi il 2.2.17 di redhat, fai "make oldconfig", vedi quante domande ti
fa: quello e' il numero di patch aggiunti. Peccato che non hanno
aggiornato anche il .config. Per ricompilare il kernel con le stesse
opzioni, se volessi farlo, devo dare la caccia ai file di configurazione
del kernel nel .src.rpm.
> occupare solo spazio inutile. Avresti fatto prima a prendere un tarball
> dal mirror ufficiale di kernel.org e ricompilarlo. Spero ti renda conto
> che porcherie infili in una macchina per poi lamentarti che il sistema
> non funziona.
Se avrei fatto prima a ricompilarlo (nessun problema a farlo), che senso ha
l'esistenza delle distribuzioni? Non dovrebbero forse creare un _prodotto_,
integrato e funzionante? Le distribuzioni sono forse solo un accrocchio di
software, e differiscono per il colore della scatola? Si vuole la "world
domination" a colpi di tarball, anche per uno squallido desktop?
> E chi ha pregato di usare _quel_ kernel invece di un tarball ;-) ? Di
L'illusione che redhat sapesse che cosa sta facendo dei suoi prodotti, cosa
che purtroppo non e'.
Ora negli updates c'e' il 2.2.17, bacato. L'ho provato e dice "VM barfed on
the floor, please clean up". Hanno cancellato il 2.2.16: andato. Perche'
e' stato cancellato? Sul sito, alla voce downloads, sono elencati solo il
50% dei package presenti sull'FTP. Dove sono le release notes? Hanno
aggiunto openssl, dov'e' openssh?
Il tutto da una societa' che ha la pretesa di essere "il linux per
l'enterprise".
Hello? McFly?
>> Ora, a parita' di kernel, si capisce perche' una Debian col 2.2.16 potesse
>> stare in piedi e la RedHat no, sullo stesso hardware: il kernel di RedHat
> Sara' forse perche' Debian non ha kernel con patches e diff? Ma volendo
> ci sarebbero per tutte le distro, RH inclusa, basta saperlo ;-)
Certo: il tarball da compilare, buono per il singolo PC o il singolo
server. Per un prodotto che va venduto e distribuito devo a) modificare la
procedura di installazione per copiare il mio kernel compilato dal CD, o b)
fare un RPM custom con il mio kernel "sano". Purtroppo ho un lavoro che non
sempre coincide con il sistemare i casini delle distribuzioni bacate.
> E' un errore VM che si ha quando cerca di liberare delle pagine di
> memoria e non ci riesce.. va avanti cosi' finche' o si congela tutto
> oppure intervieni col tasto Magic Sysreq a sbloccare la situazione. Pare
> che nel 2.4.x finalmente l'abbiano messo a posto.
Ora non posso certo aggiornare al 2.4.x la rh6.2. Mi devo aspettare che
redhat metta una toppa per questo problema, nella patch numero 158?
> Sei veramente sicuro che anche il kernel di Linux non lo faccia? Hai
> verificato?
Beh... c'e' una patch no? Dentro o fuori: le opzioni di "make menuconfig"
sono li' per bellezza :o)
>> E' chiaro che posso installare qualsiasi distribuzione e mantenerla
>> "stabile" a colpi di sorgenti e compilazioni. E' comunque opportuno evitare
> Ho idea che neanche tu abbia idea di cosa stessi facendo, considerato
> cio' che hai fatto col database di RPM e con un kernel della RH invece
> di uno ufficiale.
A questo punto devo immaginare che siano da scartare tutte le distribuzioni
basate su kernel "non ufficiali". Reiser? niente. lm_sensors? niente. ext3?
nulla. debugger? nada.
>> Prova ad installarne uno, vedi cosa dice. Non si installera'.
> inferiore che possa andare o senno' va a prenderselo nell'impianto di
> raffreddamento (Intercooler) e mi cerco un bel tarball. Forse e' proprio
> cosi' che ho mantenuto integro il mio database RPM.
... Usando tarball al posto di RPM? :o)
Domanda filosofica: che differenza concettuale c'e' fra:
a) installare gli updates di redhat che vengono dal loro stesso sito, o
b) scrivere il famoso "apt-get" per aggiornare automaticamente una Debian.
Mi pare che l'operazione sia equivalente: installare gli aggiornamenti che
raccomanda la distribuzione. L'unico problema e' che redhat raccomanda
cazzate, quindi devo supporre che non sia sbagliata l'operazione in se',
ma e' sbagliata la scelta della distribuzione.
Non mi si vorra' far credere che "apt-get" e' da super sysadmin e up2date
e' da utonti: fanno la stessa cosa. Pero' uno dei due la fa male.
> Non e' niente di particolarmente complicato. immagino basti guardare
> bene fra le opzioni di menuconfig.
A parte il dettaglio che l'ultima volta che ho guardato il pppd non
supportava CBCP, e' tutto abbastanza semplice :)
>> Fra parentesi, la procedura per la generazione degli ISO di Debian e'...
>> @#$@%@#%.... interessante. <G>
> Magari studiandola meglio... ;-)
Non ho tempo di cazzeggiare con i finti ISO e l'rsync: lascio l'ftp in
batch in ufficio e domani trovo tutto :-)
> L'importante e' che il prodotto sia ben testato, probabilmente. Non sei
> mai contento, e che cazzo ! Ti lamenti di RH perche' dici che non e'
Quando ho provato helix per mandrake e redhat 7 tutto mi e' sembrato tranne
che "ben testato". Era il festival dei --force. Se poi il loro installer
usa il --force ma lo nasconde dietro la dialog box colorata, tanti auguri.
Ma perche' devo usare --force se si trattava di helix *per* rh7?
In FreeBSD mi compilo Gnome dai sorgenti. Solo che lo fa la ports
collection senza farmi fare il download delle tarball a manina.
>> la vedo molto male. Casualmente abbiamo Slackware 7.x, Suse 7.x, RedHat
> Echissenefrega? Il bello e' che si puo' scegliere.
Indovino? Debian, andando per esclusione. Ci sara' un motivo se finiscono
tutti li'. Quando ci sono 8 scelte, e per un motivo o per l'altro 7 sono
cazzate, alla fine c'e' solo una scelta.
> Infatti, ma tanto le mosche ad ogni nuova rilis si precipitano,
> aspettandosi chissa' quale novita' tecnologica ed invece si beccano la
> solita carrettata di materiale marrone.
Intanto COM nella sua follia mi fa "pilotare" Office da Ruby e Python senza
toccare Visual Basic. Con che cosa potro' fare scripting per OpenOffice?
Bonobo o KParts? SOAP? Boh :o)
>> ... li contero', non resta altro da fare :o)
> Brao'.
5000equalcosa, Progeny dice 6000. Pero' sto vedendo nuovi PR su gnats con
nuovi port :-)
>> StarOffice, netscape. Poi io uso Emacs, ma non legge certo i file ".xls".
> Appunto ma cio' non toglie che per Linux ci siano mentre per BSD no (gne
Questo perche' chi ha fatto StarOffice non ha avuto la decenza di scrivere
"make" sulla macchina BSD. Da notare che StarOffice non e' disponibile in
versione nativa per FreeBSD unicamente perche' closed source, non per un
limite dell'OS. Se hanno fatto il port per Windows...
> gne) ma il punto non e' questo, c'e' anche tanto sw free che permette
> ugualmente di fare tutto cio' che serve.
Quasi tutto, tranne leggere la merda che ti mandano con powerpoint (non che
mi interessi leggerla in verita'). Ma io rispondo in .dvi e siamo pari.
> Per il momento non e' all'altezza di StarOffice, pare.
Allora mi viene il sospetto che non abbiano tirato fuori tutti i sorgenti.
Come nel caso di Netscape, non vengono "rilasciati i sorgenti del
software", ma "rilasciati i sorgenti di una versione intermedia ed
incompleta", sperando che qualcuno la aggiusti in qualche modo.
Perche' i progetti che _nascono_ open source vanno avanti, e quelli che
"diventano" open source vanno avanti mooolto piu' lentamente? Forse quando
erano software commerciali avevano delle scadenze da rispettare, e non si
cercava di creare un browser che facesse anche il caffe' via LDAP. Intanto
Java 2 e' sempre li' che aspetta.
> Diciamo che i casi in cui ti serve non installare in /usr sono
> abbastanza rari, eh?
Ad esempio, in FreeBSD, tutti i software che non sono "core".
>> E il software compilato dovrebbe sapere che il suo prefix puo' cambiare, ma
>> non tutti i "./configure" lo supportano. Un bel casino.
> Mboh finora mai capitato..
E allora a che servirebbe l'opzione --prefix nei ./configure, se fosse in
grado di capire da solo dove e' stato installato? In questo caso sarebbe
un'opzione del makefile: make install prefix=/usr.
> distro ha le sue colpe ma siccome anche il pezzo di carne fra sedia e PC
> ha la sua parte di merito la cosa non mi meraviglia affatto. Il mondo
> Linux avra' perso un idiota.
Potrebbero fare una versione "redhat network luserhood" e una "redhat
decent server". Ogni idiota perso e' un idiota che ingrassa Bill Gates.
Ogni idiota perso e' un'applicazione in meno di cui verra' fatto il porting
nativo in Linux. Diamo all'idiota la sua distribuzione, ma per favore giu'
le mani dalle altre. Ormai sembra che facciano la gara per chi ha
l'installatore piu' colorato, confondendo colore con facilita' d'uso.
> Nessuno ti obbliga ad usare Linuxconf: se il luser si preoccupasse di
> capire come funzionano gli *NIX cioe' con i file di configurazione, il
> problema non si porrebbe affatto.
Se e' per questo, nessuno mi obbliga ad usare redhat: dovrebbero capirlo
anche loro stessi prima di ritrovarsi con 4 utenti in croce che pagano $10
al mese per avere gli update bacati.
Jimmy Olgeni
>> La Suse utilizza le dipendenze per gli RPM?
> Certo che si.
E dove sono, dentro il file .spec?
>> Dove trovo un .src.rpm di Suse per guardarci dentro?
> Mi pare siano sotto la "z" ...
Per "zources?"... zi? inzomma... :o)))
Jimmy Olgeni
> per avere una lista di tutti i pacchetti installati su di una macchina,
> che puoi ripristinare con il comando
> dpkg --set-selections < install-debian.txt
Se lo devo ripristinare con un comando, non e' simile a kickstart:
kickstart nella sua follia lo fa da solo :o)
Per arrivare a scrivere "dpkg --set-selections" immagino di dover prima
installare una debian "base", rispondendo alle 30 domande a proposito di
versioni del kernel, file system e moduli. Il kickstart parte da un floppy
e un CD, fa il boot, e lascia la macchina installata e configurata.
Quindi si va su Progeny, o la prossima debian.
Pero' a me il kickstart serviva gia' un po' di tempo fa. Quindi mi toccava
usare redhat :-/
Nota, non sto dicendo che non sia giusto fare le domande sul file system:
RedHat non diceva niente, in omaggio alla "semplicita' di installazione", e
mi sono trovato con FS ext2 che non potevano essere letti dai kernel vecchi
(2.0.x). Occorreva impostare le "features" di ext2 da mke2fs, che continua
a chiamarsi ext2 pur mutando in modo non compatibile con la release
precedente. Poi fsck mi dice "setting file type to 6", ad ogni controllo,
per alcuni tipi di file (fifo o socket). Bug o feature?
> sono molto recenti, cosa dovuta piu` che altro alla filosofia della
> distro che a mancanza di voglia di aggiornamento
Ho visto che sawmill si chiama ancora sawmill (0.20)
Ok lasciar fermo il kernel e la libc, ma almeno i programmini scemi
aggiornateli. Ho capito: dkpg e via a compilare :-)
Provero' con la Progeny, tanto per cominciare.
thorin_...@durin.khazad-dum.net
>>>Che ci fa tutta quella roba dentro il mio kernel? Certo posso ricompilare
>> Serve a migliorarne la stabilita` o ad aggiungere feature non presenti
>> nei kernel ufficiali.
> Peccato che il kernel superpatch di redhat 7 faceva il botto sul mio
> desktop, quello di Debian no. Mi chiedo poi quanti di quei patch siano
> effettivamente necessari, e che cosa facciano. Lo avranno documentato da
> qualche parte?
Io mi chiedo invece chi ti abbia costretto ad usare quel kernel al posto
di uno ufficiale che di problemi non te ne avrebbe dati.
Renato 'Hitman' Salzano
schifo che mi circondava e come la cosidetta societa` civile sia basata
sull'ipocrisia e dominazione, thorin_...@durin.khazad-dum.net
interruppe il flusso dei miei pensieri bofonchiando:
>>> E poi non dimentichiamo che i *BSD non hanno la stessa quantita' di
>>> SW che c'e' per Linux.
>> Altroche'. Ricordi quando si parlava di 4900 package? Balle:
>Non vorrei fare a chi ce l'ha piu' lungo... rimango dell'opinione che
>Debian forse ne abbia di piu' ma non ne sono sicuro.
Se proprio vogliamo fare a chi c'e` l'ha piu lungo...
harris:~# apt-cache stats
Total Package Names : 7290 (292k)
Normal Packages: 5848
Game, set, match per Debian :)
--
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
Jimmy Olgeni
>> effettivamente necessari, e che cosa facciano. Lo avranno documentato da
>> qualche parte?
> Io mi chiedo invece chi ti abbia costretto ad usare quel kernel al posto
> di uno ufficiale che di problemi non te ne avrebbe dati.
Nessuno. Penso infatti che mi rechero' personalmente presso ogni cliente a
compilare una tarball custom, su misura. Dopo aver compilato il
compilatore. Dopo aver assemblato l'assembler. In fondo nell'opensource
non si vendono i prodotti, ma i servizi, no? :o)
Jimmy Olgeni
>>Debian forse ne abbia di piu' ma non ne sono sicuro.
> Se proprio vogliamo fare a chi c'e` l'ha piu lungo...
E poi vediamo chi fa piu' strada per andare a fare l'installazione a mano,
senza kickstart :o)
Marco d'Itri
>>>Se poi il kernel del pinguino avesse il buon gusto di lasciare un core dump
>>>del kernel quando muore,
>> C'e` una patch che lo fa, da tempo.
>Ce ne sono tante in giro, di patch. Anche quella del debugger, mi pare
>venga da SGI. Ma quelle piu' interessanti non le include nessuno? :)
Sono interessanti per gli sviluppatori, non per chi ha bisogno di un
kernel precompilato.
Anche IBM sta facendo molto sul fronte del debugging (su tutti i fronti
in realta`, anche linux/390 e` veramente carino :-) ).
>> cose come l'accesso ai dischi non funzionino piu`, e quindi potrebbe
>> succedere che il dump venga fatto in mezzo al file system.
>In FreeBSD il dump viene fatto sulla partizione di swap. Sembra
Lo so, il punto e`: il controller andra` a scrivere nel posto giusto o
no? Dopo un kernel panic il driver potrebbe essere un po' confuso.
>Vedo che Progeny ne ha addirittura 6000 (dicono). Poi bisogna vedere quanti
Progeny ha qualche pacchetto piu` di debian.
>> Tutto quello che viene installato dal package manager fa parte dell'OS.
>> Tutto il resto e` roba tua e lo metti in /usr/local.
>Qui l'OS e' quello che esce dal CVS, il resto e' il resto :o)
Puo` essere una differenza filosoficamente elegante, ma al momento di
gestire una macchina mi sembra piu` pratica quella usata da linux.
Marco d'Itri
>> Questo non e` vero. Sia debian che red hat hanno sempre considerato
>> accettabili licenze open source, che in pratica sono quelle
>> originariamente definite come libere da debian (definizione accettata
>> anche da RMS).
>Infatti possono tranquillamente distribuire e linkare software BSD.
GPL e` compatibile con la licenza BSD solo se non ha la advertising
clause.
>> E` invece vero il contrario, gli sviluppatori dei *BSD fanno sempre il
>> possibile per sostituire codice GPLed con codice coperto dalla licenza
>Questo perche' il "core" (kernel + utility) di un BSD deve essere su
>licenza BSD, altrimenti non e' BSD. Per le applicazioni, il software GPL
>viene usato senza alcun problema. Se mi fai un esempio di 3 pagine di
>credits me lo vado a vedere, cosi' mi rallegra la serata :o)
Ricordo di averlo visto nel messaggio di benvenuto di openbsd.
>>>l'open source" sono spesso sotto GPL, cosa che ovviamente impedisce l'uso
>>>dei software in questione con OS non-GPL.
>> Se sei convinto di una cosa simile allora non hai affatto capito come
>> funziona la GPL e devi correre a rileggerla.
>"l'uso" come applicativi non ne e' certo impedito, visto che sui BSD girano
>secchiate di software GPL. Ma "l'uso" a livello di linking di una libreria
>sotto GPL (non LGPL?)? o l'uso nel kernel?
Puoi usare programmi coperti dalla GPL in sistemi operativi commerciali
(esiste un porting di emacs per windows) e puoi linkarli con le loro
librerie di sistema commerciali.
>Questo se volessi distribuire il codice con licenza BSD. Cosa succede se
>invece devo distribuire in un unico kernel GPL il mio codice (non GPL), ad
>esempio in un prodotto embedded?
Lo scopo della GPL e` proprio rendere impossibili queste cose.
Marco d'Itri
>Capirei se almeno avessero scritto da qualche parte che cosa fa ogni patch,
Non conosco red hat e quindi non posso rispondere, ma debian elenca
queste cose nel changelog.
>> Tra parentesi linux il tuning a run time lo fa sempre da solo, non
>> servono mica trenta sysctl come per freebsd... :-)
>Ne conto 661 sul mio. :-)
>Pero' vedo che anche in /proc c'e' un bel po' di roba con cui giocare.
Si`, ma la differenza e` che vengono usate praticamente solo dagli
sviluppatori per fare prove, con freebsd o solaris e` un passo normale
del tuning di un sistema.
Le uniche comunemente usate sono quelle per attivare il forwarding IP
e aumentare il numero di fd.
>Peccato che il kernel superpatch di redhat 7 faceva il botto sul mio
>desktop, quello di Debian no. Mi chiedo poi quanti di quei patch siano
>effettivamente necessari, e che cosa facciano. Lo avranno documentato da
>qualche parte?
Vedi sopra.
>Linus ha troppe preferenze personali.
Per ora si sono dimostrate giuste, oppure le ha modificate come nel caso
di devfs.
>Si sente la mancanza di un core team.
Strano, gli utenti linux invece non la sentono affatto...
Marco d'Itri
>(2.0.x). Occorreva impostare le "features" di ext2 da mke2fs, che continua
>a chiamarsi ext2 pur mutando in modo non compatibile con la release
ext2 ha tre (due?) bitmap che indicano la compatibilita` e permettono di
gestire nuove feature senza necessariamente sacrificare la
compatibilita` in avanti o all'indietro.
Per esempio nei kernel 2.5 le directory saranno indicizzate, ma il file
system continuera` ad essere leggibile e scrivibile anche dai kernel
>= 2.0.
Nel caso degli sparse superblock non era possibile mantenere la
compatibilita` con i kernel 2.0, ma la feature e` stata attivata di
default dopo molto tempo, quando questi non erano piu` usati da
praticamente qualsiasi nuova installazione. E non usarla significa
sprecare parecchio spazio sui grandi file system.
Marco d'Itri
>Come funziona con dpkg? Mi leggera' i .deb di Debian 8?
Se non li leggera` allora forniremo un pacchetto installabile in grado
di farlo. Per esempio in /debian/project/a.out_upgrade/ c'e` il
pacchetto di dpkg aggiornato per fare l'upgrade di una distribuzione
a.out.
Debian offre da sempre la possibilita` di fare un aggiornamento da
qualsiasi versione precedente.
Da quello che ho capito, i nuovi dischi di boot saranno anche in grado
di installare una *vecchia* distribuzione, oltre che l'ultima.
thorin_...@durin.khazad-dum.net
>> Che a me (e non solo) non e' mai capitato.. hai letto cio' che ha
>> scritto Giambo? E per rimanere in dati statistici piu' concreti,
> ... che usa Suse?
E allora? Il package manager e' lo stesso quindi si basa sugli stessi
concetti e stranamente neanche a lui che usa SuSE e non RH si e' mai
sputtanato il database, chissa' come mai.
>> pochi hanno, basta leggere it.comp.os.linux.* per rendersi conto che non
>> succede mica cosi' spesso che qualcuno che usa RH si ritrovi il db
>> sputtanato.
> Allora io e i miei colleghi o siamo sfortunati o siamo diventati stupidi
> durante il passaggio dalla 5.2 alle 7. :o)
> Per riassumere il tutto, compreso l'ovvio:
> RPM e' un package manager, installa e rimuove software, e tiene le sue
> brave informazioni nel suo bravo database. Io posso installare e rimuovere
[..]
> In caso di demenza furiosa posso provare ad installare package di un'altra
> distribuzione: in questo caso i package possono essere:
> 1) riconosciuti in qualche modo ed installati
> 2) riconosciuti ed installati con --force --nodeps
> 3) non riconosciuti, in quanto il formato degli RPM non e' compatibile, e
> non installati
> Non ci sono altri casi.
Bene, se tu installi un RPM di Mandrake su una RH i guai te li sarai
andati a cercare visto che usera' versioni differenti delle librerie
come minimo, quindi c'e' da aspettarsi logicamente che non funzionera'
bene. Perche' installare un package di un'altra distro? Se proprio ti
serve quel package o prendi il pacchetto .src.rpm (a tuo rischio,
aggiungo) e lo compili, o prendi il pacchetto tarball e puoi o
compilarlo direttamente oppure convertirlo da te in src.rpm (c'e' un
bellissimo HOWTO che spiega come fare) ma non venire a dire che se _tu_
fai di queste cagate la colpa e' di RPM !
[..]
> Io non mi aspetto che installando qualsiasi puttanata questa funzioni, ma
> mi aspetto che RPM si gestisca i suoi dati senza andare in pezzi. Il 3.0.4
> andava in pezzi. Il 3.0.5 non c'e' piu' negli updates. Il 4 non e'
> compatibile. E grazie RedHat.
Probabilmente anche RPM si aspetta che l'utente non faccia cazzate ed
installi con criterio i pacchetti.
>>> Io avevo il 3.0.4, che e' quello "stock" di redhat 6.2. Il fatto che non
>>> funzionasse (al contrario del tuo 3.0.5 che avrai trovato da qualche altra
>>> parte) era un buon incentivo ad aggiornarlo.
>> Non l'ho trovato da qualche parte, l'ho preso da updates.redhat.com in
[..]
> Ora su updates.redhat.com c'e' solo il 4. Non potevano lasciare anche il
> 3.0.5? Non avevano abbastanza spazio sul server FTP? Ora se volessi
> aggiornare a quella versione devo andare a caccia in giro per internet:
> www.rpm.org.
Che poi non e' una impresa cosi' difficile. D'altro canto mi sono gia'
offerto per ben 2 volte di mandartelo via e-mail, di piu' non posso
fare.
>> stato rimosso non posso farci niente ma sta di fatto che evidentemente
>> tu Bugtraq non lo leggi.
> E sta di fatto che redhat non mantiene una history dei patch in modo che io
> possa scegliere fino a quale livello aggiornare la mia macchina.
Se tu leggessi Bugtraq vedresti che quando viene rilasciato un
aggiornamento il package viene rilasciato per _ognuna_ delle versioni,
dalla 5.x alla 7, poche palle !
>> Ma a te tutta quella roba, patches come iBCS servono _veramente_ ? Su un
>> PC desktop per esempio, mi spieghi a che cosa ti serve pcmcia? Per
> No, non mi serve a nulla. Ma questo e' il kernel che redhat mi installa, e
> guarda caso e' il kernel che poi da' problemi. Non mi ha chiesto se
Allora male hai fatto ad usarlo, se avessi preso, come ti ho gia' detto,
il kernel ufficiale, cio' non sarebbe successo.
> volessi pcmcia oppure no. Oltretutto pcmcia si spegne da ntsysv. Devo forse
> compilare una tarball del kernel dopo ogni installazione della
> distribuzione?
Beh di solito e' ritenuta cosa furba ricompilare per levare le cose
inutili e customizzare il kernel sul proprio HW. Se non lo fai allora
non lamentarti delle cose inutili.
> No -> la distribuzione e' tenuta a fornirmi un kernel testato e
> funzionante, senza patch fantasiosi.
Loro non sono tenuti a darti una bella mazza perche' non fanno mica
parte del team di sviluppo del kernel. E d'altro canto non possono mica
sapere se tu hai per esempio una ATA 66 (o come accidenti si chiama) e
quindi necessiti di una patch al kernel per farla funzionare.
> Si' -> la funzione della distribuzione viene a cadere, visto che devo
> compilare comunque i tarball a mano. A che mi serve allora la
Quella e' una cosa che si fa comunque. Ripeto, non lamentarti delle cose
inutili se non ti sta bene ricompilare il kernel.
> Prendi il 2.2.17 di redhat, fai "make oldconfig", vedi quante domande ti
> fa: quello e' il numero di patch aggiunti. Peccato che non hanno
Spiegami perche' dovrei usare il kernel di RH invece di quello
ufficiale, poi rifammi la stessa domanda.
>> occupare solo spazio inutile. Avresti fatto prima a prendere un tarball
>> dal mirror ufficiale di kernel.org e ricompilarlo. Spero ti renda conto
[..]
> Se avrei fatto prima a ricompilarlo (nessun problema a farlo), che senso ha
> l'esistenza delle distribuzioni? Non dovrebbero forse creare un _prodotto_,
Magari il kernel con le distribuzioni non c'entra niente?
>> E chi ha pregato di usare _quel_ kernel invece di un tarball ;-) ? Di
> L'illusione che redhat sapesse che cosa sta facendo dei suoi prodotti, cosa
> che purtroppo non e'.
Beh se tu pecchi di superficialita' non e' colpa della RH.
[..]
> Il tutto da una societa' che ha la pretesa di essere "il linux per
> l'enterprise".
> Hello? McFly?
McFly me cojoni.. tu fai le cazzate e poi dai la colpa alla RH, troppo
comodo.. A me in un tot di anni che uso RH non e' mai capitato un grammo
dei guai che vai lamentando e nemmeno a tanti altri, come ti ho gia'
scritto (basta leggere it.comp.os.linux.* per rendersene conto) quindi
piantala..
[..]
> Certo: il tarball da compilare, buono per il singolo PC o il singolo
> server. Per un prodotto che va venduto e distribuito devo a) modificare la
Non c'e' nulla da sistemare: prendi il tarball, 'make menuconfig' e
ricompili, punto.
>> E' un errore VM che si ha quando cerca di liberare delle pagine di
>> memoria e non ci riesce.. va avanti cosi' finche' o si congela tutto
[..]
> Ora non posso certo aggiornare al 2.4.x la rh6.2. Mi devo aspettare che
> redhat metta una toppa per questo problema, nella patch numero 158?
Se continui ancora, testardamente, ad usare i loro kernel allora i guai
te li vai a cercare.
>> Sei veramente sicuro che anche il kernel di Linux non lo faccia? Hai
>> verificato?
>
> Beh... c'e' una patch no? Dentro o fuori: le opzioni di "make menuconfig"
> sono li' per bellezza :o)
Mah, continuo a pensare sempre piu' che ti piaccia farti del male..
>>> E' chiaro che posso installare qualsiasi distribuzione e mantenerla
>>> "stabile" a colpi di sorgenti e compilazioni. E' comunque opportuno evitare
>> Ho idea che neanche tu abbia idea di cosa stessi facendo, considerato
[..]
> A questo punto devo immaginare che siano da scartare tutte le distribuzioni
> basate su kernel "non ufficiali". Reiser? niente. lm_sensors? niente. ext3?
> nulla. debugger? nada.
Con qualsiasi distro devi ricompilare il kernel, che c'entra? Anche con
Debian, per esempio ed anche se prendi il .deb che ti danno assieme (che
non so se sia quello ufficiale o meno) il discorso non cambia di una
virgola.
>>> Prova ad installarne uno, vedi cosa dice. Non si installera'.
>> inferiore che possa andare o senno' va a prenderselo nell'impianto di
[..]
> ... Usando tarball al posto di RPM? :o)
Perche' no? E' sicuramente una cosa piu' intelligente che installare un
RPM non adatto che va a fare casini ;-)
> Domanda filosofica: che differenza concettuale c'e' fra:
> a) installare gli updates di redhat che vengono dal loro stesso sito, o
> b) scrivere il famoso "apt-get" per aggiornare automaticamente una Debian.
L'operazione e' equivalente, con la differenza che la gestione delle
dipendenze di Debian e' migliore.
> Mi pare che l'operazione sia equivalente: installare gli aggiornamenti che
> raccomanda la distribuzione. L'unico problema e' che redhat raccomanda
> cazzate, quindi devo supporre che non sia sbagliata l'operazione in se',
> ma e' sbagliata la scelta della distribuzione.
RH raccomandera' cazzate ma tu ne hai fatte anche molte per conto tuo e
non c'entra che apt-get sia da super sysadmin o up2date (mai usato in
vita mia, sempre scaricato con wget ed installato con 'rpm -Uvh') sia da
utonti.
>> Non e' niente di particolarmente complicato. immagino basti guardare
>> bene fra le opzioni di menuconfig.
> A parte il dettaglio che l'ultima volta che ho guardato il pppd non
> supportava CBCP, e' tutto abbastanza semplice :)
A parte che non so cosa sia immagino tu non abbia nemmeno fatto lo
sforzo di cercare se c'era una patch, vero?
>>> Fra parentesi, la procedura per la generazione degli ISO di Debian e'...
>>> @#$@%@#%.... interessante. <G>
>> Magari studiandola meglio... ;-)
> Non ho tempo di cazzeggiare con i finti ISO e l'rsync: lascio l'ftp in
> batch in ufficio e domani trovo tutto :-)
Allora non lamentarti se non vuoi nemmeno capire come funziona.
>> L'importante e' che il prodotto sia ben testato, probabilmente. Non sei
>> mai contento, e che cazzo ! Ti lamenti di RH perche' dici che non e'
> Quando ho provato helix per mandrake e redhat 7 tutto mi e' sembrato tranne
> che "ben testato". Era il festival dei --force. Se poi il loro installer
Se usi --force e --nodeps per forzare la rottura delle dipendenze la
colpa e' anche tua, non solo di RPM.
> In FreeBSD mi compilo Gnome dai sorgenti. Solo che lo fa la ports
> collection senza farmi fare il download delle tarball a manina.
Mah io Gnome su RH l'ho installato da RPM.. questione di manico?
>>> la vedo molto male. Casualmente abbiamo Slackware 7.x, Suse 7.x, RedHat
>> Echissenefrega? Il bello e' che si puo' scegliere.
> Indovino? Debian, andando per esclusione. Ci sara' un motivo se finiscono
> tutti li'. Quando ci sono 8 scelte, e per un motivo o per l'altro 7 sono
Mbeh dipende anche dalle cazzate che hai fatto tu <g>
>> Infatti, ma tanto le mosche ad ogni nuova rilis si precipitano,
>> aspettandosi chissa' quale novita' tecnologica ed invece si beccano la
[..]
> Intanto COM nella sua follia mi fa "pilotare" Office da Ruby e Python senza
> toccare Visual Basic. Con che cosa potro' fare scripting per OpenOffice?
> Bonobo o KParts? SOAP? Boh :o)
Non mi sono posto il problema, primo perche' uso StarOffice e non Open
Office e secondo perche' non mi interessa fare scripting su un Office e
terzo perche' Open Office ha ancora da attendere per essere usabile, da
quanto continuo a leggere in giro.
>>> ... li contero', non resta altro da fare :o)
>> Brao'.
> 5000equalcosa, Progeny dice 6000. Pero' sto vedendo nuovi PR su gnats con
> nuovi port :-)
Allora, chi ce l'ha piu' lungo? Cosi' chiudiamo questa stupida diatriba?
>>> StarOffice, netscape. Poi io uso Emacs, ma non legge certo i file ".xls".
>> Appunto ma cio' non toglie che per Linux ci siano mentre per BSD no (gne
> Questo perche' chi ha fatto StarOffice non ha avuto la decenza di scrivere
> "make" sulla macchina BSD. Da notare che StarOffice non e' disponibile in
E quindi per questo motivo ti devi abbassare ad usare Linux, che
peccato, eh? E meno male che c'e' Linux altrimenti ti saresti ritrovato
a continuare ad usare Uord ed Eccelso..
>> gne) ma il punto non e' questo, c'e' anche tanto sw free che permette
>> ugualmente di fare tutto cio' che serve.
> Quasi tutto, tranne leggere la merda che ti mandano con powerpoint (non che
StarOffice la legge se non ricordo male ma non ne sono sicuro perche' di
quella merda non le tratto (in quanto tale..)
>> Per il momento non e' all'altezza di StarOffice, pare.
> Allora mi viene il sospetto che non abbiano tirato fuori tutti i sorgenti.
> Come nel caso di Netscape, non vengono "rilasciati i sorgenti del
Non so e non mi interessa: per le mie esigenze StarOffice basta ed
avanza e non ho voglia di andare a correre dietro ad ogni nuovo prodotto
che arriva: questi giochini li lascio alle mosche che usano le merde di
m$.
[..]
>> Diciamo che i casi in cui ti serve non installare in /usr sono
>> abbastanza rari, eh?
> Ad esempio, in FreeBSD, tutti i software che non sono "core".
Puoi usare /opt su Linux, non mi pare cosi' complicato.
>>> E il software compilato dovrebbe sapere che il suo prefix puo' cambiare, ma
>>> non tutti i "./configure" lo supportano. Un bel casino.
>> Mboh finora mai capitato..
> E allora a che servirebbe l'opzione --prefix nei ./configure, se fosse in
> grado di capire da solo dove e' stato installato? In questo caso sarebbe
> un'opzione del makefile: make install prefix=/usr.
Voglio dire che finora ho sempre trovato dei ./configure che
supportavano questa possibilita'.
>> distro ha le sue colpe ma siccome anche il pezzo di carne fra sedia e PC
>> ha la sua parte di merito la cosa non mi meraviglia affatto. Il mondo
>> Linux avra' perso un idiota.
> Potrebbero fare una versione "redhat network luserhood" e una "redhat
> decent server". Ogni idiota perso e' un idiota che ingrassa Bill Gates.
Non vedo cosa cambierebbe; un idiota riuscirebbe _comunque_ a far danni,
con una qualunque delle due. Gli idioti sono meravigliosamente bravi in
questo.
> Ogni idiota perso e' un'applicazione in meno di cui verra' fatto il porting
> nativo in Linux. Diamo all'idiota la sua distribuzione, ma per favore giu'
> le mani dalle altre. Ormai sembra che facciano la gara per chi ha
> l'installatore piu' colorato, confondendo colore con facilita' d'uso.
Ogni idiota perso sara' una occasione in piu' per non vedere ulteriori
stronzate alla Uindous nelle distribuzioni luser-oriented.
>> Nessuno ti obbliga ad usare Linuxconf: se il luser si preoccupasse di
[..]
> Se e' per questo, nessuno mi obbliga ad usare redhat: dovrebbero capirlo
> anche loro stessi prima di ritrovarsi con 4 utenti in croce che pagano $10
> al mese per avere gli update bacati.
Appunto ma nel caso la usi abbi anche il coraggio di prenderti la
responsabilita' delle cazzate che fai.
thorin_...@durin.khazad-dum.net
>>>>> La Suse utilizza le dipendenze per gli RPM?
>>>> Certo che si.
> Su rufus.w3.org vedo solo Suse 6.4 elencata.
> Ho preso un paio di file dalla Suse 7.1 "Official", su ftp.suse.com.
> Qualcuno per fortuna mi ha detto che i sorgenti sono nella "serie z". Non
> oso chiedere perche'. Forse una serie "src" sembrava difficile :-)
Non lo chiedere a me, chiedilo agli sviluppatori SuSE.
> Esempio: ho preso kgui.spm (source) e kgui.rpm. Uno a caso.
> Domanda 1: perche' nel nome del file non c'e' scritta la versione? Come
> faccio a sapere di quale versione si tratta prima di scaricare 10mega
> dall'ftp?
Se non c'e' la versione suppongo che se cerchi dei pacchetti per SuSE
7.1 andare in ftp.suse.com/pub/suse/i386/7.1 possa essere un buon
inizio.
> Domanda 2: nel file.spec ci sono questi commenti:
> # neededforbuild autoconf [snip] libpng
> # usedforbuild aaa_base [snip] xf86 xshared
> Che differenza c'e' fra "needed" e "used"?
Ad occhio che per fare il build del package sono necessari GNU autoconf
e tutto il resto mentre usedforbuild vorra' dire che vengono usati per
fare il build ma non ne sono sicuro perche' .rpm.src non ne compilo mai
quindi meno che meno posso parlare di SuSE che conosco poco.
> Non vedo i "Requires:" che si trovano sugli rpm di RedHat.
I Requires ci sono anche negli .src.rpm? A che pro se devono essere
compilati?
> Se installo questo kgui e poi non funziona perche' manca ad esempio libpng,
> come faccio a saperlo?
Immagino che se il linker si incazzi molto prima se gli serve libpng e
non riesce a risolvere i simboli.
thorin_...@durin.khazad-dum.net
>>>Debian forse ne abbia di piu' ma non ne sono sicuro.
>> Se proprio vogliamo fare a chi c'e` l'ha piu lungo...
> E poi vediamo chi fa piu' strada per andare a fare l'installazione a mano,
> senza kickstart :o)
E chi ti ha detto che bisogna farla a mano?
thorin_...@durin.khazad-dum.net
>>Non vorrei fare a chi ce l'ha piu' lungo... rimango dell'opinione che
>>Debian forse ne abbia di piu' ma non ne sono sicuro.
> Se proprio vogliamo fare a chi c'e` l'ha piu lungo...
> harris:~# apt-cache stats
> Total Package Names : 7290 (292k)
> Normal Packages: 5848
> Game, set, match per Debian :)
:-))
thorin_...@durin.khazad-dum.net
>>> effettivamente necessari, e che cosa facciano. Lo avranno documentato da
>>> qualche parte?
>> Io mi chiedo invece chi ti abbia costretto ad usare quel kernel al posto
>> di uno ufficiale che di problemi non te ne avrebbe dati.
> Nessuno. Penso infatti che mi rechero' personalmente presso ogni cliente a
> compilare una tarball custom, su misura. Dopo aver compilato il
Se ti piace fare lavoro inutile: puoi anche compilare un kernel su
floppy e poi andare solo col floppy dal cliente, se e' per questo <g>
eM'
>> E` invece vero il contrario, gli sviluppatori dei *BSD fanno sempre il
>> possibile per sostituire codice GPLed con codice coperto dalla licenza
>
> Questo perche' il "core" (kernel + utility) di un BSD deve essere su
> licenza BSD, altrimenti non e' BSD.
Questa è solo una presa di posizione arbitraria da parte degli
sviluppatori, al pari di decidere di utilizzare solo software GPL.
Con questo voglio solo sottolineare che è solo una presa di posizione
ideologica, non determinata da considerazioni tecniche sulla bontà del
codice.
> Per le applicazioni, il software GPL viene usato senza alcun problema.
> Se mi fai un esempio di 3 pagine di credits me lo vado a vedere, cosi'
> mi rallegra la serata :o)
Beh, ogni licenza simil-BSD impone che venga citato il nome della società
o organizzazione che detiene il copyright del codice.
Per questo, ad ogni linea di codice aggiunta da autori differenti dovrebbe
corrispondere la solita chilometrica dicitura, mentre con la GPL rimane la
GPL e basta...
Comunque io preferisco la GPL solo perchè garantisce che dal mio lavoro
"open" qualcuno non derivi un prodotto che aggiunga una minima
funzionalità addizionale in un prodotto chiuso. Mi darebbe incredibilmente
fastidio che, al mio ipotetico kernel, qualcuno aggiunga la capacità di
gestire la scheda di rete più diffusa nel mondo, per la quale non ho
sviluppato il driver poichè non sono disponibili pubblicamente le
specifiche, derivandone un prodotto chiuso. In tal modo costoro avrebbero
tratto guadagno dal mio lavoro, mentre io non ho neppure la possibilità
di imparare qualcosa dal loro...
Detto ciò, concordo nell'affermare che linux sia frammentato e che la
commercializzazione estrema a cui è soggetto porti numerose problematiche.
Questo è valido, però, per le distro commerciali, mentre per Debian è
diverso: ne è un esempio il fatto che la release ufficiale non abbia
kernel 2.4 e xfree 4, ma che essi siano disponibili solo come unstable...
Ben lungi dall'essere perfetta, ma perlomeno non è costretta a seguire le
mode a tutti i costi... Inoltre Debian è aperta ad altri kernel e sistemi:
ne è un esempio il progetto Debian GNU/Hurd... Non sarebbe male vedere
Debian BSD/FreeBSD 8-)
--
Au revoir.
Lele...
Jimmy Olgeni
> Nel caso degli sparse superblock non era possibile mantenere la
> compatibilita` con i kernel 2.0, ma la feature e` stata attivata di
> default dopo molto tempo, quando questi non erano piu` usati da
Eh, ora lo so anch'io. Non a caso l'installazione di Debian faceva la
domanda.
Ma se formattavi un MO sul 2.2 (rh6) e lo leggevi dal 2.0 (rh5) trovavi la
sorpresa... Bastava una riga di warning in mke2fs tanto per segnalare il
fatto :o)
Mi rimane da capire la storia del "setting filetype to 6".
Cerchero' in giro...
Jimmy Olgeni
>>Capirei se almeno avessero scritto da qualche parte che cosa fa ogni patch,
> Non conosco red hat e quindi non posso rispondere, ma debian elenca
> queste cose nel changelog.
RedHat al massimo da' una sommaria descrizione sul sito, quando si
ricorda... non la provare :)
> Si`, ma la differenza e` che vengono usate praticamente solo dagli
> sviluppatori per fare prove, con freebsd o solaris e` un passo normale
> del tuning di un sistema.
Avevo visto delle cose interessanti in /proc/sys/net/ipv4qualcosa, mi pare,
ma non ho mai trovato un pezzo di documento con scritto a cosa servisse.
>>Linus ha troppe preferenze personali.
> Per ora si sono dimostrate giuste, oppure le ha modificate come nel caso
> di devfs.
Alcune cose "quasi giuste" potrebbero diventare delle "giuste opzioni
disabilitate per default". Se uno le abilita, se le e' cercate. Poi c'e'
gia' l'opzione per la "kernel maturity", quindi... usiamola :)
Anche in FreeBSD, il debugger mica e' compilato per default.
>>Si sente la mancanza di un core team.
> Strano, gli utenti linux invece non la sentono affatto...
Le decisioni arbitrarie di una persona non sono molto differenti da quelle
di 10. 10 persone c'e' speranza che ci discutano sopra, se poi a 7 non
piace il debugger e' un'altra storia :o)
Jimmy Olgeni
>>credits me lo vado a vedere, cosi' mi rallegra la serata :o)
> Ricordo di averlo visto nel messaggio di benvenuto di openbsd.
Non e' un campione molto significativo :o)
> Puoi usare programmi coperti dalla GPL in sistemi operativi commerciali
> (esiste un porting di emacs per windows) e puoi linkarli con le loro
> librerie di sistema commerciali.
Visto / fatto.
>>invece devo distribuire in un unico kernel GPL il mio codice (non GPL), ad
>>esempio in un prodotto embedded?
> Lo scopo della GPL e` proprio rendere impossibili queste cose.
Infatti. Ed e' per questo che riscrivono alcune cose sotto licenza BSD,
mica per divertimento o per sport :)
Jimmy Olgeni
> Sono interessanti per gli sviluppatori, non per chi ha bisogno di un
> kernel precompilato.
Qualcuno (!) mi dice che il kernel precompilato e' una bestemmia, e che va
compilato a mano. Quindi... :)
Certo se il kernel fa il botto su una macchina di produzione sarebbe buona
cosa avere almeno il dump, per capire che cosa e' andato storto.
> Anche IBM sta facendo molto sul fronte del debugging (su tutti i fronti
> in realta`, anche linux/390 e` veramente carino :-) ).
Perche' non fanno una distribuzione con la shell di OS/2? :-)
> Lo so, il punto e`: il controller andra` a scrivere nel posto giusto o
> no? Dopo un kernel panic il driver potrebbe essere un po' confuso.
Andro' a chiedere in giro come funziona.
>>Qui l'OS e' quello che esce dal CVS, il resto e' il resto :o)
> Puo` essere una differenza filosoficamente elegante, ma al momento di
> gestire una macchina mi sembra piu` pratica quella usata da linux.
Dipende, c'e' una differenza tra scaricare 20k in cvsup e 30mega di glibc
compilata...! Il mio squallido modem lo sa :o)
Jimmy Olgeni
> Se non c'e' la versione suppongo che se cerchi dei pacchetti per SuSE
> 7.1 andare in ftp.suse.com/pub/suse/i386/7.1 possa essere un buon
> inizio.
Infatti e' proprio da li' che ho preso il kgui.rpm.
$ rpm -qp kgui.rpm
kgui-0.1-222
Me lo dice dopo aver scaricato... non mi pare un'organizzazione molto
vantaggiosa.
> Ad occhio che per fare il build del package sono necessari GNU autoconf
> e tutto il resto mentre usedforbuild vorra' dire che vengono usati per
Qualunque cosa voglia dire, sono commenti e quindi vengono ignorati! :o)
> fare il build ma non ne sono sicuro perche' .rpm.src non ne compilo mai
> quindi meno che meno posso parlare di SuSE che conosco poco.
Funziona cosi':
Provides: il virtual package, ad esempio "mailer"
Requires: autoconf, libBogus >= 1.0
AutoReqProv: yes, se vuoi che usi ldd e legga gli shell script per tirare
fuori altre dependency (#/bin/sh -> requires bash)
>> Non vedo i "Requires:" che si trovano sugli rpm di RedHat.
> I Requires ci sono anche negli .src.rpm? A che pro se devono essere
> compilati?
I Requires vengono compilati e scritti nel .rpm. Altrimenti come fa a
sapere da che cosa dipende quel package? Molte informazioni del file .spec
finiscono nell'header del package. Vendor, Packager, Group, Version,
Release, Name, License. Anche i pre e post install scripts sono nel .spec.
Il .spec, il tarball e i patch finiscono tutti nel .src.rpm, che poi e' un
file cpio con un header.
> Immagino che se il linker si incazzi molto prima se gli serve libpng e
> non riesce a risolvere i simboli.
Il linker si incazza quando cerci di eseguire il programma. RPM lo
installa, non lo esegue. Se le dependency non sono elencate il programma
verra' installato, ma non potra' mai funzionare.
Non capisco pero' il senso di avere l'elenco di dependency commentato, qui
serve il consiglio di qualche esperto in Suse.
Marco d'Itri
>Ben lungi dall'essere perfetta, ma perlomeno non è costretta a seguire le
>mode a tutti i costi... Inoltre Debian è aperta ad altri kernel e sistemi:
>ne è un esempio il progetto Debian GNU/Hurd... Non sarebbe male vedere
>Debian BSD/FreeBSD 8-)
Ci stanno provando, ma non hanno ancora deciso cosa dovrebbe essere.
(Per la cronaca, FreeBSD non usa dpkg perche` e` GPLed, qualcuno del
core team anni fa aveva chiesto a Ian Murdock di relicenziarlo, ma
ovviamente non ha accettato.)
Marco d'Itri
>Avevo visto delle cose interessanti in /proc/sys/net/ipv4qualcosa, mi pare,
>ma non ho mai trovato un pezzo di documento con scritto a cosa servisse.
/usr/src/linux/Documentation/networking/ip-sysctl.txt
Per il resto: /usr/src/linux/Documentation/sysctl/.
>Alcune cose "quasi giuste" potrebbero diventare delle "giuste opzioni
>disabilitate per default".
Non e` cosi` semplice. Qualsiasi cosa che non sia un driver o un file
system autocontenuto ha un impatto sul resto del kernel, che sia o no
attivo per default.
Andrea Capriotti
>harris:~# apt-cache stats
>Total Package Names : 7290 (292k)
>Normal Packages: 5848
>
>Game, set, match per Debian :)
capriott@debian:~$ apt-cache stats
Total Package Names : 9092 (364k)
Normal Packages: 6892
Saluti
--
Andrea Capriotti
thorin_...@durin.khazad-dum.net
>> Se non c'e' la versione suppongo che se cerchi dei pacchetti per SuSE
>> 7.1 andare in ftp.suse.com/pub/suse/i386/7.1 possa essere un buon
>> inizio.
[..]
> Me lo dice dopo aver scaricato... non mi pare un'organizzazione molto
> vantaggiosa.
Perche', guardare il nome della directory _prima_ di scaricare e' cosi'
difficile? O mi sfugge qualcosa?
>> Ad occhio che per fare il build del package sono necessari GNU autoconf
>> e tutto il resto mentre usedforbuild vorra' dire che vengono usati per
> Qualunque cosa voglia dire, sono commenti e quindi vengono ignorati! :o)
Boh, non mi sono mai interessato molto come siano fatti i package src di
SuSE visto che non l'ho mai usata (e penso mai la usero')
>> fare il build ma non ne sono sicuro perche' .rpm.src non ne compilo mai
>> quindi meno che meno posso parlare di SuSE che conosco poco.
[..]
>>> Non vedo i "Requires:" che si trovano sugli rpm di RedHat.
>> I Requires ci sono anche negli .src.rpm? A che pro se devono essere
>> compilati?
> I Requires vengono compilati e scritti nel .rpm. Altrimenti come fa a
> sapere da che cosa dipende quel package? Molte informazioni del file .spec
Ah ok, ma te l'ho detto, non mi sono mai interessato piu' di tanto degli
.src.rpm perche' li ho sempre trovati scomodi ed inutili e gli ho
preferito i tarball quando proprio dovevo compilare qualcosa.
>> Immagino che se il linker si incazzi molto prima se gli serve libpng e
>> non riesce a risolvere i simboli.
> Il linker si incazza quando cerci di eseguire il programma. RPM lo
> installa, non lo esegue. Se le dependency non sono elencate il programma
> verra' installato, ma non potra' mai funzionare.
Io continuo a chiedermi pero' come faccia a compilare un package se una
dipendenza non viene soddisfatta ergo, se mi serve libcrypt per
compilare un programma e non ce l'ho, per esempio.
> Non capisco pero' il senso di avere l'elenco di dependency commentato, qui
> serve il consiglio di qualche esperto in Suse.
Forse Giambo? O Leonardo (se legge)
thorin_...@durin.khazad-dum.net
>> Sono interessanti per gli sviluppatori, non per chi ha bisogno di un
>> kernel precompilato.
> Qualcuno (!) mi dice che il kernel precompilato e' una bestemmia, e che va
> compilato a mano. Quindi... :)
A parte che un nome ce l'ho e sei pregato di usarlo non ho mai scritto
che debba essere obbligatorio ma semplicemente che dovrebbe essere
cosa furba, per levare cio' che e' inutile. Non sei obbligato a farlo
pero' di certo e ' una cosa piu' intelligente di cio' che fai tu cioe'
tenerti un kernel con PCMCIA ed altre cose inutili salvo poi lamentarti
del kernel pieno di inutilita' !!
Gabriele Giambonini
>>
>> Mi pare siano sotto la "z" ...
>
>Per "zources?"... zi? inzomma... :o)))
Forse volevano essere sicuro che andasse a finire in fondo-fondo :)
--
Giambonini Gabriele Teamup AG
Software Engineer Industriestrasse 15
5242 Lupfig
Switzerland
eM'
>>Ben lungi dall'essere perfetta, ma perlomeno non č costretta a seguire
>>le mode a tutti i costi... Inoltre Debian č aperta ad altri kernel e
>>sistemi: ne č un esempio il progetto Debian GNU/Hurd... Non sarebbe
>>male vedere Debian BSD/FreeBSD 8-)
>
>Ci stanno provando, ma non hanno ancora deciso cosa dovrebbe essere.
Credo, inoltre, che utilizzerebbero openBSD come kernel BSD, dato che
freeBSD č piů limitato dal punto di vista delle architetture su cui č
disponibile...
>(Per la cronaca, FreeBSD non usa dpkg perche` e` GPLed, qualcuno del
>core team anni fa aveva chiesto a Ian Murdock di relicenziarlo, ma
>ovviamente non ha accettato.)
Oh, ma tu guarda... ;-)
--
Au revoir.
Lele...
eM'
>
> Ho visto che sawmill si chiama ancora sawmill (0.20)
>
> Ok lasciar fermo il kernel e la libc, ma almeno i programmini scemi
> aggiornateli. Ho capito: dkpg e via a compilare :-)
>
Beh, se vuoi stare più aggiornato usi i pacchetti della testing o della
unstable... A proprio rischio e pericolo (anche se per Saw[mill|fish] non
credo sia un rischio insuperabile :-)
--
Au revoir.
Lele...
Jimmy Olgeni
>> licenza BSD, altrimenti non e' BSD.
> Questa č solo una presa di posizione arbitraria da parte degli
> sviluppatori, al pari di decidere di utilizzare solo software GPL.
L'utilizzo del "software" GPL sotto BSD non e' in discussione, dato che
chiunque puo' utilizzarlo. E' l'utilizzo di _sorgenti_ GPL che puo' portare
problemi. GPL nasce per mantenere il software "libero" per forza, BSD per
consentirne qualunque uso commerciale senza vincoli di rilascio dei
sorgenti. Poi sta a te decidere quale liberta' preferisci. E' evidente che
in un kernel BSD non ci possano essere parti GPL.
> Beh, ogni licenza simil-BSD impone che venga citato il nome della societŕ
> o organizzazione che detiene il copyright del codice.
"Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials. Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.".
> Per questo, ad ogni linea di codice aggiunta da autori differenti dovrebbe
> corrispondere la solita chilometrica dicitura, mentre con la GPL rimane la
> GPL e basta...
E' sempre la stessa... ma se ogni package ne installa una, cominciano a
diventare tante...
$ locate COPYING | wc -l
75
> Comunque io preferisco la GPL solo perchč garantisce che dal mio lavoro
> "open" qualcuno non derivi un prodotto che aggiunga una minima
> funzionalitŕ addizionale in un prodotto chiuso. Mi darebbe incredibilmente
Garantisce anche che tu stesso non possa utilizzare le tue modifiche
+ parti GPL in un prodotto closed source, e trarne un vantaggio commerciale.
Come potrebbe poi portare un cosi' grande vantaggio economico un prodotto
con una cosi' _minima_ funzionalita' addizionale?
> specifiche, derivandone un prodotto chiuso. In tal modo costoro avrebbero
> tratto guadagno dal mio lavoro, mentre io non ho neppure la possibilitŕ
> di imparare qualcosa dal loro...
In tal caso nessuno usera' il tuo prodotto con quella scheda di rete, ne'
tu ne' nessun altro. Cio' che dici e' vero, ma e' altrettanto vero che non
esistono 12 cloni commerciali di *BSD ognuno con il supporto per una scheda
di rete proprietaria diversa. Allora, all'atto pratico, non funziona
esattamente cosi'.
Piuttosto, se tu devi realizzare un Embedded Bogotronic 2000, dove vai a
prendere lo stack IP: da GPL o da BSD? Dipende da che cosa vuoi fare dei
tuoi sorgenti. Almeno hai la possibilita' di scegliere.
> Detto ciň, concordo nell'affermare che linux sia frammentato e che la
> commercializzazione estrema a cui č soggetto porti numerose problematiche.
Ah, ma linux e' uno solo. Sono le distribuzioni ad essere leggermente
frammentate :-)
> diverso: ne č un esempio il fatto che la release ufficiale non abbia
> kernel 2.4 e xfree 4, ma che essi siano disponibili solo come unstable...
L'esatto contrario di redhat: mi pare un buon segno.
> ne č un esempio il progetto Debian GNU/Hurd... Non sarebbe male vedere
> Debian BSD/FreeBSD 8-)
Nessuno lo impedisce :)
Jimmy Olgeni
>> E poi vediamo chi fa piu' strada per andare a fare l'installazione a mano,
>> senza kickstart :o)
> E chi ti ha detto che bisogna farla a mano?
Da sola non si fa. O qualcuno compila sul posto, o qualcuno cambia la
procedura di installazione, o qualcuno ricompila l'rpm del kernel (RTfM).
Non vedo alternative a parte quella del floppy :^)
Jimmy Olgeni
> concetti e stranamente neanche a lui che usa SuSE e non RH si e' mai
> sputtanato il database, chissa' come mai.
Se e' per quello, sulla carta anche il kernel e' lo stesso. 2.2.x.
Stranamente poi fanno cose diverse: uno ha reiserfs, gli altri no.
Lieve differenza.
Se l'rpm di Suse non usa le dependency, e "package Makefile not in file
index" e' chiaramente un problema di dependency, il trucco mi pare
abbastanza semplice: eviti le dependency, eviti il problema.
> Bene, se tu installi un RPM di Mandrake su una RH i guai te li sarai
Mai fatta una cosa simile.
> Che poi non e' una impresa cosi' difficile. D'altro canto mi sono gia'
> offerto per ben 2 volte di mandartelo via e-mail, di piu' non posso
> fare.
Io lo posso certamente trovare su internet, ma il mitico supporto
"enterprise level" di RedHat non si puo' certo reggere sul fatto che ci sei
tu a mandare le email ai loro singoli clienti! :o)
> Se tu leggessi Bugtraq vedresti che quando viene rilasciato un
> aggiornamento il package viene rilasciato per _ognuna_ delle versioni,
> dalla 5.x alla 7, poche palle !
Infatti. E ora per la versione 6.2 danno RPM4, poche palle. Vai a
controllare e dimmi dov'e' il 3. Se oggi esce il 3 aggiornato, e domani lo
cancellano, a me pare una gestione a dir poco demente degli aggiornamenti.
Che vuol dire, che se perdo il treno dell'update giusto poi devo cercare
gli avanzi in giro per il web? Bel supporto. E' sufficiente non cancellare
gli update vecchi. Hanno dei file .nfs209384028420 da 10 mega nelle
directory dell'ftp: cancellino quelli piuttosto.
Oggi e' uscito il 2.2.19, contemporaneamente alla 7.1: non ti dico
l'intasamento del server FTP. Metterne uno a parte per i patch?
> Allora male hai fatto ad usarlo, se avessi preso, come ti ho gia' detto,
> il kernel ufficiale, cio' non sarebbe successo.
Quindi non ha senso basare un prodotto su una distribuzione: va tutto
compilato a mano? Kernel ufficiale + patch presi in giro dalla rete?
Buona "world domination", e buona notte.
> inutili e customizzare il kernel sul proprio HW. Se non lo fai allora
> non lamentarti delle cose inutili.
L'inutilita', e l'occupazione di 4k in piu' in memoria, non sono un
problema. I kernel panic invece si'.
>> No -> la distribuzione e' tenuta a fornirmi un kernel testato e
>> funzionante, senza patch fantasiosi.
> Loro non sono tenuti a darti una bella mazza perche' non fanno mica
> parte del team di sviluppo del kernel. E d'altro canto non possono mica
Attenzione: se io compro una distribuzione, il distributore e' _tenuto_ a
darmi una cosa che funziona, o almeno a provarci: ci puo' essere il bug
solo come eccezione. Seguendo questo ragionamento non sarebbero tenuti a
darmi neanche XFree o il KDE, non sarebbero tenuti a fare una
distribuzione, quindi tutti a casa. Neanche la licenza di Windows dice che
e' tenuto a funzionare.
Anche qui i casi sono due:
a) Loro *non* fanno parte del team di sviluppo del kernel, non sanno che
pesci prendere. Quindi possono benissimo darmi la tarball di Linus, che si
suppone funzioni, e dirmi "fai quello che ti pare". Non devono mettere 150
patch nel kernel se non sanno che cosa stanno facendo.
b) Loro *fanno* parte del team, o almeno hanno familiarita' con il kernel,
quindi sanno esattamente a cosa servono i 150 patch, pertanto mi aspetto
che su un hardware abbastanza comune e diffuso non si verifichino kernel
panic in idle. Pretendo inoltre che in una distribuzione commerciale i
patch siano elencati e documentati.
Se il distributore non e' tenuto a darmi nulla, mi chiedo a quel punto che
cosa mi abbia dato nel CD in cambio dei miei $40. Poteva darmi un mirror di
Sunsite/metalab/blah, dirmi "compilalo tu" e far prima.
Le distribuzioni si distinguono, e competono, anche per le caratteristiche
del kernel. Se quello di Linus e' una reference implementation, gli altri
devono almeno _tentare_ di fare meglio. Altrimenti, che senso ha comprare
la distribuzione Ultra Linux Super Oracle? Nessuno. E che fine fa il
mercato delle distribuzioni e dei servizi sull'OS? Nella tazza: usiamo
tutti Debian che funziona ed e' free. A me sta benissimo, purche' qualcuno
lo dica chiaramente.
Piuttosto installatemi la tarball e mettere i 50 patch che possono servire
(documentati!) in una directory separata: poi me li vado a scegliere io.
> sapere se tu hai per esempio una ATA 66 (o come accidenti si chiama) e
> quindi necessiti di una patch al kernel per farla funzionare.
Fammi capire: io ho bisogno di un patch anche per far funzionare ATA66,
ATA100 e tagged queuing? Pensavo che i controller IDE fossero abbastanza
comuni. Perche' questa roba e' fuori dal kernel standard?
# dmesg | grep ad0
ad0: 9770MB <Maxtor 91021U2> [19852/16/63] at ata0-master UDMA66
# sysctl -a | grep ata
hw.ata.ata_dma: 1
hw.ata.wc: 1
hw.ata.tags: 1
hw.ata.atapi_dma: 1
hw.atamodes: dma,dma,dma,dma,
> Quella e' una cosa che si fa comunque. Ripeto, non lamentarti delle cose
> inutili se non ti sta bene ricompilare il kernel.
Mi sta bene ricompilare il kernel: e' la prima cosa che si fa anche in
FreeBSD. Mi sta meno bene la caccia al patch e il configuration management
da strada.
> Spiegami perche' dovrei usare il kernel di RH invece di quello
> ufficiale, poi rifammi la stessa domanda.
Spiegami invece perche' il kernel ufficiale necessita di un patch per
ATA66. Perche' Linus usa SCSI? <G>
Non sei obbligato. Puoi compilare il tuo kernel, scrivere la tua procedura
di installazione, compilare i package che ti servono e realizzare la tua
piccola distribuzione custom. C'e' chi lo fa. Questo probabilmente ti
distogliera' per qualche mese dallo scopo principale, ovvero realizzare un
prodotto da _vendere_ basato su Linux, visto che il 50% del tempo ti
sparisce per mettere insieme i pezzi dai tarball. RPM e' bello perche'
gestisce le dipendenze, Slackware non va bene perche' non le gestisce, ma
qui siamo arrivati a dover comunque compilare le tarball. A questo punto
Slackware non e' poi tanto male come sembrava, visto che dopo la prima
installazione da CD si deve combattere a morsi per installare il software.
Se e' per quello la ports collection compila le tarball e mi fa specificare
quali opzioni usare: "make install -DWITH_GNOME -DWITH_MYSQL". Le
dependency le decido io, non chi fa il package binario.
Vallo a raccontare a rpm.
> Magari il kernel con le distribuzioni non c'entra niente?
Come no? E perche' allora viene fornito con il CD di installazione, e
installato, se non c'entra niente? D'oh.
> McFly me cojoni.. tu fai le cazzate e poi dai la colpa alla RH, troppo
> comodo.. A me in un tot di anni che uso RH non e' mai capitato un grammo
> dei guai che vai lamentando e nemmeno a tanti altri, come ti ho gia'
Tu *usi* redhat oppure *sviluppi* un prodotto basato su RedHat? Perche'
anch'io posso gestire un singolo sistema (2,3,4) a colpi di make, gcc e
tarball. Ben diverso e' realizzare un prodotto autonomo che si installa e
funziona. Se lavorare in Linux vuol dire solo fare il sistemista e
installare a mano i server...
> Non c'e' nulla da sistemare: prendi il tarball, 'make menuconfig' e
> ricompili, punto.
Se e' per questo posso anche copiare il .config da floppy con la mia
configurazione e fare direttamente il make.
Ah, ricordati di eseguire "lilo" altrimenti si dimentica di fare il boot.
Progeny ha la decenza di usare il grub e gestirselo. Io ho il boot loader
programmabile in forth. Pare proprio che RH sia l'ultima ruota del carro
nel campo "booting".
... finira' che copiero' il kernel dallo script del kickstart...
> non so se sia quello ufficiale o meno) il discorso non cambia di una
> virgola.
Mi pare ci fosse una utility che ricreava il .deb con il nuovo kernel dopo
averlo compilato: una cosa intelligente, al contrario di frugare nei
.src.rpm di redhat.
> Perche' no? E' sicuramente una cosa piu' intelligente che installare un
> RPM non adatto che va a fare casini ;-)
Ma a quel punto a che mi serve RPM? Se non lo tocco, certo che funziona.
>> b) scrivere il famoso "apt-get" per aggiornare automaticamente una Debian.
> L'operazione e' equivalente, con la differenza che la gestione delle
> dipendenze di Debian e' migliore.
Quindi con RedHat devo scegliere oculatamente i package uno ad uno, ma con
Debian posso buttarli dentro tutti. Leggi: non mi posso fidare di RedHat.
Allora non vale la pena di usarla.
Un solo Linux, una sola distribuzione?
> RH raccomandera' cazzate ma tu ne hai fatte anche molte per conto tuo e
Dimmene una. Fatta eccezione per aver scelto RedHat ovviamente. Se
controlli bene vedrai che le mie cazzate sono ben poche. Ma se io ti dico
"update ufficiale" e tu leggi "rpm rubato da mandrake" mi sa che non
finiamo piu'.
> A parte che non so cosa sia immagino tu non abbia nemmeno fatto lo
> sforzo di cercare se c'era una patch, vero?
Certo che esiste una patch. Basta andare in google. Una patch c'e' sempre,
magari in qualche server ftp in Uganda. Google e' il supporto di RedHat?
E via a compilare un'altra tarball. Saro' pedante ma in FreeBSD anche
questo e' di serie.
La man page di pppd non parla di CBCP, e mi permetterei di dire che se una
cosa non e' documentata, non esiste. Esiste un README.cbcp, ma non viene
installato da nessuna parte. E' nel tarball? Almeno nelle distribuzioni
commerciali ci dovrebbe essere. Altrimenti non mi vengano a spacciare
balle sul "corporate networking".
>> batch in ufficio e domani trovo tutto :-)
> Allora non lamentarti se non vuoi nemmeno capire come funziona.
Io ho capito come funziona, e per questo non ho voglia di perderci tempo :-)
> Se usi --force e --nodeps per forzare la rottura delle dipendenze la
> colpa e' anche tua, non solo di RPM.
Hai ragione. Infatti, perche' devo usare --force per installare un software
appositamente sviluppato per funzionare con quella distribuzione? Vedi bene
che qualcosa non torna.
>> In FreeBSD mi compilo Gnome dai sorgenti. Solo che lo fa la ports
>> collection senza farmi fare il download delle tarball a manina.
> Mah io Gnome su RH l'ho installato da RPM.. questione di manico?
Anch'io installavo Gnome da RPM. Pero' lo vorrei aggiornato prima che siano
trascorsi 3 mesi da una release. Un aggiornamento di sawfish _non_ puo'
richiedere _mesi_ di test. E' un semplice window manager. Ma come, si
aggiornano intere versioni di kernel come se fossero stracci e invece si
fanno i super test di compatibilita' con i window manager?
> Office e secondo perche' non mi interessa fare scripting su un Office e
> terzo perche' Open Office ha ancora da attendere per essere usabile, da
> quanto continuo a leggere in giro.
Le cose che oggi non interessano sono le cose per cui domani Microsoft
continuera' a far soldi. Il modello "a componenti", anche se implementato
in 5 o 6 tentativi piu' o meno felici, e' quello che rende possibile a Joe
Tardhead di sviluppare la sua piccola applicazione in Access stampando con
Word. Io non lo usero' e tu neanche, ma non si ottiene un 50% del mercato
desktop senza le aziende e i Joe Tardhead. Vogliamo uno share sul desktop
da prefisso telefonico?
Hai visto Rekall di thecompany? Ricorda molto Access :o)
>> nuovi port :-)
> Allora, chi ce l'ha piu' lungo? Cosi' chiudiamo questa stupida diatriba?
Conta il numero di package da una parte e dall'altra, poi conta il numero
di developer da una parte e dall'altra. A me va bene avere 500 port in meno
e non dover fare la caccia alle patch. Fra due mesi saranno arrivati i 500
port e tu sarai ancora su google a stanare le patch. Posso anche
sopravvivere senza l'editor che mi fa scrivere in aramaico, usando il
codice morse, pigiando la rotella del mouse col naso mentre scorreggio a
tempo di jazz.
Se trovo un software che mi serve, e che non e' gia' in FreeBSD, ce lo vado
a mettere io: magia del CVS. Non devo aspettare che la distribuzione di
turno "approvi" e "rilasci". I package non fanno parte dell'OS e seguono
un'altra strada.
>> "make" sulla macchina BSD. Da notare che StarOffice non e' disponibile in
> E quindi per questo motivo ti devi abbassare ad usare Linux, che
Io non mi "abbasso" a usare Linux. Avrei continuato felicemente ad usarlo,
se la qualita' di molte distribuzioni non fosse andata in fondo alla tazza
del cesso.
StarOffice funziona in FreeBSD in emulazione. FreeBSD legge e scrive ext2.
Non mi risulta che Linux emuli FreeBSD, al massimo legge UFS (2.2.x). "Ma
scrivere UFS non serve". Invece leggere il file system dei floppy di Amiga
serve molto.
Visto che cominciano a saltar fuori le grosse applicazioni closed source
per Linux, si potrebbe anche scegliere di mendicare un porting nativo su
FreeBSD, facendo petizioni come hanno fatto gli utenti Linux negli ultimi
anni.
Oppure si puo' eseguirle in emulazione.
# cat /compat/linux/etc/redhat-release
Red Hat Linux release 6.1 (Cartman)
E se l'emulazione e' una vergogna, perche' esiste Wine?
> peccato, eh? E meno male che c'e' Linux altrimenti ti saresti ritrovato
> a continuare ad usare Uord ed Eccelso..
Meno male che l'ex Star Division, struttura ampiamente commerciale, ha
sviluppato per Linux (e windows, e solaris, eccetera). Si e' visto che fine
hanno fatto: prima i download gratis, poi comprati da Sun per dare il suo
piccolo tributo all'open source (ma non di tasca propria).
Sbottonarsi su Java, quello mai. Posso scaricare una JVM per Linux, ma
tutte le estensioni interessanti sono per Solaris e Uindous. Dov'e' la JVM
full-GPL? Come si comporta Kaffe con Swing?
Potresti dire "meno male" se esistesse un Office degno di tale nome _nato_
sotto GPL. OpenOffice, la caramella di Sun, conta poco: hanno preso un
prodotto gia' sviluppato e lo hanno rilasciato in open source. Se io
divento ricco, compro Oracle e do' i sorgenti sotto GPL, non e' un merito
di Linux ne' dell'open source.
Vedremo Koffice. Si integrera' con OpenOffice o sara' la solita
guerricciola gnome/kde?
> avanza e non ho voglia di andare a correre dietro ad ogni nuovo prodotto
> che arriva: questi giochini li lascio alle mosche che usano le merde di
> m$.
Utenti = denaro. A te non serve MongolOffice, a me neanche, all'utente si'
e quindi deve esistere. Non sei tenuto ad usarlo anche tu. Altrimenti addio
user base: restiamo a fare i package di squid e a compilare i kernel.
>> Ad esempio, in FreeBSD, tutti i software che non sono "core".
> Puoi usare /opt su Linux, non mi pare cosi' complicato.
... ovvio: e' sufficiente compilare le tarball!! :-)
> Ogni idiota perso sara' una occasione in piu' per non vedere ulteriori
> stronzate alla Uindous nelle distribuzioni luser-oriented.
Ne basta una seria "server-oriented", le altre facciano pure gara a colpi
di icone e pupazzi. "One size fits all" non funziona per Windows e non
funzionera' per le distribuzioni Linux.
PS: ho installato la mia prima Progeny :)
eM'
>
> L'utilizzo del "software" GPL sotto BSD non e' in discussione, dato che
> chiunque puo' utilizzarlo. E' l'utilizzo di _sorgenti_ GPL che puo'
> portare problemi. GPL nasce per mantenere il software "libero" per forza,
> BSD per consentirne qualunque uso commerciale senza vincoli di rilascio
> dei sorgenti. Poi sta a te decidere quale liberta' preferisci. E' evidente
> che in un kernel BSD non ci possano essere parti GPL.
Beh, concordo in merito al kernel, ma io persavo al core, includendo le
applicazioni...
>
> "Effective immediately, licensees and distributors are no longer required to
> include the acknowledgement within advertising materials. Accordingly, the
> foregoing paragraph of those BSD Unix files containing it is hereby deleted
> in its entirety.".
Si faceva per dire... %-)
>
> E' sempre la stessa... ma se ogni package ne installa una, cominciano a
> diventare tante...
>
> $ locate COPYING | wc -l
> 75
Parbleu, forse in Debian sono anche di più (ogni pacchetto ha la sua, che
sia BSD, GPL o eco-diesel...)
>
> Garantisce anche che tu stesso non possa utilizzare le tue modifiche
> + parti GPL in un prodotto closed source, e trarne un vantaggio
> commerciale.
Se il prodotto di partenza non era mio, mi sembra giusto rispettare le
linee guida seguite dall'autore originale, senza sfruttarne il lavoro...
> In tal caso nessuno usera' il tuo prodotto con quella scheda di rete, ne'
> tu ne' nessun altro. Cio' che dici e' vero, ma e' altrettanto vero che
> non esistono 12 cloni commerciali di *BSD ognuno con il supporto per una
> scheda di rete proprietaria diversa. Allora, all'atto pratico, non
> funziona esattamente cosi'.
Di questo te ne devo dare atto, ma il fatto che non sia successo non vuol
dire che non possa succedere.
> Piuttosto, se tu devi realizzare un Embedded Bogotronic 2000, dove vai a
> prendere lo stack IP: da GPL o da BSD? Dipende da che cosa vuoi fare dei
> tuoi sorgenti. Almeno hai la possibilita' di scegliere.
Sono d'accordo. Se decido di mantenerli aperti, però, vorrei che questi lo
restassero, cosa che licenze BSD-style non garantiscono.
>
> Ah, ma linux e' uno solo. Sono le distribuzioni ad essere leggermente
> frammentate :-)
>
Nooo, non tanto }:->
> L'esatto contrario di redhat: mi pare un buon segno.
Oggi è uscita la nuova release stable (2.2r3) con gli aggiornamenti per
la sicurezza e qualche altro bugfix
--
Au revoir.
Lele...
Andrea Capriotti
>On Thu, 12 Apr 2001 02:40:47 +0200, Andrea Capriotti wrote:
>Se sto usando Debian, i package avranno ovviamente dei sorgenti (il tarball
>piu' la directory con i vari MD5, le liste dei file, eccetera). Io posso
>convertire un package binario da .deb a .rpm a .xyz, ammettendo che le
>librerie siano uguali da entrambe le parti, ma posso convertire un sorgente
>di .deb al .src.rpm corrispondente, con alien? Speriamo :-)
alien -g, --generate
Generate a temporary directory suitable for building a package from...
>Immagino allora che tu sia familiare con il resto. Fra parentesi, e' da
>notare che ormai il dibattito/confronto fra i sistemi operativi si basa
>quasi esclusivamente sulle licenze.
Ci sara' un motivo...
>Fase 1: ci si accontentava di chiedere specifiche e documentazione sui
>formati di file e sui protocolli, il closed source era una cosa ancora
>sopportabile purche' fatto bene. Il confronto poteva avvenire su temi piu'
>o meno tecnici.
IMHO il closed source e' un modello di sviluppo sbagliato.
Prima o poi i nodi vengono al pettine e la scelta verso un SW chiuso,
apparentemente vantaggiosa, si dimostra per l'impresa un errore
strategico.
>Fase 2: open source a manetta, quello che non e' open source e' spazzatura.
>Da quello che ho visto, una buona percentuale di spazzatura effettivamente
>c'e', ma qualcosa ancora si puo' salvare, no?
Visto che il progetto GNU vuole creare un sistema _completamente libero_
non vedo a cosa possa servire il software proprietario.
>Fase 3: GPL o morte, tutte le altre licenze (anche se benevolmente
>approvate dalla self-appointed "Open Source Foundation") non vanno bene,
>sono "sbagliate" e tradiscono "la grande comunita' degli hacker". Come se
>chi sviluppa software con licenza BSD fosse, in fondo, un sicario di Bill
>Gates. Amen! Sia lodata la pistola di Raymond! :o)
Per fortuna non tutti vogliono lavorare ad un progetto con il rischio
che venga reso proprietario.
>Le varie petizioni e richieste di specifiche portano sempre la motivazione
>"serve per supportare Linux", ben sapendo che esistono parecchi altri
>sistemi operativi oltre il Pinguino. Agli occhi del pubblico, "open source"
Dalla FSF, al massimo, puoi aver sentito appelli per supportare il
software libero, non solo una sua piccola parte (Linux).
>l'utilita' neanche sforzandomi. E a pensarci bene, la licenza BSD e' molto
>piu' "free" della GPL. Se io aggiungo 1.000.000 di righe a un progetto GPL
No. La liberta' implica la tutela dei diritti dell'autore.
BSD ignora completamente questo fattore.
>E' abbastanza deprimente :-)
Confermo. Non pensavo che ci fossero sostenitori di BSD che ancora non
hanno capito la GPL... :)
Saluti
--
Andrea Capriotti
Andrea Capriotti
>>>invece devo distribuire in un unico kernel GPL il mio codice (non GPL), ad
>>>esempio in un prodotto embedded?
>> Lo scopo della GPL e` proprio rendere impossibili queste cose.
>
>Infatti. Ed e' per questo che riscrivono alcune cose sotto licenza BSD,
>mica per divertimento o per sport :)
Per quale motivo un programmatore che puo' sviluppare un prodotto GPL
dovrebbe riscriverlo con licenza BSD?
In questo modo non rischia che il suo lavoro venga "usato" da qualche
altra software house senza che lui ne abbia nulla in cambio?
Saluti
--
Andrea Capriotti
Jimmy Olgeni
> tenerti un kernel con PCMCIA ed altre cose inutili salvo poi lamentarti
> del kernel pieno di inutilita' !!
A parte il fatto che ora me le installo tutte con mke2fs, tar, cpio, pax e
un colpo di zip, alla faccia di RPM e delle sue dependency un po'...
.
.
.
gnucche! :o)
Andrea Capriotti
>Conta il numero di package da una parte e dall'altra, poi conta il numero
>di developer da una parte e dall'altra. A me va bene avere 500 port in meno
>e non dover fare la caccia alle patch. Fra due mesi saranno arrivati i 500
>port e tu sarai ancora su google a stanare le patch. Posso anche
GNUBSD... <G>
Saluti
--
Andrea Capriotti
Marco d'Itri
>Fammi capire: io ho bisogno di un patch anche per far funzionare ATA66,
>ATA100 e tagged queuing? Pensavo che i controller IDE fossero abbastanza
>comuni. Perche' questa roba e' fuori dal kernel standard?
Perche` quando sono usciti i kernel 2.2 queste cose non le avevano
ancora inventate e Linus ritiene poco pulito il backporting del driver
dal 2.4.
>Mi pare ci fosse una utility che ricreava il .deb con il nuovo kernel dopo
>averlo compilato: una cosa intelligente, al contrario di frugare nei
make-kpkg.
>La man page di pppd non parla di CBCP, e mi permetterei di dire che se una
>cosa non e' documentata, non esiste. Esiste un README.cbcp, ma non viene
>installato da nessuna parte. E' nel tarball? Almeno nelle distribuzioni
Boh, debian lo ha nel solito posto... :-)
>Se trovo un software che mi serve, e che non e' gia' in FreeBSD, ce lo vado
>a mettere io: magia del CVS. Non devo aspettare che la distribuzione di
Lo faccio anche io con debian...
>Non mi risulta che Linux emuli FreeBSD, al massimo legge UFS (2.2.x). "Ma
E a che servirebbe? :-)
Comunque, sei sicuro che gli eseguibili di FreeBSD non funzionino in
iBCS?