FreeBSD tiene kernel, librerie di sistema, comandi di base e documentazione in un unico albero sorgente, sotto una sola licenza derivata da quella di Berkeley. La serie stabile è la 4.8, uscita il 3 aprile 2003 per le architetture i386 e alpha; la 5.x, aperta dalla 5.0 del 19 gennaio 2003, è il ramo di sviluppo. Qui mi interessano le conseguenze pratiche del modello “sistema unico”, non un confronto di prestazioni.

Contesto

FreeBSD discende da 4.4BSD-Lite, l’ultima distribuzione di codice del Computer Systems Research Group dell’Università della California a Berkeley. Da quella base il progetto tiene insieme tre cose che molti altri sistemi liberi tengono separate: il kernel, la userland (le librerie e i comandi che formano l’ambiente di sistema) e la documentazione, fatta di pagine man e di un Handbook che vive nello stesso repository.

La distanza dal modello Linux sta tutta qui. Linux è un kernel; quello che un utente installa è una distribuzione, cioè un kernel attorno al quale un fornitore monta la libreria C, la shell, i comandi di base, un sistema di pacchetti e la documentazione, ciascuno preso da un progetto diverso con un proprio ciclo di rilascio e una propria licenza. In FreeBSD quel lavoro di integrazione è già fatto a monte: l’albero /usr/src contiene il sistema intero, e make world lo ricompila come un unico prodotto coerente.

L’architettura del base system

Il confine che FreeBSD traccia passa tra base system e ports. Il base system è ciò che sta nell’albero sorgente: kernel, libc, i comandi in /bin e /usr/bin, i demoni essenziali, i file di configurazione predefiniti. Tutto il resto — un server web, un interprete Perl, un ambiente desktop — è software di terze parti che arriva dalla Ports Collection.

La Ports Collection è un albero di directory sotto /usr/ports. Un port non contiene il sorgente dell’applicazione: contiene un Makefile con le istruzioni per scaricarlo, le eventuali patch, l’elenco delle dipendenze e le opzioni di compilazione. Un make install in quella directory scarica il sorgente originale, applica le patch, risolve le dipendenze in modo ricorsivo e installa il risultato, registrandolo nel database dei pacchetti. La collezione raccoglie diverse migliaia di applicazioni mantenute così.

La separazione salta agli occhi al primo aggiornamento. Aggiornare il base system (cvsup dei sorgenti, poi make buildworld / make installworld) e aggiornare le applicazioni installate (portupgrade, o ricompilare i ports a mano) sono due procedure distinte, con calendari indipendenti. Il sistema di base avanza in modo conservativo; i ports seguono il ritmo dei progetti a monte.

Il punto critico: una sola licenza, e cosa concede

FreeBSD esce sotto licenza BSD. Nella forma attuale chiede solo di conservare l’avviso di copyright e la clausola di esclusione di responsabilità; non obbliga a pubblicare le modifiche né ad adottare la stessa licenza per il software derivato. Chi prende codice del base system e lo mette in un prodotto proprietario può farlo senza dover rilasciare i sorgenti.

È la differenza di fondo con la GNU General Public License, che governa il kernel Linux e gran parte della userland GNU. La GPL obbliga a rendere disponibili le opere derivate, se distribuite, sotto la stessa licenza e con il codice sorgente. Sono due scelte deliberate e legittime: la GPL ottiene reciprocità — chi estende il codice restituisce le estensioni — la licenza BSD ottiene la massima libertà di riuso a valle, al prezzo di non garantire quel ritorno.

Lo si vede nei prodotti che incorporano stack derivati da BSD senza esporre i propri sorgenti. Il caso più noto è lo stack TCP/IP di Berkeley, riusato in parecchi sistemi commerciali negli anni Ottanta e Novanta: lo stesso codice è finito, sotto i termini BSD, dentro sistemi proprietari di fornitori diversi.

Isolamento: le jail come estensione coerente

Con un sistema unico si possono costruire meccanismi che agiscono sull’intero ambiente, non sul singolo programma. Le jail, arrivate con la 4.0 il 14 marzo 2000, ne sono l’esempio. Una jail chiude un gruppo di processi in una vista parziale del sistema: una propria radice di filesystem, un proprio insieme di utenti, un proprio indirizzo di rete, senza alcun modo di vedere o toccare ciò che sta fuori.

Rispetto a chroot, che limita la sola vista del filesystem e lascia al processo gli altri canali verso il kernel, la jail estende il confinamento all’elenco dei processi, alle interfacce di rete e alle operazioni privilegiate. Il progetto è descritto nel lavoro di Poul-Henning Kamp e Robert Watson presentato alla conferenza SANE 2000: il sottotitolo — confining the omnipotent root — dice l’obiettivo con precisione, rendere root potente solo dentro il proprio recinto. Il meccanismo regge perché kernel e userland crescono insieme: le utility che creano e gestiscono le jail stanno nello stesso albero del kernel che le implementa.

Implicazioni operative

Per chi gestisce server, fra un’installazione e l’altra cambia poco. Due macchine FreeBSD alla stessa release hanno lo stesso base system, gli stessi percorsi, la stessa documentazione di riferimento. La conoscenza si trasferisce in modo prevedibile, e una procedura scritta per una macchina vale anche per le altre. La documentazione, tenuta nello stesso repository del codice, tende a restare allineata alle versioni del sistema che descrive.

Il ramo 5.x mostra anche il costo del modello. Riscrivere il supporto multiprocessore con locking a grana fine nel kernel (il lavoro noto come SMPng) e introdurre l’infrastruttura GEOM per il livello di I/O a blocchi sono interventi che toccano l’intero sistema, e per questo procedono in un ramo separato mentre la 4.x resta la scelta conservativa in produzione. Tenere insieme kernel e userland dà coerenza all’integrazione, ma vuol dire che i cambiamenti profondi si pagano sull’intero albero in una volta sola.

Limiti

Questa nota descrive un modello di distribuzione e di licenza, non misura prestazioni: parlare di comportamento sotto carico richiederebbe un banco di prova e numeri propri. Il confronto con Linux riguarda l’organizzazione del codice e delle licenze, non un giudizio di merito tra i due sistemi. La licenza BSD non è migliore della GPL in assoluto: realizza un compromesso diverso, e la scelta dipende da cosa si vuole garantire a valle. Le versioni e le date valgono alla data di scrittura; le serie 4.x e 5.x sono entrambe in evoluzione.

Immagine di copertina: Il BSD Daemon, diavoletto rosso con tridente e scarpe da ginnastica, mascotte di FreeBSD — illustrazione di Khaled, pubblico dominio — https://commons.wikimedia.org/wiki/File:Bsd_Daemon.svg