linux user group brescia

On Wed, Feb 07, 2001 at 11:48:24AM +0100, Luca Giuzzi wrote:
> 
> Il problema dell'upgrade e' che dipende strettamente dalla distribuzione
>  piuttosto che dal kernel `linux' (o bsd, o hurd o quello che si vuole).
> Distinguiamo due casi:
>  1) applicazione di patches
>  2) upgrade globale di sistema.

non ti seguo. secondo me sono la stessa identica cosa: 
upgrade totale di sistema = applicazione di patches successive.
non vedo la differenza.

(io sto intendendo per patch fare update di pacchetti singoli)

> Il caso 1 e' quello piu' tranquillo e quasi (ripeto: QUASI) automatico
>  per tutte le distribuzioni. Osserviamo che le patches dovrebbero SOLAMENTE
>  risolvere problemi noti (di sicurezza o stabilita') e non introdurre nuove
>  funzionalita'... in particolare una upgrade del kernel da 2.2 a 2.4
>  NON e' una patch.

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).

>  Le patches per un server VANNO  (non e' una raccomandazione, e' una
>  regola) seguite dal system administrator... altrimenti i problemi
>  sono garantiti. Fortunatamente sistemi tipo apt o rpm 

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.

> L'upgrade globale di sistema, come detto nel documento citato e'
>  "una brutta bestia".

vivi redhat e pensi redhat.
l'upgrade di sistema non e' una brutta bestia.
e' una operazione semplice. che deve essere ovviamente seguita, ma e' 
una operazione semplice.

#ifdef __distribution_flame
non ha senso parlare in generale di distribuzioni quando in realta' si sta
parlando in specifico di redhat...

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..)
#endif /* distribution flame */

>  Innanzitutto una premessa: NON E' POSSIBILE
>  fra distribuzioni diverse, anche se il formato dei pacchetti e' lo stesso
>  (ad es. SuSE, RH e Mandrake usano tutte e 3 pacchetti in formato .rpm
>   ma non e' possibile fare una upgrade automatica dall'una all'altra.
>   In effetti non e' molto furbo nemmeno installare gli rpm di RH sotto
>   SuSE o viceversa... le dipendenze sono diverse).

ancora una volta si sta dando per scontato che la distribuzione sia
redhat-based: io sono passato piu' di una volta da una corel a una potato, 
e una volta da una stormlinux (???) ancora a una potato.

>  L'upgrade di una distribuzione puo' essere relativamente facile o un
>   incubo a seconda di come e' disegnato il sistema dei pacchetti e del
>   numero di bachi all'interno dell'installer (RH7.0 ne aveva, per la
>   cronaca). 

ancora una volta si da per scontato che la distribuzione sia una redhat.
se la redhat *VENDE* distribuzioni che non meritano neanche il fregio di 
'alpha', il discorso non tocca sicuramente le altre distribuzioni.

> 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??
una politica *base* del kernel e' quella di includere roba solo se poi c'e' 
qualcuno che mantiene e aggiorna tale roba...

-:- bungle [~bungle a 62.XXX.XXX.XXX] has joined #ghido_vs_giuzzi
quanto sopra e' espresso chiaramente dallo stesso torvalds (linus) nel libro
'voice from opensource revolution' in replica alle critiche di troppa
parsimonia nell'inclusione di features nel kernel.
inoltre, piu' in generale, se il server e' un banale server da gestire (e con
questo intendo servizio mail, dns, web, stampa), l'upgrade in automatico sotto
debian e' piu' che automatico, anzi puo' essere delegato a cron.
se il server deve avere funzioni fault tolerance, o di continuita' di servizio,
e' preteso che l'admin sia un admin e che conosca perfettamente il suo sistema,
per poter adattare la distribuzione alle proprie esigenze. 
-:- SignOff: bungle

>   piuttosto che il comando `ls' si comporti al medesimo modo
>   [la faccenda hw si riferisce soprattutto ai moduli `solo binari' 

ok.. questo e' l'unico caso per cui non fare il salto.. ma spero che nessuna
distro usi kernel con moduli binariprecompilati ....
 
>     per
>    alcune periferiche... d'altro canto e' anche vero che esistono schede
>    video supportate solamente da XF3 piuttosto che XF4].

questo a maggior conferma.
#ifdef __distribution_flame
sotto debian in fase di upgrade tra xfree, in alcuni casi si continua a
utilizzare il server versione 3... (che e' pacchettizzata  in modo da 
coesistere pacificamente con le lib della versione 4...)

>   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.

-- 
Non entrera' nella comunita' del Signore chi ha il membro contuso o mutilato.
		-- Deuteronomio 23,2