:Author: Andrea Manni
:Copyright: GFDL
- :Version: 1.5
+ :Version: 1.51
.. contents:: Indice degli argomenti
Generato con: http://docutils.sourceforge.net/rst.html
+Appunti introduttivi alla trattazione dei sistemi operativi, le loro caratteristiche, componenti essenziali, tratti distintivi.
Sistema operativo
==================
+Il sistema operativo e' un software, ma per poter comprendere la funzione e il suo particolare rapporto con gli altri software disponibili sul vostro computer sara' prima necessario introdurre alcune sue caratteristiche e elementi distintivi.
+
+Quando questi concetti saranno stati acquisiti verra' presentata una definizione *ragionevole* del termine "sistema operativo".
+
+
Concetti introduttivi
----------------------
---------
I flussi di dati in uscita, normalmente i risultati aspettati dall'operatore. Tipiche periferiche di output dedicate sono i monitor, le casse audio, le stampanti. Come nel caso dell'input possiamo considerare periferiche come le schede di rete come di input/output. Nei sistemi operativi *Unix si fa riferimento allo **standard output** (stdout, fisicamente puo' essere dirottato sul diverse periferiche a seconda della natura dei dati (pensiamo a un file audio: verra' mandato alla scheda audio e da questa alle casse. Sarebbe poco significativo se visualizzato a schermo, e poco gradevole il caso inverso: ad es. telefonare a qualcuno e sentirsi rispondere da un FAX.) ma normalmente ci aspettiamo di vedere i risultati *a schermo*: sul nostro terminale ``/dev/tty*`` o equivalente. ).
+
+Stdout verso un file::
+
+ ls -l > ls-l.txt
+
+Stdout di un comando verso lo stdin di un altro comando (un pipe!)::
+
+ ls | toilet
+
+Stdout verso il primo teletype virtuale [ALT+F1]::
+
+ echo "Questo l'ho scritto io" > /dev/tty1
+
+
Errors
---------
Non sempre le nostre aspettative nei confronti dell'elebarotore vengono soddisfatte, talvolta il nostro programma genera errori e un risultato solo parziale. Nei sistemi *Unix questo tipo di *output* viene indicato come **standard error** (stderr) e puo' essere reindirizzato su una canale diverso dal normale output. Ad esempio suonando una serie di brani musicali l'output viene indirizzato fino alle casse del computer, ma se un brano risulta illeggibile viene visualizzato un errore a *schermo*. Situazione simile nel caso di una stampa: l'output va' alla stampante me se durante la stampa si generano messaggi di errore questi non compariranno sulla carta.
Questa possibilita' di canalizzare lo stdout e lo stderr verra' utile in seguito quando si avra' l'esigenza di pianificare operazioni svolte in automatico (es. script di back-up) durante le quali l'operatore non e' disponibile per leggere gli errori, che potranno essere re-indirizzati su un file di log o altro.
+Stderr verso un file::
+
+ ls non-esiste 2> error
+
+
Interfaccia utente
--------------------
Il sistema formato da periferiche (es tastiera e monitor) che permette lo scambio di informazioni tra l'utente e l'elaboratore. Tutti i sistemi multifunzione (cioe' che possono svolgere piu' di un singolo compito) sono dotati di una interfaccia utente. I sistemi *multi-pourpose* hanno interfacce utente piu' sofisticate rispetto alle macchine dedicate: ad es. un personal computer ha un'interfaccia utente piu' completa rispetto ad una console per videogiochi o a un cellulare. Le interfacce utente possono essere di diverso tipo:
--------------
I sistemi multiutenti possono avere piu' utenti attivi contemporaneamente (ma anche uno alla volta a seconda della disponibilita' di input).
-Il sistema e' comunque in grado di distinguere tra gli utenti: ad es. mia sorella non ha la possibilita' di eliminare le MIE foto, e viceversa. La multiutenza sotto il profilo tecnico si appoggia su un software di autenticazione / log-in per distinguere gli utenti, oltre a funzionalita' delegate al file system per limitare accessi ed esecuzione dei file ai diversi utenti di sistema. Ad esempio il filesystem FAT32_ dei vecchi sistemi Windows (e usato sulla maggior parte delle chiavette USB e memory card varie) non permette la gestione delle propieta' dei files.
+Il sistema e' comunque in grado di distinguere tra gli utenti: ad es. mia sorella non ha la possibilita' di eliminare le MIE foto, e viceversa. Per garantire una *vera* multiutenza sara' necessario un sistema di autenticazione per distinguere gli utenti, oltre a funzionalita' delegate al file system per limitare accessi ed esecuzione dei file ai diversi utenti di sistema. Ad esempio il filesystem FAT32_ dei vecchi sistemi Windows (e usato sulla maggior parte delle chiavette USB e memory card varie) non permette la gestione della propieta' dei files.
.. _FAT32: http://it.wikipedia.org/wiki/FAT32#FAT32
-La presenza di piu' utenti in genere prevede una gerarchia tra questi (ad esempio *user, power user, administrator* sotto sistemi Windows o l'utente *root* per sistemi Unix). In genere si ha un solo utente abilitato alle modifiche delle funzionalita' del sistema (l'amministratore, che puo' abilitare le periferiche o installare nuovo software nel sistema) e semplici *utenti di sistema* (``system users``) che possono solo usufruire dei programmi messi a loro disposizione. Questa soluzione, oltre che a garantire la presenza di un account in grado di rimediare in caso di emergenza a eventuali errori fatti da altri, permette di avere un ambiente di lavoro piu' sicuro dato che una volta loggati come utenti di sistema non si ha la possibilita' di causare danni gravi all'intero sistema per una semplice distrazione. *Mai lavorare come amministratori quando non e' assolutamente necessario.*
+La presenza di piu' utenti in genere porta a una gerarchia tra questi (ad esempio *user, power user, administrator* sotto sistemi Windows o l'utente *root* per sistemi Unix). In genere si ha un solo utente abilitato alle modifiche delle funzionalita' del sistema (l'amministratore, che puo' abilitare le periferiche o installare nuovo software nel sistema) e semplici *utenti di sistema* (``system users``) che possono solo usufruire dei programmi messi a loro disposizione. Questa soluzione, oltre che a garantire la presenza di un account in grado di rimediare in caso di emergenza a eventuali errori fatti da altri, permette di avere un ambiente di lavoro piu' sicuro dato che una volta loggati come *utenti di sistema* non si ha la possibilita' di causare danni gravi all'intero sistema per una semplice distrazione. **Mai lavorare come amministratori quando non e' assolutamente necessario.**
Sistema operativo
Sara' il sistema operativo a identificare gli utenti al momento di cominciare una sessione di lavoro, e garantisce gli accessi ai files in base a queste credenziali (e alle caratteristiche del file system, cosa che approfondiremo successivamente).
-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 e una 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.
+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* sul 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`` non funzionerebbe sul sistema ``Y``.
+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``.
+.. [#] Sarebbe piu' corretto parlare di incompatibilita' tra i membri di famglie di sistemi operativi tra loro diversi, ma allo stato attuale delle nostre conoscenze non complichiamoci la vita: l'eseguibile di Openoffice.org per Windows non funziona su Gnu/Linux.
I sistemi operativi, come del resto i singoli applicativi, sono rilasciati (quando possibile) in versioni a 32 o 64 bit, oppure per architetture diverse (x86, PPC, Arm, RISC...). In genere si indica la possibilita' di un OS di *girare* su architetture hardware diverse col termine *portabilita'*. Una maggiore portabilita', oltre che per l'intrinseco vantaggio, e' spesso indice di maggiore stabilita' in quanto il test del sistema in ambienti diversi permette di evidenziare *bug* difficilmente riscontrabili altrimenti.
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
====================== ========== ============
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:
========= ================ ===========
projects / doc / .git / blobdiff