A quel tempo, Berkeley, era dotata solo di grandi sistemi mainframe per l'elaborazione batch, così il primo acquisto fu un PDP-11/45, in grado di eseguire la versione 4 di Unix di allora. La Facoltà di Informatica di Berkeley, insieme a quelle di Matematica e di Statistica, fu in grado di acquistare un PDP-11/45. Nel gennaio 1974, una versione 4 su nastro magnetico fu disponibile e Unix fu installato dallo studente laureato Keith Standiford.

Sebbene Ken Thompson a Purdue non fu coinvolto in questa installazione avvenuta a Berkeley, come era solito essere per la maggior parte dei sistemi fino a quel momento, la sua competenza fu subito necessaria per poter determinare la causa di svariati e strani crash del sistema. Siccome Berkeley aveva al tempo solo un modem a una velocità di trasmissione di 300-baud con accoppiatore acustico senza risposta automatica, Thompson chiamò Standiford nella sala macchine e gli fece collegare il telefono al modem; in questo modo Thompson fu in grado di collaudare in remoto - dal New Jersey - i problemi del software.

La maggior parte dei problemi riscontrati erano dovuti all'incapacità del controller del disco di svolgere ricerche sovrapposte in modo affidabile, contrariamente a quanto asseriva la documentazione. L'11/45 di Berkley fu tra i primi sistemi nei quali Thompson si imbatté con due dischi sullo stesso controller! Il debugging remoto di Thompson fu il primo esempio di cooperazione che nacque tra Berkeley e Bell Labs. La buona volontà dei ricercatori dei laboratori di condividere il loro lavoro con Berkeley fu di valido aiuto nel rapido miglioramento dei software disponibili a Berkeley.

Sebbene Unix fu presto ristabilito e reso funzionante, l'alleanza tra le facoltà di Informatica, Matematica e Statistica iniziò a incontrare ostacoli; Matematica e

Statistica preferivano lavorare con il sistema RSTS della Digital Equipment Corporation (DEC). Dopo molte discussioni, fu raggiunto un compromesso nel quale ciascuna facoltà avrebbe usufruito di un turno di otto ore; Unix sarebbe stato messo in funzione per otto ore seguito da sedici ore di RSTS. Al fine di garantire l'equità, gli intervalli di tempo erano giornalmente a rotazione. Perciò, Unix funzionava dalle otto del mattino alle quattro del pomeriggio un giorno, dalle quattro pomeridiane a mezzanotte il giorno successivo, e da mezzanotte alle otto del mattino il terzo giorno. Nonostante questo orario bizzarro, gli studenti che frequentavano il corso su "I Sistemi Operativi" preferirono portare avanti i loro progetti con Unix piuttosto che con macchine per l'elaborazione di tipo batch.

I professori Eugene Wong e Michael Stonebraker furono entrambi intralciati dalle restrizioni dell'ambiente a lotti, perciò il loro progetto di database INGRES fu tra i primi gruppi che passarono dalle macchine per l'elaborazione batch a un ambiente interattivo fornito da UNIX. Molto presto essi trovarono intollerabili i tempi corti e insoliti del 11/45, così nella primavera del 1974, comprarono un 11/40 in grado di eseguire la versione 5 appena disponibile. Con la loro prima distribuzione di INGRES nell'autunno del 1974, il progetto INGRES diventò il primo gruppo della facoltà di Informatica a distribuire il loro software. Diverse centinaia di nastri INGRES furono distribuiti nei sei anni successivi, aiutando a consolidare la reputazione di Berkeley per aver progettato e costruito sistemi efficaci.

Anche con l'eliminazione del progetto INGRES dall'11/45, c'era ancora poco tempo disponibile per gli altri studenti. Per alleviare la carenza, i professori Michael Stonebraker e Bob Fabry, nel giugno del 1974, si prefissero di avere disponibili due 11/45 a fini didattici per la facoltà di Informatica. All'inizio del 1975 furono stanziati i fondi. All'incirca nello stesso periodo, la DEC presentò l'11/70, una macchina che pareva essere molto superiore all'11/45. I fondi per le due 11/45 furono ricongiunti al fine di comprare un solo 11/70 che fu consegnato nell'autunno del 1975. In concomitanza con l'arrivo del 11/70, Ken Thompson decise di prendersi un anno sabbatico come professore straordinario all'università californiana di Berkeley, la sua università. Thompson, insieme a Jeff Scriebman e Bob Kridle, caricò la versione più aggiornata di Unix, la 6, sull'11/70 appena implementato.

In quello stesso autunno del 1975 spuntarono due studenti laureati fino ad allora sconosciuti, Bill Joy e Chuck Haley; entrambi mostrarono un immediato interesse per il nuovo sistema. All'inizio iniziarono a lavorare sul Pascal, il sistema che Thompson aveva messo insieme mentre bighellonava nella stanza dell'11/70. Essi ampliarono e migliorarono l'interprete del Pascal fino al punto che questo diventò il sistema di programmazione scelto per gli studenti, vista la sua eccezionale capacità di gestione degli errori, oltre a una compilazione veloce e un ottima velocità di esecuzione.

Con la sostituzione del Modello 33 con telescrivente con il modello ADM-3 con videoterminale, Joy e Haley iniziarono a sentirsi intralciati dalle forzature dell'editor ed. Lavorando con un programma di utilità chiamato em che era stato fornito dal professor George Coulouris del Queen Mary's College di Londra, poterono continuare il lavoro fino alla creazione di un programma in grado di fornire editing di testo riga per riga.

Con la partenza di Ken Thompson alla fine dell'estate del 1976, Joy e Haley iniziarono ad essere interessati nell'esplorazione del kernel dall'interno. Sotto l'occhio vigile di Schriebman, installarono prima quanto rifinito e migliorato cioè il nastro dei cinquanta cambiamenti fornito dai Bell Labs. Avendo imparato a maneggiare l'interno del file sorgente, suggerirono svariati piccoli incrementi al fine di semplificare e sveltire alcuni impedimenti del kernel.

La prima distribuzione
Nel frattempo, l'interesse nel lavoro di correzione degli errori del compilatore Pascal fece accrescere le richieste di copie del sistema. All'inizio del 1977, Joy mise su la Berkeley Software Distribution (BSD). Questa prima distribuzione comprendeva il sistema Pascal e, in una sottodirectory nascosta del sorgente Pascal, l'editor di sistema. Più avanti nell'anno successivo, Joy, nella sua funzione di segretario della distribuzione, emise circa trenta copie gratuite del sistema.

Con l'arrivo di alcuni terminali ADM-3a dotati di cursori posizionabili sullo schermo, Joy fu finalmente in grado di vedere a video quanto scriveva, portando quindi l'editing visuale a Berkeley. Ben presto si ritrovò con un dilemma. Come molto spesso succede nelle università con poche capacità economiche, i vecchi apparecchi non sono mai rimpiazzati tutti in una volta. Piuttosto che adottare un codice per ottimizzare gli aggiornamenti a differenti terminali, egli decise di unificare la gestione del video usando un piccolo interprete al fine di ridisegnare il video. Questo interprete veniva guidato con una descrizione delle caratteristiche del terminale, uno sforzo che portò finalmente al termcap.

Per la metà del 1978, la distribuzione del software aveva chiaramente bisogno di essere aggiornata. Il sistema Pascal fu espressamente e marcatamente irrobustito grazie a feedback ricevuti dagli utenti finali sempre più in crescita; inoltre, era stato suddiviso in due passaggi così da poter essere eseguito sui PDP-11/34. Il risultato dell'aggiornamento fu La Seconda Berkeley Software Distribution, un nome che fu presto siglato con 2BSD. Insieme al sistema Pascal migliorato, furono anche inclusi vi e termcap per alcuni terminali. Ancora una volta Bill Joy mise in piedi da solo la distribuzione, rispondendo al telefono e incorporando i feedback degli utenti nel sistema. Poco dopo nell'anno successivo, quasi settantacinque nastri furono messi in circolo. Sebbene Joy si dedicò ad altri progetti l'anno successivo, la 2BSD continuò a espandersi. La versione finale di questa distribuzione - 2.11BSD - è un sistema completo usato da centinaia di PDP-11 ancora in funzione in svariati angoli del mondo.

VAX Unix
All'inizio del 1978, il professore Richard Fateman iniziò a cercare una macchina con un maggior spazio di indirizzamento sulla quale poter continuare il suo lavoro su Macsyma (originariamente iniziato su un PDP-10). Il nuovo arrivato VAX-11/780 soddisfava i requisiti richiesti e rientrava nel budget previsto. Fateman, insieme ad altri tredici membri di facoltà, stese una proposta di NSF (Network System File) che abbinò con alcuni fondi di facoltà, così da poter acquistare un VAX.

Inizialmente sul VAX era caricato il sistema operativo VMS della DEC, ma la facoltà era abituata all'ambiente Unix e voleva continuare a usarlo. Così, appena dopo l'arrivo del VAX, Fateman riuscì ad avere - da John Reiser e Tom London dei Bell Labs - una copia 32/V di Unix sul VAX.

Sebbene la 32/V forniva Unix versione 7 sul VAX, non si era in condizioni di sfruttare la capacità della memoria virtuale dell'hardware VAX. Come i suoi predecessori sul PDP-11, questo era un sistema interamente basato sulla funzione di swap. Per il gruppo Macsyma di Berkeley, la carenza di memoria virtuale significò che lo spazio di indirizzamento del processo era limitato dalle dimensioni della memoria fisica, inizialmente 1 megabyte sul nuovo VAX.

Per alleggerire questo problema, Fateman contattò il professor Domenico Ferrari, un membro della facoltà di sistemistica a Berkeley, così da sondare la possibilità di far mettere a punto al suo gruppo un sistema di memoria virtuale per Unix. Ozalp Babaoglu, uno degli studenti del professor Ferrari, si mise all'opera per poter trovare un qualche modo di implementare un sistema per settare l'indirizzamento delle pagine di memoria che funzionasse sul VAX; il suo compito era complicato perché il VAX non era dotato di bit di riferimento.

Appena Babaoglu raggiunse la fine della sua prima modifica dell'implementazione, si mise in contatto con Bill Joy per avere una mano nella comprensione delle complessità del kernel di Unix. Intrigato dall'approccio di Babaoglu, Joy si aggregò per aiutare a integrare il codice nel 32/V e poi collaborò anche per il successivo collaudo del programma.

Sfortunatamente, Berkeley aveva solo un unico VAX, sia per lo sviluppo dei sistemi che per la produzione generale. Così, alcune settimane subito dopo le vacanze di Natale, la ben tollerante utenza si ritrovò collegata alternativamente sul 32/V e su Virtual VAX/Unix. Spesso il lavoro svolto su quest'ultimo sistema si arrestava improvvisamente, seguito, alcuni minuti più tardi, da un prompt del 32/V. Nel 1979, a gennaio, la maggioranza degli errori furono corretti, e il 32/V entrò a far parte del passato.

Joy capì che il VAX a 32 bit avrebbe ben presto reso obsoleto il 16-bit PDP-11, e iniziò a trasferire il software della 2BSD al VAX. Mentre io e Peter Kessler trasferivamo il sistema Pascal, Joy fece la medesima cosa con l'editor ex e vi, la shell C, e una miriade di altri programmi più piccoli provenienti dalla 2BSD. Una distribuzione completa fu organizzata per la fine del 1979. Questa distribuzione comprendeva la memoria virtuale del kernel, le utilità standard 32/V, e le aggiunte dal 2BSD. Nel dicembre dello stesso anno, Joy rilasciò la prima copia di quasi un centinaio della 3BSD, la prima distribuzione VAX a Berkeley.

La versione finale dei Bell Laboratories fu la 32/V; dopodiché tutte le versioni Unix di AT&T, inizialmente System III e dopo System V, furono gestite da diversi gruppi che spinsero commercialmente delle versioni stabili. Con la commercializzazione di Unix, i ricercatori di Bell Laboratories non furono più in grado di fungere da stanza di compensazione per la continuazione delle ricerche su Unix. Dato che i ricercatori continuavano a modificare il sistema Unix, essi si resero conto che avrebbero avuto bisogno di un'organizzazione che potesse produrre versioni di ricerca. A causa del suo originario coinvolgimento con Unix e il suo passato di distributrice di strumenti basati su Unix, Berkeley si ritrovò ben presto a ricoprire il ruolo che precedentemente era stato svolto dai laboratori Bell.

Il supporto di DARPA
Nel frattempo, negli uffici di pianificazione della Defence Advanced Research Projects Administration (DARPA, Amministrazione Progetti Avanzati di Ricerca della Difesa, ndt), vi furono delle discussioni che ebbero una grande influenza sul lavoro a Berkeley. Uno dei primi successi del DARPA fu di strutturare una rete di computer a livello nazionale, collegando insieme tutti i maggiori centri di ricerca. A quel tempo, essi scoprirono che molti dei computer di questi centri stavano raggiungendo la fine dei loro giorni e dovevano essere rimpiazzati. Il costo maggiore di questa sostituzione era il trasferimento del software di ricerca sulle nuove macchine. Inoltre, molte postazioni erano incapaci di riutilizzare il software a causa della diversità dell'hardware e dei sistemi operativi.

La scelta di un solo rivenditore hardware era impraticabile a causa dei molteplici e differenti bisogni dei gruppi di ricerca e il non interesse di dipendere da un solo produttore. Perciò, i pianificatori di DARPA decisero che la soluzione migliore era di unificare il livello dei sistemi operativi. Dopo molte discussioni, Unix fu scelto come sistema standard vista la sua provata portabilità.

Nell'autunno del 1979, Bob Fabry si mostrò disponibile verso l'idea di DARPA, di muoversi verso Unix scrivendo una proposta nella quale suggeriva a Berkeley di sviluppare una versione potenziata del 3BSD a uso dell'utenza del DARPA. Fabry portò una copia di questa sua proposta a un meeting di DARPA sull'elaborazione dell'immagine e la fornì anche ai fornitori del VLSI (integrazione a larghissima scala, ndt), oltre che ai rappresentanti di Bolt, Beranek e Newman - gli sviluppatori di ARPAnet (progetto di collegamento in rete di calcolatori di centri di ricerca del Ministero della Difesa e di università statunitensi, ndt). Vi erano delle riserve sul fatto che Berkeley fosse in grado di produrre un sistema funzionante; a ogni buon conto, l'uscita di 3BSD nel dicembre del 1979 dissipò ogni dubbio.

Con la crescente buona reputazione subito dopo l'uscita del 3BSD, così da poter convalidare le sue aspirazioni, Bob Fabry fu in grado di stipulare un contratto di 18 mesi con DARPA all'inizio di aprile del 1980. Questo contratto prevedeva l'aggiunta di alcune caratteristiche richieste da DARPA. Sotto i migliori auspici di tale accordo, Bob Fabry creò un'organizzazione che fu battezzata come Computer Systems Research Group, siglata come CSRG. Immediatamente assunse Laura Tong per seguire il progetto amministrativo. Fabry pose la sua attenzione sulla ricerca di un capo progetto in grado di seguire lo sviluppo del software. Fabry ritenne che, dato che Joy aveva appena passato l'esame di ammissione per il conseguimento del Ph.D (dottorato di ricerca), si sarebbe concentrato sul conseguimento della laurea piuttosto che ricoprire una posizione di sviluppatore di software. Ma Joy aveva altri piani. Una notte, all'inizio di marzo, chiamò Fabry a casa dimostrandosi interessato nel prendersi l'incarico di seguire l'ulteriore sviluppo di Unix. Nonostante la sorpresa, Fabry non ci mise molto ad accettare questa offerta. Il progetto iniziò immediatamente. Tong strutturò un sistema di distribuzione che potesse gestire un maggior volume di ordini rispetto alla precedente distribuzione organizzata da Joy. Fabry fu in grado di coordinare insieme a Bob Guffy alla AT&T, unitamente ai legali, all'università di california, l'uscita ufficiale di Unix con termini che fossero accettati da tutti. Joy introdusse il "job control" da parte di Jim Kulp e aggiunse il riavvio automatico, un gestore di file a blocco da 1K, e ulteriore supporto alla macchina VAX più recente: la VAX-11/750. Per l'ottobre del 1980, una distribuzione impeccabile che includeva anche il compilatore Pascal, il sistema di Franz Lisp, e un sistema di gestione posta rinnovato, che fu messo in circolazione come 4BSD. Durante la sua vita, della durata di nove mesi, furono distribuite circa 150 copie. Gli accordi di licenza erano su una base per-istituzione piuttosto che per-macchina; in questo modo la distribuzione raggiunse circa 500 macchine.

Con la distribuzione sempre più ampliata e la visibilità di Berkeley Unix, alcuni critici iniziarono a emergere. David Kashtan del Stanford Research Institute produsse una relazione nella quale descriveva i risultati dei benchmark che provò sia sul VMS che sul Berkeley Unix.

Questi benchmark rilevarono seri problemi di prestazioni con il sistema Unix sul VAX. Mettendo da parte i suoi piani futuri per alcuni mesi, Joy iniziò sistematicamente a mettere a punto il kernel. In poche settimane ebbe pronto un rapporto scritto quale controprova che dimostrava che i benchmark di Kashtan potevano essere adattati sia a Unix che a VMS.

Piuttosto che continuare a caricare il 4BSD, il sistema appena approntato, con l'aggiunta del codice di autoconfigurazione di Robert Elz, uscì come 4.1BSD nel giugno del 1981. Nei suoi due anni di vita ne furono rilasciate circa 400 copie. L'intento originario era stato quello di definirla come la versione 5BSD; ad ogni modo, vi furono delle obiezioni da parte di AT&T sul fatto che avrebbe potuto crearsi della confusione tra i clienti con l'uscita commerciale di Unix, System V, e un'ulteriore uscita a Berkeley denominata 5BSD. Così, con l'intento di risolvere la questione, Berkeley si mostrò d'accordo nel cambiare la serie di nomi per le uscite a venire lasciando valido 4BSD e semplicemente incrementando il numero iniziale con un decimale.

4.2BSD
Con l'uscita del 4.1BSD, molto del furore venutosi a creare a proposito delle sue prestazioni si spense. DARPA era sufficientemente soddisfatta dei risultati del primo contratto che ne fu stipulato uno nuovo per la durata di due anni con Berkeley, utilizzando fondi cinque volte quelli stanziati precedentemente. Metà dei soldi furono destinati al progetto di Unix, il resto per altre ricerche della facoltà di Informatica. Il contratto prevedeva un lavoro maggiore da portare avanti sul sistema, così che i ricercatori di DARPA potessero continuare al meglio il loro lavoro.

Basandosi sui bisogni del gruppo DARPA, furono stabiliti gli obiettivi e il lavoro iniziò in modo da poter definire le modifiche da apportare al sistema. In particolare, il nuovo sistema avrebbe dovuto includere un file system più veloce che avrebbe aumentato le sue prestazioni fino a raggiungere quelle permesse dai dischi, supportare processi che richiedevano maggiore spazio di indirizzamento, fornire una comunicazione tra i processi flessibile e facilitata, così da mettere in grado i ricercatori di fare il loro lavoro su sistemi distribuiti; e inoltre, avrebbe integrato il supporto di rete così che le macchine fossero in grado di far girare il nuovo sistema partecipando con facilità all'ARPAnet.

Al fine di prestare assistenza nella definizione del nuovo sistema, Duane Adams, il supervisore di Berkeley del contratto presso DARPA, formò un gruppo conosciuto come "steering committee" per coadiuvare il lavoro di design assicurandosi che i bisogni del gruppo di ricerca fossero tenuti in conto. Questo comitato si riunì due volte l'anno, tra l'aprile del 1981 e giugno del 1983. Vi facevano parte tra gli altri Bob Fabry, Bill Joy e Sam Leffler dell'università californiana di Berkeley; Alan Nemeth e Rob Gurwitz di Bolt, Beranek, e Newman; Dennis Ritchie dei Bell Laboratories; Keith Lantz della Stanford University; Rick Rashid della Carnegie-Mellon University; Bert Halstead dello Massachusetts Institute of Technology; Dan Lynch de "The Information Science Institute"; Duane Adams e Bob Baker di DARPA; e Jerry Popek dell'Università Californiana di Los Angeles. Iniziate nel 1984, queste riunioni furono soppiantate con seminari che si allargavano accogliendo molte più persone.

Un documento iniziale che proponeva facilitazioni da apportare al nuovo sistema fu messo in circolo tra i membri del steering committee e altre persone al di fuori di Berkeley nel luglio del 1981, facendo nascere dibattiti prolissi. Nell'estate del 1981, mi aggregai al CSRG e misi in opera l'implementazione del nuovo file system. Durante l'estate Joy si concentrò sull'implementazione di un prototipo delle utilità di comunicazione tra processi. Nell'autunno dello stesso anno, Sam Leffler si unì al CSRG come membro dello staff a tempo pieno, lavorando con Bill Joy.

Quando Rob Gurwitz rese disponibile una prima implementazione del protocollo TCP/IP a Berkeley, Joy lo integrò nel sistema e ne calibrò le prestazioni. Durante questo lavoro, fu chiaro a Joy e Leffler che il nuovo sistema richiedeva un supporto superiore a quello standard previsto dai protocolli della rete DARPA. Quindi, fu ridisegnata la struttura interna del software, ridefinendo le interfacce in modo tale che potessero essere utilizzati simultaneamente più protocolli di rete.

Appena terminata la ristrutturazione interna e integrati i protocolli TCP/IP con i miglioramenti derivanti dal prototipo IPC, furono create diverse semplici applicazioni per poter fornire agli utenti locali un accesso alle risorse remote. Questi programmi, rcp, rsh, rlogin e rwho furono intesi come strumenti temporanei che potevano essere poi rimpiazzati da comandi più ragionevoli (così si spiega l'uso della "r" come prefisso). Questo sistema, chiamato 4.1a, fu distribuito la prima volta nell'aprile del 1982 per un uso limitato; non era mai stato previsto per una distribuzione più ampia, sebbene copie "piratate" del sistema proliferavano nell'impaziente attesa del edizione 4.2.

Il sistema 4.1a si rivelò essere obsoleto ancora prima di raggiungere il suo compimento. Comunque, il feedback degli utenti forniva utili informazioni che vennero usate per creare una proposta riveduta per un nuovo sistema chiamato 4.2BSD System Manual. Questo documento fu messo in circolazione nel febbraio 1982 e conteneva una descrizione concisa delle interfacce utente proposte per rendere più agevole il sistema che si sarebbe chiamato 4.2BSD.

In concomitanza con lo sviluppo del 4.1a, ho completato io stesso l'implementazione del nuovo, e per il mese di giugno 1982, l'avevo pienamente integrato nel kernel del 4.1a. Il sistema risultante fu chiamato 4.1b e girava solo a Berkeley su poche macchine selezionate. Joy presagiva che con delle imminenti variazioni significative da apportare al sistema, era meglio evitare anche una distribuzione locale, soprattutto visto che sarebbe stato necessario che il file system su ciascuna macchina venisse scaricato e reinstallato per convertirlo da 4.1a a 4.1b. Una volta che il file system si dimostrò essere affidabile, Leffler procedette con l'aggiunta di un nuovo file system collegato con il sistema di comunicazione, mentre Joy era al lavoro per revisionare i servizi di comunicazione tra processi.

Nella primavera inoltrata del 1982, Joy annunciò che stava per approdare alla Sun Microsystems. Durante l'estate, suddivise il suo tempo tra Sun e Berkeley, utilizzando la maggioranza del suo tempo per raffinare le sue revisioni ai servizi di comunicazione tra processi e riorganizzando i sorgenti del kernel di Unix al fine di isolare porzioni legate alla macchina. Con la partenza di Joy, Leffler assunse la responsabilità del completamento del progetto. Alcuni termini erano già stati fissati e l'uscita era stata promessa a DARPA per la primavera del 1983. Dati i tempi ristretti, il lavoro restante per il completamento della versione fu valutato e vennero stabilite delle priorità. In particolare, le migliorie alla memoria virtuale e la progettazione di parti più sofisticate di comunicazione tra processi furono relegate tra le ultime priorità (e più tardi accantonate del tutto). In più, con l'implementazione da quasi un anno e con l'alzarsi delle aspettative dell'utenza di Unix, si decise di mettere insieme una versione intermedia per tenersi stretti gli utenti fino a quando il sistema finale sarebbe stato completato. Questo sistema, chiamato 4.1c, fu distribuito nell'aprile del 1983; molti rivenditori usarono questa versione per predisporre il porting sul proprio hardware necessario per la 4.2. Pauline Schwartz fu assunta al fine di prendersi carico di tutti gli oneri relativi alla distribuzione cominciando con la versione 4.1c.

Nel giugno 1983, Bob Fabry passò il controllo della parte amministrativa del CSRG ai professori Domenico Ferrari e Susan Graham, così da poter iniziare il suo anno sabbatico liberandosi dalla marcia frenetica sostenuta per tutti i quattro anni precedenti. Leffler procedette con il completamento del sistema, implementando nuovi accorgimenti per i segnali, facendo aggiunte al supporto di rete, rifacendo il sistema unico di ingresso e uscita, così da semplificare il processo di installazione, integrando le limitazioni dei dischi con l'aiuto di Robert Elz, aggiornando tutta la documentazione, ed evidenziando tutti i difetti della versione 4.1c. Nell'agosto del 1983, il sistema 4.2BSD era pronto.

Quando Leffler lasciò Berkeley per Lucasfilm dopo aver completato il 4.2, fu rimpiazzato da Mike Karels. La precedente esperienza di Karel con la distribuzione del software 2.9BSD PDP-11, rappresentò il supporto migliore per il suo nuovo lavoro. Dopo aver terminato il mio Ph.D. nel dicembre del 1984, raggiunsi a tempo pieno Mike Karels al CSRG.

La popolarità del 4.2BSD fu impressionante: in un anno e mezzo furono emesse più di 1.000 licenze. Di conseguenza, furono immesse sul mercato più copie della versione 4.2BSD da sola, che non tutto quanto il software distribuito da Berkeley fino a quel momento. La maggior parte dei rivenditori di Unix ordinarono il sistema 4.2BSD, piuttosto che il sistema commerciale V della AT&T. La ragione di ciò fu che il System V non aveva né il servizio di comunicazione dati, né il file system Berkeley Fast. L'uscita di Unix da parte della BSD fu in grado di mantenere il posizionamento sul mercato per alcuni anni, prima di ritornare alle origini. Sia il servizio di comunicazione dati e altri miglioramenti del 4.2BSD, furono integrati nel System V, ma i rivenditori solitamente ritornarono al primo. Ad ogni modo, più avanti i miglioramenti messi a punto dal BSD continuarono comunque a essere incorporati nel System V.

4.3BSD
Proprio come con la versione 4.1BSD, le critiche non si fecero attendere. La maggior parte dei reclami erano sui tempi troppo lenti di esecuzione del sistema. Il problema - e non ci sorprese - era dovuto al fatto che i nuovi accorgimenti non erano stati messi a punto al meglio, dunque molte strutture di dati del kernel non erano state adattate nel miglior modo possibile per poter supportare queste nuove caratteristiche. Il primo anno, sia per me che per Karel, è stato utilizzato solo per mettere a punto e ripulire il sistema.

Dopo due anni di lavoro sulla messa a punto e sulla rifinitura del codice di rete, decidemmo di fare un annuncio alla conferenza Usenix nel giugno 1985, anticipando l'uscita del 4.3BSD entro l'estate. Comunque, i nostri piani furono interrotti brutalmente da quelli della BBN. Essi molto correttamente sottolinearono che non avevamo mai aggiornato la 4.2BSD con la versione finale del loro codice di rete. Piuttosto, stavamo ancora usando il prototipo iniziale che loro stessi ci avevano fornito molti anni prima. Si lamentarono con il DARPA che a Berkeley fu implementata un'interfaccia mentre BBN avrebbe dovuto implementare il protocollo, quindi Berkeley avrebbe dovuto rimpiazzare il codice TCP/IP sul 4.3BSD con l'implementazione della BBN.

Mike Karels ottenne il codice della BBN; fece una valutazione del lavoro che era stato fatto a partire dal momento in cui il prototipo fu dato in mano a quelli di Berkeley. Fu lui che decise che il piano migliore era di incorporare le idee più valide riscontrabili nel codice BBN nel codice di base di Berkeley. La ragione per la quale si conservò il codice di base di Berkeley era che questo fu testato considerevolmente e poi molto migliorato dopo la massiccia distribuzione nella versione 4.2BSD. Ad ogni modo, come compromesso, Mike propose di includere entrambe le implementazioni nella distribuzione del 4.3BSD, lasciando libera scelta agli utenti su quale dei due selezionare per il loro kernel.

Dopo aver rivisto la decisione di Mike Karels, DARPA decise che rendere disponibili due codici base avrebbe condotto a inutili problemi di operatività multiutente, e che perciò avrebbe dovuto uscire con una sola implementazione. Al fine di decidere quale dei due codici base usare, li passarono entrambi a Mike Muuse del Ballistics Research Laboratory, che fu riconosciuto sia da Berkeley che da BBN come parte terza neutrale. Dopo un mese di valutazioni, venne prodotto un rapporto nel quale si asseriva che il codice Berkeley era più efficiente ma che quello BBN gestiva meglio la congestione. Il risultato fu che il codice Berkeley eseguì tutti i test in modo ineccepibile, mentre il codice BBN si trovò inguaiato se posto in situazioni di stress. La decisione finale di DARPA fu che il 4.3BSD avrebbe avuto il codice Berkeley.

Il sistema 4.3BSD rifinito fu alla fine in circolazione nel giugno 1986. Come ci si aspettava, zittì molte delle lamentele sulle sue performance, così come il 4.1BSD calmò le riprovazioni sul 4BSD. Sebbene la maggior parte dei rivenditori erano tornati ancora al System V, un'altra buona parte avevano caricato il 4.3BSD sui loro sistemi, particolarmente sul sottosistema di rete.

Nell'ottobre del 1986, Keith Bostic si unì al CSRG. Un aspetto del suo nuovo impiego era che avrebbe potuto finire un progetto sul quale aveva lavorato nel suo precedente ufficio; tale progetto consisteva nell'interfacciare il 4.3BSD al PDP-11. Mentre sia io che Karels eravamo convinti che sarebbe stato impossibile fare in modo che un sistema compilato a 250 Kbyte sul VAX potesse andare bene su un PDP-11 che aveva una spazio di indirizzamento di 64 Kbyte, ci accordammo che Bostic avrebbe continuato in questa ricerca. Con nostra grande sorpresa, l'interfacciamento fu completato con successo; venne usata una serie intricata di overlay e stati del processore ausiliari trovati nel PDP-11. Il risultato fu la versione 2.11BSD, creata da Casey Leedom e Bostic, che è tuttora usata in alcuni degli ultimi PDP-11 ancora in funzione nel 1998.

Nel frattempo, diventava sempre più ovvio che l'architettura del VAX stava per giungere alla fine dei suoi giorni, e che era ora di cominciare a prendere in considerazione l'utilizzo di altre macchine su cui far eseguire il BSD. Una nuova e promettente architettura, per quei tempi, fu creata da Computer Consoles Incorporated, e denominata Power 6/32. Sfortunatamente, l'architettura in questione decadde appena la società decise di adottare nuove strategie. In ogni caso, queste due società fornirono al CSRG diverse macchine che resero possibile in compimento del lavoro, iniziato da Bill Joy, di suddividere il kernel del BSD in porzioni dipendenti e indipendenti dalle macchine. Il risultato di questo lavoro uscì con il nome di 4.3BSD-Tahoe nel giugno del 1988. Il nome Tahoe derivava dalla denominazione di sviluppo usata da Computer Consoles Incorporated, per la macchina che fecero finalmente uscire sul mercato con il nome di Power 6/32. Nonostante l'utilità e la durevolezza del Power 6/32 risultò breve, il lavoro svolto per suddividere in parti il kernel si dimostrò di estrema utilità, appena il BSD venne interfacciato con altre architetture.

Networking, Release 1
Per la versione 4.3BSD-Tahoe, tutti i destinatari del BSD dovevano prima procurarsi una licenza del codice sorgente da AT&T. Questo perché i sistemi BSD non erano mai stati emessi da Berkeley in formato solo binario; la distribuzione prevedeva sempre il sorgente completo per ogni parte del sistema. La storia del sistema Unix e di quello BSD in particolare, hanno dimostrato il potere del rendere disponibile il sorgente agli utenti. Invece di usare passivamente il sistema, questi hanno lavorato attivamente per trovare sempre nuovi errori, migliorare le prestazioni e la funzionalità e persino aggiungere caratteristiche completamente nuove.

Con l'incremento del costo delle licenze sul sorgente di AT&T, i rivenditori che volevano costruirsi dei prodotti di rete autonomi basati sul TCP/IP, adatti per il mercato dei PC, usando il codice BSD, riscontrarono che i costi per codice binario erano proibitivi. Quindi, fu richiesto a Berkeley di lasciar perdere il codice di rete e le sue utilità, facendo in modo di fornire termini di licenza tali da non richiedere una licenza AT&T del sorgente. Il codice di rete TCP/IP non esisteva ovviamente su 32/V e quindi fu sviluppato interamente da Berkeley e dai suoi collaboratori. Il codice di rete originato da BSD e le utilità di supporto, furono rese disponibili nel giugno 1989 come Networking Release 1, il primo codice ridistribuito gratuitamente da Berkeley.

I termini della licenza erano ampi. Un licenziatario poteva rilasciare del codice modificato o intatto sorgente o in forma binaria senza contabilizzazione o diritti per Berkeley. I soli requisiti erano che le specifiche ai diritti d'autore nel file sorgente venissero lasciate intatte; che i prodotti che incorporavano il codice indicassero nella loro documentazione che il prodotto conteneva codice dell'università di California e dei suoi collaboratori. Sebbene Berkeley richiedeva un contributo di 1.000 dollari per un nastro, chiunque era libero di averne una copia da chiunque altro che già lo aveva ricevuto. Diversi grandi siti furono costruiti per utenti ftp anonimi subito dopo il rilascio. Dato che era così facilmente disponibile, il CSRG fu compiaciuto che diverse centinaia di organizzazioni lo ordinassero, dato che con le loro quote accrescevano il fondo istituito per ulteriori sviluppi.

4.2BSD
Nel frattempo, lo sviluppo del sistema di base continuava. Il sistema di memoria virtuale, la cui interfaccia fu descritta la prima volta nel 4.2BSD, fu finalmente disponibile. Come spesso succedeva con CSRG, noi abbiamo sempre cercato di trovare il codice esistente da integrare, piuttosto che scrivere qualcosa dal nulla. Quindi, piuttosto che delineare un nuovo sistema di memoria virtuale, cercavamo delle alternative. La nostra prima scelta fu il sistema di memoria virtuale che apparve su Sun Microsystem SunOS. Sebbene ci furono alcune discussioni sul fatto che Sun sembrava dare una mano a Berkeley per il codice, nulla rimase di queste chiacchiere. Perciò noi preferimmo la nostra seconda scelta, e cioè incorporare il sistema di memoria virtuale dal sistema operativo MACH, elaborato dalla Carnegie-Mellon University. Mike Hibler dell'Università dello Utah, mise insieme il fulcro della tecnologia del MACH con l'interfaccia utente descritta nel manuale dell'architettura del 4.2BSD (era la stessa interfaccia usata dal SunOS).

Le altre aggiunte più importanti al sistema in quel momento furono una versione compatibile da Sun del gestore di file di rete (NFS). Di nuovo il CSRG fu in grado di evitare di scrivere il codice NFS da zero, fece invece in modo che un implementazione venisse fatta da Rick Macklem dell'università canadese di Geulph.

Sebbene la configurazione completa del 4.4BSD non era ancora pronta per il lancio, il CSRG decise di provare una versione provvisoria per poter così ottenere un ulteriore feedback e sperimentare le due maggiori aggiunte apportate al sistema. Questa versione provvisoria fu denominata 4.3BSD-Reno e questo successe all'inizio del 1990. La versione fu battezzata così in onore di una città del Nevada, famosa per le scommesse; questa scelta era un modo indiretto per rammentare ai suoi destinatari che, far girare una versione provvisoria rappresentava un po' una scommessa.

Networking, Release 2
Durante uno dei nostri meeting settimanali di gruppo al CSRG, Keith Bostic sollevò la questione della popolarità della versione ridistribuita gratuitamente sulla rete e si interrogò sulla possibilità di mettere a punto una versione ampliata che includesse più codice BSD. Io e Mike Karel facemmo presente a Bostic che rendere disponibili grandi parti del sistema rappresentava un'impresa ardua, ma fummo d'accordo che lui potesse scegliere come gestire la reimplementazione delle centinaia di utilità e l'enorme libreria C; e poi avrebbe affrontato la questione del kernel. In cuor nostro, io e Karel eravamo certi che così si metteva subito fine alla discussione.

Bostic fu il pioniere imperterrito della tecnica di sviluppo di massa via rete. Egli sollecitò gli altri a riscrivere le utilità di Unix dal niente, a parte le caratteristiche già note. La loro unica soddisfazione sarebbe stata quella di leggere il loro nome nella lista dei collaboratori di Berkeley, proprio accanto al nome dell'utilità che avevano riscritto. I collaboratori iniziarono lentamente e misero mano in maggioranza alle utilità più futili. Ma appena la lista delle utilità completate si allungava, e Bostic continuava a cercare nuove contribuzioni in occasione di eventi pubblici, come per esempio all'Usenix, il numero delle contribuzioni continuava a crescere. Ben presto la lista raggiunse il centinaio di utilità ed entro un anno e mezzo, quasi tutte le utilità più importanti, come pure le librerie, furono riscritte.

Bostic entrò con orgoglio e decisione nel mio ufficio e in quello di Mike Karelos, lista in pugno, chiedendo come stavamo procedendo con il lavoro sul kernel. Rassegnati al nostro lavoro - Karels, Bostic e io - passammo i mesi seguenti rivedendo tutta la distribuzione, file per file, rimuovendo i codici che erano nel 32/V. Passata la bufera, scoprimmo che rimanevano solo sei file del kernel che erano ancora contaminati e che non potevano essere riscritti così banalmente. Mentre prendevamo in considerazione la riscrittura di questi sei file, così da avere un sistema completo, decidemmo invece di rendere disponibile solo ciò che avevamo. Abbiamo cercato, sul serio e in ogni modo, di avere il permesso da parte dell'alta amministrazione dell'università di ampliare la nostra versione. Dopo lunghi dibattiti interni e verifiche del nostro metodo per determinare il codice proprietario, ci venne dato l'ok finale.

La nostra preoccupazione iniziale era di trovare un nome completamente nuovo per la nostra seconda versione in distribuzione gratuita. Comunque, consideravamo l'ottenimento di una licenza completa, nuova e approvata dai legali dell'università come un'inutile perdita di tempo e di risorse. Perciò, decidemmo di chiamare la nuova versione Networking Release 2, visto che potevamo fare solo una revisione alla già approvata licenza del Networking Release 1. Quindi, la nostra seconda grande e allargata versione gratuita iniziò a essere disponibile nel giugno del 1991. I termini di ridistribuzione e il costo erano gli stessi della prima versione. Come per la prima, alcune centinaia di singoli e organizzazioni pagarono i diritti a Berkeley, pari a 1.000 dollari.

L'intervallo dal Networking Release 2 a un sistema pienamente funzionante non fu molto lungo. Entro sei mesi dall'uscita, Bill Jolitz aveva riscritto le modifiche ai sei file mancanti. Egli prontamente approntò un sistema completamente compilato e scaricabile per i PC 386 che si chiamava 386/BSD. La distribuzione del sistema di Jolitz 386/BSD fu fatta quasi interamente sulla Rete. Semplicemente lo caricò per gli utenti ftp anonimi e lasciò che chiunque volesse fosse in grado di scaricarlo in modo del tutto gratuito. In poche settimane si creò un folto gruppo di seguaci.

Sfortunatamente, il bisogno di avere un lavoro a tempo pieno significò che Jolitz non poteva dedicare tutto il tempo necessario per mantenere aggiornato il flusso di intoppi e miglioramenti al 386/B54. Perciò, entro pochi mesi dall'uscita del 386/BSD, un gruppo di avidi utenti dello stesso, formarono il gruppo NetBSD mettendo insieme tutte le loro risorse, così da dare una mano nel mantenimento, e più avanti nel miglioramento, del sistema stesso. Queste versioni divennero conosciute come NetBSD. Il gruppo NetBSD scelse di enfatizzare il supporto di quante più piattaforme possibili, e continuò con lo stesso stile di ricerca e sviluppo utilizzato da CSRG. Fino al 1998 era solo sulla Rete; nessun altro mezzo di distribuzione era disponibile. Il loro gruppo continuò a porsi come obiettivo primario il reale fulcro composto dagli utenti tecnici. Maggiori informazioni sul progetto NetBSD si possono ottenere consultando il sito http://www.netbsd.org.

Il gruppo FreeBSD si formò qualche mese dopo il NetBSD con uno statuto tale da supportare solo l'architettura di PC, interessando un gruppo di utenti più grande ma meno avanzati tecnicamente, così come Linux aveva fatto. Tale gruppo costruì degli script di installazione elaborati e iniziò a mettere in distribuzione questo sistema su un CD-ROM a basso costo. La combinazione di un'installazione facilitata e una forte promozione sia sulla Rete che nelle principali fiere di settore - come il Comdex - portò a una veloce crescita. Sicuramente FreeBSD vanta al momento la più larga base installata di tutti gli altri sistemi derivanti dalla versione 2.

FreeBSD ha anche sfruttato l'onda della popolarità di Linux aggiungendo una modalità simulata che permette ai file binari di Linux di essere eseguiti su una piattaforma FreeBSD. Questa caratteristica permette agli utenti FreeBSD di usare il gruppo di applicazioni, sempre in crescita, disponibili per Linux mentre sfruttano la robustezza, l'affidabilità e le prestazioni del sistema FreeBSD. Il gruppo ha recentemente aperto un FreeBSD Mall (http://www.freebsdmall.com), che raduna molte componenti dell'utenza FreeBSD, compresi i servizi di consulenza, prodotti derivati, libri, e newsletter.

A metà degli anni 90, OpenBSD si sganciò dal gruppo NetBSD. I loro obiettivi tecnici erano orientati a migliorare la sicurezza del sistema. Quelli di marketing erano di rendere il sistema più facile da usare e maggiormente disponibile. Quindi, iniziarono a produrre e vendere CD-ROM con molte di queste facili installazioni per la distribuzione con FreeBSD. Maggiori informazioni sul progetto OpenBSD possono essere reperite sul sito http://www.openbsd.org.

La causa legale
Oltre ai gruppi organizzati per ridistribuire gratis i sistemi creatisi attorno al Networking Release 2, - la società Berkeley Software Design, Incorporated (BSDI) - nacque per creare e distribuire una versione commerciale del codice. (Maggiori informazioni sulla BSDI sono disponibili al sito http://www.bsdi.com). Come gli altri gruppi, iniziò aggiungendo i sei file mancanti che Bill Jolitz aveva scritto per il suo 386/BSD. La BSDI iniziò a vendere il suo sistema, sia sorgente che binario, nel gennaio del 1992 a 995 dollari. Vi fu anche una campagna nella quale si propagandava uno sconto del 99% sul prezzo imposto per il sorgente del System V più i sistemi binari. I lettori interessati avrebbero dovuto chiamare 1-800-ITS-Unix.

Subito dopo l'inizio della campagna vendite della BSDI, quest'ultima ricevette una lettera dalla Unix System Laboratories (USL) (una società consociata alla maggioritaria AT&T, che cercò di frenare lo sviluppo di Unix e la sua vendita). La lettera richiedeva l'interruzione della promozione del loro prodotto come Unix, e in particolare che si smettesse di usare un numero di telefono ingannevole. Sebbene il numero di telefono fu subito eliminato e gli annunci cambiarono in modo da informare che il prodotto non era Unix, USL era ancora insoddisfatta e sporse querela, così da diffidare la BSDI dalla vendita del loro prodotto. La querela adduceva che il prodotto della BSDI conteneva il codice proprietario USL oltre ai suoi segreti commerciali. USL cercò di ottenere un'ingiunzione per fermare le vendite della BSDI fino a quando la causa non fosse terminata, sostenendo che USL sarebbe stata soggetta a danni irreparabili, dovuti alla rivelazione dei loro segreti commerciali, se la distribuzione BSDI fosse continuata.

Al primo sentore dell'ingiunzione, la BSDI asserì fermamente che stava semplicemente usando i sorgenti distribuiti gratuitamente dall'Università di California, più sei file aggiuntivi. Si rese disponibile a discutere il contenuto di ciascuno dei sei file aggiunti, ma non riteneva che si dovesse considerare responsabile del fatto che i file fossero in distribuzione dall'Università di California. Il giudice accolse le ragioni della BSDI e decise che USL avrebbe dovuto portare avanti la causa solo per quel che riguardava i sei file, altrimenti avrebbe chiuso così il procedimento. L'USL rendendosi conto delle difficoltà che avrebbe incontrato nel farne un caso solo per i sei file, decise di sporgere di nuovo querela contro entrambe BSDI e l'Università di California. Come già prima, USL richiese un ingiunzione sulla distribuzione del Networking Release 2, sia dai prodotti dell'Università che da quelli della BSDI. Rendendosi conto che l'ingiunzione era così imminente da essere obbligatoria in poche settimane, ci si preparò con la massima serietà. Tutti i membri del CSRG deposero, così come quasi tutti gli impiegati della BSDI. Le memorie difensive, le contro-memorie difensive, le contro-contro-memorie difensive andavano avanti e indietro da un avvocato all'altro. Keith Bostic dovette personalmente scrivere, insieme a me, diverse centinaia di pagine di materiale che fu inserito in varie memorie difensive.

Nel dicembre 1992, Dickinson R. Debevoise, un giudice distrettuale dello stato del New Jersey, ascoltò le ragioni dell'ingiunzione. Sebbene i giudici solitamente regolarizzano le richieste di ingiunzione immediatamente, lui decise di farlo solo dopo consultazione. Un venerdì, circa sei settimane più tardi, produsse un rapporto di quaranta pagine nel quale annullò l'ingiunzione e respinse tutte le richieste, tranne due. Queste ultime erano ridotte ai diritti d'autore più recenti e alla possibilità di perdita dei segreti commerciali. Egli suggerì altresì che la questione avrebbe dovuto essere posta a una corte giurisdizionale statale, prima di essere sottoposta al giudizio di una corte federale.

L'Università di California raccolse subito il suggerimento e si affrettò a contattare la corte giurisdizionale californiana il lunedì mattina seguente, sporgendo una contro-querela alla USL. Nel querelare per prima in California, l'Università predispose l'ambiente ove si sarebbe svolta qualsiasi altra azione legale. La legge costituzionale prevedeva infatti che tutte le querele venissero sporte in un singolo stato, così da evitare che una delle parti con maggiori mezzi economici potesse permettersi di sporgere una querela in ciascuno dei cinquanta stati, penalizzando l'opponente. Il risultato fu che, se USL voleva portare avanti un'altra causa contro l'Università in un tribunale statale, sarebbe stata obbligata a farlo in California, piuttosto che nel suo stato, il New Jersey.

La querela dell'università sosteneva che la USL aveva fallito nel suo tentativo di vantare un credito dalla università per l'uso che quest'ultima aveva fatto del codice BSD nel System V, così come previsto dalla licenza che aveva concordemente firmato con l'università. Se questa rivendicazione fosse stata dimostrata valida, l'Università avrebbe chiesto che USL fosse obbligata a ristampare tutta la sua documentazione con i ringraziamenti esatti, notificando tutti i suoi licenziatari della sua svista, oltre che pubblicare una pagina pubblicitaria intera su tutte le pubblicazioni finanziarie più note quali The Wall Street Journal e la rivista Fortune, rendendo noto a tutto il mondo degli affari del suo errore involontario.

Subito dopo la presentazione della querela al tribunale, USL cambiò proprietario da AT&T a Novell. Il direttore generale di Novell, Ray Noorda, asserì pubblicamente che avrebbe perorato la sua causa sul mercato, piuttosto che in tribunale. Per l'estate del 1993, iniziò la conciliazione. Sfortunatamente, le due parti in causa avevano scavato talmente in profondità che questa fase procedette a rilento. Con alcune ulteriori sollecitazioni da parte di Ray Noorda verso USL, molti dei punti in questione vennero risolti e una conciliazione fu finalmente raggiunta nel gennaio del 1994. Il risultato fu che tre file vennero rimossi dai 18.000 creati nel Networking Release 2, e un numero di cambiamenti minori vennero apportati ad altri file. In aggiunta, l'Università concordò di aggiungere i diritti d'autore della USL a circa altri 70 file, sebbene questi ultimi continuassero a essere distribuiti gratuitamente.

4.4BSD
La nuova benedetta versione fu chiamata 4.4BSD-Lite e fu disponibile nel giugno del 1994 con identici termini della versione del Networking. Specificatamente, i termini permisero una distribuzione gratuita sia del sorgente che della forma binaria, soggetta solo ai termini dei diritti d'autore dell'Università; questi ultimi restarono intatti e l'Università riceveva un contributo quando altri usavano il codice. Allo stesso tempo, il sistema completo fu reso disponibile come 4.4BSD-Encumbered e richiedeva ancora dei destinatari per avere una licenza sorgente da USL.

La fine della causa legale prevedeva anche che USL non avrebbe citato in giudizio alcuna organizzazione che usasse il 4.4BSD-Lite come base per il suo sistema. Quindi, tutti i gruppi BSD che stavano creando versioni in quel momento, BSDI, NetBSD, e FreeBSD, dovettero ritoccare il loro codice base con i file sorgenti del 4.4BSD-Lite, nel quale avrebbero poi incorporato i loro abbellimenti e miglioramenti. Mentre questa reintegrazione causò un piccolo ritardo nello sviluppo dei vari sistemi BSD, questo fu comunque un bene, perché obbligò tutti i gruppi divergenti a sincronizzarsi nuovamente per i tre anni di sviluppo al CSRG, a partire dall'uscita del Networking Release 2.

4.4BSD-Lite, Release 2
I soldi realizzati con il 4.4BSD-Encumbered e il 4.4BSD-Lite, furono utilizzati per finanziare un progetto part-time di integrazione dei difetti e dei miglioramenti. Questi cambiamenti continuarono per due anni fino a quando i tempi di monitoraggio degli errori e gli avanzamenti della configurazione scomparirono un po' alla spicciolata. Il gruppo finale così risultante fu denominato 4.4BSD-Lite, Release 2, nel giugno 1995. La maggior parte di questi cambiamenti diventarono infine la base di tutti gli altri file sorgenti del sistema.

Subito dopo l'uscita del 4.4BSD-Lite Release 2, il CSRG fu sciolto. Dopo essere stato per quasi vent'anni il capitano del BSD, ritenemmo che era giunto il momento di dare ad altri la possibilità di continuare, apportando nuove idee e maggior entusiasmo. Anche se può sembrare meglio avere un solo punto di riferimento autorevole che controlla lo sviluppo del sistema, l'idea di avere gruppi diversi con statuti differenti, assicurava che più di un approccio poteva essere ritenuto valido. Dato che il sistema è disponibile come sorgente, le migliori idee possono essere raccolte anche dagli altri gruppi. Se un gruppo diventa particolarmente efficace, potrebbe eventualmente diventare il sistema dominante.

Oggi, il movimento dell'Open Source software, sta ottenendo molta attenzione e rispetto. Sebbene il sistema Linux è forse il più conosciuto, almeno la metà delle utilità di cui è fornito derivano dalla distribuzione BSD. Le distribuzioni di Linux sono anche pesantemente dipendenti dagli aggiornamenti, dal collaudo di programmi e da altri strumenti di sviluppo scritti dalla Free Software Fundation. Insieme, il CSRG, la Free Software Fundation e gli sviluppatori del kernel di Linux, hanno creato una piattaforma dalla quale è stato lanciato il movimento del software Open Source. Sono orgoglioso di aver avuto l'opportunità di aiutare i pionieri dell'Open Source software. Attendo con ansia il giorno in cui questo diventerà il modo preferito di sviluppare e comprare software ovunque, sia per gli utenti singoli che per le società.