Storia del progetto NetBSD

Da Wiki di NetBSD Italia.

(Differenze fra le revisioni)
m
m (combattimento con le accento e altri piccoli errori di battitura)
Riga 3: Riga 3:
Il progetto [[NetBSD]] fu fondato nel 1993 da Chris Demetriou (cgd@), Theo de Raadt
Il progetto [[NetBSD]] fu fondato nel 1993 da Chris Demetriou (cgd@), Theo de Raadt
(attualmente responsabile di [[OpenBSD]]), Adam Glass e Charles M.  Hannum (mycroft@),
(attualmente responsabile di [[OpenBSD]]), Adam Glass e Charles M.  Hannum (mycroft@),
-
che lascio' il progetto qualche tempo dopo. Deve le sue origini all'UCB 4.3BSD
+
che lasciò il progetto qualche tempo dopo. Deve le sue origini all'UCB 4.3BSD
originale attraverso il rilascio Networking/2 e 386BSD (il port di BSD per le
originale attraverso il rilascio Networking/2 e 386BSD (il port di BSD per le
architetture [[i386]]).
architetture [[i386]]).
La frustrazione di integrare le patch e i rilasci di 386BSD hanno portato a FreeBSD,
La frustrazione di integrare le patch e i rilasci di 386BSD hanno portato a FreeBSD,
-
il quale si e' concentrato sulla piattaforma i386, mentre NetBSD e' formato per
+
il quale si è concentrato sulla piattaforma i386, mentre NetBSD è formato per
focalizzarsi sul supporto multi-piattaforma.
focalizzarsi sul supporto multi-piattaforma.
Da allora, in aggiunta ai molti sviluppatori all'interno del progetto, sono stati
Da allora, in aggiunta ai molti sviluppatori all'interno del progetto, sono stati
-
importati cambiamenti da molti altri sorgenti, incluso 4.4BSD Lite. NetBSD e' stato
+
importati cambiamenti da molti altri sorgenti, incluso 4.4BSD Lite. NetBSD è stato
anche usato come base per altri derivati, incluso Lites (costruito sopra Mach)
anche usato come base per altri derivati, incluso Lites (costruito sopra Mach)
-
dell'Universita' dello Utah e Rhapsody della Apple.
+
dell'Università dello Utah e Rhapsody della Apple.
== Origini ==
== Origini ==
Riga 20: Riga 20:
entrambi piuttosto bacati, ed entrambi privi di alcuni importanti supporti hardware.
entrambi piuttosto bacati, ed entrambi privi di alcuni importanti supporti hardware.
Fondamentalmente vi erano delle esigenze: non c'era un pacchetto di 386BSD completo
Fondamentalmente vi erano delle esigenze: non c'era un pacchetto di 386BSD completo
-
piu' le patch necessarie per farlo girare su piu' sistemi e correggere i bug, e non
+
più le patch necessarie per farlo girare su più sistemi e correggere i bug, e non
c'era segno che [[Bill Jolitz]] sarebbe riemerso e/o avrebbe fatto qualcosa.
c'era segno che [[Bill Jolitz]] sarebbe riemerso e/o avrebbe fatto qualcosa.
Buona parte della struttura del progetto si evolse a causa di alcuni problemi.
Buona parte della struttura del progetto si evolse a causa di alcuni problemi.
Probabilmente la scelta migliore fu iniziare ad utilizzare un controllo di versione
Probabilmente la scelta migliore fu iniziare ad utilizzare un controllo di versione
-
centrale (CVS); questo consenti' una visione molto ampia della storia del codice ed
+
centrale (CVS); questo consentì una visione molto ampia della storia del codice ed
-
(eventualmente) favori' le collaborazioni con un grosso numero di sviluppatori molto
+
(eventualmente) favorì le collaborazioni con un grosso numero di sviluppatori molto
-
facilmente. Vennero ''truccate'' alcune altre cose; per esempio, Chris si stanco' di
+
facilmente. Vennero ''truccate'' alcune altre cose; per esempio, Chris si stancò di
-
essere l'uomo di punta per ogni cosa e stava cercando di laurearsi al college, cosi'
+
essere l'uomo di punta per ogni cosa e stava cercando di laurearsi al college, così
-
venne creato un "cabal" interno per la gestione del progetto, che divento' noto come
+
venne creato un "cabal" interno per la gestione del progetto, che diventò noto come
il "core group" (nucleo). Sebbene il web fosse piuttosto nuovo, venne creato piuttosto
il "core group" (nucleo). Sebbene il web fosse piuttosto nuovo, venne creato piuttosto
rapidamente un sito web per diffondere le informazioni riguardanti il progetto e i
rapidamente un sito web per diffondere le informazioni riguardanti il progetto e i
Riga 36: Riga 36:
Buona parte di questa prima struttura (CVS, sito web, cabal, etc.) fu copiata da
Buona parte di questa prima struttura (CVS, sito web, cabal, etc.) fu copiata da
altri progetti [[OpenSource|open source]] (questo termine ancora non era largamente
altri progetti [[OpenSource|open source]] (questo termine ancora non era largamente
-
usato) -- anche la forma del nome del progetto e il termine "core". Questo divento' in
+
usato) -- anche la forma del nome del progetto e il termine "core". Questo diventò in
seguito un tipo di modello standard per avviare un progetto open source.
seguito un tipo di modello standard per avviare un progetto open source.
-
Sfortunatamente commisero qualche errore qui'. Come videro col passare degli anni,
+
Sfortunatamente commisero qualche errore qui. Come videro col passare degli anni,
uno dei grandi successi di Linux fu che ebbe un forte leader, che stabiliva obiettivi
uno dei grandi successi di Linux fu che ebbe un forte leader, che stabiliva obiettivi
e direzioni, e fu capace di far fare alla gente quello che volle -- o trovare
e direzioni, e fu capace di far fare alla gente quello che volle -- o trovare
-
qualcun'altro per farlo. Quest'ultima parte e' anche un elemento chiave; non aveva
+
qualcun'altro per farlo. Quest'ultima parte è anche un elemento chiave; non aveva
-
senso che qualcun'altro "comandasse" un pezzo di Linux (sebbene la "proprietaria'"
+
senso che qualcun'altro "comandasse" un pezzo di Linux (sebbene la "proprietaria"
de facto ci sia stata in alcune parti); se tu non producevi, Linus avrebbe usato il
de facto ci sia stata in alcune parti); se tu non producevi, Linus avrebbe usato il
codice di qualcun'altro. Se volevi che le persone utilizzassero le tue cose dovevi
codice di qualcun'altro. Se volevi che le persone utilizzassero le tue cose dovevi
Riga 49: Riga 49:
NetBSD non ebbe questo. In parte a causa della mancanza di persone, e in parte a causa
NetBSD non ebbe questo. In parte a causa della mancanza di persone, e in parte a causa
-
di una mentalita' piu' aziendale, i progetti furono spesso "bloccati". Una persona
+
di una mentalità più aziendale, i progetti furono spesso "bloccati". Una persona
poteva dire che lavoravano a un progetto, e a tutti gli altri veniva detto di fare
poteva dire che lavoravano a un progetto, e a tutti gli altri veniva detto di fare
riferimento a loro. Spesso questi progetti stagnavano o non progredivano affatto.
riferimento a loro. Spesso questi progetti stagnavano o non progredivano affatto.
Riga 56: Riga 56:
materializzati affatto.
materializzati affatto.
-
[[Charles M. Hannum]], come lui stesso dice, e' dispiaciuto di aver aiutato a creare
+
[[Charles M. Hannum]], come lui stesso dice, è dispiaciuto di aver aiutato a creare
-
questi problemi e che molti dei progetti che modellano se' stessi dopo NetBSD
+
questi problemi e che molti dei progetti che modellano se stessi dopo NetBSD
-
(probabilmente a causa della loro alta popolarita' nel 1993 e 1994) hanno sofferto di
+
(probabilmente a causa della loro alta popolarità nel 1993 e 1994) hanno sofferto di
-
simili problemi. FreeBSD e XFree86, per esepmio, hanno avuto dei progetti successori
+
simili problemi. FreeBSD e XFree86, per esempio, hanno avuto dei progetti successori
(fork, Dragonfly e X.Org) per ragioni molto simili.
(fork, Dragonfly e X.Org) per ragioni molto simili.
Sfortunatamente, ancora oggi esistono questi problemi nel progetto NetBSD, e niente
Sfortunatamente, ancora oggi esistono questi problemi nel progetto NetBSD, e niente
-
e' stato fatto per risolverli.
+
è stato fatto per risolverli.
== Le dimissioni di Theo ==
== Le dimissioni di Theo ==
Riga 71: Riga 71:
confronti degli utenti e sviluppatori di NetBSD. - ''Noi crediamo che non ci sia
confronti degli utenti e sviluppatori di NetBSD. - ''Noi crediamo che non ci sia
posto per questo tipo di comportamento fra i rappresentati del progetto NetBSD e
posto per questo tipo di comportamento fra i rappresentati del progetto NetBSD e
-
che in generale e' stato dannoso per il progetto.''.
+
che in generale è stato dannoso per il progetto.''.
-
Questa decisione fu difficile da prendere perche' Theo ha una lunga storia
+
Questa decisione fu difficile da prendere perché Theo ha una lunga storia
-
di contributi positivi al progetto. E' stato il principale custode del support
+
di contributi positivi al progetto. È stato il principale custode del support
SPARC di NetBSD ed ha scritto troppo codice per essere menzionato. -- ''Siamo
SPARC di NetBSD ed ha scritto troppo codice per essere menzionato. -- ''Siamo
certamente disposti ad accettare (e ci piacerebbe molto vedere) futuri contributi
certamente disposti ad accettare (e ci piacerebbe molto vedere) futuri contributi
-
da Theo, ma crediame che e' inappropriato tenerlo ancora come rappresentante
+
da Theo, ma crediame che è inappropriato tenerlo ancora come rappresentante
"ufficiale" del progetto.''.
"ufficiale" del progetto.''.
== Stato ==
== Stato ==
-
Oggi, il progetto e' gestito da "cabal" differenti. Questo e' il risultato di un
+
Oggi, il progetto è gestito da "cabal" differenti. Questo è il risultato di un
-
''colpo'' che ha avuto luogo nel 2000-2001, nel quale La Fondazione NetBSD e' stata
+
''colpo'' che ha avuto luogo nel 2000-2001, nel quale La Fondazione NetBSD è stata
ripresa da un cambiamento fraudolento del consiglio di amministrazione. Il "Progetto
ripresa da un cambiamento fraudolento del consiglio di amministrazione. Il "Progetto
-
NetBSD" (TNP) e "La Fondazione NetBSD" (TNF) furono intesi dall'inizio come entita'
+
NetBSD" (TNP) e "La Fondazione NetBSD" (TNF) furono intesi dall'inizio come entità
separate -- l'ultima fornendo le infrastrutturo di supporto per la prima -- questa
separate -- l'ultima fornendo le infrastrutturo di supporto per la prima -- questa
-
distinzione e' stata attivamente offuscata da allora, cosi' che gli attuali
+
distinzione è stata attivamente offuscata da allora, così che gli attuali
amministratori della TNF sono piuttosto a stretto controllo su molti aspetti del
amministratori della TNF sono piuttosto a stretto controllo su molti aspetti del
TNP.
TNP.
La TNF fu composta da una buona serie di capi, questa situazione potrebbe essere al
La TNF fu composta da una buona serie di capi, questa situazione potrebbe essere al
-
piu' accettabile -- anche se certamente non ideale. Il problema e', in realta' non
+
più accettabile -- anche se certamente non ideale. Il problema è, in realtà non
ci sono capi a questo punto. Gli "obiettivi" per i rilasci non sono basati su
ci sono capi a questo punto. Gli "obiettivi" per i rilasci non sono basati su
feedback dei clienti o pensando alle esigenze futuro, ma unicamente sulla base di
feedback dei clienti o pensando alle esigenze futuro, ma unicamente sulla base di
quello che sembra essere abbastanza "caldo" per poter essere possibile che sia
quello che sembra essere abbastanza "caldo" per poter essere possibile che sia
finito in tempo. Non ci sono direzioni di alto livello; se si chiede "che si dice
finito in tempo. Non ci sono direzioni di alto livello; se si chiede "che si dice
-
in merito al problema con i thread?" o "ci sara' un file system flash-friendly?",
+
in merito al problema con i thread?" o "ci sarà un file system flash-friendly?",
-
la miglior risposta che si otterra' e' "ci piacerebbe avere entrambi" -- ma viene
+
la miglior risposta che si otterrà e' "ci piacerebbe avere entrambi" -- ma viene
-
effettuato alcun lavoro per recrutare persone per ''codare'' queste cose, o
+
effettuato alcun lavoro per recrutare persone per implementare queste cose, o
incoraggiare gli sviluppatori esistenti a lavorarci.
incoraggiare gli sviluppatori esistenti a lavorarci.
Questo vuoto ha materialmente contribuito alla corrente stagnazione del progetto.
Questo vuoto ha materialmente contribuito alla corrente stagnazione del progetto.
-
Effettivamente, NetBSD e' molto lontano dietro a una pletora di progetti molto
+
Effettivamente, NetBSD è molto lontano dietro a una pletora di progetti molto
-
importanti. Il threading non funziona su piu' CPU -- ed anche su una sola CPU e'
+
importanti. Il threading non funziona su più CPU -- ed anche su una sola CPU è
-
un po' bacato. Non c'e' nessun buon flash file system. Fino a recenti versioni
+
un po' bacato. Non c'è nessun buon flash file system. Fino a recenti versioni
del sistema non c'era supporto per il journaling (eccetto per LFS che era ancora
del sistema non c'era supporto per il journaling (eccetto per LFS che era ancora
in qualche modo sperimentale). Anche se ci sono stati alcuni recenti lavori nel
in qualche modo sperimentale). Anche se ci sono stati alcuni recenti lavori nel
-
supporto alla sospensione, e' ancora largamente "rotto". La gestione dell'energia
+
supporto alla sospensione, è ancora largamente "rotto". La gestione dell'energia
-
e' molto primitiva. Etc. Anche i nuovi supporti hardware non hanno piu' origine
+
è molto primitiva. Etc. Anche i nuovi supporti hardware non hanno più origine
su NetBSD; sono sviluppati da FreeBSD e OpenBSD, e portati dopo. Ci sono poche
su NetBSD; sono sviluppati da FreeBSD e OpenBSD, e portati dopo. Ci sono poche
eccezionia questa regola (e.g. il supporto Bluetooth).
eccezionia questa regola (e.g. il supporto Bluetooth).
-
Per queste ragioni ed altre, il progetto e' sceso quasi fino al punto di
+
Per queste ragioni ed altre, il progetto è sceso quasi fino al punto di
-
irrilevanza. C'e' chi sostiene che questo sia al di la' di quanto esposto
+
irrilevanza. C'è chi sostiene che questo sia al di di quanto esposto
-
fin'ora. Questo e' un peccato, soprattutto da quando l'utilizzo di NetBSD
+
fin'ora. Questo è un peccato, soprattutto da quando l'utilizzo di NetBSD
-- specialmente nello spazio embedded (integrati) -- ha cominciato a crescere
-- specialmente nello spazio embedded (integrati) -- ha cominciato a crescere
a buon ritimo nel 2000 e 2001, prima del colpo di cui sopra.
a buon ritimo nel 2000 e 2001, prima del colpo di cui sopra.
== Approfondimenti ==
== Approfondimenti ==
-
* E' possibile ottenere maggiori e piu' dettagliate informazioni in merito ad ogni [[:Categoria:Piattaforme|piattaforma]] consultando la relativa pagina.  
+
* È possibile ottenere maggiori e più dettagliate informazioni in merito ad ogni [[:Categoria:Piattaforme|piattaforma]] consultando la relativa pagina.  
* [http://www.netbsd.org/about/history.html Storia del progetto NetBSD] sul sito ufficiale
* [http://www.netbsd.org/about/history.html Storia del progetto NetBSD] sul sito ufficiale
* [http://www.netbsd.org/about/ Informazioni sul progetto NetBSD] sul sito ufficiale
* [http://www.netbsd.org/about/ Informazioni sul progetto NetBSD] sul sito ufficiale

Versione delle 11:20, 11 gen 2009

Questo articolo è solo un abbozzo, contribuisci a migliorarlo secondo le convenzioni di NetBSD-it mettendo a disposizione le tue conoscenze. La comunità te ne sarà grata!

Il progetto NetBSD fu fondato nel 1993 da Chris Demetriou (cgd@), Theo de Raadt (attualmente responsabile di OpenBSD), Adam Glass e Charles M. Hannum (mycroft@), che lasciò il progetto qualche tempo dopo. Deve le sue origini all'UCB 4.3BSD originale attraverso il rilascio Networking/2 e 386BSD (il port di BSD per le architetture i386).

La frustrazione di integrare le patch e i rilasci di 386BSD hanno portato a FreeBSD, il quale si è concentrato sulla piattaforma i386, mentre NetBSD è formato per focalizzarsi sul supporto multi-piattaforma.

Da allora, in aggiunta ai molti sviluppatori all'interno del progetto, sono stati importati cambiamenti da molti altri sorgenti, incluso 4.4BSD Lite. NetBSD è stato anche usato come base per altri derivati, incluso Lites (costruito sopra Mach) dell'Università dello Utah e Rhapsody della Apple.

Indice

Origini

Quando nacque il progetto, Linux e 386BSD erano entrambi piccoli sistemi per hobbisti, entrambi piuttosto bacati, ed entrambi privi di alcuni importanti supporti hardware. Fondamentalmente vi erano delle esigenze: non c'era un pacchetto di 386BSD completo più le patch necessarie per farlo girare su più sistemi e correggere i bug, e non c'era segno che Bill Jolitz sarebbe riemerso e/o avrebbe fatto qualcosa.

Buona parte della struttura del progetto si evolse a causa di alcuni problemi. Probabilmente la scelta migliore fu iniziare ad utilizzare un controllo di versione centrale (CVS); questo consentì una visione molto ampia della storia del codice ed (eventualmente) favorì le collaborazioni con un grosso numero di sviluppatori molto facilmente. Vennero truccate alcune altre cose; per esempio, Chris si stancò di essere l'uomo di punta per ogni cosa e stava cercando di laurearsi al college, così venne creato un "cabal" interno per la gestione del progetto, che diventò noto come il "core group" (nucleo). Sebbene il web fosse piuttosto nuovo, venne creato piuttosto rapidamente un sito web per diffondere le informazioni riguardanti il progetto e i vari rilasci.

Buona parte di questa prima struttura (CVS, sito web, cabal, etc.) fu copiata da altri progetti open source (questo termine ancora non era largamente usato) -- anche la forma del nome del progetto e il termine "core". Questo diventò in seguito un tipo di modello standard per avviare un progetto open source.

Sfortunatamente commisero qualche errore qui. Come videro col passare degli anni, uno dei grandi successi di Linux fu che ebbe un forte leader, che stabiliva obiettivi e direzioni, e fu capace di far fare alla gente quello che volle -- o trovare qualcun'altro per farlo. Quest'ultima parte è anche un elemento chiave; non aveva senso che qualcun'altro "comandasse" un pezzo di Linux (sebbene la "proprietaria" de facto ci sia stata in alcune parti); se tu non producevi, Linus avrebbe usato il codice di qualcun'altro. Se volevi che le persone utilizzassero le tue cose dovevi muoverti.

NetBSD non ebbe questo. In parte a causa della mancanza di persone, e in parte a causa di una mentalità più aziendale, i progetti furono spesso "bloccati". Una persona poteva dire che lavoravano a un progetto, e a tutti gli altri veniva detto di fare riferimento a loro. Spesso questi progetti stagnavano o non progredivano affatto. Se lo facevano, gli stimoli erano spesso troppo lenti. Come risultato, molti progetti importanti sono stati spostati su ritmi glaciali, o non si sono materializzati affatto.

Charles M. Hannum, come lui stesso dice, è dispiaciuto di aver aiutato a creare questi problemi e che molti dei progetti che modellano se stessi dopo NetBSD (probabilmente a causa della loro alta popolarità nel 1993 e 1994) hanno sofferto di simili problemi. FreeBSD e XFree86, per esempio, hanno avuto dei progetti successori (fork, Dragonfly e X.Org) per ragioni molto simili.

Sfortunatamente, ancora oggi esistono questi problemi nel progetto NetBSD, e niente è stato fatto per risolverli.

Le dimissioni di Theo

Il 20 dicembre del 1994, i membri del "core" di NetBSD chiesero a Theo de Raadt di consegnare le dimissioni. Fu una decisione molto difficile da prendere, fu il risultato di una lunga storia di maleducazione e abusi, da parte di Theo, nei confronti degli utenti e sviluppatori di NetBSD. - Noi crediamo che non ci sia posto per questo tipo di comportamento fra i rappresentati del progetto NetBSD e che in generale è stato dannoso per il progetto..

Questa decisione fu difficile da prendere perché Theo ha una lunga storia di contributi positivi al progetto. È stato il principale custode del support SPARC di NetBSD ed ha scritto troppo codice per essere menzionato. -- Siamo certamente disposti ad accettare (e ci piacerebbe molto vedere) futuri contributi da Theo, ma crediame che è inappropriato tenerlo ancora come rappresentante "ufficiale" del progetto..

Stato

Oggi, il progetto è gestito da "cabal" differenti. Questo è il risultato di un colpo che ha avuto luogo nel 2000-2001, nel quale La Fondazione NetBSD è stata ripresa da un cambiamento fraudolento del consiglio di amministrazione. Il "Progetto NetBSD" (TNP) e "La Fondazione NetBSD" (TNF) furono intesi dall'inizio come entità separate -- l'ultima fornendo le infrastrutturo di supporto per la prima -- questa distinzione è stata attivamente offuscata da allora, così che gli attuali amministratori della TNF sono piuttosto a stretto controllo su molti aspetti del TNP.

La TNF fu composta da una buona serie di capi, questa situazione potrebbe essere al più accettabile -- anche se certamente non ideale. Il problema è, in realtà non ci sono capi a questo punto. Gli "obiettivi" per i rilasci non sono basati su feedback dei clienti o pensando alle esigenze futuro, ma unicamente sulla base di quello che sembra essere abbastanza "caldo" per poter essere possibile che sia finito in tempo. Non ci sono direzioni di alto livello; se si chiede "che si dice in merito al problema con i thread?" o "ci sarà un file system flash-friendly?", la miglior risposta che si otterrà e' "ci piacerebbe avere entrambi" -- ma viene effettuato alcun lavoro per recrutare persone per implementare queste cose, o incoraggiare gli sviluppatori esistenti a lavorarci.

Questo vuoto ha materialmente contribuito alla corrente stagnazione del progetto. Effettivamente, NetBSD è molto lontano dietro a una pletora di progetti molto importanti. Il threading non funziona su più CPU -- ed anche su una sola CPU è un po' bacato. Non c'è nessun buon flash file system. Fino a recenti versioni del sistema non c'era supporto per il journaling (eccetto per LFS che era ancora in qualche modo sperimentale). Anche se ci sono stati alcuni recenti lavori nel supporto alla sospensione, è ancora largamente "rotto". La gestione dell'energia è molto primitiva. Etc. Anche i nuovi supporti hardware non hanno più origine su NetBSD; sono sviluppati da FreeBSD e OpenBSD, e portati dopo. Ci sono poche eccezionia questa regola (e.g. il supporto Bluetooth).

Per queste ragioni ed altre, il progetto è sceso quasi fino al punto di irrilevanza. C'è chi sostiene che questo sia al di là di quanto esposto fin'ora. Questo è un peccato, soprattutto da quando l'utilizzo di NetBSD -- specialmente nello spazio embedded (integrati) -- ha cominciato a crescere a buon ritimo nel 2000 e 2001, prima del colpo di cui sopra.

Approfondimenti

Strumenti personali