Altre correzioni, ortografia e vocabolario locale.
[gapil.git] / intro.tex
index dbddfbff95a0f01f642880838504376cf5e54348..23f677bb1247d40881205f2d3805a859d72a86cf 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -1,6 +1,6 @@
 %% intro.tex
 %%
-%% Copyright (C) 2000-2005 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -8,6 +8,7 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
+
 \chapter{L'architettura del sistema}
 \label{cha:intro_unix}
 
@@ -62,14 +63,14 @@ all'hardware, mentre i programmi normali vengono eseguiti in modalit
 (e non possono accedere direttamente alle zone di memoria riservate o alle
 porte di input/output).
 
-Una parte del kernel, lo \textit{scheduler}\itindex{scheduler}, si occupa di
+Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
 stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
 priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
-cosiddetto \textit{prehemptive
-  multitasking}\itindex{prehemptive~multitasking}).  Questo verrà comunque
-eseguito in modalità protetta; quando necessario il processo potrà accedere
-alle risorse hardware soltanto attraverso delle opportune chiamate al sistema
-che restituiranno il controllo al kernel.
+cosiddetto \itindex{prehemptive~multitasking} \textit{prehemptive
+  multitasking}).  Questo verrà comunque eseguito in modalità protetta; quando
+necessario il processo potrà accedere alle risorse hardware soltanto
+attraverso delle opportune chiamate al sistema che restituiranno il controllo
+al kernel.
 
 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
 \textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a
@@ -117,13 +118,13 @@ avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
   un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
   stringhe delle scarpe'', per indicare il compito, almeno apparentemente
   impossibile, di far eseguire un programma a partire da un computer appena
-  acceso che appunto non ne contiene nessuno; non è impossibile appunto perché
-  in realtà c'è un programma iniziale, che è appunto il BIOS.}), incaricandosi
-di caricare il kernel in memoria e di farne partire l'esecuzione;
-quest'ultimo, dopo aver inizializzato le periferiche, farà partire il primo
-processo, \cmd{init}, che è quello che a sua volta farà partire tutti i
-processi successivi. Fra questi ci sarà pure quello che si occupa di dialogare
-con la tastiera e lo schermo della console, e quello che mette a disposizione
+  acceso che appunto non ne contiene nessuno; non è impossibile perché in
+  realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
+caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
+dopo aver inizializzato le periferiche, farà partire il primo processo,
+\cmd{init}, che è quello che a sua volta farà partire tutti i processi
+successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
+tastiera e lo schermo della console, e quello che mette a disposizione
 dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
 inviare i comandi.
 
@@ -187,7 +188,7 @@ usate nella programmazione.
 
 Questo è importante da capire perché programmare in Linux significa anzitutto
 essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C, implementano direttamente
+del C, in quanto né il kernel, né il linguaggio C implementano direttamente
 operazioni comuni come l'allocazione dinamica della memoria, l'input/output
 bufferizzato o la manipolazione delle stringhe, presenti in qualunque
 programma.
@@ -517,7 +518,7 @@ asincrono (sez.~\ref{sec:file_asyncronous_io}).
 
 
 
-\subsection{Lo standard X/Open -- XPG3}
+\subsection{Lo standard X/Open}
 \label{sec:intro_xopen}
 
 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
@@ -550,13 +551,13 @@ versione di Spec 1170 divent
   Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
 
 
-\subsection{Gli standard Unix  -- Open Group}
+\subsection{Gli standard Unix}
 \label{sec:intro_opengroup}
 
 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
-alla costituzione dell'Open Group, un consorzio internazionale che raccoglie
-produttori, utenti industriali, entità accademiche e governative.
+alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
+raccoglie produttori, utenti industriali, entità accademiche e governative.
 
 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
 il lavoro di standardizzazione delle varie implementazioni, rilasciando
@@ -575,7 +576,7 @@ del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard.
 \label{sec:intro_bsd}
 
 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
-di Berkley e la AT\&T generò una delle prime e più importanti fratture del
+di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
 mondo Unix.  L'Università di Berkley proseguì nello sviluppo della base di
 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
 versioni allora disponibili, fino ad arrivare al rilascio di una versione
@@ -583,7 +584,7 @@ completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 della AT\&T.
 
 Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
-dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e
+dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
 API di grande rilievo, come i link simbolici, la funzione \code{select} ed i
 socket.
 
@@ -707,10 +708,10 @@ Le macro disponibili per i vari standard sono le seguenti:
 \end{basedescript}
 
 In particolare è da sottolineare che le \acr{glibc} supportano alcune
-estensioni specifiche GNU, che non sono comprese in nessuno degli
-standard citati. Per poterle utilizzare esse devono essere attivate
-esplicitamente definendo la macro \macro{\_GNU\_SOURCE} prima di
-includere i vari header file.
+estensioni specifiche GNU, che non sono comprese in nessuno degli standard
+citati. Per poterle utilizzare esse devono essere attivate esplicitamente
+definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header
+file.
 
 
 %% \subsection{Gli standard di GNU/Linux}
@@ -720,11 +721,6 @@ includere i vari header file.
 
 
 
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: "gapil"
-%%% End: 
-
 % LocalWords:  like kernel multitasking scheduler prehemptive sez swap is cap
 % LocalWords:  everything bootstrap init shell Windows Foundation system call
 % LocalWords:  fig libc uClib glibc embedded Library POSIX username PAM Methods
@@ -741,4 +737,10 @@ includere i vari header file.
 % LocalWords:  socket Spec Novell Specification SUSv CDE Motif Berkley select
 % LocalWords:  SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
 % LocalWords:  drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
-% LocalWords:  LARGEFILE Support LFS
+% LocalWords:  LARGEFILE Support LFS dell'
+
+
+%%% Local Variables: 
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: