linux user group brescia

PREMESSA: ho scritto un "paccone" per cui, se siete stanchi o stressati,
evitate di leggerlo o leggetelo un'altra volta. ;-)

On Fri, 21 Nov 2003, iDave wrote:
>21-11-2003 8:38: Luca Coianiz ha scritto:
>> Le distro hanno senso come "pakage di prodotto + servizi forniti da una
>> ditta". La parte "package" dell'equazione potrebbe essere più standard.
>> Penso che questa (la differenza di caratteristiche tra le varie distro) sia
>> una cosa che limita molto la diffusione e l'utilizzo di Linux: è un sistema
>> modulare al massimo, che ti puoi "assemblare" come vuoi... ma non si
>> potrebbe almeno partire da una base comune? In modo da avere (finalmente)
>> una "comunità Linux" e non "la comunità MDK", "quella Debian", "quella RH",
>> ecc.
>> Poi ognuno, quando seleziona (o modifica e ricompila) i pacchetti, fa
>> quello che vuole.
>Sono d'accordissimo. Se pensiamo a un tool con la facilità di portage, i
>pacchetti di deb, e la diffusione di rpm...

 Ecco, per esempio, conosco poco sia l'uno che l'altro (anche se li ho
utilizzati entrambi) e vorrei capire, se mi venisse spiegato da uno degli
specialisti della ML (MP ad esempio), "quali caratteristiche migliori ha,
RPM, rispetto ad Apt/Dpkg?".
 NON è per innescare la solita, sterile, "RPM vs Apt religion war" ma è
proprio per capire... bastano due parole, mica un trattato tecnico. ;)

 Inizio parlando io, che non conosco le cose nei dettagli: di Apt m'è
piaciuto il fatto che, se non ho compreso male (dato che la mia esperienza
Debian è limitatissima), se devo installare un package SwA che richiede una
libreria presente nel package SwB non sono costretto ad installare tutto il
package SwB ma quest'ultimo può "fornire" la libreria (giusto?).
 Per cui se SwA è grande 5MB, SwB 100MB e LibB 1MB alla fine nel sistema
avrò installato 6MB di "codice", non 105MB.

 Il sistema Apt/Dpkg ha sicuramente altri pregi (tipo l'installazione
tramite apt-get) ma questo mi pareva uno dei più interessanti.

 Quello che mi chiedevo è: cos'ha invece RPM per farmelo preferire ad Apt?
 La "facilità di gestione"? (mi pare che entrambi si utilizzino tramite dei
front-end), la "quantità di sw pacchettizzato in quella maniera"?.. o sono
(quasi) unicamente ragioni commerciali? (ad es. RH supporta, ovviamente,
solo distro con RPM)

 Questa domanda nasce da "come vedo io" (e spero di non sbagliarmi),
dall'esterno, il processo di sviluppo del kernel di Linux: quando ci sono
due o più "contendenti" a "miglior soluzione per il problema XYZ" mi pare
che la strada adottata dagli sviluppatori sia:

 1. scelgo quello (A, B o C) che si dimostra il migliore sul campo, se gli
algoritmi dei metodi non sono "conciliabili".

 2. cerco di "assemblare" un metodo "D" che sfrutti le migliori feature di
A+B+C in modo da disporre, volta per volta, del "miglior compromesso
possibile di caratteristiche" (e quindi, spesso, del miglior prodotto).

 3. scelgo il metodo "A", integrando alcuni algoritmi di "B" e "C", dato che
"A" sembra promettere di più.

 Ora... SE questo meccanismo è adottato per il kernel (a parte i "fork" come
AC), che è unico e solo (alla faccia di chi ha paura del monopolio ;-))),
perchè non si può adottare un meccanismo simile per la gestione dei
package?... o per la definizione dell'albero delle directories?.. (ma non
c'era FHS una volta?) o per arrivare a disporre di "un DeskTop Manager di
riferimento" che ci faccia (finalmente) mangiare gli spaghetti sulla testa
di M$ (e, magari anche di Apple)? (chiamatelo anche KDGnome per quel che me
ne frega... ;-))) ).

 Guardate che NON sto affatto dicendo "i programmi devono essere tutti
uguali" (per cui tutti gli altri programmatori, a parte quel centinaio che
sviluppano i programmi "approvati", posso tornarsene a casa)... sto parlando
dell'architettura di base, quella che non mi permette di prendere un package
.RPM generato per MDK ed installarlo "senza preoccupazioni" su una SuSE (in
Debian il problema non si pone, ovviamente).

 Quando devo gestire la mail mi posso scegliere il MUA che preferisco ed
usarlo tranquillamente perchè "la mail è sempre quella" (a parte i discorsi
tipo "maildir"... rimaniamo sul semplice): cambio MUA ma la mail non cambia.

 Ora... immagino quel che state pensando: "tanta bella (ed inutile) teoria"
eh?  ;-)))
 Beh... mi sa che se tutta questa "teoria" non diventerà anche "pratica" non
dico che Linux andrà a morire (mi pare un fenomeno troppo ampio per
spegnersi così, senza una buona ragione) ma in confronto a sistemi più
"coerenti" (anche se sicuramente non migliori) ne uscirà sempre un pò
"menomato".

 In fin dei conti una prova che non sto dicendo cavolate è la creazione di
LSB, il fatto che United Linux (dal taglio sicuramente commerciale) si
dichiari "LSB compliant" e che tenti di "regolamentare il settore"
fornendosi come "alternativa a RH".

 Penso che questi "giochini commerciali" siano cose normali in ambito
appunto commerciale e non li considero molto validi "di per se"... ma mi
pare che parte del disorientamento che c'è nel mondo Linux (ed anche del MIO
disorientamento) sia dovuto a queste differenze "non sostanziali" o con poco
senso sotto il profilo tecnico-architetturale (nel senso che non ce n'è
una vera esigenza, non che siano differenze da poco).

 Sicuramente non sono differenze da poco... Ad esempio: mi vengono i sudori
freddi pensando a quando convertirò il mio server, che gira su una SuSE8.0,
alla Debian (Woody, se per allora Sid non sarà stable)... tutto da rifare
e, in parte, da "ripensare". :-(
 Credo che passerò ugualmente a Debian per motivi, per così dire,
filosofici... però questi elementi mi trattengono non poco dal farlo.

>Credo che in fondo linux sia libertà di scelta, che purtroppo si sta
>trasformando in qualcosa che disorienta gli utenti... Non dico di arrivare
>all'estremo di Linduws, in cui la possibilità di scelta NON C'È, ma un
>compromesso bisogna raggiungerlo, se no linux non sarà mai utilizzabile da
>tutti. La possibilità di installare cose diverse deve restare, ma "di
>default" deve esserci una base comune che non si limiti al solo kernel ma
>che spazi in diversi campi quali i pacchetti e la struttura di /etc, che, a
>mio modesto parere, è ancora troppo differente tra le varie distro.

 Appunto. Io NON sono per l'uniformità applicativa, ci mancherebbe, ma solo
per quella "di base". Per tornare un attimo al discorso RPM/Apt: "mi
piacerebbe" che entrambe lavorassero sullo stesso repository come diversi
MUA (ad es. SquirrellMail e PINE) lavorano sugli stessi archivi di mail...
allora sì che uno potrebbe scegliere "uso RPM perchè mi piace (o per
particolari esigenze)" oppure "uso Apt (per gli stessi motivi)".
 Così invece sei costretto ad optare per Debian (se vuoi usare Apt) oppure
per RH, MDK e SuSE se vuoi usare RPM... ma attento: nemmeno tra questi tre
c'è l'interoperabilità dei singoli packages distribuiti (che casino). :(

 Non voglio dire che Apt debba lavorare "come RPM" (o viceversa: so che ci
sono dei tool "di convergenza") ma non si potrebbe, per esempio, (dico una
cazzata... tanto a questo punto, con tutte quelle che ho già detto... ;-)
usare un "formato unificato e terzo" tipo repository-CVS da usare tramite
Apt o RPM?

 Vabbè... speravo di scrivere veramente solo "due righe" ma è proprio vero
che (A) non ho il dono della sintesi e (B) ho ancora molti dubbi
sull'argomento "Linux e dintorni"... a volte mi chiedo se "non sarebbe
meglio passare a FreeBSD" e farla finita (e liberare anche voi della mia
ingombrante presenza).  ;-))))

	Ciao,
		Luca