Modified sistemi

diff --git a/source/sistemi.txt b/source/sistemi.txt
index 197409dd9c1997be270dafa0ab064b87f66044c9..22aef22e53af70003d695aef3269814feb36a7e9 100644 (file)
--- a/source/sistemi.txt
+++ b/source/sistemi.txt
@@ -7,7 +7,7 @@ Appunti introduttivi ai sistemi operativi
 
   :Author: Andrea Manni
   :Copyright: GFDL
-  :Version: 1.5
+  :Version: 1.51
 
 .. contents:: Indice degli argomenti
 
@@ -133,6 +133,7 @@ Sara' il sistema operativo a identificare gli utenti al momento di cominciare un
 L'OS si pone poi come tramite tra i singoli applicativi e le risorse di sistema. Ad esempio se sono disponibili diversi programmi in grado di produrre stampe ma una sola stampante, sara' il sistema operativo a gestire le code di stampa in modo che non si intralcino (a dire il vero l'esempio potrebbe non essere tecnicamente esatto. Ma rende l'idea.) I singoli programmi non utilizzeranno direttamente la stampante, ma semplicemente si *interfacceranno* all'OS al momento della stampa.
 
 Quando installiamo un nuovo editor di testo non ci preoccupiamo di fornirgli un *driver* per la stampa. Sappiamo che questo e' gia' disponibile al sistema operativo, e i singoli applicativi si appoggeranno a questo. Questo "*layer di astrazione*" sull'utilizzo delle periferiche (al quale partecipa anche il kernel) semplifica di molto la realizzazione e l'installazione dei singoli software, garantendo maggiore stabilita' all'intero *sistema*.
+Lo stesso vale per alcune funzionalita' di base dei software identificabili nelle cosi' dette *librerie condivise* gestite dal sistema operativo e utilizzate da piu' applicativi, riducendo cosi' ridondanza, spazio utilizzato su disco, possibilita' di conflitti. 
 
 In modo simile tutti gli applicativi che utilizziamo si *appoggiano* al sistema operativo, tanto che siamo abituati ad avere *versioni diverse* degli stessi software rilasciate per i *diversi sistemi* (c'e' una versione di Openoffice.org per sistemi Microsoft, Gnu\Linux, Apple e cosi' via). Ovviamente la versione per il sistema [#]_  ``X`` generalmente non funziona sul sistema ``Y``. 
 
@@ -310,12 +311,14 @@ File
 Un file e' un insieme di dati  con un inizio e una fine identificabile in mezzo ad altri.
 
 Quindi avremo:
-       * un identificatore, come un ``nome_file`` accoppiato al suo *percorso* sul file system (possono esserci molti file con lo stesso nome ma non possono esserci due file on lo stesso nome nella stessa cartella).
+       * un identificatore, come un ``nome_file`` accoppiato al suo *percorso* sul file system: possono esserci molti file con lo stesso nome ma non possono esserci due file con lo stesso nome nella stessa cartella. Es:
+               * /home/lisa/documento_testo
+               * /home/bob/Desktop/documento_testo
        
-       * Un qualche *sistema* per recuperare quel file in mezzo ad altri. Ad esempio potremmo pensare, in un sistema molto rudimentale, a una coppia di coordinate che ci permettano di identificare il punto di inizio e il termine su un block device.
+       * Un qualche *sistema* per recuperare quel file in mezzo ad altri. Ad esempio potremmo pensare, in un sistema molto rudimentale, a una coppia di coordinate che ci permettano di identificare il punto di inizio e il termine della parte di dati di nostro interesse sul  block device su cui e' contenuto.
 
 ====================== ========== ============
-     Filestem elementare
+     Filesytem elementare
 ----------------------------------------------
 Identificatore          inizio         fine
 ====================== ========== ============
@@ -352,15 +355,15 @@ Tali strumenti sono diffusi tipicamenti sui sistemi basati su software libero, i
 
 Cerchiamo di capire meglio il processo: L'autore / sviluppatore di un software (ad esempio un browser web come Mozilla Firefox) rilascia il suo lavoro con una licenza libera, che prevede la possibilita' di ottenere il codice sorgente, modificarlo e redistribuirlo. A questo punto un **mantainer** della distribuzione, che non deve per forza essere l'autore del software originale, scarica il sorgente, lo modifica in modo che si integri con gli altri software del sistema operativo, preoccupandosi che i file di configurazione, temporanei, ecc. vengano collocati sul file-system in modo analogo agli altri software del sistema operativo, in modo da ottenere un sistema il piu' possibile omogeneo e *strutturato*. Il mantainer quindi non introduce nuove funzionalita' nel software (per lo meno non nella distribuzione di cui si occupa, nel caso provvederebbe a fornire le modifiche all'autore in modo che sia lui stesse ad integrarle nella versione *ufficiale*, cosi' che poi anche chi non usa quella determinata distribuzione possa avantaggiarsene): si limita ad *adattarlo* perche possa ben funzionare nella distribuzione.
 
-Quindi possiamo dire che un software come ad es. Apache o Firefox sono funzionalmente identici in ogni distribuzione, cambia solo il loro livello di integrazione nel sistema operativo. Come gia' detto le distribuzioni si caratterizzano per la *qualita'* di questa integrazione, il numero di pacchetti che riescono a gestire, l'efficacia dei software di installazione / aggiornamento / rimozione. 
+Quindi possiamo dire che un software come ad es. Apache o Firefox sono funzionalmente identici in ogni distribuzione, cambia solo il loro livello di integrazione nel sistema operativo. Come gia' detto le distribuzioni si caratterizzano per la *qualita'* di questa integrazione, il numero di pacchetti che mettono a disposizione, l'efficacia dei software di installazione / aggiornamento / rimozione. 
 
-Non ultima per importanza: l'attenzione alle problematiche legate alla sicurezza. Infatti e' bene tener presente che sara' il mantainer a dover provvedere tempestivamente all'aggiornamento del pacchetto in caso di problemi di sicurezza, dato che l'utente finale non interagisce direttamente con l'autore del software. Il che puo' porre il seguente problema: quando l'autore rileva un problema tende spesso a risolverlo con una versione aggiornata del software (quindi si passa ad es dalla versione 1.0 alla 1.1 , e gia' che si rilascia magari si coglie l'occasione per introdurre nuove funzionalita'). Ma una distribuzione per essere definita *stabile* **deve** rimanere costante, altrimenti diventa impossibile controllare possibili conflitti tra i diversi software. In questo caso, le i mantainers delle distribuzioni dedicate al *lato server* o comunque con particolare vocazione alla sicurezza, si attivano per *portare* loro stessi i soli aggiornamente della sicurezza alla versione precedente del software in modo che eventuali nuove funzionalita' non possano rischiare di compromettere l'interazione del software con altri presenti sul sistema.
+Non ultima per importanza: l'attenzione alle problematiche legate alla sicurezza. Infatti e' bene tener presente che sara' il mantainer a dover provvedere tempestivamente all'aggiornamento del pacchetto in caso di problemi di sicurezza, non essendo l'utente finale a interagire direttamente con l'autore del software. Il che puo' porre il seguente problema: quando l'autore rileva un problema tende spesso a risolverlo con una versione aggiornata del software (quindi si passa ad es dalla versione 1.0 alla 1.1 , e gia' che si rilascia magari si coglie l'occasione per introdurre nuove funzionalita'). Ma una distribuzione per essere definita *stabile* **deve** rimanere costante, altrimenti diventa impossibile controllare possibili conflitti tra i diversi software. In questo caso, i mantainers delle distribuzioni dedicate al *lato server* o comunque con particolare vocazione alla sicurezza, si attivano per *portare* i soli aggiornamente della sicurezza alla versione precedente del software in modo che eventuali nuove funzionalita' non possano rischiare di compromettere l'interazione del software con altri presenti sul sistema o creati dall'utente.
 
-Distribuzioni come *Debian* lavorano in questo modo, altre preferiscono un approccio piu' *rilassato*: tipicamente perche mettono a disposizione dell'utente software aggiornato piu' frequentemente, atteggiamento molto gradito sulle *work station* degli utenti che possono cosi' avvantaggiarsi piu' rapidamente di nuove funzionalita'. Se il software viene aggiornato *molto rapidamente* l'utente fianale non puo' aspettarsi che l'integrazione tra i vari pacchetti sia stata testata per lunghi periodi!
+Distribuzioni come *Debian* lavorano in questo modo, altre preferiscono un approccio piu' *rilassato*: tipicamente perche' mettono a disposizione dell'utente software aggiornato piu' frequentemente, atteggiamento molto gradito sulle *work station* degli utenti che possono cosi' avvantaggiarsi piu' rapidamente di nuove funzionalita'. Se il software viene aggiornato *molto rapidamente* l'utente fianale non puo' aspettarsi che l'integrazione tra i vari pacchetti sia stata testata per lunghi periodi!
 
-Cio' non toglie che gli utenti di Debian possano decidere di utilizzare le release *Sid/unstable* o *testing* che vengono aggiornate quotidianamente. Ma sulle macchine che devono restare stabili senza creare problemi quotidianamente si puo' contare sulla versione *stable*, che garantisce due o tre anni di *ragionevole quiete senza sorprese*. Dal momento in cui si raggiunge la stabilita' del sistema con le funzionalita' richieste, in ambiente *aziendale* non si avverte la necessita' di avere sempre a disposizione l'ultima release disponibile di un software col rischio che si possano verificare problemi. Un software appena rilasciato non puo' vantare stabilita': questa infatti  non e' un concetto *assoluto*: la stabilita' si ottiene facendo girare sempre la stessa versione del software  sul piu' ampio bacino di utenza in modo da poter individuare e risolvere gli eventuali problemi che mano a mano si individuano. La stabilita', per quanto riguarda il software  *consumer*, e' relativa (allo stesso modo la *sicurezza* non e' uno *status* ma piuttosto un *processo*: i problemi si possono sempre verificare, tutto sta nella capacita' e tempi di reazione per risolverli con aggiornamenti).
+Cio' non toglie che gli utenti di Debian possano decidere di utilizzare le release *Sid/unstable* o *testing* che vengono aggiornate quotidianamente. Ma sulle macchine che vogliamo restino stabili senza creare problemi quotidianamente si puo' contare sulla versione *stable*, che garantisce due o tre anni di *ragionevole quiete senza sorprese*. Dal momento in cui si raggiunge la stabilita' del sistema con le funzionalita' richieste, in ambiente *aziendale* non si avverte la necessita' di avere sempre a disposizione l'ultima release disponibile di un software con la possibilita' che si possano verificare problemi. Un software appena rilasciato non puo' vantare stabilita': questa infatti  non e' un concetto *assoluto*: la stabilita' si ottiene facendo girare sempre la stessa versione del software  sul piu' ampio bacino di utenza disponibile in modo da poter individuare e risolvere gli eventuali problemi che mano a mano si individuano. La stabilita', per quanto riguarda il software  *consumer*, e' relativa (allo stesso modo la *sicurezza* non e' uno *status* ma piuttosto un *processo*: i problemi si possono sempre verificare, la differenza  sta nelle capacita' e tempi di reazione per risolverli con aggiornamenti, nelle precauzioni e test preliminari ritenuti necessari per poter introdurre nuove versioni dei software nel sistema).
 
-Ci sono 3 principali gestori di pacchetti in generale:
+I gestori di pacchetti principali sono tre:
 
 
 ========= ================  ===========