linux user group brescia

On Wed, Feb 07, 2001 at 03:47:06PM +0100, Luca Giuzzi wrote:
> 
> Sulla faccenda distribuzioni si puo' discutere. Personalmente ritengo
>  che quando si sostituiscono glibc/kernel/gcc e un po' di altre cosine,
>  forse e' meglio dichiarare una "upgrade globale" che non continuare
>  ad aggiornare a pezzettini. 

dissento ancora (tranne per quello che riguarda il kernel).

la glibc e' un pacchetto delicato, lo ammetto. pero' e' un pacchetto, e se si 
fanno le cose giuste e' upgradabile. ed essendo un pacchetto ha le sue
dipendenze. che devono essere soddisfatte. e ci sono pacchetti che usano la 
libc (!!) e che chiedono una libc di una particolare versione.
quindi sono in definitiva solo pacchetti. stesso discorso vale per il gcc.
per il kernel il discorso cambia, in quanto si e' costretti a riavviare la
macchina (a parte strani trucchi con strani loader di kernel).. e questo porta
un downtime che in alcuni casi non e' tollerabile.

> > perche' no? se sai che il kernel 2.4 richiede la tal libreria c  e le
> > modutils-x.x.x che problema c'e' a cambiare il kernel??
> >
> > (ovvio: devi segnalare , che ne so, di dover montare swapfs (aka shmfs), 
> > pero' non vedo che problemi ci siano a upgradare il kernel).
> 
> Il problema e' relativo a che cosa si vuole modificare e quanto si
>  vuole automatizzare. Una upgrade `automatica' puo' richiedere di
>  dover scaricare 300Mb di roba per far poi funzionare tutto al meglio!

passando su un sistema server da slink a potato richiese 40 mb di download.
altri mega di download per passare a una nuova versione di bind e di apache.
tutto qui.
(notasi che l'update si puo' fare da web/ftp/freenet, o anche da un cd ufficiale
debian..)

>  Riconosco che debian e' molto piu' compatibile fra releases che non RH
>  e che non ha sofferto dei problemi di incompatibilita' fra glibc2/2.1/2.2,
>  ma cio' non toglie che la cosa e' delicata.

si, anch'io pensavo che la cosa fosse delicata.
poi sono passato a debian ed ho scoperto che e' la cosa piu' naturale del mondo.

> > apt e rpm sono ben diversi: apt e' un sistema di update
> > (che recentemente e' stato modificato per funzionare su sistemi rpm)
> > rpm e' un formato di pacchetti, come puo' essere il deb.
> >
> Si', ma apt+rpm non e' il massimo, per il modo in cui rpm gestisce le
>  dipendenze. apt, in realta', e' nato e si aspetta un pacchetto 
>  deb. 

infatti non capisco come mai tutti continuino a usare 'sti rpm...

> In effetti il disegno dei pacchetti ".deb" e' stato fatto in modo
>  da poter implementare in modo `pulito' una utility tipo `apt'.

su una formula uno mica si mettono i copertoni lisci, giusto???
(gelmini non scaldarti)

> > > L'upgrade globale di sistema, come detto nel documento citato e'
> > >  "una brutta bestia".
> >
> > vivi redhat e pensi redhat.
> L'upgrade di sistema e' problematica in OGNI caso e l'operazione e'
>  semplice se va tutto bene, terribile se si inceppa qualchecosa.
>  Non sei contento quando il tuo lpr e' sostituito da lpNG e non lo sai,
>  credimi...

ma figurarsi adesso se un installer debian ti passa da lpr a lprng senza dirti
nulla... non ha senso...

se i file di conf di un pacchetto da una versione a un'altra cambiano in modo
non ignorabile, ti saltano fuori warning da tutte le parti in fase di 
apt-get upgrade...

certo, se qualcosa si inceppa i problemi ci sono, ma una persona con un minimo
di intelligenza riesce a risolverli...
(problemi del genere sono capitati a me che uso la sid, distribuzione 
high instability della debian...
ma c'e' scritto da tutte le parti che sid e' per persone non deboli di cuore...

> > con debian di update di sistema ne faccio mediamente un paio al giorno
> > (ovvio.. per scelta mia.. sono con la distribuzione instabile)
> > sono passato da slink a potato, da potato a woody, da woody a sid, da 
> > woody a potato (si.. downgrade di distribuzione... con debian si fa anche
> > questo..)
> 
> Beh 2 UPDATE DI SISTEMA al giorno non e' 2 UPGRADE di sistema al giorno.

ancora.. io non vedo differenza tra upgrade e update...
se upgrade intendi passare da due release diverse, beh.. quello sicuramente non
lo puoi fare 2 volte al giorno...

>  Nel primo caso, posso anche crederci (sebbene su di un server la cosa
>  mi sembri inopportuna; su una workstation e' forse solo uno spreco
>  di banda); 

e' bello avere tutto all'ultima versione: helix-gnome, nautilus, evolution,
sendmail, mutt....
(poi con aptitude decido che cosa updatare e che cosa mantenere...)

> nel secondo la cosa sarebbe leggermente eccessiva e un po'
>  poco produttiva....

ribadisco che con debian gli update si fanno 'online'.... senza riavviare o 
quant'altro....

> > > Il punto essenziale e' che si tratta di una installazione di
> > >   un nuovo sistema operativo e, sebbene non fatta ex-novo, non ci sono
> > >   garanzie che (ad es.) il vecchio hardware sia ancora supportato
> >
> > giuzzi.. che cosa hai bevuto ieri sera??
> Brunello di Montalcino... ottimo vino IMHO.

:)))))

> > una politica *base* del kernel e' quella di includere roba solo se poi c'e' 
> > qualcuno che mantiene e aggiorna tale roba...
> 
> Beh... che fine ha fatto ext1? 

beh... c'era anche xiafs, allora.. ma erano dei piccoli catorci, almeno a
sentire le motivazini per cui sono stati eliminati dal kernel...

> E il modulo per i binari in java?
> Hai provato a fare un boot del 2.4 con 2Mb di RAM? 

neanche un 2.2 boota.. e neanche un 2.0....

> E che mi dici
>  delle persistenti voci sulla rimozione del supporto per dischi XT e
>  di NTFS?

il supporto ntfs non e' mai stato un granche' stabile/definitivo...
in definitiva e' un reverse-engineering... tra l'altro su un target mobile come
quello di m$.

> E poi, che mi dici di progetti esterni al tree principale ma comunque
>  usati? RSBAC, l'userfs, il supporto AFS offerto da ARLA (e pure quello
>  di IBM) il modulo per l'esecuzione diretta di binari in bytecode java,
>  ext3 e il packet-writing, etc. Insomma, e' bene andarci cauti!!
> [attenzione: per molte cose ci sono funzionalita' equivalenti, ma non
>  identiche]

ok.. in alcuni casi il kernel puo' essere rischioso da upgradare...

> > ok.. questo e' l'unico caso per cui non fare il salto.. ma spero che nessuna
> > distro usi kernel con moduli binariprecompilati ....
> >  
> Concordo, ma temo che SuSE lo faccia :((((

la mia considerazione di suse e' _decisamente_ in calo... 

> >
> > >   In un mondo ideale tutto verrebbe gestito in automatico dal meccanismo
> > >    di aggiornamento... in realta' le cose sono un po' diverse.
> >
> > il mondo ideale esiste: basta smettere di pensare redhat.
> >
> Mah... in un mondo ideale i router fanno passare i pacchetti, nessuno cerca
>  di sfondarti il server se non hai installato l'ultima versione di ogni
>  applicazione, gli utenti si inchinano con la dovuta deferenza, etc. etc. 

ok.. un mondo ideale sarebbe una noia...
pero' rendersi piu' facile la vita si puo'...

> Purtroppo questo non e' il caso oggigiorno.

se io fossi cane, bau.
se io fossi gatto, miao.
se fosse tardi, ciao.

-- 
BOFH excuse #214:

Flourescent lights are generating negative ions. If turning them off doesn't work, take them out and put tin foil on the ends.