Guida per principianti a GNU/Linux: cos’è e a cosa serve un sistema operativo

Avatar utente
Etabeta
Messaggi: 945

Guida per principianti a GNU/Linux: cos’è e a cosa serve un sistema operativo

Messaggio #1 »

domenica, 1. gennaio 2012, 12:55

Guida per principianti a GNU/Linux: cos’è e a cosa serve un sistema operativo

Immagine

Abbiamo visto come è fatto un computer. Ma un computer è hardware (= ferraglia) senza qualcosa che lo faccia funzionare, cioè i programmi, vale a dire il software. Ma i programmi a loro volta non possono funzionare senza un software particolare, il sistema operativo. Esempi di sistema operativo sono: GNU/Linux, Windows, Mac Os X (che gira sul computer della Apple), Solaris (prodotto da Sun, la stessa che fa Java), FreeBSD, OpenBSD, NetBSD, AIX (della Ibm), HP-UX (della Hp), ecc.
Ma a che serve, di preciso il sistema operativo? Detto in due parole, serve per far girare i programmi. Ma perché è necessario un sistema operativo a questo scopo?
Per apprezzare a pieno la risposta bisognerebbe aver scritto, almeno una volta nella propria vita, un programma, meglio se in linguaggio C. Ed è proprio quello che faremo adesso.

Ehi, ma avevi promesso che avresti spiegato le cose terra-terra!

Sì, e mantengo la promessa. Preferisci che ti faccia una lunga pappardella sulla teoria dei sistemi operativi, oppure ti faccia vedere in pratica a cosa serve?

La seconda che hai detto…

Ok,comunque non è nulla di complicato.
Ecco il “codice sorgente” del nostro programma (vedremo prossimamente cosa significa “codice sorgente”, una domanda che si fanno molti neo-utenti di GNU/Linux):

Citato:
"#include <stdio.h>
int main () {
printf("Ecco il mio primo programma\n");
return 0;
,,


Supponiamo di sapere come si fa a compilare questo programma (altro argomento che vedremo in seguito) e di ottenere il codice eseguibile.

Se lo abbiamo compilato dandogli il nome “primoprogramma” potremo eseguirlo aprendo il terminale (Applicazioni > Accessori > Terminale). Questo serve perché il nostro programma prevede il suo output (uscita) su un’interfaccia testuale e quindi abbiamo bisogno di un “simulatore” di interfaccia testiale dentro l’interfaccia grafica.
Per eseguire il programma diamo un semplice ./primoprogramma:

Citato:
"guido@guido-laptop:~$ ./primoprogramma
Ecco il mio primo programma
guido@guido-laptop:~$ _
,,


Come vedi l’unico risultato del programma è scrivere “Ecco il mio primo programma”. Ma come fa a farlo?

Vediamo un po’ il sorgente del programma. Scorrendo le righe ci soffermiamo davanti a questa:

Citato:
"printf("Ecco il mio primo programma\n");,,


In effetti “print”, in inglese, vuol dire “stampa”. Ok, ma come fa il computer a stampare questa scritta?
Torniamo allo schema del computer:

Immagine

Il nostro programma risiede nella memoria principale. La CPU inizia ad eseguirlo e preleva la scritta “Ecco il mio programma” dalla memoria. Poi la manda ad un dispositivo di output, ovvero lo schermo, attraverso la scheda video.

Ma perché la stampa proprio lì e non in mezzo al terminale? Come fa a sapere dove deve iniziare a scrivere?

Questa è un ottima domanda. La risposta è che è il sistema operativo a dirglielo. In altre parole, il sistema operativo gestisce l’input e l’output dei programmi.
Questa è una buona notizia. Se ogni volta dovessimo preoccuparci di questi particolari, i programmi sarebbero lunghissimi. Per scrivere “Ecco il mio primo programma” dovremmo prendere la prima lettera dalla memoria, mandarla allo schermo, poi prendere la seconda e così via. Il tutto stando attenti a dove la mandiamo precisamente sullo schermo. E dovremmo conoscere come è fatta la scheda video per poter mandare i caratteri nel modo corretto. Invece tutte queste preoccupazioni sono risolte grazie al sistema operativo.
E nel caso di programmi grafici?

In sostanza è la stessa cosa. Apriamo Firefox. Il programma si posiziona dentro una finestra sul nostro desktop. Noi possiamo ingrandire, rimpicciolire, spostare tale finestra. Perché? Perché il sistema operativo (non il Firefox medesimo) ci permette di interagire in questo modo con il computer. In particolare è il gestore delle finestre che si occupa di tutto ciò.
Non solo: hai mai notato che se cambi il tema del desktop, i colori, il set di icone, esse cambiano anche nei programmi? Questo perché tali oggetti sono messi a disposizione del programma dal sistema operativo, in particolare da quel pezzo che va sotto il nome di ambiente desktop (Gnome, Kde, xfce sono ambienti desktop).
E, ancora: la cornice delle finestre è disegnata dal sistema operativo, non dal programma. Quindi anche nel caso dell’ambiente grafico è sempre il sistema operativo a gestire l’input/output.
Questo vale sia per l’input che per l’output, sia verso tastiera e monitor (che inseme vengono di solito definiti console) che con altri dispositivi, compreso l’hard disk e le altre memorie di massa.
Quindi abbiamo due funzioni distinte: gestire l’input/output con l’utente e gestire l’input/output tra le diverse componenti del sistema. Ma c’è di più.
Per eseguire il programma abbiamo dato un comando al terminale:

Citato:
"./primoprogramma,,


Cosa abbiamo fatto esattamente? Abbiamo detto al sistema operativo di prelevare il programma dall’hard disk, dove è memorizzato, copiarlo nella memoria principale, e iniziare ad eseguirlo. Il tutto facilmente, con un solo comando. Ma dietro questa banale operazione c’è tutto un lavoro inimmaginabile: individuare il file con quel nome nell’hard disk, aprirlo, leggere un pezzo, copiarlo nella memoria (stando attenti a non sovrascrivere altri programmi o dati), prendere un altro pezzo, ecc. fino alla fine, stando attenti a capire pure dove finisce questo file. Insomma, un lavoraccio. Per fortuna non lo facciamo noi, ma il sistema operativo.
Abbiamo scoperto un’altra cosa: il sistema operativo carica i programmi e i dati dall’hard disk alla memoria principale, assegna loro uno spazio in tale memoria, e istruisce il processore per eseguirli.

Analizziamo l’istruzione successiva:

Citato:
"return 0;,,


Cosa significa? Questa istruzione dice che il programma è finito e che non ha riportato errori (il valore 0 per convenzione vuol dire “tutto ok”). Questo zero viene memorizzato dal sistema operativo quando il programma finisce. A cosa potrebbe servire una cosa del genere? Be’, ad esempio il nostro programmino potrebbe fare parte di un software più vasto: un altro programma potrebbe chiedere al sistema operativo di eseguire primoprogramma e gli piacerebbe sapere se esso ha funzionato o meno perché, nel secondo caso, potrebbe decidere di provare ad eseguire un altro programma oppure di comunicare all’utente che qualcosa è andato storto. In qualche modo, insomma, i due programmi devono poter comunicare tra di loro. E chi se ne occuperà? Ancora una volta il sistema operativo.
In altre parole il sistema operativo si occupa della comunicazione dei programmi tra loro.
immagina come sarebbe se non ci fosse il sistema operativo. Il nostro piccolo programma vorrebbe comunicare con l’altro programma, così scrive il suo bello “0″ in una celletta della memoria principale. Ma come farebbe l’altro programma a sapere dove andare a pescare tale “0″? Se entrambi i programmi sono stati scritti dalla stessa persona, allora potrebbe anche essere facile. Ma non sempre accade così. Ci vuole qualcosa di più facile e sicuro. Ci pensa il sistema operativo.
Immagina poi se ogni programmatore, ogni volta, dovesse occuparsi di tutte le operazioni di input/output! Dovrebbe conoscere come sono fatti tutti i diversi computer e un programma dovrebbe essere riscritto per ognuno di essi. Un bel problema.
Per ora basta. Nel prossimo post vedremo come fa il computer ad eseguire più programmi contemporaneamente.
E dopo quali sono i pezzi che compongono un sistema operativo: così spiegheremo anche quella strana prima istruzione:

"Citato
#include <stdio.h>
,,


Sarà anche l’occasione di spiegare perché “Linux” va chiamato più correttamente GNU/Linux. ;)

Crescia
Etabeta