Il lug di Ragusa si muove in questa direzione dal 2001, ed e’ proprio da queste attivita’ che nasce l’ Associazione Software Libero Ragusa che, approvando pienamente le idee del LUG, decide di ampliarle e concretizzarle con uno statuto e un’ associazione legalmente riconosciuta.
Per collaborare alle iniziative del lug non e’ necessaria nessuna iscrizione, nessuna quota associativa. Chiunque ne condivide le idee e si impegna per la sua crescita, puo’ benissimo considerarsi parte attiva di esso.

Pppd

Per invocare pppd occorre lanciare il comando “pppd [ opzioni ]“. Le opzioni accettate dal comando sono veramente numerose, ed e’ in base a queste che pppd impostera’ il proprio funzionamento. Le opzioni, oltre che essere specificate sulla linea di comando, possono essere scritte su una serie di file di configurazione facilmente modificabili per poterli adattare alle proprie esigenze. All’avvio pppd legge le opzioni da, nell’ordine, i seguenti file: /etc/ppp/options, ~/.ppprc, /etc/ppp/options.<dispositivo> e, eventualmente, /etc/ppp/peers/*. I file /etc/ppp/options.<dispositivo> rappresentano dei file contenenti opzioni specifiche da usare con <dispositivo>, dove con dispositivo si intende il file del terminale seriale presente in /dev al quale pppd deve collegarsi, o il nome dell’interfaccia Ethernet (nella forma ethX) nel caso in cui si usi una versione recente di pppd e si abbia un modem adsl di tipo Ethernet collegato a quella interfaccia. I file /etc/ppp/peers/* sono invece file contenenti opzioni da utilizzare quando pppd viene invocato con l’opzione ‘call’ seguita dal nome del peer (il quale e’ un nome arbitrario) corrispondente al nome del file in /etc/ppp/peers/. Infine verranno lette le opzioni impostate sulla linea di comando. La maggior parte delle distribuzioni forniscono un file di esempio in /etc/ppp contenente varie opzioni debitamente commentate, da poter prendere come riferimento per la creazione di uno o piu’ file personalizzati.
Perche’ pppd possa svolgere il suo compito e’ necessario che vengano soddisfatti alcuni requisiti. Prima di tutto il kernel deve avere i driver/supporti necessari, e in particolare:
- Supporto per protocollo IP
- Supporto per protocollo PPP
- Supporto per i sistemi di compressione dei dati che verranno usati durante la connessione (deflate e bsd)
Altri driver che potrebbero essere necessari in taluni casi (linea ADSL, tunnel PPTP):
- Supporto per “PPP over Ethernet” (PPPOE)
- Supporto per protocollo Packet
- Supporto per compressione MPPE
Nel caso (frequente) in cui i suddetti driver siano disponibili come moduli esterni anziche’ essere compilato dentro il kernel e’ opportuno verificare che il file di configurazione dei moduli del kernel (/etc/modules.conf o /etc/modprobe.conf)3 sia in grado di istruire il sistema su quali moduli caricare all’arrivo di alcune richieste da parte dei programmi. In genere e’ sufficiente inserire, nel caso in cui non vi siano gia’, queste righe nel file:
alias net-pf-2 ipv4
alias net-pf-17 af_packet
alias net-pf-24 pppoe
alias ppp0 ppp
alias tty-ldisc-3 ppp_async
alias tty-ldisc-14 ppp_synctty
alias ppp-compress-18 ppp_mppe
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
Inoltre, dovendo pppd essere in grado di gestire direttamente i dispositivi seriali, i dispositivi di rete e le tabelle di routing, e’ necessario che pppd giri con i privilegi dell’utente root. E’ sufficiente per questo che si imposti il flag suid sull’eseguibile /usr/sbin/pppd.
Pppd puo’ benissimo essere usato per stabilire una connessione tra due macchine collegando le loro porte seriali attraverso un cavo seriale di tipo null-modem, realizzando in questo modo una piccola rete locale a bassa velocita’. In tal caso e’ sufficiente che entrambe le macchine abbiano installato pppd, e ognuna di esse potra’ richiedere un collegamento all’altra. L’utilizzo tipico di pppd e’ pero’ quello di utilizzare un modem per connettersi al proprio ISP. Nel caso in cui si abbia a disposizione una normale linea telefonica con modem analogico sara’ necessario utilizzare anche un programma che si occupi di interagire con il modem per far si’ che questo componga il numero di telefono del computer remoto ed avvii la procedura cosiddetta di “handshaking” per negoziare i parametri della connessione. Questo programma si chiama chat(8).

Chat

Chat viene normalmente invocato da pppd stesso tramite l’opzione ‘connect’. Lo scopo di questa opzione e’ appunto quello di eseguire i compiti necessari per instaurare fisicamente la connessione prima che pppd si occupi del resto. Normalmente l’argomento dell’opzione ‘connect’ e’ uno script o una linea di comando per invocare chat, ad esempio “connect ‘/usr/sbin/chat -f /etc/ppp/chat-isp’“. In questo esempio viene invocato chat passandogli come argomento dell’opzione -f il nome del file contenente il relativo script (per comodita’ tale file si colloca nella stessa directory contenente gli altri file di configurazione di pppd).
Infatti occorre che tutte le operazioni che chat deve eseguire vengano inserite in un apposito file, lo script di chat appunto, contenente una serie di comandi che ne specificano le azioni da intraprendere, fra cui la stringa di inizializzazione da inviare al modem, il numero di telefono da comporre, opzioni relative a timeout di connessione e cose simili, ed eventualmente una o piu’ coppie nel formato “stringa_ricevuta: stringa_da_inviare” che istruiscono il programma su come reagire nel caso riceva una stringa (o sottostringa) cosi’ formata, e cioe’ quale stringa di risposta dovrebbe inviare. L’utilizzo di questa funzionalita’ e’ in genere quello di rispondere alle richieste di immissione username e password del computer remoto, ma e’ in realta’ utilizzabile solo quando il protocollo di autenticazione utilizzato dall’ISP e’ il PAP. Inoltre per poter utilizzare chat per l’autenticazione sarebbe necessario indagare preliminarmente, tramite un emulatore di terminale, per sapere il formato dei prompt che l’host remoto ci invia per richiederci di autenticarci. Per ragioni di comodita’ e’ quindi preferibile evitare che l’autenticazione venga effettuata da chat, delegando direttamente pppd a questo che si occupera’ di svolgere il compito in modo totalmente trasparente all’utente.
Se chat avra’ avuto successo nell’instaurazione della connessione esso uscira’ restituendo il controllo delle operazioni a pppd.

Protocolli d’autenticazione

Vi sono vari protocolli alternativi per l’autenticazione, di cui i piu’ comuni sono il PAP ed il CHAP con le sue varianti MSCHAP80 e MSCHAP81. La pricipale differenza fra questi e’ che mentre PAP si avvale dell’uso di credenziali in chiaro, gli altri prevedono l’uso di qualche forma di cifratura per le password da inviare. Per sapere gli username e le password da utilizzare in una certa sessione, pppd legge il contenuto di due file che andra’ a cercare nella directory /etc/ppp/. I nomi di questi file sono rispettivamente pap-secrets e chap-secrets, ed il loro formato e’ praticamente identico. Questi file sono praticamente composti da righe successive contenenti ognuna le informazioni relative ad una specifica sessione suddivise in tre campi: il primo contiene lo username, il secondo contiene il nome del server remoto (di solito al suo posto viene specificato il jolly “*”), il terzo contiene la password. In realta’ ci sarebbe un quarto campo opzionale che puo’ contenere una lista di indirizzi IP validi per raggiungere il server, ma nei collegamenti via modem questo campo e’ naturalmente inutilizzato. Per consentire a pppd di sapere quale password utilizzare e’ sufficiente utilizzare nel corrispondente file in /etc/ppp/peers l’opzione ‘name’ seguita dal nostro username per quella connessione. In questo modo pppd cerchera’ nei file contenenti i ‘segreti’ la stringa contenente quello username e ne utilizzera’ la password relativa.
Terminata la fase di autenticazione pppd informera’ il kernel dell’indirizzo IP assegnatogli dall’host remoto e dell’indirizzo IP dello stesso host, impostando, nel caso una delle opzioni passategli all’avvio sia stata ‘defaultroute’, la tabella di routing in modo che l’host remoto venga riconosciuto come gateway predefinito, ossia che qualunque richiesta diretta ad indirizzi IP non contemplati nel file /etc/hosts venga instradata verso l’host remoto. Verra’ inoltre letto il file /etc/resolv.conf per conoscere gli indirizzi IP dei server DNS da interrogare per la risoluzione degli URL; e’ comunque possibile fare in modo che pppd ottenga l’indirizzo IP di un server DNS direttamente dall’host remoto, basta specificare l’opzione ‘usepeerdns’.
Da questo momento in poi sara’ disponibile un’interfaccia di rete denominata “pppX”, dove X e’ un numero che parte da 0 e si incrementa di una unita’ per ogni eventuale interfaccia creata successivamente. A tale interfaccia verra’ connesso il dispositivo seriale specificato fra le opzioni di pppd.

ADSL

Vi sono vari protocolli di trasporto per quanto riguarda la connessione a linee ADSL a banda larga, quindi per questo tipo di connessioni occorre accertarsi di quali siano i rpotocolli supportati dal nostro provider. Il caso piu’ semplice, ma purtroppo anche quello meno diffuso, prevede una connessione di tipo bridged dove la nostra macchina diventa a tutti gli effetti un nodo della sottorete del provider, e in questo caso non serve nessun tipo di software di collegamento.
Nel caso di collegamento a linea adsl con protocollo PPPoE (PPP over Ethernet), avendo a disposizione una versione sufficientemente recente di pppd e i necessari moduli di cui abbiamo accennato sopra, all’interfaccia pppX verra’ connessa la scheda di rete alla quale e’ collegato il modem. E’ importante, in quest’ultimo caso, che si sia provveduto precedentemente a caricare il driver relativo alla scheda di rete in oggetto, ma allo stesso tempo e’ necessario che l’interfaccia ethX corrispondente non sia stata configurata con un indirizzo IP, o al massimo che le sia stato assegnato un indirizzo appartenente alla stessa sottorete dell’interfaccia Ethernet del modem ADSL (utile in seguito per poter sfruttare le funzionalita’ di configurazione remota del modem); e’ sufficiente tirare su l’interfaccia con un comando del tipo “ifconfig ethX <indirizzoIP>” (oppure, se non si vuole assegnare l’indirizzo, “ifconfig ethX 0.0.0.0“).
Il terzo protocollo utilizzato sulle linee ADSL e’ il PPPoATM (PPP over ATM). In questo caso, a differenza di PPPoE, l’incapsulamento dei dati non viene effettuato da programmi in user space ma direttamente dall’hardware (e in questo caso abbiamo un guadagno in termini di prestazioni) o dal driver di periferica.
In linux esistono due possibilita’ per poter utilizzare questo protocollo: la prima riguarda l’acquisto di una scheda ATM e l’utilizzo del supporto di pppd per PPPoATM e del relativo supporto a livello kernel. Occorre pero’ notare che potrebbe non essere semplice reperire in commercio una di queste schede a causa della loro scarsa diffusione, e inoltre il driver PPPoA del kernel e’, al momento in cui scriviamo, ancora in fase sperimentale.
La seconda possibilita’ riguarda l’acquisto di un modem (generalmente con interfaccia USB) per il quale vengano sviluppati i necessari driver per Linux. Il sito di riferimento in questo caso e’ quello del progetto eciadsl (http://eciadsl.flashtux.org), un progetto che si occupa appunto dello sviluppo di driver per modem che supportano PPPoATM.
Vi sono poi casi particolari, come ad esempio quello del modem Alcatel Speedtouch Home. Questo particolare modem consente di utilizzare sia PPPoE che PPPoATM, ma mentre nel primo caso occorre configurarlo come bridge e utilizzarlo come qualunque altro modem Ethernet, nel secondo caso occorre configurarlo come server PPtP (Point to Point tunneling Protocol, un protocollo ideato da Microsoft) e installare sulla macchina un client PPtP (http://pptpclient.sourceforge.net). Successivamente occorre configurare pppd perche’ utilizzi questo client per la connessione all’internet; si rimanda alla documentazione del pacchetto pptpclient per ulteriori dettagli sulla configurazione di pppd.

Script accessori

Oltre ai file che abbiamo gia’ menzionato esistono anche vari script che vengono invocati da pppd in diverse fasi della procedura di connessione. Fra questi vi sono, ad esempio, /etc/ppp/ip-up e /etc/ppp/ip-down, che vengono eseguiti rispettivamente nel momento in cui e’ disponibile il collegamento e nel momento in cui questo cessa di esistere. Questi script vengono eseguiti in un ambiente impostato specificamente per essi e contenente solo le variabili necessarie piu’ altre variabili contenenti parametri relativi al collegamento in funzione.
Mediante questi file possiamo automatizzare lo svolgimento di alcuni compiti, come ad esempio il prelevamento di posta da un server pop3 remoto, lo svuotamento della coda di messaggi del nostro server di posta, la sincronizzazione dell’orologio di sistema con un time server, e cosi’ via. E’ sufficiente creare questi file e scriverci dentro tutti i comandi che vogliamo vengano eseguiti.
Le funzionalita’ di pppd lo rendono un software veramente molto flessibile, in grado di soddisfare praticamente qualsiasi nostra esigenza. E’ possibile ad esempio sfruttare la funzionalita’ di multilink moltiplicando la larghezza di banda a nostra disposizione tramite lo sfruttamento contemporaneo di piu’ modem, o utilizzare la capacita’ di pppd di avviare autonomamente una connessione solo quando viene richiesto un accesso all’esterno, salvo poi interromperla nel caso che non venga utilizzata per un certo periodo di tempo.
Se si sono creati i file necessari in /etc/ppp/peers, e si sono inserite tutte le necessarie opzioni nei vari file di configurazione, per lanciare la connessione ad Internet sara’ sufficiente utilizzare il comando “pppd call nome_connessione“, dove nome_connessione deve corrispondere al nome di un file presente in /etc/ppp/peers. Naturalmente potremo facilmente associare il comando ad un’icona sul desktop, o ad una voce nel menu dell’ambiente grafico preferito. Nel momento in cui vorremo fermare il collegamento dovremo semplicemente “uccidere” il processo relativo al demone con il comando “killall pppd”.

Poi fu scoperto un nuovo continente. Uno spazio immenso, e poco popolato. C’erano coloni, c’erano pacifici abitanti originari, c’erano assemblee e decisioni comuni di buon senso. I coloni non avevano nè polizia nè esercito. Ma sapevano scrivere…

Mandarono lettere in Europa, raccontando com’era la loro vita. E un giovane svizzero, dal cuore ardente, ne lesse molte. Si chiamava Jean-Jacques Rousseau. Si mise a scrivere un libro, stampato dai liberi editori svizzeri.

Inventò, scrisse e riscrisse un concetto eretico, il più rivoluzionario mai scritto: “il diritto naturale dei popoli e delle genti”.

Il nostro nuovo continente, per noi che abitiamo anche il cyberspazio, è Internet. Qui finora non c’è stata troppa polizia, pochi i reati, minima la violenza e la prevaricazione. In rapporto a ciò che abbiamo fatto e costruito.

Abbiamo colonizzato in dieci anni uno spazio per mezzo miliardo di esseri umani (e più). Senza una vittima, senza una strage, senza nemmeno una guerra: un record millenario! Mai era successo nella storia conosciuta. E continua tuttora…

Siamo la generazione della pace, della trasformazione non violenta. Spostiamo bit e non atomi

Qualcuno però impose leggi ingiuste a quegli antichi coloni di allora. Se volevano bere una tazza di tè dovevano pagare una tassa a un re lontano, indifferente e sconosciuto….

Si ribellarono. Rifiutarono l’ingiusta legge. Si liberarono.

Oggi un legge ingiusta, cresciuta sulle trame e sul potere occulto di alcune multinazionali, ci impone tagliole su tutto lo scibile umano delle conoscenze, dell’arte e della cultura.

Ci marchia come pirati, come malfattori, come disonesti. In nome di norme contrarie a qualsiasi diritto naturale.

Questo scempio si chiama copyright per 175 anni filati, si chiama brevettazione anche di oggetti e fenomeni naturali, del nostro stesso codice genetico.

Questo scempio ci impone di pagare tasse anche se vogliamo condividere liberamente e gratuitamente ciò che è nostro, la nostra musica, le nostre fotografie, filmati, il nostro software.

Noi invece affermiamo il nostro diritto inalienabile a vivere serenamente la rete, senza manette, senza sorveglianti pubblici o privati

A non essere costretti a pagare per ciò che è abbondante come l’aria, e che è nostro.

Ad apprendere, sperimentare e crearci un futuro

A vincere sulla nostra qualità, la nostra firma

A cercare la nostra felicità, come dissero allora quegli uomini liberi….

Colonizzando in pace il cyberspazio noi abbiamo fatto un favore a noi stessi, agli altri e al mondo. Anche a coloro che vorrebbero vederci in prigione o soggetti di leggi e tasse assurde.

Con internet abbiamo sviluppato un gioco di libertà reciproca, e di mutuo arricchimento (materiale e non) quale non si era mai visto negli ultimi cento anni.

Nessuno Stato, potere o impresa l’ha creato. L’ha creato invece prima la comunità scientifica, poi quella tecnica, quindi cittadini e utenti come Noi. Insieme.

Noi intendiamo andare avanti su questo cammino di Pace e vantaggioso per tutti. E rifiutiamo gli ostacoli artificiali che ci vengono imposti.

Questo cammino sta già cambiando la vita di un terzo degli italiani. Quando mai una trasformazione tanto vasta è stata tanto pacifica e silenziosa nel nostro Paese?

Quante le proteste contro internet? Oggi è divenuta persino invisibile, tanto è naturale usarla. E sono passati solo sei anni dalla sua partenza di massa qui da noi…

Oggi l’80% delle imprese italiane usa la rete. E’ diventato il sistema nervoso del lavoro del Paese.

E’ diventato lo strumento degli studenti, e di chi impara, di qualsiasi età egli sia.

Internet vale un milione di posti di lavoro in Italia e almeno dieci milioni in Europa. E’ il maggiore datore di lavoro per le nuove generazioni del continente.

Invece di punire e di mettere tasse ingiuste perchè i nostri politici non cercano di capire Internet e di facilitarci il cammino?

Cercano di bloccare qualcosa che è nei fatti: la condivisione della conoscenza e del sapere dell’umanità. Ormai nelle cose, nella tecnica, nell’infrastruttura. Vogliono far girare all’indietro la ruota della storia?

Beppe Caravita

Linux & KDE tratta una introduzione a Linux e illustra le operazioni fondamentali per l’uso quotidiano. Si parla di utenti, diritti, permessi, gestione di file e directory, supporti di memorizzazione esterni (floppy, cd/dvd-rom), personalizzazioni dell’ambiente.

OpenOffice Writer tratta dell’uso del programma di word processing del progetto OpenOffice.org. Vengono trattati: formattazione di selezione, paragrafi, pagine, controllo ortografico, ricerca e sostituzione, tabulazioni, tabelle, immagini, stampa in serie, personalizzazioni, formati aperti, stampe.

Firefox & Thunderbird tratta dell’uso del browser e del client di posta elettronica del progetto Mozilla. Tratta di come muoversi nel web, segnalibri, cronologia, navigazione per schede, difesa della privacy, impostazione account di posta elettronica, ricezione e composizione/invio di messaggi, allegati, uso della rubrica, contatti, liste, filtri.

Il materiale comprende la versione PDF delle slide presentate nella serata, tre pagine di codice, rispettivamente di HTML, JavaScript e PHP e tre pagine contenenti i commenti alle pagine suddette. In realta’, nella logica temporale degli argomenti, le pagine HTML (codice e commenti) andrebbero lette dopo la slide 8, le pagine JavaScript dopo la slide 12 e, infine, le pagine PHP dopo la slide 17.

Chi e’ interessato puo’ scaricare da http://ennebi.solira.org/tepweb/tepweb-pdf.zip un file compresso contenente due file PDF: uno con le slide ed uno con le parti commentate.

Materiali per la consultazione

Innanzi tutto da http://ennebi.solira.org/LUG/tecweb.pdf si possono consultare le slide che costituiscono l’ossatura dell’intervento.

ListHTML
Questa e’ la pagina che contiene un esempio di esecuzione e il listing della prima pagina di esempio che tratta le caratteristiche principali di HTML.

CommHTML
La pagina contiene i commenti sul codice della pagina HTML di esempio precedente

ListJS
Questa e’ la pagina che contiene un esempio di esecuzione e il listing della seconda pagina di esempio che tratta le caratteristiche principali di JavaScript?

CommJS
Pagina contenete commenti sul codice JavaScript? inserito nella seconda pagina di esempio

ListPHP1
La prima pagina contenete codice PHP. La pagina prepara i dati per l’interrogazione del database

CommPHP1
I commenti al codice della pagina di preparazione dei dati

ListPHP2
La seconda pagina contenete codice PHP. La pagina effettua l’interrogazione e costruisce l’HTML da restituire al client

CommPHP2
I commenti al codice della seconda pagina PHP

Un sistema operativo non e’ un singolo software, anche se di solito chi utilizza un computer da poco tempo ha la tendenza a vederlo come tale, ma e’ bensi’ una collezione di software che consentono di utilizzare un computer. Non e’ detto che questi software siano scritti da un unico soggetto, anzi, solitamente e’ vero il contrario, sia che si parli di sistemi proprietari o di sistemi liberi; basti pensare ad esempio alle aziende produttrici di hardware che producono i driver necessari per l’utilizzo dei loro prodotti. I software che costituiscono il sistema operativo possono essere rappresentati in gruppi, detti livelli, in funzione della loro collocazione logica; si va in questo caso dal livello piu’ alto rappresentato dall’utente scendendo fino ai componenti elettronici della macchina.

Al livello piu’ basso, quindi piu’ vicino all’hardware della macchina, troviamo il kernel. Il kernel, come indica lo stesso termine nella sua traduzione letterale dall’inglese, e’ il nucleo del sistema operativo, e da esso dipende il funzionamento di tutta la macchina. In pratica si tratta dello strato software presente fra le applicazioni che girano nello spazio utente e la parte hardware composta dall’unita’ centrale e dalle varie periferiche installate nella macchina. Si occupa della gestione dei processori, della gestione della memoria, dell’assegnazione delle risorse ai vari processi in esecuzione. Il kernel si occupa anche della gestione di ogni periferica installata sulla macchina, in modo diretto se il codice necessario e’ stato incluso all’interno del kernel stesso, o indirettamente occupandosi del caricamento del codice esterno contenente i driver necessari al loro funzionamento.

I kernel possono essere di due tipi: parleremo di kernel monolitici, e Linux e’ uno di questi, se ci riferiamo ad un unico programma che si occupa di tutti gli aspetti relativi alla gestione della macchina e dei processi. Anche se alcune funzioni di questi possono essere incluse in moduli esterni da caricare all’occorrenza, di fatto poi questi moduli andranno comunque a costituire parte integrante del kernel stesso. L’alternativa e’ rappresentata dai cosiddetti microkernel, che delegano invece la maggior parte delle funzioni a programmi separati limitando al minimo le proprie funzionalita’. Questi ultimi, teorizzati da Tanenbaum, dovrebbero rappresentare la concezione piu’ moderna di kernel, ma non hanno avuto in pratica, almeno fino ad ora, quel seguito che Tanenbaum si sarebbe aspettato. Lo stesso Tanenbaum bollo’ come gia’ obsoleto il kernel Linux fin dalla sua nascita, soltanto per il fatto che era stato concepito come monolitico: i posteri gli hanno evidentemente dato torto.

Al di sopra del kernel troviamo le librerie di sistema, le quali sono composte da codice contenente le chiamate di sistema necessarie per interagire con il kernel e tutte quelle funzioni di cui ha bisogno ogni programma per svolgere il suo compito. In questo modo il programmatore che va a scrivere un’applicazione non dovra’ inserire direttamente all’interno della stessa tutto il codice necessario, ma si limitera’ a scrivere le funzioni specifiche dell’applicazione facendo in modo che vengano incluse le funzioni rese disponibili dalle librerie condivise a tutti i programmi che ne hanno bisogno, riducendo cosi’ drasticamente il carico del sistema e lo spazio occupato sul disco.

Salendo piu’ in alto troviamo tutti quei programmi di utilita’ necessari alla gestione della macchina. In questa categoria ricadono programmi che vengono avviati contestualmente all’avvio della macchina, e che quindi non vengono utilizzati spesso dall’utente ma funzionano in modo autonomo dopo essere stati appositamente configurati. Si tratta prevalentemente di software che provvedono al monitoraggio del sistema stesso o all’esecuzione di compiti ben determinati, come ad esempio l’avvio di operazioni a cadenza prestabilita o l’inizializzazione della coda di stampa.

Infine, al livello piu’ vicino all’utente, troviamo tutti quei programmi che presuppongono una stretta interazione con l’utente e che spesso costituiscono la dotazione dei comandi del sistema. Infatti i comandi di uso comune non sono altro che dei semplici programmi installati nel sistema al pari di qualunque altro software, e che invochiamo semplicemente, almeno nell’uso da linea di comando, chiamandoli per nome. Qui troviamo principalmente l’interfaccia utente, sia essa a linea di comando o grafica, tutti quei comandi e/o interfacce che ci permettono di interagire con il filesystem, varie utilita’ per la configurazione della macchina, programmi che ci permettano di editare file di testo, e cosi’ via.

Con questo avremmo gia’ un sistema funzionante, ma qualunque sistema operativo non puo’ non essere affiancato da una collezione di software per l’uso produttivo della macchina, e questa dotazione di software variera’ in funzione dell’utilizzo al quale e’ destinato quel sistema. Se ad esempio dobbiamo utilizzare la macchina come server da collegare ad internet, installeremo un server web, un server di posta, e cosi’ via. Se invece la macchina sara’ destinata a fare da workstation in un ufficio, dovremo installare un word processor, un gestionale, magari un software di disegno tecnico, eccetera.

POSIX

Linux e’ un moderno sistema operativo basato su UNIX. UNIX e’ forse il sistema operativo piu’ longevo, visto che venne introdotto nel 1970 quando ancora la diffusione dei computer presso l’utenza domestica e nei piccoli uffici era ancora (relativamente) lontana. UNIX ha conosciuto nel corso degli anni diversi cambi di proprietario e di licenza. Da UNIX vennero derivati diversi sistemi proprietari e non, e ad un certo punto si penso’ di fare in modo che lo sviluppo di questi sistemi cosi’ simili fra di loro non procedesse percorrendo strade lontane le une dalle altre. In particolare le case produttrici di software non volevano correre il rischio di dover creare vari rami di sviluppo troppo differenti tra loro per i prodotti che commercializzavano, in modo da farli funzionare su ognuna di queste piattaforme che di fatto avevano piu’ o meno tutte lo stesso target, erano cioe’ destinate alla stessa tipologia di utenza. Se da un lato UNIX rappresentava gia’ uno standard di per se’, dall’altro pero’ occorreva pagare per poter commercializzare un sistema come UNIX-compliant, e molti sistemi liberi nati nei momenti in cui parti di codice di UNIX erano state rilasciate con licenza libera, i cosiddetti sistemi UNIX-like, non potevano certo permettersi di pagare delle royalty.

Per questo motivo naquero due processi di standardizzazione, ad opera di due diversi enti, che poi confluirono in un unico standard: POSIX. Lo standard POSIX si occupa di definire alcuni concetti di base da seguire nella realizzazione del sistema operativo, in modo da garantire la portabilita’ delle applicazioni da un sistema all’altro con il minimo sforzo. La conseguenza di questo e’ una sostanziale uniformita’ di molti aspetti dei sistemi operativi, come ad esempio l’utilizzo di chiamate di sistema simili, la struttura dell’albero delle directory, i nomi dei comandi basilari ed il modo per invocarli con delle opzioni, il funzionamento di base dell’interprete dei comandi, e altre cose. In pratica, chi e’ abituato a utilizzare qualunque sistema conforme alle specifiche POSIX, si trovera’ a suo agio davanti ad un altro sistema POSIX.

La famiglia dei sistemi POSIX e’ piuttosto ampia e comprende diversi sistemi commerciali, per lo piu’ derivati direttamente da UNIX, (AIX, SunOs?, IRIX, ecc.) e molti sistemi a codice aperto come le diverse varianti di BSD e, naturalmente, Linux. In tempi relativamente recenti alla famiglia si e’ aggiunta anche Apple, che ha basato il suo sistema operativo MacOS? su BSD a partire dalla versione 10 (assumendo il nome di MacOS? X).

Linux

Linux ha un ruolo trainante nel mondo POSIX. L’espansione di Linux nei suoi 14 anni di vita, e l’interesse da parte di una folta schiera di programmatori e di software house che lo supportano, ha fatto si’ che venisse sviluppata una quantita’ non indifferente di software, e questo, unito alla facilita’ nel portare il software verso altri sistemi POSIX, ha contribuito indirettamente in modo positivo all’arricchimento della dotazione di questi. Ove vi fossero incompatibilita’ di licenza, o altre cose che non permettessero il porting diretto delle applicazioni, si e’ provveduto a realizzare uno strato di emulazione che permettesse di eseguire direttamente binari compilati per Linux; data la grande somiglianza fra questi sistemi, i programmi che mettono a disposizione questi ambienti emulati risultano estremamente efficienti. FreeBSD? e MacOSX? traggono giovamento da questo sistema.

Il supporto hardware di Linux non e’ assolutamente inferiore alla dotazione di applicativi. Oggi il kernel Linux supporta direttamente gran parte dell’hardware disponibile sul mercato. Molte case produttrici hanno contribuito a far si’ che il loro hardware venisse supportato, o fornendo le specifiche che permettessero lo sviluppo dei driver, oppure rilasciando esse stesse i moduli binari da caricare all’interno del kernel.

Linux, inoltre, e’ il sistema operativo che supporta il piu’ alto numero di piattaforme. Sebbene sia nato e si sia sviluppato su piattaforma x86, alla quale appartengono la grande maggioranza delle macchine che utilizziamo, Linux e’ stato in seguito portato anche su altre piattaforme. Al giorno d’oggi e’ disponibile una versione del kernel Linux per circa 20 diverse architetture, comprese le ultime architetture a 64 bit prodotte da AMD e Intel e derivate direttamente dall’originale x86 a 32 bit. Un settore nel quale Linux sta ultimamente riscuotendo un discreto successo e’ quello dei dispositivi embedded, sistemi che sono caratterizzati dal fatto di dover funzionare in ambiti ben specifici, la maggior parte delle volte senza dispositivi di memorizzazione di massa. Il fatto di poter compilare, grazie alla disponibilita’ del codice sorgente, una versione del kernel personalizzata che includesse solo le caratteristiche effettivamente necessarie, ha fatto si’ che sempre piu’ aziende produttrici di tali sistemi scegliessero Linux come base per lo sviluppo di sistemi operativi dedicati alla gestione di prodotti digitali. Fra questi sistemi troviamo ricevitori satellitari per la TV, video registratori digitali, computer palmari, telefoni cellulari multiuso.

Linux e’ un sistema operativo multitasking e multiutente estremamente stabile e performante. La gestione della memoria da parte del kernel di Linux e’ molto efficace. La memoria del sistema viene suddivisa in tante piccole parti chiamate pagine di memoria. Ogni programma venga lanciato sotto Linux da’ vita ad almeno un processo, il quale verra’ trasferito in un determinato spazio di memoria, e li’ verra’ eseguito. Altre aree di memoria conterranno parti di codice condiviso tra diverse applicazioni, verosimilmente librerie condivise, e aree destinate all’immagazzinamento temporaneo di dati. L’esecuzione contemporanea di vari processi e’ garantita dallo scheduler, una parte del kernel che si occupa di distribuire i cicli di CPU fra i processi che li richiedono prestando attenzione alla priorita’ di un processo rispetto ad un altro e al suo effettivo bisogno della CPU in quel dato istante. Inoltre, a differenza di altri sistemi operativi, gli applicativi in Linux, come negli altri POSIX, generalmente non accedono direttamente all’hardware. Mentre altrove questo, per ragioni architetturali, e’ quasi una prassi, l’architettura di Linux scoraggia di fatto il programmatore che delega, salvo quando effettivamente necessario, per queste operazioni il kernel.

Per tutti questi motivi, se un processo si blocca, non solo non causa il blocco di altre applicazioni che girano ognuna nel loro spazio di memoria, ma soprattutto non blocca il sistema operativo. Questo e’ vitale per qualunque sistema, come praticamente tutti i sistemi POSIX, che sono nati per essere installati su server di produzione; e’ semplicemente impensabile che una macchina che gestisca, ad esempio, il funzionamento di un’intera rete aziendale, fornendo servizi ai vari client, si blocchi improvvisamente paralizzando l’intera struttura.

Ma oltre ad essere un sistema stabile e performante Linux e’ anche un sistema con una particolare inclinazione alla sicurezza. La multiutenza in Linux, a differenza di altri sistemi che si spacciano per multiutente per il solo fatto di cambiare lo sfondo del desktop in funzione di chi ha effettuato il login, e’ realmente tale. Qualunque utente puo’ autenticarsi nel sistema anche quando vi sono altri utenti gia’ presenti, e per ogni utente vengono stabilite a priori le operazioni che si possono eseguire. Grazie alle caratteristiche dei file system utilizzati in Linux e’ possibile limitare gli accessi ai file, alle directory, e ai file eseguibili, ed inoltre il sistema operativo e’ in grado di assegnare ad ogni utente una determinata quantita’ di spazio sul disco e perfino un limite all’utilizzo delle risorse del sistema.

Ogni programma che viene eseguito sotto Linux eredita i privilegi dell’utente che lo ha lanciato, e da questo consegue che solo i programmi lanciati con l’identificatore dell’amministratore del sistema (che nei sistemi POSIX si chiama root) possono realmente essere pericolosi per l’integrita’ del sistema stesso. Fortunatamente pero’ in pratica l’amministratore non si autentica mai nel sistema come tale, ma piuttosto assume i privilegi necessari ai compiti che intende svolgere solo quando occorre. Inoltre pochi programmi vengono lanciati in esecuzione con l’identificatore di root, e si tratta per lo piu’ di programmi noti per la loro sicurezza, e questo consente a chi amministra un sistema Linux di poter andare a dormire la sera con relativa tranquillita’.

Quando ci si riferisce a Linux si pensa spesso ad uno dei tanti CD che si possono facilmente trovare allegati ad una rivista di informatica e che contengono una distribuzione Linux completa e pronta da usare.
In realta’, il nome Linux designava in origine il kernel scritto da Linus Torvalds sulla base di Minix, un sistema operativo creato a fini didattici da Tanenbaum, e venne in seguito esteso, nel gergo popolare, per definire anche il sistema operativo GNU/Linux e le sue varie distribuzioni.

Il Kernel e’ lo strato software piu’ basso del sistema, a diretto contatto con l’hardware, e si occupa di gestire i processori, di assegnare le risorse ai vari processi che vengono eseguiti, della gestione della memoria, del caricamento dei driver per le periferiche, i protocolli di rete, e cosi’ via.
In questo modo i programmi che girano nello spazio utente non hanno bisogno di sapere quale particolare periferica e’ installata fisicamente sulla macchina, possono concentrarsi esclusivamente sul loro lavoro, poiche’ ogni istruzione che dovra’ essere inviata all’hardware verra’ gestita dal kernel insieme a quelle di tutte le altre applicazioni e del kernel stesso.

Appare evidente che per poter svolgere il suo compito e permettere alle applicazioni di essere eseguite, il kernel deve essere caricato prima di ogni altra cosa. A questo pensano il BIOS della macchinae il bootloader. Il BIOS, dopo aver eseguito le inizializzazioni di base e aver testato la memoria, cerchera’ di eseguire il codice contenuto nel primo settore di ognuno dei dispositivi a blocchi in cui gli abbiamo detto di cercare (dischi fissi, floppy o CD-ROM), fermandosi appena ne avra’ trovato uno valido. Nel caso in cui avremmo installato Linux sul disco fisso, sul primo settore di quel disco si trovera’ un bootloader (di solito lilo o grub) che si occupera’ di caricare il kernel.

Struttura del kernel

La forma in cui si trova il kernel Linux e’ quella di un file, detto immagine del kernel, solitamente contenuto nella directory /boot. Se abbiamo compilato il kernel includendo i vari driver direttamente al suo interno, allora diremmo che abbiamo creato un kernel monolitico.
Nei sistemi desktop questa pratica e’ poco seguita in quanto un kernel del genere, dovendo necessariamente includere il supporto a tutto quello che intenderemo usare, finisce per raggiungere dimensioni considerevoli. Inoltre, ogni singolo driver verrebbe caricato in memoria anche quando non ci serve realmente, e questo comporta un aumento della memoria allocata per il kernel a danno di quella a disposizione dei programmi che girano nello spazio utente.

I kernel monolitici vengono utilizzati generalmente su macchine che svolgono compiti specifici, di solito quindi dei server, i quali non hanno bisogno di caricare all’occorrenza dei driver perche’ quello che hanno installato gli serve solitamente fin dall’inizio, e non gli serve null’altro. In questo modo si puo’ evitare il rischio che dei malintenzionati dall’esterno possano sfruttare una debolezza nel meccanismo di caricamento dei driver, potendo cosi’ dare qualche dispiacere all’amministratore del sistema.

Nell’uso comune, invece, si preferisce creare dei kernel modulari, in modo che le specifiche funzionalita’ vengano caricate in memoria solo quando occorrono, senza caricare inutilmente il sistema. Inoltre, possiamo in questo modo cambiare la configurazione di un driver semplicemente scaricandolo e ricaricandolo con parametri diversi.
Questo e’ ancor piu’ vero se si deve preparare un kernel che debba poter funzionare su diverse configurazioni hardware, come quelli che vengono inclusi nelle comuni distribuzioni del sistema GNU/Linux. In tal caso il kernel non si limita a risiedere nel file immagine, ma ad esso vanno affiancati i moduli da caricare a runtime, che possiamo trovare nella directory /lib/modules/<numero_versione>. Si capisce che in questo modo possiamo tenere sulla nostra macchina diversi kernel, purche’ ognuno di essi abbia un numero di versione diverso dall’altro, in quanto in /lib/modules avremo una directory per i moduli di ogni kernel; l’unico limite e’ rappresentato dalla capienza del disco fisso.

Ricompilazione del kernel

Nel momento in cui installiamo una distribuzione qualunque ci viene fornito un kernel generico, funzionante di solito in tutte le configurazioni hardware, dotato di tutti i moduli che potrebbero servire, e a volte con qualche piccola modifica rispetto al kernel originale per implementare qualche funzionalita’ aggiuntiva. Nella maggior parte dei casi questo kernel svolge egregiamente il suo compito, ma a volte e’ necessario dover compilare un kernel personale per poter sfruttare appieno tutte le potenzialita’ del nostro sistema, o anche per poter sfruttare un particolare dispositivo, o infine per poter semplicemente avere un kernel scaricato di tutto quello che sappiamo non potra’ mai servirci, aumentando cosi’ l’efficienza globale del sistema.

Per poter compilare un kernel occorre avere detrminati requisiti di base:
- il compilatore C di GNU, ‘gcc’
- il pacchetto ‘make’, sempre di GNU
- una serie di pacchetti generalmente inclusi in ogni distribuzione, come ad esempio le binutils e le util-linux
- vari pacchetti in funzione dei supporti che si desidera includere (ad esempio e2fsprogs se si vuole includer il supporto per ext2)
- eventualil tool per la gestione dei moduli (modutils per i kernel fino al 2.4.x, module-init-tools per quelli della serie 2.6.x)
- pacchetti necessari ai tool di configurazione (vedi piu’ avanti)

La versione corretta di ogni pacchetto e una lista completa dei requisiti minimi e’ contenuta nel file Documentation/Changes all’interno dei sorgenti del kernel.

Per quanto riguarda i sorgenti abbiamo due possibilita’: installare il pacchetto contenente i sorgenti del kernel della nostra distribuzione, oppure scaricare i sorgenti ‘vanilla’, quelli originali di Linus, dal sito http://www.kernel.org . Questi ultimi si presentano sotto forma di archivio compresso, per cui occorrera’ copiarli nella directory scelta e scompattarli con un ‘tar xzvf <nome_pacchetto>’.
La directory standard per i sorgenti del kernel e’ /usr/src/linux, ma si puo’ optare per una directory qualsiasi purche’ si faccia un collegamento simbolico /usr/src/linux che punti a quest’ultima (di solito si usa /usr/src/linux che punta a /usr/src/linux-<versione>).

Configurazione dei sorgenti

Una volta scompattato il file contenente i sorgenti, prima di iniziare la compilazione vera e propria dovremo configurarli. Esistono diversi metodi per la configurazione del kernel, e per usare ognuno di essi sara’ necessario aver installato determinati software, in modo che sia possibile al programma di configurazione creare l’interfaccia per interagire con l’utente.
L’unica eccezione in questo senso e’ rappresentata dal comando ‘make config’; per configurare i sorgenti con questo comando non e’ necessario nessun software aggiuntivo, in quanto questi ci presentera’ una semplice interfaccia testuale, ponendoci una domanda per ogni voce di configurazione. Per ogni domanda possiamo rispondere con uno di quattro possibili tasti: ‘y’ dira’ al configuratore di includere il relativo driver/supporto nell’immagine del kernel, ‘n’ gli dira’ di non includerlo, con ‘m’ (presente solo se avremo risposto affermativamente alla domanda che ci chiede se vogliamo abilitare il supporto ai moduli) si fara’ in modo che il driver/supporto venga compilato come modulo esterno, e con ‘?’ otterremo un messaggio di aiuto che ci spiega nei dettagli a cosa si rifersce quella particolare opzione. Il difetto principale di ‘make config’ e’ che non si puo’ tornare indietro per correggere gli eventuali errori, per cui e’ necessario ripetere l’intera procedura se abbiamo un ripensamento. Questo lo rende effettivamente poco usato da chiunque.

In alternativa si possono configurare i sorgenti con ‘make menuconfig’, una simpatica interfaccia a menu in modalita’ semigrafica (utilizzabile quindi da console o da terminale) che utilizza le librerie ncurses (che dovremo avere installate). Con ‘make menuconfig’ il lavoro e’ decisamente piu’ facile. Le opzioni di configurazione sono raggruppate in vari menu che potremo navigare semplicemente con i tasti freccia su/giu. Nella parte bassa della finestra ci sono tre pulsanti, selezionabili con i tasti freccia dx/sx, che rispettivamente ci fanno entrare in un sottomenu, ci fanno tornare al menu precedente, o visualizzano il testo di aiuto. Posizionati su ciascuna opzione possiamo selezionarla, deselezionarla o marcarla per essere compilata come modulo, rispettivamente con i tasti <invio>, <n> e <m>.
Purtroppo al momento la lingua utilizzata per i nomi delle opzioni e per i testi di aiuto e’ l’inglese, ma esiste un progetto per la traduzione di questi testi in italiano mantenuto dal sottoscritto, quindi state sintonizzati

Esistono inoltre altre due possibilita’ di configurazione, che utilizzano delle finestre in modalita’ grafica e che quindi hanno bisogno del server X per poter funzionare.
La prima e’ ‘make xconfig’, per la quale avremo bisogno di installare le librerie grafiche QT (quelle che usa KDE, per intenderci). La seconda e’ ‘make gconfig’, che invece richiede le librerie GTK utilizzate dall’ambiente grafico GNOME.
Entrambi i comndi ci presentano un’interfaccia a menu molto simile a quella di ‘make menuconfig’, quindi la scelta di una di queste e’ puramente una questione di preferenza estetica.

Possiamo fare in modo che il nostro kernel abbia un numero di versione diversa da quello che abbiamo gia’, pur trattandosi degli stessi sorgenti, semplicemente editando il file ‘Makefile’ presente nella directory radice dei sorgenti stessi.
Nelle prime righe di questo file vengono definite le variabili che identificano il numero di versione, ma mentre le prime tre (VERSION, PATCHLEVEL e SUBLEVEL) non vanno toccate, la quarta (EXTRAVERSION) puo’ essere modificata a piacimento. Questo potra’ esserci utile nel momento in cui dovremo avviare il nuovo kernel senza per questo eliminare il vecchio.

Compilazione e installazione

Una volta configurato i sorgenti possiamo passare alla compilazione vera e propria. Qui si tratta solo di pazienza, in quanto bastera’ dare semplicemente il comando ‘make bzImage’. Se abbiamo scelto di compilare dei moduli occorrera’ dare anche il comando ‘make modules’ per compilarli, e ‘make modules_install’ per installare i moduli nella directory /lib/modules/<versione>, creando inoltre dei file contenenti le dipendenze tra i vari moduli. E’ possibile dare questi comandi tutti insieme, con una stringa come ‘make bzImage && make modules && make modules_install’, in modo da non doverci preoccupare di essere presenti nel momento che uno dei comandi avra’ terminato il suo compito.
Dopo un po’ di tempo, dipendente dalle prestazioni della macchina sulla quale stiamo compilando e dal numero di funzionalita’ incluse in fase di configurazione, se tutto va per il verso giusto avremo il nostro nuovo kernel.

Per poter avviare la macchina con il nuovo kernel dovremo copiare l’immagine, e preferibilmente anche la mappa dei simboli, e reinstallare il boot-loader. La mappa dei simboli e’ il file ‘System.map’ che si trova nella directory radice dei sorgenti (verosimilmente /usr/src/linux), l’immagine del kernel si puo’ invece trovare nella directory /usr/src/linux/arch/<tipo_architettura>/boot/ con il nome ‘bzImage’. La destinazione di questi file dovrebbe essere la directory /boot. Se in /boot e’ gia’ presente il file ‘System.map’ del vecchio kernel conviene rinominare entrambi i file in ‘System.map-<versione>’.

Fatto questo si va ad editare il file di configurazione del bootloader (qui si assume che come loader si utilizzi lilo, quindi il file relativo e’ /etc/lilo.conf) aggiungendovi, insieme alla voce per l’avvio del vecchio kernel, anche una voce anche per il nuovo kernel. Si puo’ prendere spunto dalla voce gia’ presente per la composizione della nuova, tenendo presente che una voce per l’avvio di un kernel Linux inizia con la riga ‘image = /boot/<file_immagine>’ ed e’ seguita da varie righe per la definizione della modalita’ di avvio del kernel. Se tra le opzioni generali, all’inizio del file, non e’ presente una riga contenente la parola ‘prompt’ (che indica al loader di chiederci con quale kernel avviare la macchina), occorrera’ aggiungerla.

Dopo aver salvato il file sara’ sufficiente lanciare il comando ‘lilo -v’ per installare il nuovo loader. Al prossimo avvio potremo scegliere di partire con il nostro nuovo kernel, e se tutto e’ andato per il verso giusto, e il kernel funziona senza problemi, potremo editare (se lo vogliamo) nuovamente il file di configurazione di lilo rimuovendo il riferimento al kernel che non usiamo piu’, e ridare nuovamente il comando ‘lilo -v’. Potremo ovviamente rimuovere anche i file relativi al kernel in disuso (l’immagine del kernel, la mappa dei simboli, e la directory con tutti i moduli) e goderci appieno il nostro kernel personalizzato.

DIRETTIVA 19 dicembre 2003

Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni.

(G.U. n. 31 del 7-2-2004)

IL MINISTRO PER L’INNOVAZIONE E LE TECNOLOGIE

Visto il regio decreto 18 novembre 1923, n. 2440, recante «Nuove disposizioni sull’amministrazione del patrimonio e sulla contabilita’ generale dello Stato»;
Visto il regio decreto 23 maggio 1924, n. 827, recante «Regolamento per l’amministrazione del patrimonio e per la contabilita’ generale dello Stato»;
Visto il decreto legislativo 24 luglio 1992, n. 358, recante «Testo unico delle disposizioni in materia di appalti pubblici di forniture, in attuazione delle direttive 77/62/CEE, 80/767/CEE e 88/295/CEE», e successive modificazioni (con particolare riguardo al decreto legislativo 20 ottobre 1998, n. 402, in attuazione delle direttive 93/36/CEE e 97/52/CE);
Vista la legge 7 agosto 1990, n. 241, recante «Nuove norme in materia di procedimento amministrativo e di diritto di accesso ai documenti amministrativi»;
Visto l’art. 12 del decreto legislativo 12 febbraio 1993, n. 39, recante «Norme in materia di sistemi informativi automatizzati delle amministrazioni pubbliche, a norma dell’art. 2, comma 1, lettera mm), della legge 23 ottobre 1992, n. 421»;
Visto il decreto del Presidente del Consiglio dei Ministri 6 agosto 1997, n. 452, recante «Regolamento recante approvazione del capitolato di cui all’art. 12, comma 1, del decreto legislativo 12 febbraio 1993, n. 39, relativo alla locazione e all’acquisto di apparecchiature informatiche, nonche’ alla licenza d’uso dei programmi»;
Visto l’art. 6 della legge 24 dicembre 1993, n. 537, recante
«Interventi correttivi di finanza pubblica», come modificato dall’art. 44 della legge 23 dicembre 1994, n. 724;
Visto il decreto del Presidente della Repubblica 18 aprile 1994, n. 573, recante «Norme per la semplificazione dei procedimenti di aggiudicazione di pubbliche forniture di valore inferiore alla soglia di rilievo comunitario»;
Visto il decreto legislativo 17 marzo 1995, n. 157, recante
«Attuazione della direttiva 92/50/CEE in materia di appalti pubblici di servizi», e successive modificazioni (con particolare riguardo al decreto legislativo 25 febbraio 2000, n. 65, in attuazione delle direttive 97/52/CE e 98/4/CE);
Visto il decreto legislativo 17 marzo 1995, n. 158, recante
«Attuazione delle direttive 90/531/CEE e 93/38/CEE relative alle procedure di appalti nei settori esclusi», e successive modificazioni (con particolare riguardo al decreto legislativo 25 novembre 1999, n. 525, in attuazione delle direttive 94/22/CE e 98/4/CE);
Visto l’art. 20, comma 8, allegato 1, punto 12 della legge 15 marzo 1997, n. 59, recante «Delega al Governo per il conferimento di funzioni e compiti alle regioni ed enti locali, per la riforma della pubblica amministrazione e per la semplificazione amministrativa»;
Visto l’art. 24 della legge 24 novembre 2000, n. 340, recante
«Disposizioni per la delegificazione di norme e per la semplificazione di procedimenti amministrativi – legge di semplificazione 1999»;
Visto il decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, di approvazione del «Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa (Testo A)»;
Vista la legge 27 dicembre 2002, n. 289, (legge finanziaria 2003), ed in particolare l’art. 26, comma 2, lettera a);
Visto il decreto del Presidente della Repubblica in data 10 giugno 2001, di nomina del Ministro senza portafoglio per l’innovazione e le tecnologie;
Visto il decreto del Presidente del Consiglio dei Ministri in data 9 agosto 2001, concernente delega di funzioni del Presidente del Consiglio dei Ministri al Ministro senza portafoglio per l’innovazione e le tecnologie;
Visti i significativi sviluppi delle tecnologie dell’informazione e della comunicazione ed in particolare il processo di produzione, distribuzione ed evoluzione di programmi informatici che si basa sulla disponibilita’ del codice sorgente aperto;
Considerati gli esiti dell’indagine conoscitiva sui programmi informatici a codice sorgente aperto svolta dalla Commissione appositamente istituita e composta da numerosi e qualificati esperti delle pubbliche amministrazioni, del mondo accademico e del settore delle imprese;
Ritenuto di dover fornire un indirizzo univoco relativo alle scelte delle soluzioni per la predisposizione e per l’acquisizione dei programmi informatici da parte delle pubbliche amministrazioni;

Emana

la seguente direttiva in materia di sviluppo e utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni.

1. Finalita’.

Con la presente direttiva si forniscono alle pubbliche amministrazioni indicazioni e criteri tecnici e operativi per gestire piu’ efficacemente il processo di predisposizione o di acquisizione di programmi informatici. In particolare, nella presente direttiva si indica come le pubbliche amministrazioni debbano tener conto della offerta sul mercato di una nuova modalita’ di sviluppo e diffusione di programmi informatici, definita «open source» o «a codice sorgente aperto». L’inclusione di tale nuova tipologia d’offerta all’interno delle soluzioni tecniche tra cui scegliere, contribuisce ad ampliare la gamma delle opportunita’ e delle possibili soluzioni, in un quadro di equilibrio, di pluralismo e di aperta competizione.

2. Definizioni.

Ai fini della presente direttiva si intende:
a) per «formato dei dati» la modalita’ con cui i dati vengono rappresentati elettronicamente in modo che i programmi informatici possano elaborarli. Il formato specifica la corrispondenza fra la rappresentazione binaria e i dati rappresentati (testo, immagini statiche o dinamiche, suono, ecc.).
Esempi di formati sono Bitmap, GIF, JPEG, ecc.;
b) per «formato aperto», un formato dei dati reso pubblico e documentato esaustivamente;
c) per «tecnologia proprietaria», una tecnologia posseduta in esclusiva da un soggetto che in genere ne mantiene segreto il funzionamento;
d) per «formato proprietario» un formato di dati utilizzato in esclusiva da un soggetto che potrebbe modificarlo a proprio piacimento;
e) per «standard» una specifica o norma condivisa da una comunita’. Lo standard puo’ essere emanato da un ente di standardizzazione oppure essersi imposto di fatto (industry standard). Nel caso dei formati dei dati o dei documenti, un formato e’ standard quando e’ definito da un ente di standardizzazione (per esempio, il formato XML), o e’ di fatto condiviso da una comunita’ (per esempio, il formato PDF);
f) per «interoperabilita» la capacita’ di sistemi informativi anche eterogenei di condividere, scambiare e utilizzare gli stessi dati e funzioni d’interfaccia;
g) per «programmi informatici ad hoc o custom» applicazioni informatiche sviluppate o mantenute da un fornitore per soddisfare specifiche esigenze di uno o piu’ clienti. Normalmente questo tipo di sviluppo viene eseguito all’interno di un contratto di servizio per il quale il cliente corrisponde al fornitore un compenso;
h) per «programmi a licenza d’uso», o «pacchetti», applicazioni informatiche che vengono cedute in uso (e non in proprieta) dal fornitore al cliente. Tale cessione d’uso e’ regolata da opportune licenze che indicano i vincoli e i diritti che sono garantiti al titolare della licenza stessa;
i) per «programmi di tipo proprietario», applicazioni informatiche basate su tecnologia di tipo proprietario, cedute in uso dietro pagamento di una licenza, che garantisce solo la fornitura del codice eseguibile e non del codice sorgente. Esempi di tali prodotti sono MS Windows, IBM DB2, Oracle DB;
j) per «programmi a codice sorgente aperto» o «open source», applicazioni informatiche il cui codice sorgente puo’ essere liberamente studiato, copiato, modificato e ridistribuito;
k) per «costo totale di possesso», l’insieme dei costi che nel corso dell’intera vita operativa di un sistema informativo e’ necessario sostenere affinche’ esso sia utilizzabile proficuamente dall’utenza;
l) per «costo di uscita», l’insieme dei costi da sostenere per abbandonare una tecnologia o migrare verso una tecnologia o soluzione informatica differente. Comprende i costi di conversione dati, di aggiornamento dell’hardware, di realizzazione interfaccia e di formazione;
m) per «piattaforma», infrastruttura informatica, comprendente sia hardware che software, su cui vengono elaborati i programmi applicativi;
n) per «portabilita», possibilita’ di trasferire un programma informatico da una piattaforma a un’altra.

3. Analisi comparativa delle soluzioni.

1. Le pubbliche amministrazioni, nel rispetto della legge 7 agosto 1990, n. 241 e del decreto legislativo 12 febbraio 1993, n. 39, acquisiscono programmi informatici a seguito di una valutazione comparativa tra le diverse soluzioni disponibili sul mercato.
2. In particolare, valutano la rispondenza alle proprie esigenze di ciascuna delle seguenti soluzioni tecniche:
a) sviluppo di programmi informatici ad hoc, sulla scorta dei requisiti indicati dalla stessa amministrazione committente;
b) riuso di programmi informatici sviluppati ad hoc per altre amministrazioni;
c) acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d’uso;
d) acquisizione di programmi informatici a codice sorgente aperto;
e) acquisizione mediante combinazione delle modalita’ di cui alle lettere precedenti.
3. Le pubbliche amministrazioni valutano quale soluzione, tra le disponibili, risulta piu’ adeguata alle proprie esigenze mediante comparazioni di tipo tecnico ed economico, tenendo conto anche del costo totale di possesso delle singole soluzioni e del costo di uscita. In sede di scelta della migliore soluzione si tiene altresi’ conto del potenziale interesse di altre amministrazioni al riuso dei programmi informatici, dalla valorizzazione delle competenze tecniche acquisite, della piu’ agevole interoperabilita’. La prospettazione degli elementi di cui sopra e’ peraltro oggetto di valutazione da parte del Centro nazionale per l’informatica nella pubblica amministrazione in sede di rilascio del parere di cui all’art. 8 del decreto legislativo 12 febbraio 1993, n. 39. La suindicata valutazione va inclusa nell’ambito dello studio di fattibilita’ prescritto dall’art. 13 del decreto legislativo 12 febbraio 1993, n. 39, allorche’ si tratti di contratti di grande rilievo.

4. Criteri tecnici di comparazione.

Le pubbliche amministrazioni, nella predisposizione o nell’acquisizione dei programmi informatici, privilegiano le soluzioni che presentino le seguenti caratteristiche:
a) soluzioni informatiche che, basandosi su formati dei dati e interfacce aperte e standard, assicurino 1′interoperabilita’ e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione, salvo che ricorrano peculiari ed eccezionali esigenze di sicurezza e segreto;
b) soluzioni informatiche che, in assenza di specifiche ragioni contrarie, rendano i sistemi informatici non dipendenti da un unico fornitore o da un’unica tecnologia proprietaria; la dipendenza e’ valutata tenendo conto dell’intera soluzione;
c) soluzioni informatiche che, con il preventivo assenso del C.N.I.P.A. ed in assenza di specifiche ragioni contrarie, garantiscano la disponibilita’ del codice sorgente per ispezione e tracciabilita’ da parte delle pubbliche amministrazioni, ferma la non modificabilita’ del codice, fatti salvi i diritti di proprieta’ intellettuale del fornitore e fermo l’obbligo dell’amministrazione di garantire segretezza o riservatezza;
d) programmi informatici che esportino dati e documenti in piu’ formati, di cui almeno uno di tipo aperto.

5. Proprieta’ dei programmi software.

Nel caso di programmi informatici sviluppati ad hoc, l’amministrazione committente acquisisce la proprieta’ del prodotto finito, avendo contribuito con proprie risorse all’identificazione dei requisiti, all’analisi funzionale, al controllo e al collaudo del software realizzato dall’impresa contraente. Sara’ cura dei committenti inserire, nei relativi contratti, clausole idonee ad attestare la proprieta’ dei programmi.

6. Trasferimento della titolarita’ delle licenze d’uso.

Le pubbliche amministrazioni si assicurano contrattualmente la possibilita’ di trasferire la titolarita’ delle licenze d’uso dei programmi informatici acquisiti, nelle ipotesi in cui all’amministrazione che ha acquistato la licenza medesima ne subentri un’altra nell’esercizio delle stesse attivita’; parimenti va contrattualmente previsto l’obbligo del fornitore di trasferire, su richiesta dell’amministrazione, senza oneri ulteriori per l’amministrazione stessa, e salve eccezionali cause ostative, la licenza d’uso al gestore subentrante, nel caso in cui l’amministrazione trasferisca a terzi la gestione di proprie attivita’, ovvero l’obbligo di emettere, laddove possibile, nuova licenza d’uso con i medesimi effetti nei confronti del nuovo gestore.

7. Riuso.

1. Al fine di favorire il riuso dei programmi informatici di proprieta’ delle amministrazioni, nei capitolati o nelle specifiche di progetto dovra’ essere previsto, ove possibile, che i programmi sviluppati ad hoc siano facilmente portabili su altre piattaforme.
2. Nei contratti di acquisizione di programmi informatici sviluppati per conto e a spese delle amministrazioni, le stesse includono clausole, concordate con il fornitore e che tengano conto delle caratteristiche economiche ed organizzative di quest’ultimo, volte a vincolarlo, per un determinato lasso di tempo, a fornire, su richiesta di altre amministrazioni, servizi che consentono il riuso delle applicazioni. Le clausole suddette definiscono le condizioni da osservare per la prestazione dei servizi indicati.

8. Supporto alle amministrazioni.

Il Centro nazionale per l’informatica nella pubblica amministrazione promuove l’attuazione della presente direttiva e fornisce alle amministrazioni adeguato supporto.

Roma, 19 dicembre 2003

Il Ministro: Stanca

Registrato alla Corte dei conti il 23 gennaio 2004

Ministeri istituzionali – Presidenza del Consiglio dei Ministri, registro n. 1, foglio n. 129

Si tratta di undici diversi tipi di licenze create da una equipe di giuristi dell’Università di Standford, di Harvard e del MIT sul modello della licenza open-source GNU-GPL.

L’obiettivo è quello di consentire agli autori di testi (articoli, saggi, racconti o romanzi), di brani musicali e di filmati di qualunque tipo di diffondere in rete le proprie opere permettendone lo scambio e la riproduzione a condizione che vengano rispettate le limitazioni previste dalla specifica licenza Creative Commons adottata.

Gli elementi che compongono ciascuna singola licenza sono:

1) Attribuzione – l’autore può consentire la diffusione e la riproduzione della propria opera a condizione che venga sempre inserita l’indicazione dell’autore stesso;

2) uso non-commerciale – l’autore può scegliere di consentire la diffusione e la riproduzione dell’opera a condizione che non siano effettuate a scopo di lucro;

3) utilizzabilità in un’opera derivata – l’autore può scegliere se consentire l’utilizzo della propria opera per la creazione di un’opera derivata o, invece, ammettere la riproduzione o la diffusione dell’opera originaria a condizione che ad essa non venga apportata alcuna modifica e che non venga inserita in un opera derivata (ad esempio un’antologia);

4) conformità della licenza dell’opera derivata – l’autore può scegliere di consentire l’uso della propria opera in un’opera derivata a condizione che quest’ultima venga rilasciata sotto lo stesso tipo di licenza.

In Italia il progetto di traduzione ed adattamento delle licenze all’ordinamento comunitario e nazionale è guidato dal Dipartimento di Scienze Giuridiche dell’Università di Torino.

This work is licensed under the Creative Commons Attribution-No Derivs-Non Commercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

A questo punto il sistema operativo potrebbe essere completo, dispone di tutti i programmi che ci servono per poter lavorare, abbiamo editor di testo, programmi di disegno, suite per l’ufficio e, perchè no, giochi e passatempi, quindi possiamo subito accingerci alla sua installazione. Facile a dirsi, ma all’atto pratico ci si presentano subito i primi scogli.
In primo luogo tutto il software che abbiamo menzionato è distribuito in formato sorgente. Questo significa che dobbiamo compilare uno ad uno tutti i programmi, dal kernel all’ultimo tool, e questa operazione, oltre che presumere una certa competenza ed una dimestichezza con i vari compilatori a disposizione, ci porterebbe via un mare di tempo. In seguito, una volta che avremmo compilato tutto e messo ogni cosa al suo posto, ci troveremmo a dover configurare il sistema, scrivendo i file di configurazione per l’inizializzazione del sistema e per tutti i programmi che abbiamo installato, ed anche questa operazione ci porterebbe via parecchio tempo.

É a questo punto che ci viene in aiuto il terzo soggetto impegnato nello sviluppo di GNU/Linux: il distributore.
In principio fu Slackware. Già ai tempi in cui il sistema operativo cominciava ad assumere le proprie sembianze si presentò il problema di dare a chi avesse voluto installarlo sulla propria macchina gli strumenti adeguati per farlo, ed il team capitanato da Patrick Volkerding si occupò di risolverlo. Venne creato un sistema che chiunque (o quasi) avrebbe potuto installare. Era sufficiente effettuare l’avvio della macchina con l’apposito floppy di installazione e seguire la procedura rispondendo a qualche semplice domanda. Inserendo in successione i dischetti il programma di installazione si sarebbe occupato di copiare sul disco fisso i pacchetti precompilati dei programmi che si avrebbe richiesto, comprensivi dei relativi file di configurazione già redatti, ed infine si sarebbe occupato di installare il loader che avrebbe permesso il caricamento del sistema operativo “Slackware GNU/Linux” (che nel frattempo ha allungato ulteriormente il suo nome).

Successivamente si assistette al moltiplicarsi delle distribuzioni di GNU/Linux, per la maggior parte ad opera di società commerciali che vedevano nel software libero una concreta possibilità di guadagno. L’azienda che riuscì a catalizzare la maggior parte del mercato del software libero fu Red Hat, ideatrice tra le altre cose del sistema di gestione dei pacchetti software chiamato Red hat Package Manager (rpm). I pacchetti rpm potevano essere installati mediante un apposito tool che si preoccupava di vedere se nel sistema fosse già installata una versione diversa di quel particolare programma, se il funzionamento del programma fosse subordinato alla presenza di altri pacchetti come librerie e ulteriori programmi, e se l’installazione poteva dar luogo a conflitti tra diversi programmi che potessero pregiudicare il funzionamento dello stesso, se non addirittura il funzionamento dell’intero sistema.

Ma non erano solo le aziende ad interessarsi a GNU/Linux. Intorno al software libero nacque un vero e proprio movimento ideologico, ed alcuni seguaci di questo movimento stabilirono alcuni concetti fondamentali per la classificazione del software libero, coniando di fatto la definizione “Open Source”: si trattava del gruppo Debian.
La distribuzione “Debian GNU/Linux” si contraddistingue dalle altre perchè sviluppata appunto da un’intera comunità sparsa in tutto il pianeta, e per la particolare attenzione che viene prestata alla classificazione del software in base al tipo di licenza che lo accompagna ed in base al livello di stabilità. Anche Debian sviluppa un proprio sistema di pacchettizzazione del software, per molti versi più avanzato di quello di Red Hat, per mezzo del quale è possibile tenere costantemente aggiornato il sistema operativo senza bisogno di fare ricorso ad aggiornamenti radicali ogni volta che viene rilasciata una nuova versione.

In seguito altre aziende seguirono le orme di Red Hat sfornando ognuna la propria distribuzione, sviluppando la propria interfaccia grafica per l’installazione e i propri tool per agevolare la prima configurazione del sistema e la sua successiva manutenzione. Al susseguirsi delle versioni il software a corredo di ogni distribuzione migliorava costantemente, e l’obbiettivo che tutti cercavano di raggiungere era principalmente uno: realizzare un sistema con delle interfacce amichevoli e delle procedure di installazione sempre più automatizzate, in grado di rilevare l’hardware installato sulla macchina ed installare gli appositi driver, in modo che qualunque utente si fosse avvicinato al mondo del software libero non avrebbe avuto particolari difficoltà nella sua installazione e nella sua gestione.
Non vi è ombra di dubbio che il risultato sia stato tutt’altro che deludente. Tutte le moderne distribuzioni sono facilmente installabili, e qualunque utente alle prime armi non troverà nessuna difficoltà ad effettuare l’installazione, o quantomeno non troverà più difficoltà di quelle che si possono incontrare anche installando i più blasonati sistemi operativi commerciali.

Ogni distribuzione differisce dalle altre per molti aspetti quali la struttura del filesystem, la quantità e varietà del software fornito a corredo, la tipologia di utenza alla quale si orienta. In questo senso noteremo che alcune saranno più orientate al mercato dei server come Red Hat e Debian, mentre altre saranno più orientate al desktop come Mandrake e Suse, ma tutte avranno lo stesso sistema operativo alla base e di tutte, come stabilito dalla licenza GPL, saranno disponibili i sorgenti.