The Unix and Internet Fundamentals HOWTO
  by Eric S. Raymond
  v1.4, 25 settembre 1999

  Questo documento descrive il funzionamento di base dei computer di
  classe PC, i sistemi operativi di tipo Unix e Internet usando un lin
  guaggio non troppo tecnico.  Traduzione a cura di Mirko Nasato,
  mn@altern.org.

  1.  Introduzione



  1.1.  Scopo di questo documento

  Questo documento vuole essere un aiuto per gli utenti di Linux e di
  Internet che stanno imparando dalla pratica. Anche se il ``learning by
  doing''  un ottimo metodo per acquisire abilit, a volte lascia
  determinate lacune nella conoscenza delle basi che possono rendere
  difficile il pensiero creativo o la risoluzione efficace dei problemi,
  a causa della mancanza di un chiaro modello mentale relativo a cosa
  sta succedendo nella realt.

  Cercher di descrivere con un linguaggio chiaro e semplice come
  funziona il tutto. La presentazione sar calibrata per persone che
  usano Unix o Linux su hardware di classe PC. Di solito far comunque
  riferimento semplicemente a `Unix', dato che la maggior parte delle
  descrizioni vale anche per altre piattaforme e varianti Unix.

  Assumer che stiate usando un PC Intel. I dettagli differiscono
  leggermente se lavorate su un Alpha o un PowerPC o qualche altro
  computer Unix, ma i concetti di base sono gli stessi.

  Non ripeter le cose, quindi dovrete stare attenti, ma ci significa
  anche che imparerete da ogni parola che leggete.  una buona idea
  limitarsi a dare una scorsa la prima volta che leggete; dovreste poi
  tornare indietro e rileggere alcune volte finch avrete digerito
  quello che avete imparato.

  Questo  un documento in evoluzione. Intendo continuare ad aggiungere
  sezioni in risposta agli stimoli dei lettori, pertanto periodicamente
  dovreste tornare a rivederlo.


  2.  Cosa c' di nuovo

  Nuovo nella 1.2: La sezione `Come il computer immagazzina dati in
  memoria'.  Nuovo nella 1.3: Le sezioni `Cosa succede al login?' e
  `Propriet dei file, permessi e sicurezza'.


  2.1.  Risorse correlate

  Se state leggendo questo documento al fine di imparare come diventare
  un hacker, dovreste anche leggere la How To Become A Hacker FAQ
  <http://www.tuxedo.org/~esr/faqs/hacker-howto.html>.  Contiene dei
  link ad altre risorse utili.


  2.2.  Nuove versioni di questo documento

  Nuove versioni dello Unix and Internet Fundamentals HOWTO verranno
  periodicamente postate su comp.os.linux.help, comp.os.linux.announce e
  news.answers <news:answers>.  Saranno anche depositate su vari siti
  WWW e FTP dedicati a Linux, inclusa la LDP home page.

  Potete vedere l'ultima versione sul World Wide Web all'URL
  <http://metalab.unc.edu/LDP/HOWTO/Unix-Internet-Fundamentals-
  HOWTO.html>.


  2.3.  Commenti, suggerimenti e correzioni

  Se avete domande o commenti su questo documento sentitevi liberi di
  contattare Eric S. Raymond all'indirizzo esr@thyrsus.com.  Qualsiasi
  suggerimento o critica sar il benvenuto. Apprezzo particolarmente
  link a spiegazioni pi dettagliate dei singoli concetti. Se trovate un
  errore per favore fatemelo sapere, in modo che lo possa correggere
  nella prossima versione. Grazie.


  3.  Anatomia di base del computer

  Dentro al vostro computer c' un chip processore che compie
  l'elaborazione vera e propria. C' una memoria interna (quella che la
  gente DOS/Windows chiama ``RAM'' e la gente Unix spesso chiama
  ``core''). Il processore e la memoria risiedono sulla scheda madre,
  che  il cuore del vostro computer.

  Il vostro computer ha uno schermo ed una tastiera. Ha dischi fissi e
  dischi floppy. Lo schermo e i dischi hanno schede controller che si
  attaccano sulla scheda madre e aiutano il computer a gestire questi
  dispositivi.  (La tastiera  troppo semplice per aver bisogno di una
  scheda separata; il controller  costruito all'interno della tastiera
  stessa.)

  Scenderemo pi avanti in alcuni dei dettagli relativi al funzionamento
  di questi dispositivi. Per ora, ecco alcune cose di base da tenere a
  mente sul come funzionano assieme:

  Tutte le parti interne del vostro computer sono collegate da un bus.
  Fisicamente, il bus  quello dove si attaccano le schede controller
  (la scheda video, il controller del disco, una scheda audio se ce
  l'avete). Il bus  l'autostrada dei dati tra il processore, lo
  schermo, il disco e tutto il resto.

  Il processore, che fa funzionare tutto il resto, in realt non  in
  grado di vedere direttamente nessuno degli altri pezzi: deve
  comunicare con loro attraverso il bus. L'unico sottosistema al quale
  ha accesso veramente rapido, immediato,  la memoria (core). Perch i
  programmi siano eseguiti, dunque, devono essere in memoria.

  Quando il vostro computer legge un programma o dei dati dal disco in
  effetti succede che il processore usa il bus per spedire una richiesta
  di lettura disco al controller del disco. Dopo un po' di tempo il
  controller del disco usa il bus per segnalare al computer che ha letto
  i dati e li ha messi in una certa locazione di memoria. Il processore
  pu allora usare il bus per guardare in quella memoria.

  Anche la tastiera e lo schermo comunicano con il processore attraverso
  il bus, ma in modi pi semplici. Ne discuteremo pi avanti. Per ora,
  ne sapete abbastanza per capire cosa succede quando accendete il
  vostro computer.


  4.  Cosa succede quando si accende un computer?

  Un computer senza un programma in esecuzione  soltanto un ammasso
  inerte di componenti elettronici. La prima cosa che un computer deve
  fare quando viene acceso  far partire un programma speciale chiamato
  sistema operativo. Il compito del sistema operativo  aiutare gli
  altri programmi del computer a funzionare, gestendo gli intricati
  dettagli relativi al controllo dell'hardware del computer.

  Il processo di avvio del sistema operativo si chiama boot (in origine
  era bootstrap e alludeva alla difficolt di tirarsi su da solo, ``by
  your bootstraps'').  Il vostro computer sa come avviarsi perch le
  istruzioni per il boot sono incorporate in uno dei suoi chip, il BIOS
  (Basic Input/Output System).

  Il chip BIOS gli dice di cercare uno speciale programma chiamato boot
  loader (quello di Linux si chiama LILO) che si trova in un posto
  predefinito del disco fisso con numero pi basso (il disco di avvio).
  Il compito del boot loader  far partire il sistema operativo vero e
  proprio.

  Per compiere quest'ultima operazione il loader cerca un kernel, lo
  carica in memoria e lo fa partire. Quando avviate Linux e vedete
  "LILO" sullo schermo, seguito da una riga di puntini, vuol dire che
  sta caricando il kernel. (Ogni puntino significa che ha caricato un
  altro blocco disco di codice kernel).

  (Vi potreste chiedere come mai il BIOS non carica il kernel
  direttamente: perch questo processo a due stadi con il boot loader?
  Beh, il BIOS non  molto intelligente. In effetti  proprio stupido, e
  Linux non lo usa pi dopo la fase di avvio. Fu scritto in origine per
  i primitivi PC a 8 bit con dischi poco capienti e proprio non riesce
  ad accedere ad una parte abbastanza grande del disco per caricare
  direttamente il kernel. La fase del boot loader consente anche di far
  partire diversi sistemi operativi da diversi posti del vostro disco,
  nella improbabile circostanza che Unix non vi soddisfi a sufficienza.)

  Dopo essere partito, il kernel si guarda in giro, trova il resto
  dell'hardware e si prepara a far girare i programmi. Fa tutto questo
  guardando non nelle ordinarie locazioni di memoria ma piuttosto alle
  porte I/O, speciali indirizzi bus che probabilmente hanno schede
  controller di dispositivi che sono in ascolto in attesa di comandi. Il
  kernel non cerca a caso; ha molta conoscenza innata su cosa 
  probabile trovare dove, e su come i controller rispondono se sono
  presenti. Questo processo si chiama autorilevamento.

  La maggior parte dei messaggi che vedete durante la fase di avvio sono
  del kernel che fa l'autorilevamento del vostro hardware attraverso le
  porte I/O, riconosce cosa ha a sua disposizione e si adatta al vostro
  computer. Il kernel di Linux  estremamente bravo in questo, meglio
  della maggior parte degli altri Unix e molto meglio del DOS o di
  Windows. Infatti, molti linuxiani della prima ora pensano che
  l'intelligenza del rilevamento all'avvio di Linux (che lo rende
  relativamente facile da installare) sia stata una delle principali
  ragioni che lo hanno fatto sfondare dal mucchio di esperimenti di Unix
  liberi, attraendo una massa critica di utenti.

  Ma avere il kernel del tutto caricato e funzionante non  la fine del
  processo di boot; ne  solo il primo stadio (a volte chiamato run
  level 1, livello di esecuzione 1).

  Il prossimo passo del kernel  assicurarsi che i vostri dischi siano a
  posto. I file system dei dischi sono fragili: se vengono danneggiati
  da un malfunzionamento hardware o da un'improvvisa mancanza di
  elettricit, ci sono buoni motivi per compiere alcune operazioni di
  riaggiustamento prima che il vostro Unix sia tutto a posto. Parleremo
  pi approfonditamente di questo pi avanti, a proposito di ``come i
  file system si possono danneggiare''.

  Il passo successivo del kernel  far partire diversi demoni. Un demone
  (o daemon)  un programma quale uno spooler di stampa, un programma
  che attende di ricevere posta in arrivo oppure un server WWW che
  rimane latente in sottofondo, aspettando qualcosa da fare. Questi
  programmi speciali devono spesso coordinare diverse richieste che
  rischiano di confliggere. Sono demoni perch spesso  pi facile
  scrivere un programma che gira costantemente e viene a conoscenza di
  tutte le richieste piuttosto che cercare di assicurarsi che un gruppo
  di copie (che girano tutte contemporaneamente, con ciascuna che
  processa una richiesta) non si ostacolino a vicenda.  La particolare
  serie di demoni che il vostro sistema fa partire pu variare, ma quasi
  certamente include uno spooler di stampa (un demone che fa da
  `portinaio' per la vostra stampante).

  Una volta che tutti i demoni sono avviati ci troviamo al run level 2.
  Il prossimo passo  prepararsi per gli utenti. Il kernel fa partire
  una copia di un programma chiamato getty per controllare la vostra
  console (e forse altre copie per controllare le porte seriali dial-
  in). Questo programma  quello che emette il prompt login alla vostra
  console. Siamo ora al run level 3, pronti per fare il log in e
  lanciare i programmi.


  5.  Cosa succede al login?

  Quando fate il login (date un nome e la password) vi identificate a
  getty e al computer. Parte allora un altro programma chiamato
  (ovviamente) login, che compie qualche operazione di servizio e poi fa
  partire un interprete di comandi, la shell. (S, getty e login
  potrebbero essere un solo programma. Sono separati per motivi storici
  che qui non vale la pena approfondire.)

  Ecco qualche nozione in pi su cosa fa il sistema prima di darvi una
  shell; vi servir per capire meglio la parte successiva sui permessi
  dei file. Vi identificate dando un nome di login e una password. Quel
  nome di login viene controllato in un file chiamato /etc/password, che
   una sequenza di linee ciascuna delle quali descrive un account
  utente.

  Uno di questi campi  una versione crittata della password
  dell'account. Quella che voi digitate come password di account viene
  crittata esattamente nello stesso modo e il programma login verifica
  che le due corrispondano. La sicurezza di questo metodo dipende dal
  fatto che, se  facile passare dalla vostra password in chiaro alla
  versione crittata,  molto difficile fare il contrario. Perci, anche
  se qualcuno riuscisse a vedere la versione crittata della vostra
  password, non sarebbe in grado di usare il vostro account (questo
  significa anche che, se dimenticate la vostra password, non c' modo
  di recuperarla ma si pu solo cambiarla con una nuova).

  Una volta che avete effettuato con successo il login, avete tutti i
  privilegi associati all'account individuale che state usando. Potete
  anche essere riconosciuti come parte di un gruppo. Un gruppo  una
  collezione di utenti alla quale viene dato un nome, messa in piedi
  dall'amministratore di sistema. I gruppi possono avere privilegi
  indipendenti dai privilegi dei loro membri. Un utente pu far parte di
  pi gruppi (per maggiori dettagli su come funzionano i privilegi in
  Unix, v. la successiva sezione sulla ``Propriet dei file, permessi e
  sicurezza'').

  (Notate che anche se di solito ci si riferisce agli utenti ed ai
  gruppi usando dei nomi, internamente vengono memorizzati come ID
  numerici. Il file delle password associa i nomi dei gruppi agli ID
  numerici di gruppo. I comandi che si occupano di account e gruppi
  effettuano automaticamente la conversione.)

  La vostra voce di account contiene anche la home directory, il posto
  del file system di Unix dove si trovano i vostri file personali.
  Infine, la voce di account imposta anche la vostra shell, l'interprete
  di comandi che login fa partire per accettare i vostri comandi.
  6.  Cosa succede quando si eseguono i programmi dalla shell?

  La shell normale vi presenta il prompt '$' che vedete dopo il login (a
  meno che non lo abbiate personalizzato). Non parleremo della sintassi
  della shell e delle cose semplici che potete vedere da soli sullo
  schermo; daremo piuttosto uno sguardo dietro le quinte a quello che
  succede dal punto di vista del computer.

  Dopo la fase di avvio e prima che sia eseguito un programma, potete
  pensare al vostro computer come ad un contenitore di un repertorio di
  processi che stanno tutti aspettando qualcosa da fare. Stanno tutti
  aspettando degli eventi. Un evento pu essere voi che premete un tasto
  o muovete il mouse. Oppure, se il vostro computer  collegato ad una
  rete, un evento pu essere un pacchetto di dati che arriva lungo
  quella rete.

  Il kernel  uno di questi processi.  uno speciale, perch controlla
  quando gli altri processi utente possono girare ed  normalmente
  l'unico processo con accesso diretto all'hardware del computer.
  Infatti, i processi utente devono fare richiesta al kernel quando
  vogliono ottenere un input dalla tastiera, scrivere sullo schermo,
  leggere o scrivere su disco o fare qualsiasi altra cosa che non sia
  macinare bit in memoria. Queste richieste sono note come chiamate di
  sistema.

  Normalmente tutto l'I/O passa attraverso il kernel, cos quest'ultimo
  pu organizzare le operazioni e impedire che i processi si ostacolino
  a vicenda. Alcuni processi utente speciali hanno il permesso di
  aggirare il kernel, di solito per ottenere accesso diretto alle porte
  I/O. I server X (i programmi che gestiscono le richieste degli altri
  programmi di generare grafica sullo schermo, sulla maggior parte dei
  computer Unix) sono i pi comuni esempi al riguardo. Ma non siamo
  ancora arrivati ad un server X; state guardando il prompt della shell
  su una console a caratteri.

  La shell  solo un processo utente e neppure uno tanto speciale.
  Attende che voi digitiate qualcosa, ascoltando (attraverso il kernel)
  sulle porte I/O della tastiera. Come il kernel vede che avete digitato
  qualcosa lo visualizza sullo schermo e poi lo passa alla shell. Quando
  il kernel vede un `Invio' passa la vostra linea di testo alla shell.
  La shell tenta di interpretare questo testo come se si trattasse di
  comandi.

  Diciamo che digitate `ls' e Invio per invocare il programma Unix che
  lista le directory. La shell applica le sue regole incorporate per
  indovinare che volete lanciare il comando eseguibile nel file
  `/bin/ls'. Fa una chiamata di sistema chiedendo al kernel di far
  partire /bin/ls come un nuovo processo figlio e di dargli accesso allo
  schermo e alla tastiera attraverso il kernel. Poi la shell va a
  dormire, aspettando che finisca.

  Quando /bin/ls ha finito dice al kernel che ha terminato emettendo una
  chiamata di sistema exit. Il kernel allora sveglia la shell e le dice
  che pu riprendere a girare. La shell emette un altro prompt e attende
  un'altra linea di input.

  Tuttavia (supponiamo che stiate listando una directory molto lunga)
  potrebbero succedere altre cose mentre `ls'  in esecuzione.  Potreste
  passare su un'altra console virtuale, fare il login di l e iniziare
  una partita a Quake, per esempio. Oppure immaginate di essere
  collegati a Internet. Il vostro computer potrebbe spedire o ricevere
  posta mentre /bin/ls  in esecuzione.




  7.  Come funzionano i dispositivi di input e gli interrupt?

  La tastiera  un dispositivo di input molto semplice: semplice perch
  genera piccole quantit di dati molto lentamente (per gli standard di
  un computer). Quando premete o rilasciate un tasto, il valore di
  questo evento viene segnalato attraverso il cavo della tastiera per
  far scattare un interrupt hardware.

   compito del sistema operativo stare attento a questi interrupt. Per
  ogni possibile tipo di interrupt c' un gestore dell'interrupt, una
  parte del sistema operativo che immagazzina i dati ad esso associati
  (come il valore del vostro premere/rilasciare il tasto) finch pu
  essere processato.

  Quello che effettivamente fa il gestore dell'interrupt della vostra
  tastiera  mettere il valore del tasto in un'area di sistema vicino al
  fondo della memoria. L rimane a disposizione per ispezione quando il
  sistema operativo passa il controllo al programma che ritiene stia
  attualmente leggendo dalla tastiera.

  Dispositivi di input pi complessi come i dischi o le schede di rete
  funzionano in modo simile. Sopra abbiamo fatto il caso di un
  controller del disco che usa il bus per segnalare che una richiesta
  disco  stata ultimata. In realt succede che il disco fa scattare un
  interrupt. Il gestore dell'interrupt del disco copia poi in memoria i
  dati ottenuti, ad uso successivo da parte del programma che aveva
  fatto la richiesta.

  Ad ogni tipo di interrupt  associato un livello di priorit. Gli
  interrupt con priorit pi bassa (come gli eventi della tastiera)
  devono dare la precedenza agli interrupt con priorit pi alta (come i
  tick dell'orologio o gli eventi del disco). Unix  progettato per dare
  alta priorit al tipo di eventi che necessitano di essere processati
  rapidamente, in modo da mantenere fluida la risposta del computer.

  Tra i messaggi d'avvio del vostro SO potete vedere dei riferimenti a
  numeri di IRQ. Forse sapete, senza capirne esattamente il perch, che
  uno dei modi pi comuni di configurare male l'hardware  avere due
  dispositivi diversi che cercano di usare lo stesso IRQ.

  Ecco la spiegazione. IRQ  l'abbreviazione di "Interrupt Request"
  (richiesta di interrupt). Il sistema operativo ha bisogno di sapere al
  momento dell'avvio quali interrupt numerati verranno usati da ciascun
  dispositivo hardware, in modo da poter associare a ciascuno il gestore
  appropriato. Se due dispositivi diversi cercano di usare lo stesso IRQ
  a volte gli interrupt verranno notificati al gestore sbagliato. Questo
  di solito provocher quantomeno il blocco del dispositivo, ma pu a
  volte confondere il SO a tal punto da farlo diventare instabile oppure
  mandarlo in crash.


  8.  Come fa il computer a fare diverse cose contemporaneamente?

  Non lo fa, in realt. I computer possono svolgere soltanto un task (o
  processo) alla volta. Ma un computer pu cambiare task molto
  rapidamente e indurre i lenti esseri umani a pensare che sta facendo
  diverse cose contemporaneamente. Questo viene chiamato timesharing
  (condivisione di tempo).

  Uno dei compiti del kernel  gestire il timesharing. Ha una parte
  chiamata scheduler (pianificatore) che contiene informazioni relative
  a tutti gli altri processi (a parte il kernel) del vostro repertorio.
  Ogni sessantesimo di secondo nel kernel fa scattare un timer e viene
  generato un interrupt di orologio. Lo scheduler ferma qualunque
  processo sia attualmente in esecuzione, lo sospende sul posto e passa
  il controllo ad un altro processo.
  Un sessantesimo di secondo pu non sembrare una grande quantit di
  tempo. Ma per i microprocessori odierni  sufficiente per eseguire
  decine di migliaia di istruzioni macchina, che si possono tradurre in
  una gran mole di lavoro. Quindi anche se ci sono molti processi
  ciascuno di essi pu fare molte cose nella porzione di tempo a sua
  disposizione.

  In pratica non sempre un programma ottiene la sua intera porzione di
  tempo. Se scatta un interrupt da un dispositivo I/O il kernel ferma
  effettivamente il task corrente, esegue il gestore dell'interrupt e
  poi ritorna al task corrente. Una tempesta di interrupt ad alta
  priorit pu scombinare il normale funzionamento dei processi; questo
  fenomeno viene chiamato thrashing e per fortuna  molto difficile da
  indurre negli Unix moderni.

  Infatti la velocit dei programmi solo molto di rado  limitata dalla
  quantit di tempo macchina a loro disposizione (ci sono alcune
  eccezioni a questa regola, quali il suono o la generazione di grafica
  3D). Molto pi spesso dei ritardi si generano quando il programma deve
  attendere dei dati da un disco o da una connessione di rete.

  Un sistema operativo che pu di norma gestire pi processi
  simultaneamente  detto "multitasking". La famiglia di sistemi
  operativi Unix  stata progettata fin dall'inizio per il multitasking
  e lo fa molto bene, in modo molto pi efficace rispetto a Windows o al
  Mac OS ai quali il multitasking  stato appiccicato a posteriori in
  seguito ad un ripensamento e lo fanno in modo piuttosto povero. Il
  multitasking efficiente ed affidabile costituisce buona parte di ci
  che rende Linux superiore per le applicazioni di rete, le
  comunicazioni e i servizi Web.


  9.  Come fa il computer a evitare che i processi si intralcino tra
  loro?

  Lo scheduler del kernel si prende cura di dividere il tempo tra i
  processi. Il vostro sistema operativo deve dividere tra i processi
  anche lo spazio, per evitare che non sconfinino oltre la porzione di
  memoria loro assegnata. Le operazioni compiute dal sistema operativo
  per risolvere questo problema si chiamano gestione della memoria.

  Ogni processo del vostro repertorio ha la propria area di memoria
  core, come luogo dal quale eseguire il proprio codice e dove
  immagazzinare le variabili e i risultati. Potete pensare a questo
  insieme come formato da un segmento codice, di sola lettura (che
  contiene le istruzioni del processo) e da un segmento dati (che
  contiene tutte le variabili immagazzinate dal processo). Il segmento
  dati  sempre unico per ogni processo, mentre nel caso due processi
  usino lo stesso codice Unix automaticamente fa in modo che condividano
  un unico segmento codice, come misura di efficienza.

  L'efficienza  importante, perch la memoria core  costosa. A volte
  non ne avete abbastanza per contenere per intero tutti i programmi che
  il computer sta eseguendo, specialmente se usate un grosso programma
  quale un server X. Per ovviare a questo problema Unix usa una
  strategia chiamata memoria virtuale. Non cerca di tenere in core tutti
  i dati ed il codice di un processo. Tiene piuttosto caricato solo un
  working set relativamente piccolo; il resto dello stato del processo
  viene lasciato in uno speciale spazio swap sul vostro disco fisso.

  Come i processi sono in esecuzione Unix tenta di anticipare i
  cambiamenti del working set per avere in memoria solo le parti che
  servono davvero. Riuscirci in modo efficace  ingegnoso e complesso,
  pertanto non cercher di descriverlo tutto qui, ma si basa sul fatto
  che il codice e i riferimenti ai dati tendono a comparire a gruppi, ed
   probabile che un nuovo gruppo si colleghi a luoghi vicini a quelli
  di uno precedente. Quindi se Unix tiene caricati i dati ed il codice
  usati pi di frequente (o di recente) di solito riuscir a risparmiare
  del tempo.

  Notate che in passato quel "A volte" di due paragrafi fa era un "Quasi
  sempre", perch la dimensione della memoria era tipicamente ridotta
  rispetto alla dimensione dei programmi in esecuzione, quindi il
  ricorso allo swap era frequente. Oggi la memoria  molto meno costosa
  e persino i computer di fascia bassa ne hanno parecchia. Sui moderni
  computer monoutente con 64MB di memoria e oltre  possibile eseguire X
  ed un tipico insieme di programmi senza neppure ricorrere allo swap.

  Anche in questa felice situazione la parte del sistema operativo
  chiamata gestore della memoria mantiene un importante ruolo da
  svolgere. Deve garantire che i programmi possano modificare soltanto
  il proprio segmento dati; deve cio impedire che del codice difettoso
  o malizioso in un programma rovini i dati di altri programmi. A questo
  scopo tiene una tabella dei segmenti dati e codice. La tabella 
  aggiornata non appena un processo richiede pi memoria oppure libera
  memoria (quest'ultimo caso ricorre di solito all'uscita dal
  programma).

  Questa tabella  usata per passare dei comandi a una parte
  specializzata dell'hardware sottostante chiamata MMU o unit di
  gestione della memoria. I processori moderni hanno MMU incorporate. La
  MMU ha la peculiare capacit di porre dei delimitatori attorno alle
  aree di memoria, in modo che un riferimento che sconfina venga
  rifiutato e faccia scattare uno speciale interrupt.

  Se avete mai visto un messaggio del tipo "Segmentation fault", "core
  dumped" o qualcosa del genere, questo  esattamente quello che 
  successo: un tentativo da parte del programma in esecuzione di
  accedere alla memoria al di fuori dal proprio segmento ha fatto
  scattare un interrupt fatale. Questo rivela un bug nel codice del
  programma; il core dump (scarico della memoria) che lascia dietro di
  s costituisce una informazione diagnostica volta ad aiutare il
  programmatore nell'individuazione del problema.


  10.  Come fa il computer a immagazzinare le cose in memoria?

  Probabilmente sapete che nel computer tutto viene immagazzinato come
  serie di bit (binary digits, cifre binarie; potete pensarle come molti
  piccoli interruttori on-off). Qui spiegheremo come vengono usati quei
  bit per rappresentare le lettere ed i numeri che il vostro computer
  sta macinando.

  Prima di arrivare a questo, dovete fare la conoscenza della dimensione
  di parola (word size) del vostro computer. La dimensione di parola 
  la dimensione preferita dal computer per muovere in giro unit di
  informazione; dal punto di vista tecnico  la capacit dei registri
  del processore, che sono i contenitori usati dal processore per fare
  calcoli aritmetici e logici. Quando leggete di computer con certe
  dimensioni di bit (ad esempio ``32-bit'' o ``64-bit''), si riferiscono
  a questo.

  La maggior parte dei computer (compresi 386, 486, Pentium e Pentium
  II) hanno una word size di 32 bit. I vecchi 286 avevano una dimensione
  di parola di 16 bit. I mainframe vecchio stile spesso usavano parole
  di 36-bit. Alcuni processori (come l'Alpha prodotto da quella che era
  DEC ed ora  Compaq) hanno parole di 64-bit. Parole di 64-bit
  diverranno pi comuni nei prossimi cinque anni; Intel ha in progetto
  la sostituzione del Pentium II con un chip a 64-bit chiamato `Merced'.

  Il computer vede la memoria core come una sequenza di parole numerate
  da zero ad un qualche valore elevato che dipende dalla quantit della
  vostra memoria. Quel valore  limitato dalla dimensione di parola, che
  nei vecchi 286 costringeva a dolorose acrobazie per accedere a grandi
  quantit di memoria. Non li descriver qui; fanno ancora venire gli
  incubi ai vecchi programmatori.


  10.1.  Numeri

  I numeri vengono rappresentati o come parole o come coppie di parole,
  a seconda della dimensione di parola del processore. Una parola per
  una macchina a 32-bit  la dimensione pi comune.

  L'aritmetica dei numeri si avvicina ma non coincide con la matematica
  a base due. Il bit di ordine inferiore vale 1, il successivo 2, poi 4
  e cos via come nella binaria pura. Ma i numeri con segno vengono
  rappresentati con notazione complemento a due. Il bit di ordine
  superiore  il bit di segno che rende la quantit negativa e ogni
  numero negativo si pu ottenere dal corrispondente valore positivo
  invertendo tutti i bit. Questo  il motivo per cui gli interi su una
  macchina a 32-bit vanno in una scala da -2^31 + 1 a 2^31 - 1 (dove ^ 
  l'operazione di elevamento a potenza, 2^3 = 8). Quel 32esimo bit viene
  usato per il segno.

  Alcuni linguaggi per computer danno accesso alla aritmetica senza
  segno che  quella liscia a base 2 con i soli numeri positivi e lo
  zero.

  La maggior parte dei processori e alcuni linguaggi possono gestire
  numeri in virgola mobile (capacit incorporata in tutti i processori
  recenti). I numeri in virgola mobile (floating-point) offrono una
  scala di valori molto pi ampia rispetto agli interi e consentono di
  esprimere frazioni. I modi nei quali questo viene fatto variano e sono
  piuttosto complessi per essere discussi in dettaglio, ma l'idea
  generale  molto simile a quella della cosiddetta `notazione
  scientifica', dove si pu scrivere (per esempio) 1.234 * 10^23; la
  codifica del numero  divisa in una mantissa (1.234) e una parte
  esponente (23) per il moltiplicatore a potenze di dieci.


  10.2.  Caratteri

  I caratteri sono normalmente rappresentati come stringhe di sette bit
  ciascuno in una codifica chiamata ASCII (American Standard Code for
  Information Interchange). Sui computer moderni, ciascuno dei 128
  caratteri ASCII sta nei sette bit inferiori di un otteto di 8-bit; gli
  otteti sono impacchettati in parole di memoria cosicch (ad esempio)
  una stringa di sei caratteri occupa solo due parole di memoria. Per
  vedere una tabella dei codici ASCII, digitate `man 7 ascii' al vostro
  prompt Unix.

  Il paragrafo precedente  fuorviante per due motivi. Quello meno
  importante  che il termine `otteto'  formalmente corretto ma
  raramente usato in concreto; la maggior parte delle persone si
  riferisce ad un otteto come ad un byte e si aspetta che i byte siano
  di otto bit. In senso proprio, il termine `byte'  pi generale;
  c'erano, ad esempio, macchine a 36-bit con byte da 9-bit (anche se
  probabilmente non ce ne saranno mai pi).

  Il motivo pi importante  che non tutto il mondo usa l'ASCII.
  Infatti, la maggior parte del mondo non pu -- ASCII, anche se va bene
  per l'inglese americano, non ha molti caratteri accentati e altri
  segni speciali che servono agli utenti di altre lingue. Anche
  l'inglese britannico si trova in difficolt per la mancanza del
  simbolo della sterlina.


  Ci sono stati numerosi tentativi di rimediare a questo problema. Tutti
  si servono del bit in pi che l'ASCII non utilizza, rendendolo la met
  inferiore di un insieme di 256 caratteri. Il pi diffuso  l'insieme
  di caratteri noto come `Latin-1' (pi formalmente ISO 8859-1). Questo
   l'insieme di caratteri predefinito per Linux, l'HTML e X. Microsoft
  Windows usa una variante del Latin-1 che aggiunge alcuni caratteri
  come le doppie apici in posti lasciati inutilizzati dal Latin-1 per
  ragioni storiche (per un resoconto dei problemi che questo causa, v.
  demoroniser <http://www.fourmilab.ch/webtools/demoroniser/>).

  Il Latin-1 gestisce la maggior parte delle lingue europee, inclusi:
  inglese, francese, tedesco, spagnolo, italiano, olandese, norvegese,
  svedese, danese. Tuttavia, neppure questo  sufficiente ed esiste
  tutta una serie di insiemi di caratteri da Latin-2 a -9 per gestire
  lingue quali greco, arabo, ebreo e serbo-croato. Per maggiori
  dettagli, v. ISO alphabet soup
  <http://www.utia.cas.cz/user_data/vs/documents/ISO-8859-X-
  charsets.html>.

  La soluzione definitiva  uno standard possente chiamato Unicode (e il
  suo gemello identico ISO/IEC 10646-1:1993). L'Unicode  identico al
  Latin-1 nelle sue 256 caselle inferiori. In aggiunta, su uno spazio di
  16-bit, include greco, cirillico, armeno, ebreo, arabo, devanagari,
  bengalese, gurmukhi, gujarati, oriya, tamil, telugu, kannada,
  malayalam, thai, lao, georgiano, tibetano, giapponese kana, l'insieme
  completo del coreano hangul moderno e un insieme unificato di
  ideogrammi cinesi giapponesi e coreani (CJK). Per maggiori dettagli,
  v. Unicode Home Page <http://www.unicode.org/>.


  11.  Come fa il computer a immagazzinare le cose su disco?

  Quando leggete un disco fisso su Unix vedete un albero di nomi di file
  e directory. Normalmente non avrete bisogno di andare oltre, ma pu
  essere utile avere maggiori dettagli se vi capita un crash del disco e
  dovete cercare di salvare dei file. Sfortunatamente non c' un buon
  modo per descrivere l'organizzazione del disco dal livello dei file in
  gi, quindi dovr partire dall'hardware e risalire.


  11.1.  Struttura di basso livello del disco e del file system

  La superficie del vostro disco, dove vengono immagazzinati i dati, si
  divide in una sorta di bersaglio per il tiro a freccette: in tracce
  circolari che sono poi `affettate' in settori. Dal momento che le
  tracce vicino al bordo esterno hanno area maggiore di quelle vicino al
  centro, le tracce esterne hanno pi settori rispetto a quelle interne.
  Ogni settore (o blocco disco) ha la stessa dimensione, che sui moderni
  Unix  generalmente pari a 1K binario (1024 parole da 8 bit). Ogni
  blocco  individuato da un indirizzo univoco, il numero di blocco
  disco.

  Unix divide il disco in partizioni disco. Ogni partizione  formata da
  una serie continua di blocchi che vengono usati separatamente da
  quelli delle altre partizioni, come file system oppure come spazio
  swap. La partizione con numero pi basso viene spesso trattata in modo
  speciale, come partizione di avvio dove si pu mettere un kernel da
  far partire.

  Ogni partizione  alternativamente uno spazio swap, usato per
  implementare ``memoria virtuale'', oppure un file system, usato per
  contenere i file. Le partizioni swap sono trattate proprio come una
  sequenza lineare di blocchi. I file system, invece, hanno bisogno di
  un modo per associare i nomi dei file alle sequenze di blocchi disco.
  Dal momento che la dimensione dei file aumenta, diminuisce, si
  modifica nel tempo, i blocchi dati di un file non saranno una sequenza
  lineare ma potranno essere disseminati su tutta la sua partizione
  (dipende da dove il sistema operativo riesce a trovare un blocco
  libero quando gliene serve uno).


  11.2.  Nomi dei file e delle directory

  All'interno di ciascun file system la corrispondenza tra i nomi e i
  blocchi viene assicurata da una struttura chiamata inode. C' un
  gruppo di questi elementi vicino al ``fondo'' (i blocchi a numerazione
  pi bassa) di ciascun file system (quelli pi bassi in assoluto sono
  usati a fini di manutenzione e di etichettatura, non ne parleremo
  qui). Ogni inode individua un file. I blocchi dati dei file si trovano
  sotto gli inode.

  Ciascun inode contiene una lista dei numeri di blocco disco relativi
  al file che individua. (Questa  una mezza verit, corretta solo per i
  file piccoli, ma il resto dei dettagli non  importante qui.)  Notate
  che l'inode non contiene il nome del file.

  I nomi dei file si trovano nelle strutture delle directory. Una
  struttura della directory associa i nomi ai numeri inode. Ecco perch,
  su Unix, un file pu avere pi nomi reali (o hard link); sono soltanto
  diverse voci di directory che puntano allo stesso inode.


  11.3.  Mount point

  Nel caso pi semplice, tutto il vostro file system Unix si trova su di
  una sola partizione disco. Anche se questa situazione si ritrova in
  qualche piccolo sistema Unix personale,  inusuale. Pi tipicamente
  esso  suddiviso tra pi partizioni disco, magari su diversi dischi
  fisici. Cos, per esempio, il vostro sistema pu avere una piccola
  partizione dove alloggia il kernel, una un po' pi grande dove si
  trovano i programmi di utilit del SO ed una molto pi grande dove ci
  sono le directory personali degli utenti.

  La sola partizione alla quale avrete accesso subito dopo l'avvio del
  sistema  la partizione root, che  (quasi sempre) quella dalla quale
  avete fatto il boot. Essa contiene la root directory del file system,
  il nodo superiore dal quale dipende tutto il resto.

  Le altre partizioni del sistema devono collegarsi a questa root
  affinch tutto il vostro file system multipartizione sia accessibile.
  Circa a met del processo di avvio, il vostro Unix render accessibili
  queste partizioni non root. Dovr montare ciascuna di esse su una
  directory della partizione root.

  Per esempio, se avete una directory chiamata `/usr', si tratta
  probabilmente di un mount point per una partizione che contiene molti
  programmi che fanno parte della distribuzione standard del vostro Unix
  ma che non sono necessari durante l'avvio iniziale.


  11.4.  Come viene cercato un file

  Ora possiamo guardare al file system dall'alto al basso. Ecco cosa
  succede quando aprite un file (quale, ad esempio,
  /home/esr/WWW/ldp/fundamentals.sgml):

  Il kernel parte dalla radice del vostro file system Unix (dalla
  partizione root). Cerca una directory chiamata `home'. Di solito
  `home'  un mount point per una grande partizione utente da qualche
  altra parte, cos va di l. Nella struttura della directory di livello
  pi alto di quella partizione utente cerca poi una voce chiamata `esr'
  e ne estrae un numero di inode. Va a quell'inode, vede che si tratta
  di una struttura di directory e cerca `WWW'. Estraendo quell'inode, va
  alla corrispondente sottodirectory e cerca `ldp'. Questo lo porta ad
  un altro inode di directory ancora. Aprendolo, trova il numero inode
  di `fundamentals.sgml'. Questo inode non  una directory, ma contiene
  piuttosto la lista dei blocchi disco associati al file.


  11.5.  Propriet dei file, permessi e sicurezza

  Per evitare che i programmi, in modo accidentale o malizioso, accedano
  a dati cui non dovrebbero accedere, Unix usa la caratteristica dei
  permessi. Questi furono originariamente ideati per gestire il
  timesharing proteggendo gli utenti multipli su uno stesso computer gli
  uni dagli altri, ancora ai tempi in cui Unix girava principalmente su
  costosi minicomputer condivisi.

  Per capire i permessi dei file, dovete richiamare alla mente la nostra
  descrizione degli utenti e dei gruppi dalla sezione ``Cosa succede al
  login?''. Ogni file  di propriet di un utente e di un gruppo. Questi
  sono inizialmente quelli del creatore del file; possono essere
  cambiati con i programmi chown(1) e chgrp(1).

  I permessi di base che possono essere associati con un file sono
  `lettura' (permesso di leggere i dati in esso contenuti), `scrittura'
  (permesso di modificarlo) e `esecuzione' (permesso di lanciarlo come
  programma). Ogni file ha tre serie di permessi: uno per l'utente che
  ne  proprietario, uno per qualunque utente del suo gruppo
  proprietario e uno per tutti gli altri. I `privilegi' che avete quando
  fate il login sono solo la possibilit di leggere, scrivere ed
  eseguire quei file per i quali i bit di permesso corrispondono al
  vostro user ID o uno dei gruppi cui appartenete.

  Per vedere come questi possono interagire e come lo Unix li mostra,
  guardiamo un listato di file di un ipotetico sistema Unix. Eccone uno:



       snark:~$ ls -l notes
       -rw-r--r--   1 esr      users         2993 Jun 17 11:00 notes




  Si tratta di un ordinario file di dati. Il listato ci dice che 
  posseduto dall'utente `esr' ed  stato creato di propriet del gruppo
  `users'. Probabilmente il computer pone tutti gli utenti ordinari in
  questo gruppo in modo predefinito; altri gruppi usati di frequente su
  macchine condivise sono `staff', `admin' o `wheel' (per ovvie ragioni,
  i gruppi non sono molto importanti sulle workstation per utente
  singolo o sui PC). Il vostro Unix potrebbe usare un diverso gruppo
  predefinito, magari uno con lo stesso nome del vostro user ID.

  La stringa `-rw-r--r--' rappresenta i bit di permesso per il file. Il
  primissimo trattino  la posizione del bit di directory; mostrerebbe
  `d' se il file fosse una directory. Dopo di questo, i primi tre posti
  sono i permessi utente, i secondi tre i permessi di gruppo e i terzi i
  permessi per gli altri (spesso chiamati `mondo' o `world'). Per questo
  file, l'utente proprietario `esr' pu leggere o scrivere il file, le
  altre persone nel gruppo `users' possono leggerlo e tutti gli altri al
  mondo possono leggerlo. Si tratta di un insieme di permessi tipico per
  un ordinario file di dati.

  Ora diamo un'occhiata ad un file con permessi differenti. Questo file
   GCC, il compilatore C GNU.


       snark:~$ ls -l /usr/bin/gcc
       -rwxr-xr-x   3 root     bin         64796 Mar 21 16:41 /usr/bin/gcc




  Questo file appartiene ad un utente chiamato `root' e ad un gruppo
  chiamato `bin'; pu essere scritto (modificato) solo da root, ma letto
  od eseguito da chiunque. Si tratta di propriet e insieme di permessi
  tipici per un comando pre-installato. Il gruppo `bin' esiste in alcuni
  Unix per raggruppare i comandi di sistema (il nome  un residuo
  storico, abbreviazione di `binari'). Il vostro Unix potrebbe invece
  usare un gruppo `root' (che non  proprio la stessa cosa dell'utente
  `root'!).

  L'utente `root'  il nome convenzionale per lo user ID di numero 0,
  uno speciale, privilegiato account che pu disporre di tutti i
  privilegi. Accedere come root  utile ma pericoloso: un errore di
  digitazione pu cancellare fondamentali file di sistema che lo stesso
  comando digitato da un utente ordinario non riuscirebbe ad intaccare.

  Dal momento che l'account root  cos potente, il suo accesso dovrebbe
  essere custodito con molta cura. La vostra password di root 
  l'informazione di sicurezza pi critica e fondamentale del vostro
  sistema ed  ci che qualunque cracker e intruso che vi dia la caccia
  mira ad ottenere.

  (Riguardo alle password: non scrivetele -- e non scegliete una
  password che possa essere facilmente indovinata, come il nome della
  vostra ragazza/o. Questa  una cattiva prassi incredibilmente comune
  che aiuta moltissimo i cracker...)

  Ora vediamo un terzo caso:



       snark:~$ ls -ld ~
       drwxr-xr-x  89 esr      users          9216 Jun 27 11:29 /home2/esr
       snark:~$




  Questo file  una directory (notate la `d' nella prima casella dei
  permessi). Vediamo che pu essere scritto solo da esr, ma letto ed
  eseguito da chiunque altro. I permessi vengono interpretati in maniera
  speciale quando riguardano una directory: regolano l'accesso ai file
  contenuti nella directory.

  Il permesso di lettura di una directory  semplice: significa soltanto
  che potete attraversare la directory per aprire i file e le directory
  in essa contenuti. Il permesso di scrittura attribuisce la capacit di
  creare e rimuovere file nella directory. Il permesso di esecuzione vi
  d la possibilit di cercare nella directory -- cio di listarla e
  vedere i nomi dei file e delle directory che contiene. A volte vedrete
  directory che sono leggibili da chiunque ma non eseguibili da
  chiunque: significa che un utente qualsiasi pu raggiungere i file e
  le directory in essa contenuti, ma solo conoscendo esattamente i loro
  nomi.

  Per finire, vediamo quali sono i permessi dello programma login
  stesso.




  snark:~$ ls -l /bin/login
  -rwsr-xr-x   1 root     bin         20164 Apr 17 12:57 /bin/login




  Ha i permessi che ci aspettiamo per un comando di sistema -- eccetto
  quella `s' dove ci dovrebbe essere il permesso di esecuzione per il
  proprietario. Questa  la visualizzazione di uno speciale permesso
  chiamato `set-user-id' o setuid bit.

  Il setuid bit  di solito associato a programmi che hanno bisogno di
  dare agli utenti ordinari i privilegi di root, ma in modo controllato.
  Quando  impostato su un programma eseguibile, vi sono consentiti i
  privilegi del possessore di quel file di programma mentre il programma
  sta funzionando per conto vostro.

  Come lo stesso account di root, i programmi setuid sono utili ma
  pericolosi. Chiunque riesca sovvertire o modificare un programma
  setuid di propriet di root pu usarlo per lanciare una shell con
  privilegi di root. Per questa ragione, aprire un file in scrittura
  disattiva automaticamente il setuid bit sulla maggior parte degli
  Unix. Molti attacchi alla sicurezza di Unix cercano di sfruttare bachi
  nei programmi setuid per sovvertirli. Gli amministratori di sistema
  consci dei problemi di sicurezza sono quindi estremamente cauti con
  questi programmi e riluttanti ad installarne di nuovi.

  Ci sono un paio di dettagli importanti che abbiamo trascurato parlando
  dei permessi. In particolare, come il gruppo proprietario e i permessi
  vengono assegnati quando un file viene creato per la prima volta. Il
  gruppo  un problema perch gli utenti possono far parte di pi
  gruppi, ma solo uno di questi (specificato nella voce dell'utente in
  /etc/passwd)  il gruppo predefinito dell'utente e avr normalmente la
  propriet dei file creati dall'utente.

  La storia dei bit di permesso iniziali  un po' pi complicata. Un
  programma che crea un file di solito specifica i permessi di partenza.
  Ma questi verranno modificati da una variabile d'ambiente dell'utente
  chiamata umask. La umask specifica quali bit di permesso disattivare
  al momento della creazione di un file. Il valore pi comune,
  predefinito nella maggior parte dei sistemi,  -------w- o 002, che
  disattiva il bit di scrittura per il mondo intero. Rifatevi alla
  documentazione del comando umask nella pagina di manuale della vostra
  shell per maggiori dettagli.


  11.6.  Come le cose possono andare male

  Prima accennavamo al fatto che i file system possono essere delicati.
  Ora sappiamo che per raggiungere un file dobbiamo fare il gioco della
  campana attraverso quella che pu essere una catena arbitrariamente
  lunga di riferimenti inode e directory. Supponiamo ora che sul vostro
  disco fisso si formi un punto danneggiato.

  Se siete fortunati ci vi far perdere solo qualche file di dati. Se
  invece siete sfortunati, si potrebbe danneggiare una struttura di
  directory o un numero inode e un intero sottoalbero del vostro sistema
  potrebbe rimanere pendente nel limbo. Oppure, peggio ancora, si
  potrebbe originare una struttura rovinata che punta in pi modi allo
  stesso blocco disco o inode. Un danneggiamento di questo tipo si pu
  propagare a partire da una normale operazione sui file, facendo
  perdere tutti i dati collegati al punto danneggiato di origine.

  Fortunatamente questo tipo di eventualit  divenuto abbastanza
  infrequente perch l'hardware dei dischi  pi affidabile. Tuttavia,
  questo comporta che il vostro Unix voglia controllare periodicamente
  l'integrit del file system per assicurarsi che non ci sia nulla fuori
  posto. Gli Unix moderni compiono un rapido controllo dell'integrit di
  ciascuna partizione nella fase di avvio, giusto prima di montarle.
  Ogni tot riavvii fanno un controllo molto pi approfondito che impiega
  qualche minuto in pi.

  Se tutto questo pu far sembrare che Unix sia terribilmente complesso
  e incline a malfunzionamenti, pu essere rassicurante sapere che
  questi controlli nella fase d'avvio tipicamente intercettano e
  correggono i problemi normali prima che diventino veramente
  disastrosi. Altri sistemi operativi non hanno questi strumenti, cosa
  che velocizza un po' l'avvio ma pu mettervi molto di pi nei pasticci
  quando cercate di fare un salvataggio a mano (e sempre assumendo che
  abbiate una copia delle Norton Utilities o simili, tanto per
  cominciare...).


  12.  Come funzionano i linguaggi per computer?

  Abbiamo gi discusso ``come vengono eseguiti i programmi''. Ogni
  programma in definitiva deve eseguire un flusso di byte che sono
  istruzioni nel linguaggio macchina del vostro computer. Ma gli esseri
  umani non se la cavano molto bene con il linguaggio macchina;
  riuscirci  divenuta un'arte rara, una magia nera persino tra gli
  hacker.

  Quasi tutto il codice Unix, ad eccezione di una piccola porzione
  relativa all'interfaccia diretta con l'hardware nel kernel, viene oggi
  scritto in un linguaggio di alto livello. (`Alto livello' in questa
  espressione  un residuo storico volto a distinguerlo dai linguaggi
  assembler di `basso livello', che sono fondamentalmente sottili
  involucri attorno al codice macchina.)

  Ci sono diversi tipi di linguaggi di alto livello. Per affrontare
  l'argomento troverete utile tenere a mente che il codice sorgente di
  un programma (la versione creata dall'uomo, editabile) deve passare
  attraverso un qualche tipo di traduzione in codice macchina che il
  computer pu effettivamente eseguire.


  12.1.  Linguaggi compilati

  Il tipo pi convenzionale di linguaggio  il linguaggio compilato. I
  linguaggi compilati vengono tradotti in file eseguibili di codice
  macchina binario da uno speciale programma chiamato (ovviamente)
  compilatore. Una volta che il codice binario  stato generato potete
  eseguirlo direttamente senza pi guardare al codice sorgente. (La
  maggior parte del software  fornita come binari compilati a partire
  da codice che non vedete.)

  I linguaggi compilati tendono a dare prestazioni eccellenti e hanno il
  pi completo accesso al SO, ma tendono anche a essere difficili da
  programmare.

  C, il linguaggio in cui Unix stesso  scritto,  di gran lunga il pi
  importante tra questi (con la sua variante C++). FORTRAN  un altro
  linguaggio ancora usato tra gli ingegneri e gli scienziati ma di anni
  pi vecchio e molto pi primitivo. Nel mondo Unix nessun altro
  linguaggio compilato  nell'uso dominante. Al di fuori di esso, il
  COBOL  molto usato per il software finanziario e commerciale.

  C'erano molti altri linguaggi compilati, ma la maggior parte di essi
  si sono estinti oppure sono strumenti strettamente di ricerca. Se
  siete nuovi sviluppatori Unix e usate un linguaggio compilato 
  estremamente probabile che questo sia il C o il C++.

  12.2.  Linguaggi interpretati

  Un linguaggio interpretato dipende da un programma interprete che
  legge il codice sorgente e lo traduce al volo in calcoli e chiamate di
  sistema. Il sorgente deve essere reinterpretato (e l'interprete deve
  essere presente) ogni volta che il codice viene eseguito.

  I linguaggi interpretati tendono ad essere pi lenti dei linguaggi
  compilati e spesso hanno accesso limitato al sistema operativo e
  all'hardware sottostanti. D'altra parte, essi tendono ad essere pi
  facili da programmare e pi propensi a perdonare gli errori di
  codifica rispetto ai linguaggi compilati.

  Molti programmi di utilit di Unix, inclusa la shell, bc(1), sed(1) e
  awk(1), sono in effetti piccoli linguaggi interpretati. I BASIC sono
  di solito interpretati. Cos pure il Tcl. Storicamente, il pi
  importante linguaggio interpretato  stato il LISP (un grande
  miglioramento rispetto ai suoi predecessori). Oggi il Perl  molto
  usato ed in costante crescita di popolarit.


  12.3.  Linguaggi a codice P

  Dal 1990  andato assumendo importanza crescente un tipo di linguaggi
  ibridi che usa sia la compilazione che l'interpretazione. I linguaggi
  a codice P sono come i linguaggi compilati nel senso che il sorgente
  viene tradotto in una forma binaria compatta che  ci che viene
  realmente eseguito, ma che non  esattamente codice macchina. Si
  tratta invece di pseudocodice (o codice P) che  solitamente molto pi
  semplice ma pi potente di un vero linguaggio macchina. Quando
  eseguite il programma, interpretate il codice P.

  Il codice P pu girare velocemente quasi quanto un binario compilato
  (gli interpreti di codice P possono essere abbastanza semplici,
  leggeri e rapidi). Ma i linguaggi a codice P riescono a mantenere la
  flessibilit e la potenza di un buon interprete.

  Importanti linguaggi a codice P includono il Python ed il Java.


  13.  Come funziona Internet?

  Per aiutarvi a capire come funziona Internet daremo un'occhiata alle
  cose che succedono quando fate una tipica operazione di Internet:
  indirizzate un browser alla prima pagina di questo documento, sul sito
  Web del Linux Documentation Project. L'indirizzo di questo documento 


  http://metalab.unc.edu/LDP/HOWTO/Fundamentals.html



  che significa che si trova nel file LDP/HOWTO/Fundamentals.html sotto
  la web directory dell'host sunsite.unc.edu.


  13.1.  Nomi e locazioni

  La prima cosa che il vostro browser deve fare  stabilire una
  connessione remota al computer dove si trova il documento. A tal fine
  deve prima trovare la locazione remota dell'host sunsite.unc.edu
  (`host'  la forma breve di `computer host' o `host remoto';
  sunsite.unc.edu  un tipico hostname). La locazione corrispondente 
  in realt un numero chiamato indirizzo IP (spiegheremo pi avanti la
  parte `IP' di questa espressione).

  A questo scopo il vostro browser interroga un programma chiamato name
  server. Il name server pu trovarsi sul vostro computer, ma  pi
  probabile che giri su un computer del fornitore col quale il vostro
  computer dialoga. Quando vi collegate ad un ISP una parte della
  procedura consiste quasi sicuramente nel dire al vostro software per
  Internet qual  l'indirizzo IP di un name server sulla rete dell'ISP.

  I name server sui vari computer si parlano tra loro, scambiandosi e
  tenendo aggiornate tutte le informazioni necessarie per risolvere i
  nomi degli host (per mapparli agli indirizzi IP). Il vostro name
  server pu interrogare tre o quattro diversi siti sulla rete nel
  processo di risoluzione di sunsite.unc.edu, ma di solito questo si
  verifica molto rapidamente (tipo in meno di un secondo).

  Il name server dir al vostro browser che l'indirizzo IP di Sunsite 
  152.2.22.81; a questo punto il vostro computer sar in grado di
  scambiare direttamente bit con sunsite.


  13.2.  Pacchetti e router


  Quello che il browser vuole  mandare al Web server su Sunsite un
  comando come questo:


  GET /LDP/HOWTO/Fundamentals.html HTTP/1.0



  Ecco cosa succede. Dal comando si costruisce un pacchetto, cio un
  blocco di bit come un telegramma che  `impacchettato' con tre cose
  importanti: l'indirizzo di provenienza (l'indirizzo IP del vostro
  computer), l'indirizzo di destinazione (152.2.22.81) e un numero di
  servizio o numero di porta (in questo caso 80) che indica che si
  tratta di una richiesta World Wide Web.

  Il vostro computer spedisce allora il pacchetto lungo il cavo (la
  connessione modem al vostro ISP o rete locale) finch arriva ad un
  computer specializzato chiamato router. Il router ha nella sua memoria
  una mappa di Internet, non sempre una completa, ma una che descrive
  completamente il vostro vicinato di rete e sa come raggiungere i
  router per altri circondari di Internet.

  Il vostro pacchetto potrebbe passare attraverso svariati router lungo
  la strada per la sua destinazione. I router sono intelligenti.
  Guardano quanto tempo impiegano gli altri router per avvertire che
  hanno ricevuto un pacchetto. Usano questa informazione per dirigere il
  traffico verso i collegamenti veloci. La usano per accorgersi se un
  altro router (o un cavo) sono fuori servizio o irraggiungibili e
  quindi, se possibile, ovviare al problema trovando un'altra strada.

  C' una leggenda metropolitana secondo la quale Internet  stata
  progettata per sopravvivere alla guerra nucleare. Questo non  vero,
  ma la struttura di Internet  estremamente adatta ad ottenere
  prestazioni affidabili anche con l'hardware precario che caratterizza
  questo mondo incerto. Questo deriva direttamente dal fatto che la sua
  intelligenza  distribuita tra migliaia di router piuttosto che
  riunita in poche enormi centrali (come la rete telefonica). Questo
  significa che i malfunzionamenti tendono a essere ben localizzati e la
  rete pu aggirarli.

  Una volta che il vostro pacchetto  giunto al computer di destinazione
  quest'ultimo usa il numero di servizio per inviare il pacchetto al
  server web. Il server web pu capire a chi rispondere guardando
  l'indirizzo IP di provenienza del pacchetto con il comando. Quando il
  server web restituisce questo documento lo suddivide in un certo
  numero di pacchetti. La dimensione dei pacchetti varia a seconda del
  mezzo di trasmissione sulla rete e del tipo di servizio.


  13.3.  TCP e IP

  Per capire come vengono gestite le trasmissioni a pacchetti multipli,
  dovete sapere che Internet in realt usa due protocolli, uno
  sovrapposto all'altro.

  Il livello pi basso, l'IP (Internet Protocol), sa come prendere
  singoli pacchetti da un indirizzo di provenienza a un indirizzo di
  destinazione ( per questo che si chiamano indirizzi IP). Tuttavia
  l'IP non  affidabile: se un pacchetto si perde o cade i computer di
  origine e di destinazione possono non venirne mai a conoscenza. Nel
  gergo delle reti, l'IP  un protocollo senza connessione; il mittente
  si limita a far partire un pacchetto per il destinatario e non si
  aspetta un avviso di ricevuta.

  L'IP  veloce ed economico, comunque. A volte veloce, economico e
  inaffidabile va bene. Quando giocate in rete a Doom o Quake, ogni
  pallottola  rappresentata da un pacchetto IP. Se alcune vengono
  perse, pazienza.

  Il livello superiore, TCP (Transmission Control Protocol), vi d
  affidabilit. Questi due computer negoziano una connessione TCP (cosa
  che fanno usando l'IP); il ricevente sa che deve spedire al mittente
  un avviso di ricevuta dei pacchetti che legge. Se il mittente non vede
  un avviso di ricevuta per un pacchetto entro un certo periodo di tempo
  (timeout) allora rispedisce quel pacchetto. Inoltre, il mittente
  attribuisce ad ogni pacchetto TCP un numero di sequenza, che il
  ricevente pu usare per riassemblare i pacchetti nel caso che
  risultino in disordine. (Cosa che si verifica se un collegamento della
  rete viene attivato o cade durante una connessione.)

  I pacchetti TCP/IP contengono anche un checksum per consentire
  l'individuazione di dati rovinati da collegamenti difettosi. Cos, dal
  punto di vista di chiunque usi il TCP/IP e i name server, sembra
  affidabile passare flussi di byte in coppie hostname/numero di
  servizio. Chi scrive i protocolli di rete non deve quasi mai pensare
  agli aspetti di basso livello relativi alla pacchettizzazione, al
  riassemblaggio dei pacchetti, al controllo degli errori, al checksum e
  alla ritrasmissione.


  13.4.  HTTP, un protocollo applicativo

  Torniamo ora al nostro esempio. I browser ed i server web dialogano
  usando un protocollo applicativo che si appoggia al TCP/IP, usandolo
  semplicemente come un modo per passare stringhe di byte avanti e
  indietro. Questo protocollo  chiamato HTTP (Hyper-Text Trasfer
  Protocol, protocollo per il trasferimento di ipertesti) e abbiamo gi
  visto un suo comando: il GET mostrato sopra.

  Quando il comando GET arriva al server web sunsite.unc.edu con numero
  di servizio 80 verr notificato al demone server che  in attesa sulla
  porta 80. La maggior parte dei servizi Internet sono implementati da
  demoni server che si limitano ad ascoltare sulle porte, attendono ed
  eseguono i comandi in arrivo.

  Se il disegno di Internet ha una regola generale, questa  che tutte
  le parti dovrebbero essere il pi possibile semplici e accessibili per
  gli esseri umani. L'HTTP e i suoi simili (come il Simple Mail Transfer
  Protocol, SMTP, che viene usato per trasferire la posta elettronica
  tra gli host) tende a usare comandi in semplice testo stampabile che
  terminano con un codice di carriage return/line feed.

  Questo  marginalmente inefficiente: in qualche circostanza potreste
  ottenere una velocit maggiore usando un protocollo binario di stretta
  codifica. Ma l'esperienza ha dimostrato che i benefici di avere
  comandi facili da descrivere e comprendere per gli esseri umani supera
  qualsiasi marginale guadagno di efficienza che si possa ottenere al
  prezzo di rendere le cose oscure e complicate.

  Di conseguenza, quello che il demone server vi rispedisce via TCP/IP 
  anch'esso testo. L'inizio della risposta assomiglier in qualche modo
  a questa (alcuni header sono stati omessi):


  HTTP/1.1 200 OK
  Date: Sat, 10 Oct 1998 18:43:35 GMT
  Server: Apache/1.2.6 Red Hat
  Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT
  Content-Length: 2982
  Content-Type: text/html



  Questi header saranno seguiti da una linea vuota e dal testo della
  pagina web (dopodich la connessione viene lasciata cadere). Il vostro
  browser si limita a visualizzare quella pagina. Gli header servono a
  spiegargli come (in particolare, l'header Content-Type gli dice che i
  dati restituiti sono veramente HTML).