Newsgroup: it.comp.os.dibattiti
Titolo: linux e freebsd

Ciao a tutti, e' un po' che seguo il NG
e ho notato che qualcuno oltre a utilizzare i classici windoss
e linux, utilizza freeBSD.
ma di cosa si tratta esattamente?? Ho letto qualcosa sul
sito, ma non mi sembra molto diverso da linux (non picchiatemi).
quali sono le differenze fondamentali??
ad esempio la licensa che regola la distribuzione,
in cosa differisce??
la compatibilita' con l'HW e' lo stesso??
..e la stabilita' del sistema e delle applicazioni??
linux e' una sorta di paradiso del programmatore...
e freeBSD??
ciao e grazie
diego
-- 
...e che vuoi di piu' dalla vita??

 quali sono le differenze fondamentali??
Fondamentalmente lo sviluppo Linux è decentralizzato mentre quello di BSD è
centralizzato.
Ci sono dei pro e dei contro.
La larga diffusione di Linux e la nomea di sistema robusto per BSD sono gli
effetti più percepibili.
Ciao.
Marco Spedaletti

 quali sono le differenze fondamentali??
...
Ciao,
i kernel *BSD derivano dal kernel Unix (quello con la U maiuscola) in
pratica mentre linux è stato scritto da zero freeBSD è un'evoluzione dello
Unix originale.
Motivi storici a parte pare che i BSD siano più stabili, poi ci sono le
differenti licenze con le loro guerre di religione...
A mio parere i BSD sono rimasti un po' indietro come tools di configurazione
e come facilità d'uso rispetto a linux (ma troverai chi ti dirà che il bello
sta proprio lì :-) ) questo può anche migliorarne la robustezza, ma non so
se il gioco vale la candela.
Saluti.
--
~°~°~°~°~°~°~°~°~°~°~°~°~°~°~°~
<<Medaglia, medaglia, medaglia....>>
Muttley (ICQ:  63051387)
~°~°~°~°~°~°~°~°~°~°~°~°~°~°~°~

diego

 lo modifichi, devi rilasciarlo come GPL. La licenza BSD dice che se
Questo lo dice la LGPL. :)

 sta proprio lì :-) ) questo può anche migliorarne la robustezza, ma non so
No, io dico proprio che trovo FreeBSD più facile da configurare di linux.
Pensa alla ricompilazione del kernel sotto linux o sotto FreeBSD, pensa
all'installazione del sw, ecc...
Ciao.

 all'installazione del sw, ecc...
Più pratica "urpmi nomepacchetto.rpm" in mandrake o della gestione pacchetti
di debian?
Io preferisco linux, ma in fondo è solo questione di gusti. :-)
ciao,


 riferisci ...
mi pareva fosse vecchia la deifnizione per distinguoere tra Linux e
distribuzione. Linux e' solo un kernel mi pare ... anzi, non mi pare: e'
cosi.
-- 
Massimiliano Adamo
ufficio CED - Reno de' Medici S.p.A.
Tel. +39 02 75288 447
FAX  +39 02 75288 432

 dipendenze e' una croce e' un altro, se mi parli di Debian e' un altro.
La Debian non l'ho mai utilizzata, ed in effetti mi hanno parlato molto
bene di apt-get, io mi riferivo a quella porcheria di RPM che ho avuto
la sfortuna di utilizzare per un certo periodo. 
Ciao.

 Io preferisco linux, ma in fondo è solo questione di gusti. :-)
Certamente, e per i miei gusti linux non esiste proprio...
Ciao.



Pň esse, dopotutto stavo andando a memoria. Ma la LGPL non č quella
che dice "puoi ficcarlo dove ti pare, compresi i software commerciali,
basta che se lo modifichi lo rilasci sotto LGPL", e la BSD "puoi
modificarlo o no, ma qualunque cosa tu faccia basta dichiari di averlo
usato " (libera traduzione dal legalese)?
=========================
Chi si accontenta gode,
ma chi gode si accontenta
molto di piů

 apt e' tutta un'altra cosa,  credimi.
Lo so, è parecchio che vorrei provare la Debian, ma visto che con FreeBSD
mi trovo alla perfezione (e non solo per i ports...), non ho avuto ancora
tempo di farlo...
Ciao.

 giudizi.
Non sono solo i ports e/o apt ad essere fondamentali... Comunque è molto che 
vorrei provare la Debian, ma non ne ho il tempo...
Ciao.

 cosi.
 
Si, č sicuramente cosě.
Perň se il problema di Massimiliano sono gli RPM il kernel non c'entra.
Ciao,
	Nicholas

 X con FreeBSD faccio semplicemente portinstall kde. E basta.
insomma una specie di setup.exe, poi invio, invio, invio, e alla fine ti
chiede anche di "riavviare il sistema per rendere effettive le modifiche"
:)
Sulla maggior parte dei sistemi Unix (o replacement) che io conosco e'
necessario soddisfare (ahime' manualmente) le dipendenze tra i pacchetti:
non riesco ad installare la bash su Aix perche mi chiede
bos.rte.libc.4.3.xxxx Purtroppo e' cosi', ma per fortuna funziona sempre
bene ... senza contare il fatto che senza SMIT il sistema di pacchetti di
Aix sarebbe davvero assurdo da gestire.
Poi ci sono anche dei software, piu' o meni universali (come red-carpet
per esempio) che ti semplificano la vita abbastanza.


 Con RPM?
Boh.
Con apt: apt-get install kde.
Ciao,
	Nicholas

credimi.
Sante parole! se mi scrivi anche un driver per il mio modem cesso USB
ADSL torno a Debian di corsa :-)
funziona bene apt sotto MDK?
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
" ride or die "

Più pratica "urpmi nomepacchetto.rpm" in mandrake
Sarà ma dopo 1 anno di debian io ancora non mi trovo
con sto urpmi


 per esempio) che ti semplificano la vita abbastanza.
Bella porcheria... RedCarpet, intendo...
Ciao.

 Con apt: apt-get install kde.
Bene, da questo punto di vista apt ed i ports si equivalgono. Sarei cursioso
di conoscere da chi ha utilizzato entrambi le differenze ed i punti di forza
dei due sistemi.
Ciao.

 portinstall kde. E basta. Con RPM?
urpmi kde-base
:P
(anche se non so per cercare anche "tutto il resto" di KDE cosa bisogni
fare, non ho mai avuto voglia di studiare approfonditamente)

 chiede anche di "riavviare il sistema per rendere effettive le modifiche"
Amen.

 per esempio) che ti semplificano la vita abbastanza.
Purtroppo la logica di funzionamento di Red Carpet può molto facilmente
peggiorarla più che migliorarla (vedi "come NON si fa un upgrade di
pacchetti multipli su un sistema RPM"... sigh)

:P
Un'evoluzione, finalmente, anche se si tratta di un tool e non del
funzionamento del sistema... 
Curiosità, come viene mantenuto/aggiornato il database dei pacchetti?
Ovvero, chi/cosa/come/quando dice ad urpmi quali pacchetti installare e da
dove scaricarli?
Ciao.

 dove scaricarli?
URPMI in pratica è composto da diversi script (credo tutti in Perl e
Python):
urpmi		
	scarica e installa i programmi
urpmi.addmedia
urpmi.removemedia 
	aggiungono o tolgono delle "fonti" a scelta dell'utente, è anche
possibile attivare/disattivare fonti senza toglierle dalla lista, di
default ci sono i CD di installazione e la lista dei mirror per i security
update
urpmi.update
	serve ad aggiornare la lista dei package disponibili presso le fonti
inserite dall'utente. Non è necessario usarlo per i normali update, il
tool che se ne occupa scarica la lista aggiornata quando viene lanciato.
Io lo uso per tenermi aggiornato rispetto alla Cooker (unstable) presente
su un FTP ceco (de facto ufficiale anche se non tutti i pacchetti sono
"firmati") che ha una lista di 21 MB, ma la lista per gli update comuni è
molto più piccola.
Ovviamente se vede che la lista non è stata aggiornata non si riscarica
tutto (e per fortuna).
Diciamo che per chi usa solo MandrakeUpdate (ovvero un'interfaccia grafica
con un paio di preset per gli update normali) non c'è da lanciare niente
che non sia il MU stesso.

 fare, non ho mai avuto voglia di studiare approfonditamente)
<flame>
Per KDE quel comando è già troppo: appare almeno un warning tipo 'step
on the right foot' o 'there's no place like gnome' ? Su Debian si,
giuro!
</flame>

 - Roberto :

Un piccolo hint:
Replacing available packages info, using /var/cache/apt/available.
Information about 11357 package(s) was updated.
:p
Ciao,
	Nicholas

funzioni discretamente bene e che apt4rpm sia pari pari apt.
Boh proverò...


 Information about 11357 package(s) was updated.
nicholas
nicholas-bluff
nicholas-devel
nicholas-doc
nicholas-lib
nicholas-man
nicholas-misc
nicholas-stuff
Gia' che ci sei, dicci anche come si fa un CD di installazione con
450 a scelta tra questi package...?

Aix sarebbe davvero assurdo da gestire.
Se usi AIX suppongo tu conosca gli aix toolbox for unix:
http://www-1.ibm.com/servers/aix/products/aixos/linux/altlic.html
C'e RPM per aix con cui puoi installare tutta una serie di tools:
http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html
Fra cui bash, gnome, kde, samba e tanto altro.
Le librerie che occorro ai vari package sono comprese nei tools
disponibili.
Ottimi per rendere aix un poco piu' umano a chi, come me, e' piu'
abituato a linux.
Ciao
Francesco
-- 
Francesco

 450 a scelta tra questi package...?
Description: Progeny Debian auto-installation system
 The basic model is that of cloning an existing system; after installing
 and configuring a Debian system to taste, the configuration is
 "dumped"
 to the configuration files, along with some extra information.
 
 It currently supports flexible constraints for partitioning
 differently-sized disks in a logical fashion, hardware
 auto-configuration with discover (including configuration of X,
 if appropriate), network.       

 manina uno per uno (a volte possono essere tanti)?
La risposta è si se il pacchetto dipendente dipende *esattamente* dal
pacchetto che hai cancellato, altrimenti:
nicholas@ilweran:~$ apt-cache show deborphan
<...>
Description: Find orphaned libraries.
 deborphan finds "orphaned" packages on your system.
 It determines which packages have no other packages
 depending on their installation, and shows you a list of
 these packages. It is most useful when finding libraries,
 but it can be used on packages in all sections.
Generalmente ti posso consigliare di apt-gettare piuttosto che
dselectare :p Anche se mi dicono che aptitude sia migliore di dselect...
Ciao,
	Nicholas



 Fallo !
Wuf!

 senza neppure X con FreeBSD faccio semplicemente portinstall kde. E basta.
Se la macchina e' pulita portinstall non c'e' :)

 giudizi.
Aspettiamo ancora il tuo reportage su FreeBSD.

  The basic model is that of cloning an existing system; after installing
Figatona! Un'altra delle innovazioni che mi sarebbero servite qualche
anno fa. Fortunatamente il progresso avanza e la defunta Progeny
ci ha lasciato una piccola eredita' (non vedo pero' perche' dovrei
fare il "cloning" di un sistema invece di scrivere 4 file di
configurazione).

 - Pogoboy :

Non l'ho mai fatto, ho solo cercato installation con apt-cache search :p
Sicuramente c'è un modo migliore.
Ciao,
	Nicholas

 	serve ad aggiornare la lista dei package disponibili presso le fonti
[cut]
Ok, mi pare sia un buon meccanismo. Almeno uno dei "problemi" l'hanno quindi
risolto...
Ciao

 portinstall kde. E basta. Con RPM?
Lo installi allo stesso modo. Quelli che ti dicono che e' una porcheria,
semplicemente non lo sanno usare.
ciao
-- 
Marco Ermini
http://macchi.markoer.net
 - ICQ UIN 50825709 - GPG KEY 0x64ABF7C6
Never attribute to malice that which is adequately explained
by stupidity. (Hanlon's Razor, corollary to Finagle's law)

 Bella porcheria... RedCarpet, intendo...
[...]
Mah... perche' poi sarebbe una porcheria? io lo trovo efficace. Peccato
che per usarlo bene praticamente devi pagare. Non trovo nemmeno male
l'up2date di RedHat.


 portinstall kde. E basta. Con RPM?
up2date kde-base
con RedHat


 semplicemente non lo sanno usare.
No, l'ho sperimentato sulla mia pelle, ed *è* una porcheria. Ti scordi 
delle dipendenze da installare *manualmente*?
Ovviamente sto parlando di RPM nudo e crudo, perché con urpmi, ecc... 
le cose sono ben diverse...
Ciao.

 l'up2date di RedHat.
Perché l'ho provato...
Ciao.

 con RedHat
Come ho gią detto io parlo di RPM nudo e crudo, non di tool vari...
Ciao.

 Come ho già detto io parlo di RPM nudo e crudo, non di tool vari...
Tra l'altro quando è uscito sto up2date?
Ciao.

 RPM nudo e crudo, perché con urpmi, ecc... le cose sono ben diverse...
E allora? significa solo che il tool e' piu' "atomico", in perfetta
filosofia Unix, e quindi e' piu' flessibile. Puoi usare un sacco di cose
con RPM, il citato urpmi, up2date, apt4rpm, gnome-rpm ecc.
Io ho sempre trovata molto valida la gestione di dipendenze di RPM, e
sicuramente come strumento e' molto piu' raffinato e complesso sia di apt,
che della gestione dei port di FreeBSD. Solo che bisogna saperlo
utilizzare, non basta "averlo provato".
Io per esempio mi trovo abbastanza bene, in genere mi scarico il pacchetto
sorgente e modifico lo .spec se ho particolari esigenze (es cambiare le
dipendenze adattandole alle *mie* necessita', cosa che con altri tool non
puoi fare molto bene, proprio perche' la gestione delle dipendenze e'
*troppo* automatizzata).
Se a qualcuno interessano, tengo alcuni dei miei pacchetti personalizzati
qui:
http://macchi.markoer.net/works/index.php?_browse=RPMS


 Marco Ermini wrote:

Checcivoifa'? de gustibus! ;-)


 Come ho già detto io parlo di RPM nudo e crudo, non di tool vari...
Ripeto, il fatto che RPM sia piu' "a granularita' piu' fine" rispetto, per
esempio, ad apt, non mi sembra un problema ma un vantaggio in
flessibilita'. RPM gestisce i pacchetti, e' questo il suo lavoro e non
pretende di fare altro: questa e' la perfetta filosofia Unix dei tool
semplici ma combinabili fra loro. Poi, *sopra* RPM ci puoi costruire
quello che ti pare, e quindi ogni distro fornisce il suo software di
aggiornamento.
Pero' dire, per esempio, che "apt4rpm rende decente l'RPM" significa avere
scarsa esperienza di RPM, e piu' cha altro significa assecondare dei
pregiudizi diffusi - ovviamente e' solo la mia opinione...


 Roberto wrote:

C'e' dalla RedHat 7.0... quindi un bel po' di tempo fa.


 utilizzare, non basta "averlo provato".
Qui però dimostri posa esperienza tu: i .deb vengono gestiti da dpkg,
non da apt. Apt è un tool, esattamente come up2date, basato
completamente su dpkg e costruito su dpkg, su cui sono stati costruiti
ulteriori tool, da tasksel a dselect a aptitude. 
Si parla sempre di apt perchè è il tool su cui è costruito il sistema di
packaging di Debian, ma se si vuole lavorare 'di fino' come fai tu con
RPM si usa dpkg.
Ciao,
	Nicholas

 C'e' dalla RedHat 7.0... quindi un bel po' di tempo fa.
Uhm... Con che versione c'è stato il passaggio da RPM 3 a 4?
Se non mi ricordo male la versione che ho avuto la sfortuna di utilizzare
era le 6.qualcosa. Quindi niente up2date. E tra l'altro la 6.x funzionava 
ancora decentemente, perché a detta di molti la versione 7 era 
super-ultra-bacata...
Ciao.

 *troppo* automatizzata).
Bene, questo conferma che non hai utilizzato i ports...
Ciao.

 ad attingere ad "unstable"...
Non uso Debian, e comunque quel "niente di cosě terribile" mi fa perdere
tempo. Sai, vorrei tornare a casa in orario, la sera...
Ciao.

 credimi.
Premetto che non conosco Debian... 
cosa ha in piu' apt?

 (leggi *non* tool "esterni" e/o sviluppati dopo)
Cosa vuol dire «tool "esterni" e/o sviluppati dopo»?
Pensavo che il problema fosse il fatto che le cose funzionino.

 Pensavo che il problema fosse il fatto che le cose funzionino.
Semplice, che il fatto che siano richiesti tool che "modifichino"
notevolmente il funzionamento di un sistema è indice che alla base 
ci sia qualcosa che non va...
Ciao.

 ci sia qualcosa che non va...
Veramente non modificano un bel niente.
(e non si vede perchè un tool di installazione per i probrammi dovrebbero
essere nella "struttura base" del sistema operativo)

 essere nella "struttura base" del sistema operativo)
Per evitare quello che succede sotto windows, dove ogni programma di 
installazione fa ciň che vuole, con i risultati che tutti conosciamo?
Ciao.

 quella che hai di qualche pacchetto.
Sei troppo divertente :o)

 - Roberto :

Può essere, non è questo il caso, dato che il 'tool' non modifica
*affatto* il funzionamento del sistema, ma automatizza dei passaggi che
dovrebbero essere fatti a mano. Gli RPM sono sempre gli stessi.

 quella che hai di qualche pacchetto.
Io correggerei:
"Nessuno e' mai costretto ad attingere ad unstable a meno che non sei *tu* 
ad avere bisogno di una versione piu' recente rispetto a quella che hai di 
qualche pacchetto"

Roberto wrote:
 > Per evitare quello che succede sotto windows, dove ogni programma di
 > installazione fa ciò che vuole, con i risultati che tutti conosciamo?
Perché, sotto linux i programmi di installazione non fanno quello che
vogliono? Anzi, c'è qualche sistema dove i programmi di installazione
non fanno quello che vogliono?
Sorge spontanea una domanda: sai che i prorammi di installazione sono
dei semplici... programmi?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 gestione delle dipendenze ha sempre fatto pena.
Questo tuo giudizio, un po' affettato, andrebbe per lo meno giustificato.
Non capisco perche' "farebbe pena" la gestione delle dipendenze. Sai farmi
qualche esempio concreto? cioe', hai creato degli RPM ed hai visto che la
gestione delle dipendenze faceva pena?
A me, detto fra noi, sembra assai poco diversa... piu' che altro mi
sembrano molto e soprattutto "ideologici" i giudizi, che a volte sembrano
dettati da pregiudizi e da un certo "conformismo" che regna nell'ambiente
Linux - non sei d'accordo con me?
E poi, paragonare "RPM nudo e crudo" ad apt e' come paragonare un Fiat
Ducato vuoto ad un Centro Mobile di rianimazione: la stessa struttura, ma
c'e' un po' di trasformazione e qualche decina di milioni di
apparecchiature di differenza.


 super-ultra-bacata...
Il solito conformismo... tutte sciocchezze. C'era stata una questione su
gcc, ma alla fine aveva ragione la RedHat... invece, incredibilmente, la
7.0 e la 8.0 per la prima volta paiono delle puntozero quasi decenti...
(io ho avuto problemi con ext3 sull'ultimo kernel dell'8.0 - ci sono
stati gia' due aggiornamenti sul kernel... Dopo circa 50 ore mi crashava
Linux ed andava in core dump - pero' i tasti SysReq erano utilizzabili e
potevo fare il sync su ext3 - alla faccia di chi dice che ext3 non
gestisce gli errori - e quindi non ho perso nulla. Ho risolto
ricompilando da solo il kernel e adesso con 2.4.20-pre11 non ho piu'
problemi da un po').


 qualche pacchetto.
Per avere Apache 2.0 (che non mi sembra proprio una cosi' incredibile
novita'... o che sia un'esigenza cosi' fuori dal mondo...) devono
attingere ad unstable, e non e' stato semplice far funzionare certe cose.
Potrei fare altri esempi, ma questo direi che e' abbastanza "clamoroso".
Insomma, nulla di cosi' fantascientifico. Secondo me la scelta della
distro e' dettata molto dall'abitudine o da convenienze particolari. Io
non ho difficolta' ad ammettere che sono *abituato* alla RedHat, ma ho
lavorato anche con altre distro senza grandi drammi. Non sono di quelli
che dice che usare una distro piuttosto che un'altra e' un grande
problema...
Secondo me sono solo le persone piu' *ottuse* ed "ideologiche" che fanno
tanti drammi sulle distro, non credi? se sai lavorare con Linux, lavori
egualmente bene (piu' o meno) con tutte le distro... no?
Poi, ovviamente, e' solo la mia opinione "5 cent worth".


 dovrebbero essere fatti a mano. Gli RPM sono sempre gli stessi.
E ti sembra poco? Anche portupdate è un utility "esterna", ma i ports
gestiscono da soli l'installazione delle dipendenze.
Scrivere portupgrade kde è la stessa cosa che scrivere
cd /usr/ports/x11/kde3 && make install clean, nulla di più.
Ciao.

 dei semplici... programmi?
Ma dai? Pensa che credevo fossero farfalle...
Ciao.

 7.0 e la 8.0 per la prima volta paiono delle puntozero quasi decenti...
Allora sarò conformista, ma almeno non ho problemi.
Sai com'è, io faccio un lavoro che mi piace molto, e pure l'ambiente
in cui lavoro è ottimo, però a casa ho una moglie e tre splendide 
figlie che mi aspettano... il mio tempo preferisco passarlo con loro che a
lavorare...
Ciao.

 mio tempo preferisco passarlo con loro che a lavorare...
Non ho capito, perche' secondo te io alla mia ora non esco? :-) ho anche
io una fidanzata... e non ho capito perche' ci dovrei mettere di piu'
solo perche' ho RedHat. Al limite, posso capire che tu mi dica "conosco
meno RedHat e quindi non la uso perche' perderei tempo ad impararla".
Come diceva Hobbes, perche' imparare cose nuove, se l'ignoranza e'
istantanea? ;-)


 meno RedHat e quindi non la uso perche' perderei tempo ad impararla".
Nel periodo che l'ho utilizzata ho *dovuto* imparare ad utilizzarla
Tutto nasce dal fatto che con linux + RPM (la distribuzione non č
importante) ho perso inutilmente del tempo. E non considero perso il tempo
impiegato ad imparare ad utilizzarla, ma quello impiegato ad utilizzarla.
Ciao.

  attingere ad unstable, e non e' stato semplice far funzionare certe cose.
Licenziateli, e` in testing da un pezzo
Ciao, Andrea
-- 
          (o_  |  Andrea Carosi, just another Linux user ( #210218 )
(o_  (o_  //\  |------------------------------------------------------
(/)_ (/)_ V_/_ |         GnuPG ElG/DSA 2048/1024 key available
ID: 0x1D1CE569 - Fingerprint: DB849F4C79E33F0FAFF9DC0B01B17CDA1D1CE569

  gcc, ma alla fine aveva ragione la RedHat...
Ogni tanto girando per la rete, trovo dei software interessanti e leggo 
"do not compile with gcc 2.96 shipped with Red Hat", chiaramente sono 
gli sviluppatori di tali pacchetti che sono degli incompetenti, si
ostinano a scrivere codice non RH-compliant...


 Sicuramente c'è un modo migliore.
Quando lo trovi, e lo provi, fatti risentire :)

 semplicemente non lo sanno usare.
O forse stanno cercando di lavorarci.

 *troppo* automatizzata).
Ah beh, nei ports usare un "make -DWITH_ODBC" e' certamente piu'
scomodo di fare un paio di file .spec e tenerli aggiornati rispetto
alle macro che ti rifila RH ad ogni versione (vedi RPM3 -> RPM4).

 urpmi scopiazzando da apt di Debian che e' il migliore in assoluto e non
Certo, e' tutto copiato. Chissa' poi quanti modi di fare "thorin-install
kde" esistono...

 gestisce gli errori - e quindi non ho perso nulla. Ho risolto
Ce ne fosse uno che ha capito di quali errori si sta parlando.

 cd /usr/ports/x11/kde3 && make install clean, nulla di più.
Con la differenza che portupgrade ti direbbe "** No such package
'kde3' is installed." :)

 trovarmi a dover affrontare dipendenze circolari (installo a.rpm e dice
Che caso curioso. Thorin smette di usare RH -> Thorin ci parla dei
problemi di RH. Thorin passera' a Gentoo -> Thorin ci raccontera'
dei suoi problemi con Debian...

     stronzate con apt non succedono.
Scusa, questo l'ho visto ora... cioe', secondo te
# rpm -i a.rpm b.rpm
sarebbe un workaround? no perche' io lo trovo un utilizzo normale di
RPM...
Non capisco proprio perche' questo tuo esempio dimostrerebbe che RPM e'
una "stronzata" (e vai, che piano piano scopriamo dove stanno le
lacune...).
Se due pacchetti si richiedono l'un l'altro, ci sara' un perche'. Mettiamo
anche che sia una "stronzata", ma non vedo dove sia il problema: li
installi insieme, e bon! apt e' un tool che va "sopra" i vari dpkg-*, se
usi dpkg-add sei allo stesso livello di RPM, esattamente come se usi un
tool che va "sopra" RPM sei allo stesso livello di apt. Quindi non
paragonare due cose diverse.
Personalmente, preferisco fare a mano # rpm -Uvh a.rpm b.rpm e controllare
da solo quello che viene richiesto; se mi viene richiesto un pacchetto che
non voglio installare per dipendenze stupide, semplicemente mi prendo il
pacchetto sorgente e lo ricompilo (e' un solo comando...) e risolvo il
problema.
Le dipendenze *apparentemente* "stupide" ci sono (e ci sono state e ci
sono anche quelle *veramente* stupide, ok! ;-) e ci sono anche su Debian
(ad esempio, io non voglio avere TeX su un sistema ma per installare un
certo pacchetto e' richiesto per creare la documentazione...) come ci sono
su molte altre distro.
Con RPM hai tutti gli strumenti per eliminarle ed e' anche molto semplice
e veloce, basta sapere dove mettere le mani ed avere un minimo di
esperienza. Certo, c'e' chi si aspetta miracoli da uno stupido software di
gestione pacchetti... se non ti piace RPM non lo usi, ma non sparare a
zero su chi lo fa: personalmente mi sento offeso e mi pare giudicato
superficialmente un ottimo strumento.
(nota anche, che dalla 4.x alla 8.0 sia la RedHat che RPM *ne hanno
fatta*, di strada...)


 utilizzarla.
Sei sicuro di aver imparato bene? no perche', alla fine, questa
affermazione e' davvero ideologica... se sai usare rpm, come se sai usare
apt, alla fine sempre un Linux ottieni... francamente, non vedo grosse
differenze tra usare RedHat e Debian, se sai usarli ciascuno come si deve.
(In genere, la vera qualita' di uno strumento la si vede nel massiccio uso
professionale: questo accade in tutti i campi delle attivita' umane... e
chissa' perche' i piu' grossi ISP del mondo, tipo Rackspace, Hurricane
Electrics, Interland, Dialtone ecc., che installano server a decine ogni
giorno, utilizzano RedHat e non Debian... queste cose i sostenitori di
Debian non le spiegano molto bene in genere! ;-)


 il file sshd.config, tutto commentato, bella robbba, proprio bella...
Beh non sai che e' vietato lamentarti delle installazioni di default? mi
pare ci sia una legge di Murphy in proposito ;-)... e d'altronde, non hai
scelto "server"... che vuoi allora? ;-)
E poi, se ti installa troppa roba, ettulla levi, no?


 che ti rifila RH ad ogni versione (vedi RPM3 -> RPM4).
Perche' rifare? e perche' un paio?


 On Sun, 17 Nov 2002 18:32:44 -0500, Marco Ermini wrote:

E quindi spiegamelo tu? perche' io si vede che non l'ho capito!...
Io so solo che ext3 "crashava", mandando il kernel in core dump...


 ostinano a scrivere codice non RH-compliant...
No, scrivono codice *non standard C++ compliant*, come era il gcc
pre-redhat 7.0.


Roberto wrote:
 > Fabio Alemagna wrote:
 >
 >>Perché, sotto linux i programmi di installazione non fanno quello che
 >>vogliono? Anzi, c'è qualche sistema dove i programmi di installazione
 >>non fanno quello che vogliono?
 >
 > Sai com'è, se di programma di installazione ce n'è più di uno...
E tutti fanno quello che vogliono. O mi sbaglio?
 >>Sorge spontanea una domanda: sai che i prorammi di installazione sono
 >>dei semplici... programmi?
 >
 > Ma dai? Pensa che credevo fossero farfalle...
Sai com'è, da come parli sembra quasi che il sistema operativo faccia
differenza tra "programmi di installazione" e "programmi", e non
consenta ai primi di fare le stesse cose che fanno i secondi.
Assodato che convieni con me che tale differenzazione non esiste,
assodato che fare una tale differenziazione è impossibile, rimane la
domanda: di che stai parlando, allora?


 E tutti fanno quello che vogliono. O mi sbaglio?
Intendo, anche sotto linux posso avere tanti programmi di installazione 
quanti ne voglio, e tutti fanno quello che vogliono.


 'kde3' is installed." :)
Ooppss!! Era portinstall...
Ciao.

 differenze tra usare RedHat e Debian, se sai usarli ciascuno come si deve.
Ho imparato quell che mi serviva, per il resto c'è sempre man...
Comunque, se ti fosse sfuggito io non uso Debian, non uso proprio linux...
Ciao.

 domanda: di che stai parlando, allora?
Del fatto cha avere *un* sistema di installazione che *funzioni* (ed uno
nativo del SO ha ben più probabilità di funzionare) o due che siano
coerenti (e sistemi nativi del SO hanno ben più probabilità di essere
coerenti), ti dà la possibilità di *non* avere problemi derivanti da 
scelte diverse di sistemi diversi.
E per sistemi "nativi" non intendo nulla di più di semplici programmi, 
sviluppati però nel contesto del SO stesso e non tool di terze parti o
sviluppati in seguito per "tappare i buchi".
Ciao.

 quanti ne voglio, e tutti fanno quello che vogliono.
Appunto, ottima ragion per utilizzarne uno o due che funzionino e siano
coerenti.
Ciao.

 Del fatto cha avere *un* sistema di installazione che *funzioni* 
Windows l'ha il suo bel sistama di installazione bello e pronto, sta a 
chi fa i programmi usarlo.



Cosa che a windows non è preclusa, mi pare...


> Se usi AIX suppongo tu conosca gli aix toolbox for unix:
Certo che lo so.
Volevo fare un appunto su come vengono gestite le dipendenze nei vari
Unix.
p.s.: un grazie (molto, molto in ritardo) per avermi consigliato il
tightvnc, che adesso e' felicemente in produzione su centinaia di
computer :)
-- 
Massimiliano Adamo
ufficio CED - Reno de' Medici S.p.A.
Tel. +39 02 75288 447
FAX  +39 02 75288 432

 tempo di farlo...
Ti capisco, quando uno si trova bene con un SO perchè cambiare? :-)
Saluti,
--
~°~°~°~°~°~°~°~°~°~°~°~°~°~°~°~
<<Medaglia, medaglia, medaglia....>>
Muttley (ICQ:  63051387)
~°~°~°~°~°~°~°~°~°~°~°~°~°~°~°~

 dipendenze e' una croce e' un altro, se mi parli di Debian e' un altro.
Ciao,
Ora Mandreik gli RPM li gestisce molto meglio, autoinstallandosi (quando sa
dove trovarle) le dipendenze. Certo Debian sarà ancora più avanti sul
versante della gestione pacchetti, ma gli altri non stanno a guardare.


 con sto urpmi
urpmi è all'inizio, aptget ha già un po' di storia alle spalle, è già un
prodotto maturo, dai un po' di tempo e anche urpmi si rifinirà.


 giuro!
buuuuuu :PP
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it

computer :)
prego :)
Ciao
-- 
Francesco


Qui una distro decente linux vince a mani basse [apt-get, per citarne
uno, è meglio di qualsiasi cosa abbia prodotto *BSD].
-- 
Renato 'Hitman' Salzano / 
http://spazioinwind.libero.it/hitman/
GdG #6 / IHGGer #778 / Counter VFNCL di IFTMdG / Yane's Fan #00 
"[-](Back to the front)/you will do what I say,when I say/[-]/you will die
when I say,you must die/[-]/you coward/you servant/you blindman/you soldier"


No, apt può installare sia sorgenti ricompilandoli sia binari già
compilati. 


 pacchetto, pronto da reinstallare su altre macchine, altro che cazzi,
pkg_create -b, studia, cucciolone.

 compilati. 
portinstall -PP kde3.

 uno, è meglio di qualsiasi cosa abbia prodotto *BSD].
Soprattuto l'installazione unattended, di cui ancora aspetto
dettagliato resoconto (il famoso package di progeny, ad esempio,
qualcuno lo avra' pure usato).

 chi fa i programmi usarlo.
Non ha però un sistema di packaging. L'installer di windows non mi pare
molto valido...
Ciao.

 Cosa che a windows non è preclusa, mi pare...
No, non è preclusa, ma di fatto non c'è per windows un sistema di
packaging.
Ciao.

 uno, è meglio di qualsiasi cosa abbia prodotto *BSD].
Lo dici così a priori o hai doti magiche che ti consentono di valutare le
cose senza neppure vederle?
Ciao.

 compilati. 
Ti hanno già risposto, quindi...
Ciao.

 piaga, eh?) il bellissimo dpkg-repack?
Mi pare che di piaghe non ce ne siano proprio...
man pkg_create
Ciao.


E perché no?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism


Certo che c'è: apt e compagnia bella sono portabili, per non parlare di 
quello di sistema, per non parlare del fatto che i sistemi di packaging 
non mi pare siano stati dimostrati essere la soluzione migliore al 
problema delle installazioni.


  pre-redhat 7.0.
Vediamo di finirla con la disinformazione, la RedHat 6.2 appena installata 
aveva gcc 2.95, la 7.0 gcc 2.96
Me lo ricordo abbastanza bene, la RH 6.2 e` stata la prima e ultima RH
che ho provato
Andrea
-- 
          (o_  |  Andrea Carosi, just another Linux user ( #210218 )
(o_  (o_  //\  |------------------------------------------------------
(/)_ (/)_ V_/_ |         GnuPG ElG/DSA 2048/1024 key available
ID: 0x1D1CE569 - Fingerprint: DB849F4C79E33F0FAFF9DC0B01B17CDA1D1CE569

 provati, su OpenBSD, e non sono paragonabili IMHO a cio' che fa apt.
"Su OpenBSD" is the keyword here.

 
Ho provato i ports [gentoo], ma apt mi sono parsi un più flessibili. I
ports sono molto buoni per una macchina in cui hai un pò di tempo per
ricompilare e ottimizzare, altrimenti preferisco apt.
