The Answer Guy
Le risposte alle domande più ricorrenti

del
James T. Dennis
traduzione di
Nicola Intini
In questo numero:
Versioni a go-go e la tragedia di essere "Lasciato indietro"
Un Setup di base per la posta elettronica di Linux?
'sendmail' Problemi di capacità e intasamenti.


(?)

Versioni a go-go e la tragedia di essere "Lasciato indietro"

Da Richard Storey, 20 Maggio 1998

Essendo un novellino che e' li' li' per installare Linux, qualcosa che leggo mi fa pensare che piccole scosse si stanno verificando nell'arena delle versioni di Linux. Cio' mi ha instillato un po' di dubbi sulla direzione da intraprendere perche' non sono realmente interessato ad intallare un sacco di roba, configurarla e poi scorpire che 6 mesi dopo sono "out" a causa di un cambio di standard.

(!)
Posso capire il tuo cruccio. Questo e' un problema che i Managers della Information Technology prospettano ogni volta che devono scegliere Hardware e software per le proprie aziende. E' un problema anche per i privati. Ma nessuno viene licenziato per questi piccoli disastri (potrebbero causare al massimo dei divorzi…).

Questo spiega la regola nel MIS/IT "nessuno e' mai stato licenziato per aver comprato IBM" (ed anche il perche' vediamo una tale "devozione" nei confronti dei prodotti Microsoft).

Comunque posso trattenere le tue lacrime per almeno un paio di ragioni: Questo NON e' il mercato. E' il mondo del Free software. (in questo caso particolare mi riferisco a
GNU e Linux free software e non semplicemente al mondo dell' "open software").

(?)

Cos'e' questa storia di alcune librerie gcc GNU che stanno migrando verso un nuovo standard? Ho letto qualche info a riguardo e ci ho capito appena qualcosa, ma non sono un programmatore, percio' non riesco ad avere il quadro della situazione.

(!)
La discussione su glibc2 (Linux libc 6) e libc5 riguarda soprattutto i programmatori. Anche come sysadmin sono abbastanza attento a questo. E' una faccenda di package e gestori di distribuzioni (che e' probabilmente l'origine dei messaggi di cui parli).

C'e' sicuramente molto discussione circa i pro ed i contro di ognuino. Non volgio entrare in questo, soprattutto perche non sono qualificato per farlo. (non sono un programmatore).

Una visione molto dall'alto ci dice che glibc e libc5 coesistono piu' o meno altrettanto bene quanto libg5 coesiste con libc4 e a.out coesiste con ELF. Nessuno viene abbandonato per stada. In questo caso la cosa e' completamente differente dal passaggio da DOS e Windows 3.x al Windows '95 e/o da uno di questi a NT. Ed e' lontanissimo dalla maniera vergognosa con cui Microsoft e IBM hanno trattato i loro utenti di OS/2..

Guardando piu' da vicino posso dire che le prossime release delle principali distribuzioni saranno basate su glibc. Molti probabilmente forniranno come optionanl le librerie libc5 per coloro che vogliono o hanno bisogno di programmi che si linkano ad esse.

glibc e' la implementazione di riferimento per lo standard 86Open. Esso sara' supportato da quasi tutti i produttori di Unix per x86 per il prossimo paio di anni. (Spero che la maggior parte di noi si saranno orientati verso PPC, Alpha, Merced [benche' il suo piano di rilascio sia stato allungato], o qualsiasi cosa ci sara' allora -- ma io sono quello dei server vecchi di 10 anni che gestiscono tutta la posta in ingresso ed in uscita dal mio dominio --- percio' non scommetteteci).

La speranza e' che avremo finalmente una reale compatibilita' fra tutte le varianti di Unix per PC. SCO e Sun lo hanno tradizionalmente contrastato nell'interesse della loro rivalita' sul mercato --- ma la crescente accettazione di Linux e gli altri software GNU la rendono la loro unica scelta sensata. Nessuno di loro puo' forzare il mercato ad adottare il proprio standard (iBCS e le x86 ABI) ed il mercato del software consumer si sta spostando rapidamente verso Linux.

Dovrebbe essere anche molto piu' facile per Linux mantenere la pace con il resto del mondo GNU se adottiamo glibc. Si dovrebbero evitare anche inutili sprechi di risorse nel portare le nuove caratteristiche da glibc/gcc a Linux. rispetto a quando c'erano le precedenti libc's.

Attualmente siamo in transizione, come lo eravamo un paio di anni fa quando ci spostammo da a.out a ELF. 'a.out' e ELF sono "formati di link" --- modi differenti di rappresentare le stesse istruzioni di linguaggio macchina. Esse richiedono metodi di loading dal kernel differenti, per girare correttamente. E' possibile supportare a.out e ELF sullo stesso sistema correntemente. Infatti io posso compilare a.out come un "modulo caricabile" e configurare il mio sistema per caticarlo automaticamente ed in maniera traspaente --- il che fa risparmiare un po' di memoria di kernel quando non sto facendo girare alcuna vecchia applicazione --- ma mi consente di farlo senza problemi.

Benche' le librerie condivise siano completamente differenti dal (ed indipendenti dal) formato eseguibile, la similitudine e' che noi (come utenti ed admins) possiamo soltanto far in modo che i programmatori, distributori e gestori di package possono aver cura di tutto cio'.

Cerchero' di spiegare cosa c'e' dietro a questo:

La maggior parte dei programmi sotto Linux (e la maggior parte dei moderni Unix) sono "linkati dinamicamente" alle "librerie condivise (shared libraries)" Le DLL di Windows (dynamically linked libraries) sono un esempio del tentativo di Microsoft di implementare simili features per i propri OS. (Credo che le librerie condivise di Unix siano precedenti all' OS/2 ed a MS Windows di un bel po')

Piu' o meno tutti i programmi linkati dinamicamente sono linkati a qualche versione di "libc" (che fornisce le funzioni che ottieni usando la direttiva #include <stdio.h> in un programma C). Ovviamente la vostra distribuzione include libc alla quale sono linkati buona parte dei programmi.

Essa puo' anche includere altre versioni delle librerie condivise. Un eseguibile specifica la versione e la minima sottoversione della libreria di cui ha bisogno. Pertanto un programma linkato a libc5 potrebbe specificare che abbisogna libc5 o libc5.4.
Se possiedi soltanto libc5.3 ed il programma richiede libc5.4 otterrai un messaggio di errore. Se hai libc5.3 e libc5.4 allora il programma dovrebbe girare senza problemi. Qualsiasi programma che richiede soltanto libc5 (e che non fornisce indicazioni sulla sottoversione) si linkera’ all’ultima versione di libc5.x (assumendo che la tua ldconfig sia corretta).

Questo non significa che il sistema sia perfetto. Occasionalmente troverai programmi come Netscape Navigator o StarOffice i quali specificano la libreria meno precisamente di quanto dovrebbero (o talvolta potrebbero avere la specifica errata). Quando questo accade il bug puo’ errese alquanto subdolo. Cio’ e’ specialmente vero quando un programma "dipende da un bug delle librerie" (cosi’ la correzione del bug nella libreria porta al malfunzionamento del porgramma che vi e’ linkato).

Nel caso peggiore potresti semplicemente mettere copia delle librerie necessarie (e funzionanti) in una directory e lanciare il programma affetto attraverso un piccolo script "wrapper" di shell. Questo wrapper non fa che esportare le variabili di ambiente: LD_PRELOAD e/o LD_LIBRARY_PATH per puntare a queste librerie o queste directory (rispettivamente). Queste variabili di ambiente "magiche" forzeranno il linker dinamico a modificare le normali convenzioni di linkaggio secondo i tuoi bisogni.

(Cio’ e’ ovviamente un problema solo se i sorgenti della applicazione affetta non sono disponibili perche’ normalmente la ricompilazione ed il re-linking risolverebbero il problema).

Nei casi veramente disperati potresti avere un eseguibile linkato staticamente. Questo dovrebbe contenere tutto il codice necessario e non e’ necessario (ne’ possibile) nessun link dinamico.

Nota che il problema che ho appena descritto riguarda gia’ le librerie condivise. Questa non e’ una novita’ con la introduzione di glibc --- giacche’ i casi reali dove ho dovuto usare LD_PRELOAD erano tutti con libc5.

(?)

Alcune defezioni da Debian mi fanno dubitare se usare quella versione.

(!)
Non sono sicuro di capire. Per prima cosa non sono sicuro a quali defezioni ti stai riferendo. Presumo che tu abbia letto alcuni messaggi sul fatto che alcuni sviluppatori o manutentori di package hanno omesso di fare questa migrazione (alla glibc).

Ancora piu’ importante, non sono sicuro della versione alla quale ti riferisci.

La versione corrente di Debian (1.3) usa libc5. La prossima versione (attualmente in feature freeze --- dovrebbe essere la 2.0) usa glibc.

(?)

Ho letto di alcuni grossi problemi con RedHat 5.0, ma la 4.x non e’ compatibile con le nuove libreire GNU gcc, (esatto?).

(!)
Non definirei tali problemi con Red Hat 5.0 come grossi. Quando ero al supporto tecnico e QA usavamo un sistema di categorie di bugs che andavano dalla "cat 1" alla "cat 4." Le categorie erano piu’ o meno:
      1. Causa perdite di dati o manda in crash l’intero sistema
      2. Si blocca ed e’ inutilizzabile
      3. Alcume funzioni principali non funzionano
      4. cosmetica
... e i problemi che ho visto nel RH5 erano tutti della categoria 3 o piu’ semplice. (Qualcuno potrebbe non essere d’accordo con il livello di severita’ di alcuni bugs di sicurezza --- ma non adentriamoci in questo).

Comunque sono d’accordo che ci fossero molti errori in quela release --- e che molti di essi fossero evidenti e molto brutti.

Una delle due volte in cui ho cenato con Erik Troan (che e’ un senior developer per Red Hat Inc) gli ho chiesto perche’ hanno forzato il supporto di glibc cosi’ presto e per una release cosi’ importante.

Egli mi ha dato una risposta rinfrancante e lineare chiedendomi :

"Quanti utenti glibc c’erano un mese fa?"

(realmente nessuno --- soltanto qualche sviluppatore )… e:

"Quanti ce ne sono adesso?"

In sostanza sembrerebbe che Red Hat Inc sapesse che si sarebbe andati incontro a problemi con glibc --- e ha preso la decisione strategica di farlo uscire e supportarlo con forza. Questo sarebbe stato doloroso ma venne visto probabilmente come l’unico modo per spingere l’intera comunita’ Linux in avanti.

Penso che avrebbero potuto lavorare un tantino in piu’ prima di rilasciare. Avevo sperato che essi avessero aspettato che la versione 2.2 del Kernel fosse pronta cosi’ avrebbero potuto accoppiare le due cose in una nuova release.

(Comunque, penso che cio' avrebbe ritardato i loro piani di 7-8 mesi. Invece sembra che essi vogliano rilasciare una nuova sottoversione ogni 4-6 mesi).

Allo stesso tempo devo riconoscere il loro approccio come un servizio alla comunita’. Essi hanno risolto i bugs rapidamente (e le nuove stampe degli stessi CD contengono molte di queste correzioni). Come tutte le aziende che impacchettano software Red Hat Inc. e’ obbligata (dai canali di distribuzione) a fare un "aggiornamento silenzioso" (incorporare correzioni ai bugs senza incrementare il numero di versione). Questo e’ un triste fenomeno della industria --- e costa agli utenti ed alle aziende molta confusione e milioni di ore spese a risolvere i problemi.

(Il mio suggerimento era che RH facesse un CD mensile dei suoi bug fixes e della directory "contrib" e offrisse abbonamenti ed ordini diretti a questi. Non so se mi hanno preso in considerazione. La mia preoccupazione e’ quella di salvaguardare un po’ di larghezza di banda. Occasionalmente masterizzo CD di questo tipo e li distribuisco nei meeting di utenti cosicche’ possano essere distribiuti liberamente.

(?)

Potresti spiegare un po’ di queste migrazioni di versioni nel mondo Linux?

(!)
Spero di aver aiutato qualcuno. Ci sono stati molti tipi di migrazioni e conversioni in Linux durante questi anni. Ovviamente ci sono state migrazioni da libc4 a libc5, e da a.out a ELF, e tra diverse versioni di kernel : .99 a 1.0. --> 1.1 --> 1.2 --> 2.0 e lo sforzo che si sta attualmente compiendo per rilasciare il 2.2

Penso che tutte queste migrazioni siano state progressive

Quella che abbiamo sofferto di piu’ e’ stato il cambio nella struttura del filesystem /proc dalla 1.2 alla 2.0. E’ stata l’unica volta che un kernel appena compilato ha fatto collassare e morire programmi vitali dello ‘user space’. (comandi come ‘ps’ e ‘top’ erano inutilizzabili).

Questo si’ che era terribile!

Non c’era una maniera facile per commutare i kernel sullo stesso filesystem root. La migliore soluzione a quel tempo sembrava essere tenere un filesystem con la vecchia suite "procps" ed un altro con la nuova. Bisognava allora montare tutti gli altri filesystem per ognuno di questi. Per coloro che come me creano abitualmente un piccolo filesystem root e creano una versione primaria ed alternativa / di emergenza di questa --- era un problema troppo grande.

(normalmente io uso 63Mb --- a volte 127Mb e monto /usr, /var e altri --- o al minimo monto /usr e /usr/local e faccio cose come /var, /opt e /tmp in symlinks adatti. Isolai soltanto i binari 'cattivi' spostandoli da /usr a /root/.usr/ e li rimpiazzai con symlinks. Quindi il ‘pc’ che lanciavo veniva indirizzato a quello sotto il mio filesystem root – che era diverso a seconda di quale kernel lanciavo).

Non credo che glibc (o il kernel 2.2 ) porra’ questo tipo di problemi. Il peggior problema che prevedo con glibc e’ la sua enorme dimensione. Sara' un problema, quindi, creare dischetti di boot. Ho sentito che e’ possibile comprimerlo fin quasi alla stessa dimensione di libc5 --- il che significa che saranno possibili dischetti basati su glibc usando initrd (initialization RAM disks) compresso. Porbabilmente pero’ non sara’ necessario. La caratteristica principale di glibc sembrerebbe essere nel supporto di NIS (risoluzioni in rete di cose come user account e informazioni sui gruppi --- cose fattibili accedendo a files come /etc/passwd e /etc/group). Molte di queste caratteristiche non sono probabilmente necessarie per un dischetto di emergenza.

Una nota finale su queste migrazioni e cambi:

Non sei obbligato a seguire la corrente. Puoi restare indietro e usare Red Hat 4.2 o Debian 1.3 per tutto il tempo che desideri. Puoi installarli ed installare glibc con essi. Non sei obbligato ad aggiornare o cambiare tutto insieme.

Queste "vecchie versioni" non diventano mai veramente 'non supportate' --- c’e’ qualcuno che ha appena rilasciato un Linux-Lite aggiornato (basato sul kernel 1.0.9). Questo e’ uno dei kernels piu’ piccoli e piu’ stabili nella storia del Sistema Operativo. E’ stato aggiornato per supportare ELF e contiene alcune correzioni di bugs. Puo’ essere lanciato con appena 2Mb di RAM (che e’ sufficiente per un router interno o per un server di stampa) e gestire applicazioni embedded che abbisognano di TCP/IP.

Siccome sono disponibili i sorgenti e siamo autorizzati a modificarli e ridistribuirli per sempre (questo e’ il cuore della GPL) possiamo continuare a manutenerlo per tutto il tempo che vogliamo. Certamente ci sara’ qualcuno in rete a cui piacera’.

(?)

Thanks.
RS


Per l'articolo originale: © 1998 James T. Dennis
Pubblicato sul n.29-Giugno 1998 di Linux Gazette
Per l'edizione italiana: © 1998 LGEI