diff --git a/it_IT.ISO8859-15/articles/committers-guide/article.sgml b/it_IT.ISO8859-15/articles/committers-guide/article.sgml index b04d2f0dfa..d5c3171f92 100644 --- a/it_IT.ISO8859-15/articles/committers-guide/article.sgml +++ b/it_IT.ISO8859-15/articles/committers-guide/article.sgml @@ -1,1557 +1,1558 @@ %man; %freebsd; %authors; %teams; %mailing-lists; %translators; ]>
Guida del Committer The FreeBSD Italian Documentation Project $FreeBSD$ 1999 2000 2001 2002 2003 The FreeBSD Italian Documentation Project Questo documento fornisce informazioni per la comunità dei committer di FreeBSD. Tutti i nuovi committer dovrebbero leggere questo documento prima di iniziare, e i committer già esistenti sono fortemente incoraggiati a riguardarselo di tanto in tanto. Traduzione a cura di &a.it.alex;. Dettagli Amministrativi Host con il Repository Principale ncvs.FreeBSD.org Metodi di Accesso &man.ssh.1;, solo protocollo 2 CVSROOT Principale ncvs.FreeBSD.org:/home/ncvs &a.cvs; Principali &a.peter; e &a.markm;, così come &a.joe; per i ports/ Mailing List &a.developers;, &a.committers; (Entrambe sono liste private; gli archivi possono essere trovati in /home/mail/developers-archive e /home/mail/committers-archive sul cluster di FreeBSD.org.) Report mensili del Core Team /home/core/public/monthly-report sul cluster di FreeBSD.org. Tag CVS Degni di Nota RELENG_4 (4.X-STABLE), HEAD (-CURRENT) È richiesto l'uso di &man.ssh.1; o &man.telnet.1; con Kerberos 5 per connettersi agli host del progetto e solo &man.ssh.1;, protocollo 2 ha il permesso di collegarsi all'host con il repository. Questi sono generalmente più sicuri che un semplice &man.telnet.1; o &man.rlogin.1; visto che la negoziazione delle credenziali avverrà sempre in modo cifrato. Tutto il traffico è cifrato di default con &man.ssh.1;. Insieme a programmi di utilità come &man.ssh-agent.1; e &man.scp.1;, anch'essi disponibili, &man.ssh.1; è di gran lunga più conveniente. Se non sai nulla di &man.ssh.1;, guarda la . Tipi di Bit di Commit Il repository CVS di FreeBSD ha un numero di componenti che, se combinati, supportano i sorgenti di base del sistema operativo, la documentazione, l'infrastruttura dei port delle applicazioni di terze parti, e vari programmi di utilità. Quando vengono assegnati i bit di commit di FreeBSD, vengono specificate le aree dell'albero dove il bit può essere usato. Solitamente, le aree associate a un bit corrispondono a quelle di chi ha autorizzato l'assegnamento del bit di commit. Ulteriori aree di autorità possono essere aggiunte in seguito: se occorrerà, il committer dovrà seguire le normali procedure di allocazione del bit di commit per quell'area dell'albero, chiedendo l'approvazione all'entità appropriata e possibilmente prendendo un mentore per quell'area per un po' di tempo. Tipo di Committer Responsabile Componenti dell'Albero src core@ src/, doc/ soggetta ad appropriata revisione doc doceng@ doc/, www/, documentazione src/ ports portmgr@ ports/ I bit di commit assegnati prima dello sviluppo della nozione di aree di autorità possono essere usati in molte parti dell'albero. Tuttavia, il buon senso dice che un committer che non ha mai lavorato precedentemente in un'area dell'albero chieda una revisione del proprio lavoro prima di effettuare il commit, chieda l'approvazione del responsabile appropriato, e/o lavori d'accordo con un mentore. Dato che le regole sulla manutenzione del codice differiscono a seconda dell'area dell'albero, questo è per il bene del committer che lavora in un'area poco familiare tanto quanto per gli altri che lavorano sull'albero. I committer sono incoraggiati a chiedere la revisione del proprio lavoro come parte del normale processo di sviluppo, indifferentemente dall'area dell'albero in cui stanno lavorando. Operazioni sul CVS Si assume che tu abbia già familiarità con le operazioni di base di CVS. I &a.cvs; sono i proprietari del repository CVS e sono responsabili delle sue modifiche dirette allo scopo di ripulire o sistemare dei gravi abusi di CVS da parte di un committer. Nel caso dovessi causare qualche problema al repository, diciamo una errata operazione di cvs import o cvs tag, invia un messaggio ai &a.cvs; (o chiama uno di loro) ed esponi il problema ad uno di loro. Gli unici che hanno il permesso di manipolare direttamente i bit del repository sono i repomeister. Non ci sono shell di login disponibili su ncvs.FreeBSD.org, tranne che per i repomeister. Le operazioni sul CVS sono fatte da remoto impostando la variabile di ambiente CVSROOT a ncvs.FreeBSD.org:/home/ncvs e la variabile CVS_RSH a ssh, e quindi effettuando le appropriate operazioni di check-out/check-in. Se desideri aggiungere qualcosa di totalmente nuovo (ad esempio dei sorgenti in contrib, ecc.), deve essere usato cvs import. Guarda come riferimento la pagina man di &man.cvs.1; per l'utilizzo. Per favore non usare cvs checkout o update con la macchina con il repository ufficiale impostata come CVS Root per tenere aggiornato il tuo albero dei sorgenti. CVS da remoto non è ottimizzato per la distribuzione via rete e richiede un grande sovraccarico di lavoro e di amministrazione sul lato server. Utilizza il nostro metodo di distribuzione avanzato cvsup per ottenere i bit del repository, ed esegui solamente l'operazione di commit sull'host con il repository. Forniamo un'estesa rete di mirror cvsup per questo scopo, così come diamo accesso al cvsup-master se hai veramente bisogno di essere aggiornato alle ultime modifiche. Il cvsup-master ha la potenza necessaria a gestire questa cosa, il repository principale no. &a.jdp; è a capo del cvsup-master. Molti committer definiscono l'alias fcvs che si traduce in cvs -d xxx@ncvs.FreeBSD.org:/home/ncvs per questo scopo. In questo modo svolgono tutte le operazioni di CVS localmente ed usano fcvs commit per effettuare il commit sull'albero CVS ufficiale. Se devi usare le operazioni add e delete di CVS come se fosse un'operazione &man.mv.1;, allora va effettuata una copia nel repository piuttosto che usare add e delete di CVS. In una copia nel repository, un CVS Meister copierà il/i file nei loro nuovi nomi e/o locazioni e ti avviserà ad operazione avvenuta. Lo scopo di una copia del repository è di preservare la cronologia dei cambiamenti del file, o i log. Noi del FreeBSD Project diamo molta importanza alla cronologia dei cambiamenti che CVS fornisce al progetto. Informazioni di riferimento, tutorial, e FAQ su CVS possono essere trovate su: http://www.cvshome.org/docs/, e anche le informazioni contenute nei capitoli di Karl Fogel da Open Source Development with CVS sono molto utili. &a.des; ha fornito inoltre il seguente mini manuale su CVS. Effettua il check out di un modulo con il comando co o checkout. &prompt.user; cvs checkout shazam Questo estrae una copia del modulo shazam. Se non c'è alcun modulo shazam nel file dei moduli, cercherà allora una directory di primo livello chiamata shazam. Opzioni utili con <command>cvs checkout</command> Non crea le directory vuote Estrae solo un livello, non le sottodirectory Estrai la versione, il ramo, o il tag ver Estrai i sorgenti com'erano in data data
Esempi pratici su FreeBSD: Estrai il modulo miscfs, che corrisponde a src/sys/miscfs: &prompt.user; cvs co miscfs Ora hai una directory chiamata miscfs con le sottodirectory CVS, deadfs, devfs, e così via. Una di queste (linprocfs) è vuota. Estrai gli stessi file, ma con il percorso completo: &prompt.user; cvs co src/sys/miscfs Ora hai una directory chiamata src, con le sottodirectory CVS e - sys. src/sys ha le + sys. La directory + src/sys ha le sottodirectory CVS e miscfs, ecc. Estrai gli stessi file, ma elimina le directory vuote: &prompt.user; cvs co -P miscfs Ora hai una directory chiamata miscfs con le sottodirectory CVS, deadfs, devfs... ma nota che non c'è nessuna sottodirectory linprocfs, perché non contiene alcun file. Estrai la directory miscfs, ma nessuna delle sue sottodirectory: &prompt.user; cvs co -l miscfs Ora hai una a directory chiamata miscfs con solo una sottodirectory chiamata CVS. Estrai il modulo miscfs com'è nel ramo 4.X: &prompt.user; cvs co -rRELENG_4 miscfs Puoi modificare i sorgenti ed effettuare il commit su questo ramo. Estrai il modulo miscfs com'era nella 3.4-RELEASE. &prompt.user; cvs co -rRELENG_3_4_0_RELEASE miscfs Non potrai effettuare il commit delle modifiche, visto che RELENG_3_4_0_RELEASE corrisponde ad un preciso istante di tempo, non a un ramo. Estrai il modulo miscfs com'era il 15 gennaio 2000. &prompt.user; cvs co -D'01/15/2000' miscfs Non potrai effettuare modifiche. Estrai il modulo miscfs com'era una settimana fa. &prompt.user; cvs co -D'last week' miscfs Non potrai effettuare modifiche. Tieni presente che cvs salva i metadati in sottodirectory chiamate CVS. Gli argomenti di e sono fissi, che vuol dire che cvs se li ricorderà in seguito, ad esempio quando farai un cvs update. Controlla lo stato dei file estratti con il comando status. &prompt.user; cvs status shazam Questo visualizza lo stato del file shazam o di ogni file nella directory shazam. Per ogni file, lo stato è uno fra: Up-to-date Il file à aggiornato e non è stato modificato. Needs Patch Il file non è stato modificato, ma c'è una nuova versione nel repository. Locally Modified Il file è aggiornato, ma è stato modificato. Needs Merge Il file è stato modificato, e c'è una nuova versione nel repository. File had conflicts on merge Ci sono stati conflitti l'ultima volta che il file è stato aggiornato, e non sono ancora stati risolti. Vedrai anche la versione e la data locale, il numero dell'ultima versione appropriata (ultima appropriata perché se hai una data, un tag o un ramo fissati, può non essere l'ultima versione), e i tag, le date o le opzioni applicate. Dopo avere estratto qualcosa, puoi aggiornarlo con il comando update. &prompt.user; cvs update shazam Questo aggiorna il file shazam o il contenuto della directory shazam all'ultima versione sul ramo che hai estratto. Se hai estratto un preciso instante di tempo, non fa nulla a meno che i tag non siano stati spostati nel repository o qualche altra strana cosa sia in corso. Opzioni utili, in aggiunta a quelle elencate sopra, con checkout: Estrae ogni directory aggiuntiva mancante. Scarica l'ultima versione del ramo principale. Altre magie (guarda sotto). Se hai estratto un modulo con o , l'esecuzione di cvs update con un argomento differente di o o con selezionerà un nuovo ramo, una nuova versione o una nuova data. L'opzione elimina tutti i tag, le date o le versioni fissate mentre e ne impostano di nuove. Teoricamente, specificando HEAD come argomento di avrai lo stesso risultato di , ma è solo in teoria. L'opzione è utile se: qualcuno ha aggiunto delle sottodirectory al modulo che hai estratto dopo averlo estratto. hai estratto con , e dopo cambi idea e vuoi estrarre anche le sottodirectory. hai cancellato delle sottodirectory e vuoi estrarle nuovamente. Osserva l'output di cvs update con cura. La lettera all'inizio di ogni file indica cosa è stato fatto su di esso: U Il file è stato aggiornato senza problemi. P Il file è stato aggiornato senza problemi (vedrai questo solo quando lavorerai su un repository remoto). M Il file è stato modificato, ed è stato fuso senza conflitti. C Il file è stato modificato, ed è stato fuso con dei conflitti. La fusione è ciò che avviene quando estrai una copia di qualche codice sorgente, lo modifichi, quindi qualcun altro effettua il commit di un'altra modifica, e tu esegui cvs update. CVS nota che tu hai fatto dei cambiamenti locali, e cerca di fondere le tue modifiche con quelle fatte tra la versione che hai originariamente estratto e quella che stai aggiornando. Se i cambiamenti sono a due parti separate del file, solitamente non ci saranno problemi (sebbene il risultato possa non essere sintatticamente o semanticamente corretto). CVS stamperà una M davanti ad ogni file modificato localmente anche se non c'è una nuova versione nel repository, quindi cvs update è adatto per avere un resoconto di quello che hai cambiato in locale. Se appare una C, allora le tue modifiche sono in conflitto con i cambiamenti presenti nel repository (le modifiche sono sulle stesse righe, o righe vicine, o hai cambiato così tanto il file locale che cvs non è in grado di applicare le modifiche al repository). Dovrai allora andare a modificare il file a mano e risolvere i conflitti; questi saranno evidenziati da righe di simboli <, = e >. Per ogni conflitto, ci sarà una linea di demarcazione formata da sette < e il nome del file, seguita da una porzione di quello che il tuo file locale conteneva, seguita da una riga di separazione con sette =, seguita dalla porzione corrispondente presente nella versione del repository, seguita da una riga di separazione con sette > e il numero di versione che stai aggiornando. L'opzione è un po' voodoo. Aggiorna il file locale alla versione specificata come se avessi usato , ma non cambia il numero di versione o il ramo registrato del file locale. Non è realmente utile tranne quando usata due volte, nel qual caso fonderà le modifiche tra le due versioni specificate nella copia su cui stai lavorando. Per esempio, supponiamo che ti abbia effettuato il commit di una modifica a shazam/shazam.c in &os.current; e che più tardi tu voglia effettuare l'MFC. Le modifiche che vuoi fondere sono nella versione 1.15: Estrai la versione &os.stable; del modulo shazam: &prompt.user; cvs co -rRELENG_4 shazam Applica le modifiche tra la ver 1.14 e la 1.15: &prompt.user; cvs update -j1.14 -j1.15 shazam/shazam.c Quasi certamente avrai un conflitto a causa delle righe $Id$ (o nel caso di FreeBSD, $FreeBSD$), quindi dovrai modificare a mano il file per risolvere il conflitto (rimuovi le righe di separazione e la seconda linea $Id$, lasciando la linea $Id$ originale intatta). Guarda le differenze tra la versione locale e quella sul repository con il comando diff. &prompt.user; cvs diff shazam mostra ogni modifica che hai fatto al file o al modulo shazam. Opzioni utili con <command>cvs diff</command> Utilizza il formato diff unificato. Utilizza il formato diff contestuale. Visualizza i file mancanti o aggiunti.
Vorrai sempre utilizzare , visto che le diff unificate sono molto più semplici da leggere rispetto a quasi tutti gli altri formati (in alcune circostanze, le diff contestuali generate con l'opzione possono essere meglio, ma sono molto più voluminose). Una diff unificata consiste di una serie di parti. Ogni parte inizia con una riga con due caratteri @ e specifica dove si trovano le differenze nel file e su quante linee si estendono. Questa è seguita da un certo numero di righe; alcune (precedute da uno spazio) fanno parte del contesto; altre (precedute da un -) sono quelle eliminate e altre ancora (precedute da un +) sono quelle aggiunte. Puoi anche effettuare una diff con una versione differente rispetto a quella che hai estratto specificando la versione con o come per il checkout o l'update, o anche visualizzare le differenze tra due versioni arbitrarie (indipendentemente da quella che hai localmente) specificando due versioni con o . Guarda le righe di log con il comando log. &prompt.user; cvs log shazam Se shazam è un file, questo stamperà un'intestazione con le informazioni sul file, come la locazione nel repository dove il file è salvato, a quale versione è l'HEAD per questo file, in quali rami si trova il file, e qualsiasi tag valido per questo file. Quindi, per ogni versione del file, viene stampato un messaggio di log. Questo include la data e l'ora del commit, chi ha fatto il commit, quante righe sono state aggiunte e/o tolte, e alla fine il messaggio di log che il committer ha scritto quando ha inviato la modifica. Se shazam è una directory, allora le informazioni di log descritte sopra vengono stampate a turno per ogni file presente nella directory. A meno che tu abbia dato l'opzione a log, vengono stampati anche i log per tutte le sottodirectory di shazam, in maniera ricorsiva. Usa il comando log per vedere la storia di uno o più file, come è salvata nel repository CVS. Puoi anche usarlo per vedere il messaggio di log di una versione specifica, se aggiungi al comando log: &prompt.user; cvs log -r1.2 shazam Questo stamperà solamente il messaggio di log per la versione 1.2 del file shazam se è un file, oppure i messaggi di log per le versioni 1.2 di ogni file sotto shazam se è una directory. Guarda chi ha fatto cosa con il comando annotate. Questo comando visualizza ogni riga del file o dei file specificati, insieme all'utente che ha modificato più recentemente quella riga. &prompt.user; cvs annotate shazam Aggiungi nuovi file con il comando add. Crea il file, usa cvs add su di esso, quindi cvs commit. In modo analogo, puoi aggiungere nuove directory creandole e poi utilizzando cvs add su di esse. Nota che non c'è bisogno di usare il commit sulle directory. Rimuovi i file obsoleti con il comando remove. Rimuovi il file, quindi usa cvs rm su di esso, ed infine cvs commit. Effettua il commit con il comando commit o checkin. Opzioni utili con <command>cvs commit</command> Forza il commit di un file non modificato. Specifica un messaggio di commit sulla riga di comando anziché invocare un editor.
Usa l'opzione se ti accorgi che hai lasciato fuori informazioni importanti dal messaggio di commit. Buoni messaggi di commit sono importanti. Dicono agli altri perché hai fatto le modifiche che hai fatto, non solo qui ed ora, ma per mesi o anni quando qualcuno si chiederà perché dei pezzi di codice all'apparenza illogici o inefficienti sono entrati nel file sorgente. È inoltre un aiuto inestimabile per decidere su quali modifiche va effettuato l'MFC e su quali no. I messaggi di commit devono essere chiari, concisi, e fornire un ragionevole sommario per dare un'indicazione di cosa è stato cambiato e perché. I messaggi di commit devono fornire abbastanza informazioni affinché una terza parte possa decidere se la modifica è rilevante per lei e se debba leggere la modifica stessa. Evita di effettuare il commit di più modifiche scollegate in una volta sola. Questo rende difficile la fusione, e inoltre rende più complicato determinare quale modifica è colpevole se salta fuori un bug. Evita di effettuare il commit di correzioni di stile o di spaziatura insieme a correzioni di funzionalità. Questo rende difficile la fusione, e inoltre rende più complicato capire quali modifiche alle funzionalità sono state fatte. Nel caso di file di documentazione, può rendere il lavoro dei gruppi di traduzione più complicato, visto che diventa difficile per loro determinare esattamente quali modifiche al contenuto vanno tradotte. Evita di effettuare il commit di cambiamenti a più file con un unico messaggio generico o vago. Invece, effettua il commit di un file alla volta (o di piccoli gruppi di file correlati) con un messaggio di commit appropriato. Prima di effettuare il commit, devi sempre: verificare su che ramo stai effettuando il commit, tramite cvs status. revisionare i tuoi cambiamenti, con cvs diff Inoltre, devi SEMPRE specificare esplicitamente sulla riga di comando su quali file deve essere effettuato il commit, in modo da non toccare incidentalmente altri file non voluti - cvs commit senza argomenti effettuerà il commit di ogni modifica nella directory corrente ed ogni sottodirectory. Suggerimenti e trucchi aggiuntivi: Puoi inserire le opzioni più comunemente usate nel tuo ~/.cvsrc, come in questo caso: cvs -z3 diff -Nu update -Pd checkout -P Questo esempio dice: usa sempre il livello di compressione 3 quando si parla con un server remoto. Questo è un salvavita quando si lavora su una connessione lenta. usa sempre le opzioni (visualizza i file aggiunti o rimossi) e (formato diff unificato) con &man.diff.1;. usa sempre le opzioni (elimina le directory vuote) e (estrai le nuove directory) quando si effettua l'update. usa sempre l'opzione (elimina le directory vuote) quando si estrae. Usa lo script cdiff di Eivind Eklund per visualizzare le diff unificate. È un wrapper per &man.less.1; che aggiunge i codici colore ANSI per far risaltare le intestazioni delle sezioni, le righe rimosse e quelle aggiunte; il contesto rimane invariato. Inoltre espande i tab correttamente (i tab spesso appaiono errati nelle diff a causa del carattere aggiuntivo all'inizio di ogni riga). http://people.FreeBSD.org/~eivind/cdiff Semplicemente usalo al posto di &man.more.1; o &man.less.1;: &prompt.user; cvs diff -Nu shazam | cdiff Alternativamente alcuni editor come &man.vim.1; (editors/vim5) hanno il supporto al colore e quando vengono usati con l'evidenziazione della sintassi attiva evidenzieranno molti tipi di file, incluse le diff, le patch, e i log CVS/RCS. &prompt.user; echo "syn on" >> ~/.vimrc &prompt.user; cvs diff -Nu shazam | vim - &prompt.user; cvs log shazam | vim - CVS è vecchio, arcano, complesso e buggato, e a volte esibisce comportamenti non deterministici che qualcuno sostiene siano la prova che CVS non sia niente di più di una manifestazione Newtoniana di una entità ultradimensionale sensibile. Non è umanamente possibile conoscere ogni dettaglio di CVS, quindi non essere dispiaciuto di chiedere aiuto all'Intelligenza Artificiale (&a.cvs;). Non lasciare il comando cvs commit nella modalità di inserimento del messaggio di commit per troppo tempo (più di 2–3 minuti). Questo blocca la directory in cui stai lavorando ed impedirà ad altri sviluppatori di effettuare commit nella stessa directory. Se devi digitare un messaggio di commit lungo, scrivilo prima di eseguire cvs commit, e inseriscilo successivamente. Convenzioni e Tradizioni Come nuovo committer ci sono alcune cose che dovresti fare all'inizio. Aggiungere te stesso alla sezione Developers della Contributors List e rimuovere te stesso dalla sezione Additional Contributors. Una volta fatto ciò, non dimenticarti di aggiungere la tua entity di autore in doc/en_US.ISO8859-1/share/sgml/authors.ent; usa le altre voci come esempio. Questo è un compito relativamente semplice, ma rimane una buona prima prova delle tue abilità con CVS. Aggiungi una voce per te stesso in www/en/news/news.xml. Guarda le altre voci che assomigliano a A new committer e segui il formato. Se hai una chiave PGP o GnuPG, potresti volerla aggiungere in doc/en_US.ISO8859-1/books/handbook/pgpkeys. &a.des; ha scritto uno script di shell per rendere questa operazione molto semplice. Guarda il file README per maggiori informazioni. Alcune persone aggiungono una voce per se stessi in ports/astro/xearth/files/freebsd.committers.markers. Alcune persone aggiungono una voce per se stessi in src/usr.bin/calendar/calendars/calendar.freebsd. Presentati agli altri committer, altrimenti nessuno avrà idea di chi tu sia o di cosa ti occupi. Non devi scrivere una biografia completa, basta un paragrafo o due su chi sei e su quello di cui hai intenzione di occuparti come committer di FreeBSD. Invialo alla &a.developers; e sarai sulla strada giusta! Loggati su hub.FreeBSD.org e crea un file /var/forward/utente (dove utente è il tuo nome utente) contenente l'indirizzo e-mail dove vuoi che i messaggi indirizzati a tuonomeutente@FreeBSD.org siano inoltrati. Questo include tutti i messaggi di commit così come ogni altro messaggio inviato alla &a.committers; e alla &a.developers;. Caselle di posta veramente grandi che hanno preso residenza fissa su hub spesso vengono accidentalmente troncate senza preavviso, quindi inoltra o leggi i messaggi in modo da non perderli. Se sei iscritto alla &a.cvsall;, probabilmente vorrai disiscriverti per evitare di ricevere copie doppie dei messaggi di commit e della loro evoluzione. Tutti i nuovi committer hanno un mentore assegnato a loro per i primi mesi. Il tuo mentore è più o meno responsabile di spiegarti ogni cosa ti sia poco chiara ed è anche responsabile delle tue azioni durante questo periodo iniziale. Se fai un commit errato, imbarazzerai il tuo mentore e probabilmente dovresti passare almeno i primi commit a lui prima di agire direttamente sul repository. Tutti i commit dovrebbero andare su &os.current; prima di essere fusi in &os.stable;. Nessuna nuova caratteristica importante o modifica ad alto rischio dovrebbe essere fatta sul ramo &os.stable;. Relazioni tra Sviluppatori Se stai lavorando direttamente sul tuo codice o su codice che è già stabilito essere di tua responsabilità, allora c'è probabilmente poca necessità di confrontarsi con altri committer prima di effettuare un commit. Se vedi un bug in un'area del sistema che è chiaramente orfana (e ce n'è qualcuna di queste aree, per nostra vergogna), agisci allo stesso modo. Se, tuttavia, stai per modificare qualcosa che è chiaramente mantenuto attivamente da qualcun'altro (ed è solo guardando la mailing list cvs-committers che puoi veramente sapere cosa è e cosa non è) allora invia le modifiche a lui, come avresti fatto prima di diventare committer. Per i port, dovresti contattare il MAINTAINER specificato nel Makefile. Per altre parti del repository, se non sei sicuro di chi possa essere il maintainer attivo, potrebbe essere utile scorrere l'output di cvs log per vedere chi ha effettuato delle modifiche in passato. &a.fenner; ha scritto un utile script di shell che può aiutare a determinare chi sia il maintainer attivo. Questo elenca ogni persona che ha effettuato commit su un file specifico con il numero di commit che ha fatto. Può essere trovato su freefall in ~fenner/bin/whodid. Se alle tue richieste non corrisponde una risposta o se il committer in altro modo dimostra uno scarso interesse nell'area oggetto della modifica, vai avanti ed effettua il commit tu stesso. Se non sei sicuro di un commit per qualunque motivo, fallo revisionare da -hackers prima di effettuare il commit. Meglio che sia criticato lì piuttosto che quando è parte del repository CVS. Se ti capita di effettuare un commit che provoca controversie, potresti voler considerare l'annullamento delle modifiche finché il problema sia chiarito. Ricorda – con CVS possiamo sempre tornare indietro. Non mettere in dubbio le intenzioni di qualcuno che non è d'accordo con te. Se vedono una soluzione differente dalla tua per un problema, o anche un problema diverso, non è perché sono stupidi, perché hanno una dubbia origine, o perché stanno cercando di distruggere il tuo duro lavoro, la tua immagine personale, o FreeBSD, ma semplicemente perché hanno una visione differente del mondo. La diversità è una buona cosa. Dissenti onestamente. Argomenta la tua posizione con i suoi meriti, sii onesto sui difetti che può avere, e sii disponibile a guardare le loro soluzioni, o anche le loro visioni del problema, con mente aperta. Accetta le correzioni. Possiamo tutti sbagliare. Se hai fatto un errore, scusati e vai avanti con la tua vita. Non picchiarti, e sicuramente non picchiare gli altri per il tuo sbaglio. Non sprecare tempo imbarazzandoti o recriminando, risolvi solo il problema e vai avanti. Chiedi aiuto. Cerca (e dai) revisioni dagli altri. Uno delle cose in cui dovrebbe eccellere il software open source è il numero di occhi che lo scrutano; questo non è vero se nessuno revisionerà il codice. GNATS Il FreeBSD Project utilizza GNATS per gestire i bug e le richieste di cambiamenti. Assicurati di usare edit-pr numero-pr su freefall quando effettui il commit di una correzione o di un suggerimento trovato in un PR GNATS per chiuderlo. È inoltre considerato gentile se trovi il tempo di chiudere ogni PR associato al tuo commit, se esistono. Puoi anche usare &man.send-pr.1; tu stesso per proporre qualsiasi cambiamento che pensi debba essere fatto, a seguito di una maggiore revisione da parte di altre persone. Puoi trovare di più su GNATS su: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html http://www.FreeBSD.org/support.html &man.send-pr.1; Puoi far girare una copia locale di GNATS, e poi integrare l'albero GNATS di FreeBSD in esso tramite CVSup. In seguito puoi usare i comandi GNATS localmente, o usare altre interfacce, come tkgnats. Questo ti permette di interrogare il database dei PR senza bisogno di essere connesso a Internet. Utilizzo di un albero GNATS locale Se non stai già scaricando l'albero GNATS, aggiungi questa riga al tuo supfile, e riesegui &man.cvsup.1;. Nota che siccome GNATS non è sotto il controllo di CVS non ha tag, quindi se lo stai aggiungendo al tuo supfile esistente deve apparire prima di ogni voce tag= dato che queste rimangono attive una volta impostate. gnats release=current prefix=/usr Questo metterà l'albero GNATS di FreeBSD in /usr/gnats. Puoi usare un file refuse per controllare quali categorie ricevere. Per esempio, per ricevere solo i PR docs, metti questa riga in /usr/local/etc/cvsup/sup/refuse Il percorso preciso dipende dall'impostazione *default base nel tuo supfile. . gnats/[a-ce-z]* Il resto di questi esempi assume che tu abbia scaricato solo la categoria docs. Modificali quando è necessario, a seconda delle categorie che tieni in sincronia. Installa il port GNATS da ports/databases/gnats. Questo metterà le varie directory GNATS sotto $PREFIX/share/gnats. Crea un symlink per le directory GNATS che aggiorni tramite CVSup sotto la versione di GNATS che hai installato. &prompt.root; cd /usr/local/share/gnats/gnats-db &prompt.root; ln -s /usr/gnats/docs Ripeti tante volte quanto necessario, a seconda di quante categorie GNATS tieni in sincronia. Aggiorna il file categories di GNATS con queste categorie. Il file è $PREFIX/share/gnats/gnats-db/gnats-adm/categories. # Questa categoria è obbligatoria pending:Categoria per i PR errati:gnats-admin: # # Categorie di FreeBSD # docs:Bug di Documentazione:freebsd-doc: Esegui $PREFIX/libexec/gnats/gen-index per ricreare l'indice GNATS. L'output deve essere reindirizzato su $PREFIX/share/gnats/gnats-db/gnats-adm/index. Puoi fare questo periodicamente da &man.cron.8;, o eseguire &man.cvsup.1; da uno script di shell che fa anche questo. &prompt.root; /usr/local/libexec/gnats/gen-index \ > /usr/local/share/gnats/gnats-db/gnats-adm/index Verifica la configurazione interrogando il database dei PR. Questo comando visualizza i PR docs aperti. &prompt.root; query-pr -c docs -s open Anche altre interfacce, come quella fornita dal port databases/tkgnats, dovrebbero funzionare correttamente. Prendi un PR e chiudilo. Questa procedura funziona solo per permetterti di visualizzare ed interrogare i PR localmente. Per modificarli o chiuderli dovrai ancora loggarti su freefall e farlo da lì. Chi è Chi Oltre ai meister del repository, ci sono altri membri e team del FreeBSD Project che probabilmente arriverai a conoscere nel tuo ruolo di committer. Brevemente, e senza pretesa di elencarli tutti, questi sono: &a.jhb; John è il manager dell'SMPng Project, e ha autorità sulla progettazione architetturale e sull'implementazione del passaggio a un sistema di threading e locking del kernel a grana fine. È anche l'autore dell'SMPng Architecture Document. Se stai lavorando sullo stesso sistema, coordinati con John. Puoi imparare di più sull'SMPng Project dalla sua home page: http://www.FreeBSD.org/smp/ &a.jake;, &a.tmm; Jake e Thomas sono i maintainer del port sull'architettura sparc64. - &a.nik; + &a.doceng; - Nik supervisiona il Documentation Project. - Oltre a scrivere documentazione mette insieme l'infrastruttura - sotto doc/share/mk e i fogli di stile e il - codice relativo sotto doc/share/sgml. Se hai - domande su questi sei incoraggiato a inviarle attraverso la &a.doc;. - I committer interessati a contribuire alla documentazione - dovrebbero familiarizzare con il doceng è il gruppo responsabile dell'infrastruttura + per la realizzazione della documentazione, approva i nuovi committer + della documentazione, e assicura che il sito web di FreeBSD e la + documentazione sul sito FTP siano aggiornati rispetto all'albero + CVS. Non è un organo di risoluzione dei conflitti. + La maggior parte delle discussioni relative alla documentazione + prendono posto sulla &a.doc;. I committer interessati a contribuire + alla documentazione dovrebbero familiarizzare con il Documentation Project Primer. &a.ru; Ruslan è Mister &man.mdoc.7;. Se stai scrivendo una pagina man e hai bisogno di qualche suggerimento sulla struttura, o sul linguaggio di markup, chiedi a Ruslan. &a.bde; Bruce è lo Style Police-Meister. Quando fai un commit che poteva essere fatto meglio, Bruce sarà lì a dirtelo. Ringrazia che qualcuno lo sia. Bruce conosce anche molto bene gli standard applicabili a FreeBSD. &a.gallatin; &a.mjacob; &a.dfr; &a.obrien; Questi sono gli sviluppatori e i supervisori primari della piattaforma DEC Alpha AXP. &a.dg; David è il supervisore del sistema VM. Se hai in mente una modifica al sistema VM, coordinala con David. &a.dfr; &a.marcel; &a.peter; &a.ps; Questi sono i principali sviluppatori e supervisori della piattaforma Intel IA-64, ufficialmente conosciuta come l'Itanium Processor Family (IPF). &a.murray; &a.steve; &a.rwatson; &a.jhb; &a.bmah; &a.scottl; Questi sono i membri del &a.re;. Questo team è responsabile di decidere i tempi delle release e controllare il processo di release. Durante i periodi di congelamento del codice, gli ingegneri di release hanno l'autorità finale su tutte le modifiche al sistema per quel ramo di cui si sta preparando la release. Se c'è qualcosa che vuoi sia fuso da &os.current; a &os.stable; (qualsiasi valore queste possano avere in un dato momento), queste sono le persone con cui devi parlare. Bruce è anche l'autore della documentazione di release (src/release/doc/*). Se effettui il commit di una modifica che pensi sia degna di menzione nelle note di release, assicurati che Bruce lo sappia. Meglio ancora, inviagli una patch con il tuo commento. &a.benno; Benno è il maintainer ufficiale del port per PowerPC. &a.brian; Maintainer ufficiale di /usr/sbin/ppp. &a.nectar; Jacques è il FreeBSD Security Officer e supervisiona il &a.security-officer;. &a.wollman; Se hai bisogno di consigli sulle oscure parti interne delle reti o non sei sicuro di qualche eventuale modifica al sottosistema di rete che hai in mente, Garrett è qualcuno con cui parlare. Garret è inoltre molto esperto sui vari standard applicabili a FreeBSD. &a.committers; cvs-committers è l'entità che CVS usa per inviarti tutti i messaggi di commit. Non devi mai inviare email direttamente a questa lista. Puoi solamente rispondere a questa lista quando i messaggi sono brevi e direttamente correlati a un commit. &a.developers; Tutti i committer sono iscritti a -developers. Questa lista è stata creata per essere un forum sulle questioni della comunità dei committer. Esempi sono le votazioni per il Core, annunci, ecc. Questa lista non è intesa come posto per la revisione del codice o come rimpiazzo della &a.arch; o della &a.audit;. Infatti usarla in questo modo urta il FreeBSD Project dato che dà l'impressione di una lista privata dove vengono prese le decisioni generali che influenzano tutta la comunità che usa FreeBSD senza essere rese pubbliche. Ultimo, ma non per importanza mai e poi mai invia un messaggio alla &a.developers; mettendo in CC:/BCC: un'altra lista FreeBSD. Mai e poi mai invia un messaggio su un'altra mailing list mettendo in CC:/BCC: la &a.developers;. Fare questo può diminuire enormemente i benefici di questa lista. Inoltre, non pubblicare o inoltrare mai email inviate alla &a.developers;. L'atto di inviare un messaggio alla &a.developers; anziché a una lista pubblica significa che le informazioni contenute non sono ad uso pubblico. Guida Rapida a SSH Se stai usando FreeBSD 4.0 o successivo, OpenSSH è incluso nel sistema base. Se stai usando una release precedente, aggiorna ed installa uno dei port di SSH. In generale, probabilmente vorrai prendere OpenSSH dal port security/openssh. Potresti anche voler estrarre l'ssh1 originale dal port security/ssh, ma sii certo di porre la dovuta attenzione alla sua licenza. Nota che questi port non possono essere installati contemporaneamente. Se non vuoi digitare la tua password ogni volta che usi &man.ssh.1;, e usi chiavi RSA o DSA per autenticarti, &man.ssh-agent.1; è lì per la tua comodità. Se vuoi usare &man.ssh-agent.1;, assicurati di eseguirlo prima di utilizzare altre applicazioni. Gli utenti X, per esempio, solitamente fanno questo dal loro file .xsession o .xinitrc. Guarda &man.ssh-agent.1; per i dettagli. Genera un paio di chiavi con &man.ssh-keygen.1;. Le chiavi finiranno nella tua directory $HOME/.ssh. Invia la tua chiave pubblica ($HOME/.ssh/identity.pub) alla persona che ti sta configurando come committer in modo che possa inserirla nel file authorized_keys nella tua home directory su freefall (ad esempio, $HOME/.ssh/authorized_keys). Ora dovresti essere in grado di usare &man.ssh-add.1; per autenticarti una volta a sessione. Ti verrà richiesta la pass phrase della tua chiave privata, e quindi verrà salvata nel tuo agente di autenticazione (&man.ssh-agent.1;). Se non vuoi più avere la tua chiave salvata nell'agente, l'esecuzione di ssh-add -d la rimuoverà. Verifica facendo qualcosa come ssh freefall.FreeBSD.org ls /usr. Per maggiori informazioni, guarda security/openssh, &man.ssh.1;, &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1;, e &man.scp.1;. Il Lungo Elenco di Regole dei Committer di FreeBSD Traduzione in corso Supporto per Diverse Architetture Traduzione in corso FAQ Specifiche sui Port Traduzione in corso Benefici del Lavoro Traduzione in corso Domande Generali Traduzione in corso
diff --git a/it_IT.ISO8859-15/articles/multi-os/article.sgml b/it_IT.ISO8859-15/articles/multi-os/article.sgml index eeb91c490c..c4f809ee02 100644 --- a/it_IT.ISO8859-15/articles/multi-os/article.sgml +++ b/it_IT.ISO8859-15/articles/multi-os/article.sgml @@ -1,764 +1,769 @@ %authors; %translators; ]>
Installazione e Utilizzo di FreeBSD con altri Sistemi Operativi Jay Richmond
jayrich@sysc.com
 6 Agosto 1996 Questo documento spiega come far coesistere felicemente FreeBSD con altri sistemi operativi come Linux, MS-DOS, OS/2, e Windows 95. Un ringraziamento speciale va a: Annelise Anderson andrsn@stanford.edu, Randall Hopper rhh@ct.picker.com, e &a.jkh;. Traduzione a cura di &a.it.max;. Introduzione Molta gente non può far convivere questi sistemi operativi senza avere a disposizione un hard disk di grosse dimensioni, perciò sono state incluse informazioni speciali sui drive EIDE di grosse dimensioni. Poiché ci sono così tante combinazioni di possibili sistemi operativi e configurazioni di hard disk, la potrebbe esserti di aiuto più di altre. Contiene descrizioni di specifiche configurazioni che usano molteplici sistemi operativi. Questo documento assume che tu abbia già fatto posto sul tuo hard disk per un altro sistema operativo. Ogni volta che ripartizioni il tuo hard disk, corri il rischio di distruggere e quindi perdere i dati sulle partizioni originali. In ogni caso, se il tuo hard disk è completamente occupato dal DOS, potresti usare FIPS (incluso nel CDROM di FreeBSD nella directory \TOOLS oppure via ftp). Ti permette di ripartizionare il tuo hard disk senza distruggere i dati già contenuti. C'è anche un programma commerciale chiamato Partition Magic, che ti permette di ridimensionare e cancellare partizioni senza conseguenze. Panoramica sui Boot Manager Si tratta solo di brevi descrizioni dei diversi boot manager che potresti trovare. A seconda del tuo computer, potresti trovare utile usarne più di uno sullo stesso sistema. Boot Easy Questo è il boot manager standard fornito con FreeBSD. Ha la possibilità di far partire qualsiasi cosa, incluso BSD, OS/2 (HPFS), Windows 95 (FAT e FAT32), e Linux. Le partizioni vengono scelte con i tasti funzione (F1-F12). Boot Manager di OS/2 Questo fa partire FAT, FAT32, HPFS, FFS (FreeBSD), ed EXT2 (Linux). Le partizioni vengono scelte usando i tasti freccia. L'OS/2 Boot Manager è l'unico ad usare una propria partizione separata, diversamente dagli altri, che usano il master boot record (MBR). Di conseguenza, deve essere installato prima del 1024esimo cilindro per evitare problemi di avvio. Può far partire Linux usando LILO quando questo è parte del settore di avvio, non dell'MBR. Leggi gli HOWTO di Linux sul World Wide Web per avere più informazioni su come far partire Linux con il boot manager di OS/2. OS-BS Questa è un'alternativa a Boot Easy. Ti dà più controllo sul processo di avvio, con la possibilità di impostare la partizione di default da cui partire e il timeout di avvio. La versione beta di questo programma ti permette di avviare scegliendo il sistema operativo con i tasti freccia. È incluso nel cd di FreeBSD nella directory \TOOLS oppure via ftp. LILO, o LInux LOader Questo è un boot manager limitato. Farà partire FreeBSD, sebbene siano necessari alcuni accorgimenti e sistemazioni nel file di configurazione. A proposito di FAT32 FAT32 è il rimpiazzo al file system FAT incluso nella Release Beta SR2 di Microsoft, che dovrebbe essere installata con Windows 95 a partire dalla fine del 1996. Converte il normale file system FAT e ti permette di usare cluster di dimensioni più piccole per hard disk di dimensioni maggiori. Inoltre FAT32 modifica il settore di avvio tradizionale e la tabella di allocazione, rendendola incompatibile con alcuni Boot Manager. Una Installazione Tipica Diciamo che ho due grandi hard disk EIDE e voglio installarci FreeBSD, Linux, e Windows 95. Ecco come potrei fare usando questi due hard disk: /dev/wd0 (Primo hard disk) /dev/wd1 (Secondo hard disk) Tutti e due hanno 1416 cilindri. Parto dalla partizione MS-DOS o dal dischetto di avvio di Windows 95 che contiene l'utility FDISK.EXE e creo una piccola partizione primaria da 50 MB (35-40 per Windows 95, più un po' di spazio per respirare) sul primo disco. Creo anche una partizione più grande sul secondo hard disk per le applicazioni di Windows e per i dati. Faccio ripartire ed installo Windows 95 (più facile a dirsi che a farsi) sulla partizione C:. La prossima cosa che farò sarà installare Linux. Non sono sicuro per le altre distribuzioni, ma la Slackware include LILO (guarda la ). Quando ripartiziono il mio hard disk con l'fdisk di Linux, metterò tutto ciò che riguarda Linux sul primo hard disk (probabilmente 300 MB per una partizione di root decente e un po' di spazio di swap). Dopo aver installato Linux, quando viene chiesto di installare LILO, assicurati di installarlo sul settore di avvio della partizione di Linux, non nell'MBR (Master Boot Record). La parte rimanente di hard disk va a FreeBSD. Assicurati anche che la slice root di FreeBSD non vada oltre il 1024esimo cilindro. (Il 1024esimo cilindro è circa intorno ai 528 MB in un disco ipotetico, il mio, di 720 MB). Userò il resto dell'hard disk (circa 270 MB) per /usr e /. Il resto del secondo hard disk (la grandezza varia a seconda di quanto spazio ho lasciato agli applicativi e ai dati per Windows quando ho creato la partizione nel primo passo) può essere usata per /usr/src e per lo spazio di swap. Se visualizzato con l'utility fdisk di Windows 95, l'hard disk dovrebbe risultare in questo modo: --------------------------------------------------------------------- Display Partition Information Current fixed disk drive: 1 Partition Status Type Volume_Label Mbytes System Usage C: 1 A PRI DOS 50 FAT** 7% 2 A Non-DOS (Linux) 300 43% Total disk space is 696 Mbytes (1 Mbyte = 1048576 bytes) Press Esc to continue --------------------------------------------------------------------- Display Partition Information Current fixed disk drive: 2 Partition Status Type Volume_Label Mbytes System Usage D: 1 A PRI DOS 420 FAT** 60% Total disk space is 696 Mbytes (1 Mbyte = 1048576 bytes) Press Esc to continue --------------------------------------------------------------------- ** Potrebbe essere FAT16 o FAT32 se stai usando l'aggiornamento OEM SR2. Guarda la . Installazione di FreeBSD. Assicurati di avviare il computer con il primo hard disk configurato con NORMAL nel BIOS. Se non è così, dovrai settare la vera geometria del disco all'avvio (per arrivare a fare ciò, fai partire Windows 95 e consulta Microsoft Diagnostics (MSD.EXE), o controlla il BIOS) con il parametro hd0=1416,16,63 dove 1416 è il numero di cilindri sull'hard disk, 16 è il numero di testine per traccia, o heads per track, e 63 è il numero di settori per traccia sul drive. Quando partiziono l'hard disk, cerco sempre di mettere Boot Easy sul primo hard disk. Non mi preoccupo del secondo hard disk, non parte nulla da quello. Al riavvio, Boot Easy dovrebbe riconoscere le tre partizioni avviabili, cioè quella DOS (ovvero Windows 95), Linux, e BSD (FreeBSD). Considerazioni Speciali Molti sistemi operativi sono molto pignoli su come e dove devono essere messi sull'hard disk. Windows 95 deve essere sulla prima partizione primaria sul primo hard disk. OS/2 fa eccezione. Può essere installato in una partizione primaria o estesa sul primo o sul secondo hard disk. Se non sei sicuro, mantieni la parte avviabile di partizione sotto il 1024esimo cilindro. Se installi Windows 95 su un sistema BSD esistente, questo distruggerà l'MBR, e dovrai reinstallare il boot manager precedente. Boot Easy può essere reinstallato usando l'utility BOOTINST.EXE inclusa nella directory \TOOLS sul cdrom, oppure via ftp. Puoi anche ricominciare l'installazione e andare all'editor delle partizioni. Da lì, marcare la partizione di FreeBSD come avviabile, scegliere Boot Manager, e quindi digitare W per scrivere le informazioni nell'MBR. Puoi ora riavviare, e Boot Easy dovrebbe riconoscere Windows 95 e DOS. Ricordati che OS/2 può leggere partizioni FAT e HPFS, ma non FFS (FreeBSD) o EXT2 (Linux). Diversamente Windows 95 può leggere e scrivere solo su FAT o FAT32 (guarda la ). FreeBSD può leggere gran parte degli altri file system, ma al momento non può leggere partizioni HPFS. Linux può leggere partizioni HPFS, ma non può scrivervi. Versioni recenti del kernel di Linux (2.x) possono leggere e scrivere su partizioni di Windows 95 di tipo VFAT (VFAT è ciò che permette a Windows 95 di avere i nomi di file lunghi - è molto simile alla FAT). Linux può leggere e scrivere sulla maggior parte dei file system. Capito? Lo spero... Esempi (La sezione ha bisogno di lavoro, per favore spedisci il tuo esempio a jayrich@sysc.com). FreeBSD+Win95: Se hai installato FreeBSD dopo Windows 95, dovresti vedere DOS nel menu di Boot Easy. Questo è Windows 95. Se hai installato Windows 95 dopo FreeBSD, leggi la sopra. Fin quando il tuo hard disk non ha più di 1024 cilindri, non dovrebbero esserci problemi. Se una partizione va oltre il 1024esimo cilindro, e hai messaggi di errore come invalid system disk sotto DOS (Windows 95) e FreeBSD non parte, prova a cercare una opzione nel BIOS chiamata > 1024 cylinder support o NORMAL/LBA mode. DOS potrebbe necessitare dell'LBA (Logical Block Addressing - Indirizzamento Logico dei Blocchi) per partire correttamente. Se l'idea di cambiare delle impostazioni nel BIOS ogni volta che si accende il computer non ti piace, puoi far partire FreeBSD da DOS con l'utility FBSDBOOT.EXE che trovi sul CD (dovrebbe trovare la tua partizione FreeBSD e farla partire). FreeBSD+OS/2+Win95: Nulla di nuovo qui. Il boot manager di OS/2 può far partire tutti questi sistemi operativi, cosicché non dovrebbero esserci problemi. FreeBSD+Linux: Puoi usare Boot Easy per far partire tutti e due i sistemi operativi. FreeBSD+Linux+Win95: (guarda la ) Altre Fonti di Aiuto Ci sono molti HOW-TO su Linux che trattano come affrontare il problema di avere più sistemi operativi sullo stesso hard disk. Il Linux+DOS+Win95+OS2 mini-HOWTO offre aiuto su come configurare il boot manager di OS/2 e il Linux+FreeBSD mini-HOWTO potrebbe essere anch'esso interessante. Anche il Linux-HOWTO è di grande aiuto. + L'NT + Loader Hacking Guide fornisce buone informazioni sul + multibooting di Windows NT, '95, e DOS con altri sistemi operativi. + E il pacchetto di Hale Landis, How It Works contiene alcune utili informazioni su tutti i tipi di geometrie dei drive e su argomenti legati al processo di avvio. Puoi trovarlo su ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works/allhiw.zip. + url="ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works/allhiw.zip">. Inoltre non perderti la documentazione del kernel di FreeBSD sul processo di avvio, disponibile nella distribuzione dei sorgenti del kernel (si scompatta in file:/usr/src/sys/i386/boot/biosboot/README.386BSD. Dettagli Tecnici (Contributo di Randall Hopper, rhh@ct.picker.com) Questa sezione prova a fornire abbastanza informazioni di base sugli hard disk e sul processo di avvio così da essere poi capaci di determinare le cause dei problemi più frequenti che potreste affrontare al momento dell'installazione e della configurazione di più sistemi operativi. Inizia con un linguaggio semplice, così potresti voler scorrere la pagina fino a quando non ti sembri difficile e cominciare quindi da quel punto a leggere. Introduzione agli Hard Disk Sono generalmente usati tre termini fondamentali per descrivere l'allocazione dei dati sull'hard disk: Cylinders (Cilindri), Heads (Testine), e Sectors (Settori). Non è particolarmente importante sapere esattamente cosa significano questi termini e quale sia il loro compito specifico, ma interessa sapere che, insieme, identificano dove si trovano fisicamente i dati sull'hard disk. Ogni hard disk ha un particolare numero di cilindri, di testine, e di settori per ogni parte di cilindro relativa a una singola testina (che generalmente viene chiamato track, o traccia). Questi dati contribuiscono a determinare la geometria fisica del disco dell'hard disk. Ci sono generalmente 512 byte per settore, e 63 settori per traccia, mentre il numero di cilindri e testine varia a seconda del tipo di hard disk. In questo modo puoi trovare la quantità di dati che il disco potrebbe contenere semplicemente calcolando: (numero di cilindri) × (numero di testine) × (63 settori/traccia) × (512 byte/settore) Per esempio, sul mio Western Digital AC31600 EIDE, questo è: (3148 cilindri) × (16 testine) × (63 settori/traccia) × (512 byte/settore) che sarebbe 1,624,670,208 byte, o circa 1.6 Giga. Puoi scoprire la geometria fisica del disco (cioè il numero di cilindri, testine, e il fattore settori/tracciati) del tuo hard disk usando ATAID o altri programmi reperibili su Internet. Probabilmente il tuo hard disk ti è stato venduto con queste informazioni. Comunque stai attento: se stai usando l'opzione LBA del BIOS (vedi la ), non puoi usare un qualsiasi programma per conoscere la geometria fisica. Questo perché molti programmi (ad esempio MSD.EXE o l'fdisk di FreeBSD) non identificano la geometria fisica del disco, fanno invece riferimento alla geometria traslata (Numeri virtuali usando LBA). Continua a leggere per saperne di più. Un altro aspetto interessante di questi termini. Dati 3 numeri—un numero di cilindri, un numero di testine, e un numero di settori per tracciato—si può identificare uno specifico settore assoluto (un blocco di 512 byte di dati) sull'hard disk. I cilindri e le testine sono numerati partendo da 0, e i settori sono numerati partendo da 1. Per quelli che sono interessati a dettagli più tecnici, informazioni sulla geometria dei dischi, settori di avvio, BIOS, e altro, possono trovare grandi quantità di informazioni in Internet. Basta fare una ricerca con Lycos, Yahoo e altri digitando boot sector o master boot record. Tra le numerose informazioni utili che si possono trovare c'è il pacchetto di documentazione How It Works (in italiano Come Funziona) di Hale Landis. Guarda la per alcuni puntatori a questo pacchetto. Ok, troppa terminologia finora. Adesso parliamo del processo di avvio. Il Processo di Avvio Sul primo settore del tuo disco (Cyl 0, Head 0, Sector 1) risiede il Master Boot Record (MBR). Questo contiene una mappa del tuo disco. Identifica fino a 4 partizioni, ciascuna delle quali è uno spazio, una parte, di quel disco. FreeBSD chiama queste partizioni slices per evitare confusione con le sue partizioni, di cui ora non parleremo. Ciascuna partizione può contenere un sistema operativo diverso. Ogni elemento che rappresenta una partizione presente nell'MBR ha un Partition ID, un valore Start Cylinder/Head/Sector, e un valore End Cylinder/Head/Sector. Il Partition ID mostra di che tipo di partizione si tratta (di che sistema operativo) e i valori di inizio/fine dicono dove questa si trova. La mostra una lista di partition ID più comuni. Partition ID ID (hex) Descrizione 01 DOS12 primaria (12-bit FAT) 04 DOS16 primaria (16-bit FAT) 05 DOS estesa 06 DOS primaria di grande dimensione (> 32MB) 0A OS/2 83 Linux (EXT2FS) A5 FreeBSD, NetBSD, 386BSD (UFS)
Nota che non tutte le partizioni sono avviabili (per esempio quelle DOS estese). Alcune lo sono, altre no. Ciò che rende una partizione avviabile è la configurazione del Partition Boot Sector che si trova all'inizio di ciascuna partizione. Quando configuri il tuo boot manager preferito, questo cerca gli elementi nella tavola delle partizioni sull'MBR di tutti i tuoi hard disk e fa in modo che tu possa dare un nome a tutte gli elementi della lista. Quindi all'avvio, il boot manager viene invocato da un codice particolare presente nell'MBR del primo hard disk che viene rilevato sul tuo sistema. Questo guarda la tavola delle partizioni dell'MBR corrispondente alla partizione che hai scelto, usa l'informazione sullo Start Cylinder/Head/Sector per quella partizione, carica il Partition Boot Sector per quella partizione, e sli dà il controllo. Quel settore di avvio per la partizione contiene abbastanza informazioni per cominciare a caricare il sistema operativo di quella partizione. Un particolare che abbiamo sorvolato e che è importante conoscere. Tutti gli hard disk hanno l'MBR. Ad ogni modo, quello importante è quello del disco che viene rilevato per primo dal BIOS. Se hai solo hard disk IDE, è il primo disco IDE (cioè il disco primario del controller primario). Stessa cosa per i sistemi SCSI. Se hai sia SCSI che IDE invece, i dischi IDE vengono riconosciuti per primi dal BIOS, quindi il primo disco IDE è quello che viene riconosciuto per primo. Il boot manager che installerai si troverà quindi sull'MBR del primo disco riconosciuto come descritto. Limitazioni sull'Avvio e Avvertimenti Ora un po' di cose interessanti alle quali devi stare attento. Il maledetto limite dei 1024 cilindri e l'aiuto dell'LBA del BIOS La prima parte del processo di avvio viene effettuata attraverso il BIOS, (se questo è un termine nuovo per te, il BIOS è un chip contenente del software presente sulla scheda madre che contiene il codice di avviamento per il computer). Quindi, questa prima parte del processo è soggetta alle limitazioni dell'interfaccia del BIOS. L'interfaccia BIOS usata per leggere gli hard disk in questo momento (INT 13H, Subfunction 2) alloca 10 bit per il Cylinder Number, 8 bit per l'Head Number, e 6 bit per il Sector Number. Questo porta gli utenti ad essere sottoposti a dei limiti (per esempio i boot manager installati nell'MBR così come i loader installati nei Boot Sector) che ora vediamo: 1024 cilindri, massimo 256 testine, massimo 64 settori/traccia, massimo (in realtà 63, 0 non è disponibile) Ora, hard disk grossi hanno molti cilindri, ma non molte testine, quindi invariabilmente con grandi hard disk il numero di cilindri sarà più alto di 1024. A causa di questo e della situazione dell'interfaccia BIOS, non puoi far partire un sistema operativo da qualsiasi punto del disco. Il codice di avvio (il boot manager e il loader del sistema operativo devono essere nei settori di avvio di tutte le partizioni avviabili) deve risiedere entro il limite dei 1024 cilindri. In pratica, se il tuo hard disk è generico e contiene 16 testine, questo si tramuta in: 1024 cilindri/disco × 16 testine/disco × 63 settori/traccia × 512 byte/settore che è intorno al summenzionato limite dei 528MB. Qui è dove entra in gioco l'LBA (Logical Block Addressing, Indirizzamento Logico dei Blocchi) del BIOS. L'LBA del BIOS fornisce all'utente delle API del BIOS accesso ai cilindri fisici oltre al 1024esimo attraverso l'interfaccia BIOS ridefinendo un cilindro. Quindi, rimappa cilindri e testine, facendo sembrare al BIOS che il computer contenga meno cilindri e più testine di quanto in realtà non ne abbia. In altre parole, si avvantaggia del fatto che gli hard disk hanno relativamente poche testine e molti cilindri semplicemente bilanciando tra cilindri e testine facendo in modo che tutti e due i numeri rimangano sotto la soglia (1024 cilindri, 256 testine). Con l'LBA del BIOS, la limitazione agli hard disk è virtualmente eliminata (beh, spostata ad 8 Gigabyte). Se hai un BIOS che supporta l'LBA, puoi mettere FreeBSD o qualsiasi altro OS in qualsiasi parte tu voglia senza toccare il limite dei 1024 cilindri. Per usare ancora l'esempio del mio Western Digital da 1.6 Giga, la sua geometria fisica è: (3148 cilindri, 16 testine, 63 settori/traccia, 512 byte/settore) Ad ogni modo, il mio LBA del BIOS rimappa questo in: (787 cilindri, 64 testine, 63 settori/traccia, 512 byte/settore) dandomi la stessa grandezza effettiva di disco, ma con numero di cilindri e testine entro i limiti dell'API del BIOS (casualmente, ho sia Linux che FreeBSD installati su uno dei miei hard disk sopra il 1024esimo cilindro fisico, e tutti e due partono perfettamente, grazie all'LBA del BIOS). Boot Manager e Allocazione del Disco Un altro punto di cui tener conto al momento al momento dell'installazione di un boot manager, è quello di ricordarsi di allocare spazio per il tuo boot manager. È meglio aver presente fin da subito questo problema, per non accorgersene troppo tardi e dover quindi reinstallare uno o più sistemi operativi. Se hai seguito il discorso nella a proposito del Master Boot Sector (dove si trova l'MBR), dei Partition Boot Sectors, e dell processo di avvio, potresti esserti chiesto esattamente dove quel piccolo boot manager risiede sul tuo hard disk. Bene, alcuni boot manager sono abbastanza piccoli da risiedere nel Master Boot Sector (Cilindro 0, Testina 0, Settore 0) insieme alla tabella delle partizioni. Alcuni invece hanno bisogno di un po' di spazio in più e si estendono su alcuni settori oltre il Master Boot Sector nella traccia del Cilindro 0 Testina 0, dato che questa è tipicamente libera. Ecco qui. Alcuni sistemi operativi (incluso FreeBSD) fanno in modo che le loro partizioni possano cominciare subito dopo il Master Boot Sector, cioè al cilindro 0, testina 0, settore 2 se vuoi. Infatti, se dai al sysinstall di FreeBSD un disco con una parte iniziale vuota oppure un disco vuoto, quello è il punto da cui comincerà la partizione FreeBSD di default (o almeno lo ha fatto quando sono caduto in questa trappola). Poi quando vai ad installare il tuo boot manager, se è uno che occupa alcuni settori oltre all'MBR, andrà a sovrascrivere la parte iniziale dei dati della prima partizione. Nel caso di FreeBSD, questo sovrascrive il label del disco, e fa in modo da rendere non avviabile la partizione di FreeBSD. Il modo più semplice per eliminare questo problema (e lasciarti la flessibilità di provare in seguito differenti boot manager) è quello di lasciare sempre la prima traccia del tuo hard disk completamente libera quando partizioni il tuo hard disk. Ciò significa lasciare libero lo spazio tra il cilindro 0, testina 0, settore 2 fino a cilindro 0, testina 0, settore 63, e cominciare la prima partizione sul cilindro 0, testina 1, settore 1. Per ciò che vale, quando crei una partizione DOS all'inizio del tuo hard disk, il DOS lascia sempre questo spazio libero di default (ecco perché molti boot manager presumono che sia libero). Quindi creare una partizione DOS all'inizio del disco toglie questi problemi tutti insieme. Mi piace fare da solo, creando una partizione DOS da 1 mega all'inizio, perché questo evita che cambino le lettere dei drive DOS quando ripartiziono in seguito. Come riferimento, i seguenti boot manager usano il Master Boot Sector per immagazzinare il loro codice e i loro dati: OS-BS 1.35 Boot Easy LILO Questi boot manager usano alcuni settori addizionali dopo il Master Boot Sector: OS-BS 2.0 Beta 8 (settori 2-5) Boot Manager di OS/2 Cosa fare se il tuo computer non parte? In alcuni momenti quando installi dei boot manager, potresti lasciare l'MBR in uno stato in cui il computer non riesce più a partire. Questo è spiacevole, ma possibile quando si utilizza FDISK su di un boot manager già installato. Se hai una partizione DOS avviabile sul tuo hard disk, puoi partire da un floppy DOS, e poi eseguire il comando: A:\> FDISK /MBR Per mettere il codice originale di avvio del DOS nel sistema. Puoi ora avviare DOS (e solamente DOS) dall'hard disk. Alternativamente, puoi far ripartire il programma di installazione del tuo boot manager da un floppy avviabile.
diff --git a/it_IT.ISO8859-15/books/handbook/eresources/chapter.sgml b/it_IT.ISO8859-15/books/handbook/eresources/chapter.sgml index e85efc4995..71fefff236 100644 --- a/it_IT.ISO8859-15/books/handbook/eresources/chapter.sgml +++ b/it_IT.ISO8859-15/books/handbook/eresources/chapter.sgml @@ -1,2186 +1,2266 @@ Risorse su Internet Il rapido sviluppo di FreeBSD rende la carta stampata un mezzo non pratico per poterne seguire l'evoluzione. Le risorse in rete sono il migliore, se non l'unico, modo per tenersi informati sulle novità di questo sistema. Dal momento che FreeBSD è il prodotto del lavoro di volontari, la comunità degli utenti generalmente si presta anche ad una funzione di supporto tecnico di varia natura, con l'email e le news USENET come il mezzo più efficace per entrare in contatto con queste comunità. I più frequentati punti di ritrovo della comunità FreeBSD sono esposti di seguito. Se aveste conoscenza di altre risorse non menzionate in questa sede, vi preghiamo di darne informazione a &a.doc; cosicchè possano essere incluse. Mailing Lists Anche se molti sviluppatori di FreeBSD leggono USENET, non può esservi garanzia di ottenere risposta alle proprie domande in tempi brevi (e in generale non può esservi garanzia di ottenere alcuna risposta) semplicemente scrivendo ad uno dei mail-group di comp.unix.bsd.freebsd.*. Indirizzando i propri messaggi alla mailing list appropriata si raggiungerà una audience più concentrata ed informata, permettendo risposte più precise (o quanto meno più - sollecite). + sollecite). Gli argomenti delle varie liste sono elencati all'inizio del documento. Si prega di leggere gli argomenti prima di unirsi o scrivere ad una lista. La maggior parte dei sottoscrittori di liste ricevono ogni giorno svariate centinaia di messaggi, e mantenendo argomenti e regole di comportamento cerchiamo di tenere alto il rapporto segnale/rumore della lista. Venir meno a queste regole vorrebbe dire il fallimento della mailing list come mezzo efficace di comunicazione per il progetto. Vengono tenuti archivi per tutte le mailing list, e questi possono essere esplorati usando il FreeBSD World Wide Web server. L'archivio esplorabile per parole chiave costituisce un mezzo eccellente per trovare risposte a domande poste di frequente e dovrebbe essere consultato prima di spedire una domanda. Sommario delle liste Liste generiche: Le seguenti sono liste - generiche a cui tutti sono invitati (e incoraggiati) a - partecipare: + generiche a cui tutti sono invitati (e incoraggiati) a + partecipare: Lista Argomento cvs-all Cambiamenti apportati all'albero dei sorgenti di FreeBSD freebsd-advocacy Evangelismo FreeBSD freebsd-announce Eventi importanti e annunci di progetti freebsd-arch Discussioni sull'architettura ed il design freebsd-bugbusters Discussioni incentrate sul mantenimento del database dei report dei problemi di FreeBSD e progetti correlati freebsd-bugs - Report sui bugs + Report sui bug freebsd-chat Argomenti non-tecnici di interesse della comunità - FreeBSD + FreeBSD freebsd-config Sviluppo del processo di installazione e configurazione di FreeBSD freebsd-current - Discussioni sull'utilizzo di FreeBSD-current + Discussioni sull'utilizzo di &os.current; freebsd-isp Argomenti di interesse degli Internet Service Providers che usano FreeBSD freebsd-jobs Opportunità di lavoro e consulenza relative a FreeBSD freebsd-newbies Discussioni ed attività dei nuovi utenti FreeBSD freebsd-policy Le decisioni sulla politica da adottare del core degli sviluppatori FreeBSD. Toni pacati e sola lettura freebsd-questions - Domande degli utenti e assistenza tecnica - - - - freebsd-security - - Questioni di sicurezza + Domande degli utenti e assistenza tecnica freebsd-security-notifications Notifiche sulla sicurezza freebsd-stable - Discussioni sull'uso di FreeBSD-stable + Discussioni sull'uso di &os.stable; freebsd-test Dove spedire i tuoi messaggi di test, lasciando in pace le altre liste Liste tecniche: le seguenti liste sono a carattere tecnico. Dovreste leggere attentamente gli argomenti elencati di seguito prima di unirvi o spedirvi mail, poichè ci sono strette linee di condotta per il loro uso ed il loro contenuto. Lista Argomento freebsd-afs - Il porting di AFS a FreeBSD + Il porting di AFS su FreeBSD freebsd-aic7xxx Sviluppare drivers per Adaptec AIC 7xxx freebsd-alpha - Il porting di FreeBSD ad Alpha + Il porting di FreeBSD su Alpha freebsd-arm - Il Porting di FreeBSD a processori ARM + Il porting di FreeBSD su processori ARM freebsd-atm Usare reti ATM con FreeBSD freebsd-audit Il progetto di audit del codice sorgente freebsd-binup Il design e lo sviluppo del sistema di aggiornamento dei binari freebsd-cluster Usare FreeBSD in cluster freebsd-cvsweb - Il mantenimento di CVSWeb + Il mantenimento di CVSweb freebsd-database Discussioni sull'uso e lo sviluppo di database sotto FreeBSD freebsd-doc Creare documenti su FreeBSD freebsd-emulation L'emulazione di altri sistemi operativi come Linux/DOS/Windows freebsd-firewire Discussioni tecniche sui FreeBSD Firewire (iLink, IEEE 1394) freebsd-fs I file system freebsd-gnome - Il Porting di GNOME e delle applicazioni GNOME + Il porting di GNOME + e delle applicazioni GNOME freebsd-hackers Discussioni tecniche generiche freebsd-hardware Discussioni tecniche generiche sull'hardware e FreeBSD freebsd-i18n L'internazionalizzazione di FreeBSD freebsd-ia32 FreeBSD sulla piattaforma IA-32 (Intel x86) freebsd-ia64 Il porting di FreeBSD ai futuri sistemi Intel IA64 freebsd-ipfw Discussioni tecniche sul redesign del codice del firewall freebsd-isdn Sviluppatori ISDN freebsd-java Sviluppatori Java e sviluppatori coinvolti nel porting della JDK sotto FreeBSD freebsd-lfs - Il Porting di LFS sotto FreeBSD + Il porting di LFS sotto FreeBSD freebsd-libh Il sistema di installazione e di gestione dei pacchetti di seconda generazione + + freebsd-mips + + Il porting di FreeBSD su MIPS + + freebsd-mobile - Discussioni sul calcolo mobile + Discussioni sui portatili freebsd-mozilla - Il Porting di Mozilla sotto FreeBSD + Il porting di Mozilla sotto + FreeBSD freebsd-multimedia Applicazioni multimediali freebsd-new-bus Discussioni tecniche sull'architettura bus freebsd-net Discussione sul networking e codice sorgente TCP/IP freebsd-openoffice - Il porting di OpenOffice.org e Staroffice - a FreeBSD + Il porting di OpenOffice.org e + StarOffice su FreeBSD + + + + freebsd-performance + + Questioni relative alla calibrazione delle + prestazioni per installazioni a ad alta performance + o carico elevato freebsd-platforms Riguardo al porting di FreeBSD ad architetture non-Intel freebsd-ports Discussione sui programmi ports freebsd-ppc - Il porting di FreeBSD a PowerPC + Il porting di FreeBSD su PowerPC freebsd-qa Discussione su certificati di qualità, solitamente sotto una release freebsd-realtime - Sviluppo di estensioni in real-time a FreeBSD + Sviluppo di estensioni realtime su FreeBSD freebsd-scsi Il sottosistema SCSI + + freebsd-security + + Questioni relative alla sicurezza di FreeBSD + + freebsd-small L'uso di FreeBSD in applicazioni embedded freebsd-smp Discussioni di design per sistemi a multiprocessore [a]simmetrico freebsd-sparc - Il porting di FreeBSD ad architetture SPARC + Il porting di FreeBSD su architetture SPARC freebsd-standards La coerenza di FreeBSD agli standards C99 e POSIX freebsd-testing Test di stabilità e performance di FreeBSD + + freebsd-threads + + Threading in FreeBSD + + freebsd-tokenring Supporto per il token-ring in FreeBSD - Liste limitate: Le seguentu liste sono adatte + Liste limitate: Le seguenti liste sono adatte ad un audience più specializzata (ed esigente) e probabilmente non sono di interesse del pubblico generico. È inoltre buona norma frequentare le liste tecniche prima di unirsi ad una di queste liste così da comprendere l'etichetta di comunicazione richiesta. Lista Argomento freebsd-core Il team centrale di FreeBSD freebsd-hubs Per coloro che gestiscono mirrors (supporto infrastrutturale) freebsd-install Sviluppo delle procedure di installazione freebsd-user-groups Coordinamento dei gruppi utenti freebsd-vendors Coordinamento dei venditori pre-release freebsd-www Coloro che mantengono il sito www.FreeBSD.org Liste digest: Molte delle seguenti liste - sono anche consultabili come digest. I nuovi messaggi vengono - raccolti e spediti via e-mail quando la loro dimensione supera i - 100KB. Le liste disponibili in formato digest sono: + sono anche consultabili come digest. I nuovi messaggi inviati alla + lista vengono raccolti e spediti in un'unica email quando vengono + ricevuti più di 100 KB di messaggi. + Le liste disponibili in formato digest sono: Lista cvs-all-digest freebsd-afs-digest freebsd-alpha-digest freebsd-arm-digest freebsd-chat-digest freebsd-current-digest freebsd-database-digest freebsd-hackers-digest freebsd-ia32-digest freebsd-ia64-digest freebsd-isdn-digest freebsd-java-digest freebsd-questions-digest freebsd-security-digest freebsd-sparc-digest freebsd-stable-digest freebsd-test-digest - Liste CVS: Le seguenti liste sono per persone interessate ad esaminare i log dei cambiamenti nelle varie parti dell'albero dei sorgenti. Sono liste Sola-Lettura e non si dovrebbe mandare mail a loro. Lista Area dei sorgenti Descrizione dell'area (sorgenti per) cvs-all - /usr/src + /usr/src Tutti i cambiamenti all'albero (sovrainsieme) Come iscriversi - Tutte le mailing lists risiedono su FreeBSD.org, così per unirsi ad una lista - basta inviare una mail a - <listname@FreeBSD.org>. - Sarà poi redisribuita a tutti i membri della lista. - Per iscriverti ad una lista, invia una mail a &a.majordomo; ed includi subscribe <nome_della_lista> [<optional address>] nel corpo del messaggio. Ad esempio per iscriverti a freebsd-announce, devi digitare: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D + Per mandare un messaggio ad una lista basta inviare + una mail a <listname@FreeBSD.org>. + Sarà poi redisribuita a tutti i membri della lista. + Per favore notateche le richieste di + sottoscrizione vanno a &a.majordomo;, non alle liste stesse. + Se volete iscrivervi usando uno pseudonimo o effettuare una richiesta di iscrizione da parte di una mailing list locale ( procedura efficiente se avete molti utenti interessati e molto apprezzata da noi!), dovreste semplicemente scrivere: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@example.com ^D Infine, è anche possibile ritirare la propria iscrizione da una lista, visionare la lista di tutti i membri della lista o ottenere la lista di tutte le liste inviando altri messaggi di controllo a majordomo. Per una lista completa dei comandi disponibili, provate con: &prompt.user; mail majordomo@FreeBSD.org help ^D A costo di ripeterci, vorremmo che i membri della lista tecnica tenessero la discussione su un tono tecnico. Se siete solo interessati ad annunci importanti, allora è preferibile che sottoscriviate freebsd-announce, creata apposta per traffico non frequente Argomenti delle liste Tutte le mailing list FreeBSD hanno alcune regole base che tutti gli utenti devono seguire. La mancata aderenza a queste regole comporterà due (2) avvisi scritti dal PostMaster FreeBSD postmaster@FreeBSD.org, dopo dei quali, ad una terza trasgressione, il membro sarà espulso da tutte le mailing list di FreeBSD e gli sarà impedita qualsiasi futura iscrizione. Siamo mortificati del fatto che queste regole e misure siano necessarie, ma al giorno d'oggi Internet è diventato, a quanto pare, un'ambiente alquanto disordinato, e molti paiono scordarsi di quanto siano fragili alcuni suoi meccanismi. Regole della strada: L'argomento di ogni messaaggio dovrebbe aderire all'argomento della lista a cui è inviato, ad esempio se la lista è a carattere tecnico, i vostri messaggi dovrebbero contenere discussioni tecniche. Chiacchiericci continui ed irrilevanti vanno a discapito del valore della lista per tutti i suoi membri e non saranno tollerati. Per discussioni libere senza restrizioni sull'argomento, la &a.chat; è liberamente fruibile e dovrebbe essere usata per questo. Non bisognerebbe scrivere a più di due mailing list, ed anche a due solo e soltanto se un motivo reale e concreto esiste. Per molte liste, esiste già un grande traffico di messaggi che si sovrappongono ed eccetto per i mix più esoterici (ad - esempio "-stable & -scsi"), non c'è alcun motivo di - scrivere a più di una lista alla volta. Se un messaggio - è inviato in modo tale che molte mailing list appaiono nella - linea Cc , allora la linea Cc - dovrebbe essere suddivisa prima di inviare nuovi messaggi. - Voi siete del tutto responsabili per - i vostri messaggi inviati in modo errato, non importa di chi sia la - causa. + esempio -stable & -scsi), non c'è alcun + motivo di scrivere a più di una lista alla volta. + Se un messaggio è inviato in modo tale che molte mailing list + appaiono nella linea Cc, allora la linea + Cc dovrebbe essere suddivisa prima di inviare + nuovi messaggi. Voi siete del tutto responsabili per + i vostri messaggi inviati in modo errato, non importa di chi sia + la causa. Attacchi personali ed insulti (nel contesto di una discussione) non sono permessi, e questa regola comprende membri e sviluppatori. Gravi violazioni della netiquette, come citare o inviare messaggi altrui quando il permesso a farlo non c'era e non sarebbe giunto sono altamente disapprovate ma non sanzionate direttamente. Comunque, ci sono pochissimi casi in cui questi messaggi sarebbero pertinenti all'argomento della lista, quindi tali comportamenti probabilmente otterrebbero un avviso (o un espulsione) del Postmaster, solo per quel motivo. Pubblicità di prodotti non-FreeBSD è altamente proibita e comportertà un'espulsione immediata se è chiaro che il trasgressore sta inviando pubblicità spam. Argomenti delle singole liste: FREEBSD-AFS Andrew File System Questa è la lista per le discussioni sul porting e l'uso dell' AFS da CMU/Transarc. FREEBSD-ANNOUNCE Eventi importanti/pietre miliari Questa è la mailing list per le persone interessate soltanto in annunci occasionali di eventi significativi riguardanti FreeBSD. Contiene annunci riguardo snapshots e altre release. Contiene annunci su nuove potenzialità di FreeBSD. Può contenere richieste di volontari etc. È una mailing list dal poco traffico, strettamente regolata. FREEBSD-ARCH Discussione sull'architettura ed il design Questa lista è per la discussione dell'architettura FreeBSD. I messaggi saranno mantenuti strettamente tecnici di natura. Esempi di possibili argomenti: Come modificare il processo di build per avere molti build personalizzati in funzione allo stesso tempo. Cosa deve essere modificato nel VFS per far funzionare i layers Heimann. Come modificare l'interfaccia dei device driver per poter usare gli stessi driver senza problemi su molti buses e architetture. Come scrivere un driver di rete. FREEBSD-AUDIT Progetto di audit del sorgente Questa è la mailing list per il progetto di audit del codice FreeBSD. Anche se in origine era intesa per cambiamenti relativi alla sicurezza, le sue caratteristiche sono state estese per includere ogni cambiamento al codice. Questa lista è piena di discussioni di patch, e probabilmente di non grandissimo interesse per l'utente medio FreeBSD. Discussioni sulla sicurezza non relative ad una particolare modifica del codice si tengono in FreeBSD-security. Nel frattempo tutti gli svilupatori sono incoraggiati a spedire le proprie patch a questa lista per correzioni, specialmente se toccano parte del sistema dove un bug può influenzare negativamente l'integrità del sistema. FREEBSD-BINUP Aggiornamento dei binari FreeBSD Questa lista esiste per fornire un terreno di discussione per il sistema di aggiornamento dei binari, o - binup. Sono consentite - Questioni di design, dettagli di implementazione, - patches, reports di bugs, report di status, richieste di feature, - log delle modifiche, e tutte ciò che riguardi + binup. + Sono consentite questioni di design, dettagli di implementazione, + patch, report di bug, report di status, richieste di feature, + log delle modifiche, e tutto ciò che riguardi binup. FREEBSD-BUGBUSTERS Coordinamento dello sforzo di gestione dei Problem Report Lo scopo di questa lista è di servire come forum di coordinamento e discussione per il Bugmeister, i suoi Bugbuster, e ogni altra parte che abbia un genuino interesse nel database PR. Questa lista non è per la discussione di bug specifici, patch, o PR. FREEBSD-BUGS Report di bug Questa è la lista per i report dei bug di FreeBSD. Quando possibile, i bug dovrebbero essere indicati usando il comando &man.send-pr.1; o tramite la sua interfaccia WEB. FREEBSD-CHAT Argomenti non tecnici relativi alla comunità FreeBSD Questa lista contiene ciò che resta dalle altre liste riguardo ad informazioni non tecniche, sociali. Include discussioni sul fatto che Jordan sembri o meno un toon ferret, se scrivere o meno in maiuscolo, chi sta bevendo troppo caffè, dove spillano la migliore birra, chi spilla birra in cantina, e così via. Annunci occasionali di eventi importanti (party a venire, celebrazioni di matrimoni, nascite, nuovi lavori etc.) possono essere fatti alle liste non tecniche, ma i suddetti argomenti dovrebbero essere diretti a questa lista. FREEBSD-CORE Il core team di FreeBSD Questa è una lista interna ad uso dei membri core. Messaggi possono esservi spediti quando una seria questione relativa a FreeBSD richiede un arbitrato da un alto scrutinio. FREEBSD-CURRENT Discussioni sull'uso di - FreeBSD-current + &os.current; Questa è la mailing list di discussione di - freebsd-current. Contiene avvertimenti su nuove features in - arrivo in -current che toccheranno gli utenti, ed istruzioni su - passi che devono restare -current. Chiunque usi - current deve sottoscrivere questa lista. + &os.current;. Contiene avvertimenti su nuove features in + arrivo in -CURRENT che toccheranno gli utenti, ed istruzioni su + passi che devono restare -CURRENT. Chiunque usi + CURRENT deve sottoscrivere questa lista. È una mailing list tecnica per la quale ci si attende materiale strettamente tecnico. FREEBSD-CURRENT-DIGEST - Discussioni sull'uso di FreeBSD - current + Discussioni sull'uso di + &os.current; Questa è la versione digest della mailing list freebsd-current. Il digest consiste di tutti i messaggi inviati alla lista freebsd-current sono raccolti ed inviati come un unico messaggio. Questa è una lista Read-Only e non si dovrebbe spedirvi alcunchè. FREEBSD-CVSWEB Progetto FreeBSD CVSweb Discussioni tecniche sull'uso, sviluppo e mantenimento di FreeBSD-CVSweb FREEBSD-DOC Progetto documentazione Questa mailing list è per la discussione di argomenti e progetti riguardanti la creazione della documentazione FreeBSD. I membri di questa mailing list sono noti in genere come The FreeBSD Documentation Project. È una lista aperta, sentitevi liberi di unirla e contribuirvi. FREEBSD-FIREWIRE Firewire (iLink, IEEE 1394) Questa è la mailing list per la discussione del design e l'implementazione di un sottosistema Firewire (anche noto come IEEE 1394 o iLink) per FreeBSD. Argomenti rilevanti includono nello specifico gli standards, i bus devices, i loro protocolli, insiemi di adapter boards/cards/chips, e l'architettura e implementazione del codice per il loro pieno supporto. FREEBSD-FS File system Discussioni riguardanti i file system FreeBSD. Questa è una lista dalle caratteristiche tecniche per la quale ci si attende contenuto strettamente tecnico. FREEBSD-GNOME GNOME - Discussioni riguardanti The Gnome Desktop Environment per - sistemi FreeBSD. Questa è una mailing list tecnica per - la quale ci si attende materiale strettamente tecnico. + Discussioni riguardanti The Gnome + Desktop Environment per sistemi FreeBSD. Questa è una + mailing list tecnica per la quale ci si attende materiale + strettamente tecnico. FREEBSD-IPFW IP Firewall Questo è il forum di discussione riguardante il redesign del codice IP firewall di FreeBSD. Questa è una mailing list tecnica per la quale ci si attende materiale strettamente tecnico. FREEBSD-IA64 Il porting FreeBSD a IA64 Questa è una mailing list tecnica per individui impegnati attivamente nel porting di FreeBSD alla piattaforma IA-64 dall'Intel, nel sollevare problemi e nel proporre soluzioni. Individui interessati nel seguire le discussioni tecniche sono comunque benvenuti. FREEBSD-ISDN Sistema di comunicazione ISDN Questa è la mailing list per le persone che discutono lo sviluppo del supporto ISDN per FreeBSD. FREEBSD-JAVA Sviluppo Java Questa è la mailing list per le persone impegnate nello sviluppo di applicazioni significative per FreeBSD ed il porting ed il mantenimento delle JDKs. FREEBSD-HACKERS Discussioni tecniche Questo è un forum per discussioni tecniche relative a FreeBSD. Questa è la mailing list tecnica principale. È per individui che lavorano attivamente a FreeBSD per sollevare problemi o discutere soluzioni alternative. Individui interessati nel seguire le discussioni tecniche sono comunque benvenuti. È una mailing list tecnica per la quale ci si attende contenuto strettamente tecnico. FREEBSD-HACKERS-DIGEST Discussioni tecniche Questa è la versione digest della mailing list freebsd-hackers. Il digest consiste di tuti i messaggi spediti alla freebsd-hackers raccolti insieme e spediti come un singolo messaggio. Questa è una lista Read-Only e non bisognerebbe inviarvi messaggi. FREEBSD-HARDWARE Discussione generale sull'hardware e FreeBSD Discussione generica sui vari tipi di hardware che FreeBSD supporta, vari problemi e suggerimenti riguardo a cosa convenga acquistare e cosa evitare. FREEBSD-HUBS Siti mirror Annunci e discussioni per persone che mantengono siti mirror FreeBSD. FREEBSD-INSTALL Discussioni sull'installazione Questa mailing list è per discutere lo sviluppo della procedura di installazione di FreeBSD nelle prossime release. FREEBSD-ISP Questioni riguardanti gli Internet Service Provider Questa mailing list è per la discussione di argomenti riguardanti gli Internet Service Provider (ISP) che usano FreeBSD. È una mailing list tecnica per a quale ci si attende materiale strettamente tecnico. FREEBSD-NEWBIES Discussioni sulle attività dei nuovi adepti Copriamo ogni attività riguardante i nuovi utenti che non sia coperta altrove, inclusi: tecniche di apprendimento e soluzione dei problemi indipendenti, la ricerca e l'uso di risorse in rete e la richiesta di aiuto ad altri utenti, come usare mailing list e quali liste usare, chat generiche, gli errori, i pregi, la condivisione di idee, storie, supporto morale (ma non tecnico), e prendere parte attiva nella comunità FreeBSD. Prendiamo i nostri problemi e le richieste di supporto a freebsd-questions, e usiamo freebsd-newbies per incontrare altra gente che sia impegnata nelle stesse attività in quanto nuovo utente. FREEBSD-OPENOFFICE OpenOffice.org Questione concernenti il porting ed il mantenimento di - OpenOffice.org e Staroffice. + OpenOffice.org e + StarOffice. + + + + + FREEBSD-PERFORMANCE + + + Discussioni riguardo la calibrazione o la + velocizzazione di FreeBSD + + Questa mailing list esiste per procurare ad hackers, + amministratori di sistema, e/o parti interessate un luogo + dove discutere argomenti legati alla performance di FreeBSD. + Argomenti accettabili includono installazioni di FreeBSD ad + alto carico, con problemi di performance o che stanno spingendo + ai limiti delle sue possibilità FreeBSD. Le parti + interessate che sono disposte a lavorare per un miglioramento + delle prestazioni di FreeBSD sono altamente incoraggiate + a sottoscrivere questa lista. Questa è una lista + estremamente tecnica, idealmente adatta per utenti FreeBSD + esperti, hackers o amministratori intenzionati a mantenere + FreeBSD veloce, robusto e scalabile. Questa lista non è + una lista domanda-e-risposta che sostituisce l'uso della + documentazione, quanto piuttosto un luogo dove apportare i propri + contributi o porre domande che non hanno avuto risposta altrove + riguardo a tematiche di prestazione. FREEBSD-PLATFORMS - Il porting alle piattaforme non + Il porting sulle piattaforme non Intel Questione concernenti FreeBSD fra le varie piattaforme, discussioni generiche e proposte per ports ad architetture non Intel. È una maliling list tecnica per la quale ci si attende materiale strettamente tecnico. FREEBSD-POLICY Le decisioni della politica del Core Team Questa è una mailing list a scarso traffico, di sola lettura, per le decisioni politiche del Core Team. FREEBSD-PORTS Discussioni sui ports Discussioni riguardanti la collezione di ports di FreeBSD (/usr/ports), proposte di nuovi ports, modifiche alla struttura della collezione dei ports e coordinamento generale degli sforzi. È una mailing list a carattere tecnico per la quale ci si attende materiale strettamente tecnico. FREEBSD-QUESTIONS Domande degli utenti Questa è una mailing list per domande riguardanti FreeBSD. Non dovreste porre domande del tipo how to alle liste tecniche a meno che stiate considerando le questioni come molto tecniche. FREEBSD-QUESTIONS-DIGEST Domande degli utenti. Questa è la versione digest della mailing list freebsd-questions. Il digest consiste di tutti i messaggi inviati alla lista freebsd-question raccolti assieme e inviati come un singolo messaggio. FREEBSD-SCSI Sottosistema SCSI Questa è la mailing list per le persone impegnate nel sottosistema SCSI di FreeBSD. È una mailing list tecnica per la quale ci si attende materiale strettamente tecnico. FREEBSD-SECURITY Questioni di security Argomenti relativi alla sicurezza dei sistemi FreeBSD (DES, Kerberos, buchi di sicurezza noti e fixes, etc.). Questa è una mailing list tecnica per la quale ci si attende - materiale strettamente tecnico. + materiale strettamente tecnico. Notate che questa non è + una lista domanda e risposta, ma che i contributi (SIA domande + SIA risposte) alle FAQ sono benvenute. FREEBSD-SECURITY-NOTIFICATIONS Notifiche riguardanti la security Notifiche riguardanti problemi di sicurezza di FreeBSD e fix. Non è una lista di discussione. La relativa lista di discussione è FreeBSD-security. FREEBSD-SMALL Usare FreeBSD in applicazioni embedded Questa lista discute argomenti relativi ad installazioni di FreeBSD su macchine dalle risorse estremamente limitate e sistemi embedded. FREEBSD-STABLE Discussioni riguardo l'uso di - FreeBSD-Stable + &os.stable; Questa è la mailing list degli utenti di - FreeBSD-Stable. Include avvertimenti su nuove caratteristiche - in arrivo nella Stable che toccheranno gli utenti, e istruzioni - sui passi da compiere per tenere aggiornata la stable. Chiunque - usi la stable dovrebbe sottoscrivere questa lista. + &os.stable;. Include avvertimenti su nuove caratteristiche + in arrivo nella -STABLE che toccheranno gli utenti, e istruzioni + sui passi da compiere per tenere aggiornata la -STABLE. Chiunque + usi la STABLE dovrebbe sottoscrivere questa lista. È una lista di carattere tecnico per la quale ci si attende materiale strettamente tecnico. FREEBSD-STANDARDS Rispetto degli standards C99 & POSIX Questo è un forum di discussioni tecniche relative al rispetto degli standards C99 e POSIX da parte di FreeBSD. FREEBSD-USER-GROUPS Lista di coordinamento dei gruppi utenti Questa è la mailing list per i coordinatori di ogni Gruppo Utenti locale, in cui discutere questioni fra di loro e un membro designato del Core Team. Questa mailing list dovrebbe essere limitata a discussioni su meeting e coordinamento di progetti che riguardano molti Gruppi Utenti. FREEBSD-VENDORS I venditori Discussioni di coordinamento fra il FreeBSD Project e venditori di software e hardware per FreeBSD. - Newsgroup Usenet Oltre ai due newsgroup specificamente designati per FreeBSD, ve ne sono molti altri in cui FreeBSD è discusso o che sono comunque rilevanti per gli utenti FreeBSD. Sono disponibili degli archivi - interrogabili attraverso parole chiave su questi newsgroups per + interrogabili attraverso parole chiave su questi newsgroup per gentile concessione di Warren Toomey wkt@cs.adfa.edu.au. - Newsgroups specifici BSD + Newsgroup specifici BSD comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (Tedesco) fr.comp.os.bsd (Francese) - - Altri newsgroups Unix di interesse + Altri newsgroup Unix di interesse comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Windows System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine Server World Wide Web http://www.FreeBSD.org/ — Server Centrale. http://www.ar.FreeBSD.org/ — Armenia. http://www.au.FreeBSD.org/ — Australia/1. http://www2.au.FreeBSD.org/ — Australia/2. http://www3.au.FreeBSD.org/ — Australia/3. http://www4.au.FreeBSD.org/ — Australia/4. http://www5.au.FreeBSD.org/ — Australia/5. http://www6.au.FreeBSD.org/ — Australia/6. http://freebsd.itworks.com.au/ — Australia/7. http://www.at.FreeBSD.org/ — Austria. http://www2.at.FreeBSD.org/ — Austria/2. http://freebsd.unixtech.be/ — Belgio. http://www.br.FreeBSD.org/www.freebsd.org/ — Brasile/1. http://www2.br.FreeBSD.org/www.freebsd.org/ — Brasile/2. http://www3.br.FreeBSD.org/ — Brasile/3. http://www.bg.FreeBSD.org/ — Bulgaria. http://www.ca.FreeBSD.org/ — Canada. http://www.cn.FreeBSD.org/ — Cina. http://www.kr.FreeBSD.org/ — Corea/1. http://www2.kr.FreeBSD.org/ — Corea/2. http://www3.kr.FreeBSD.org/ — Corea/3. http://www.dk.FreeBSD.org/ — Danimarca. http://www3.dk.FreeBSD.org/ — Danimarca/3. http://www.ee.FreeBSD.org/ — Estonia. http://www.FreeBSD.org.ph/ — Filippine. http://www.fi.FreeBSD.org/ — Finlandia. http://www2.fi.FreeBSD.org/ — Finlandia/2. http://www.fr.FreeBSD.org/ — Francia. http://www.de.FreeBSD.org/ — Germania/1. http://www1.de.FreeBSD.org/ — Germania/2. http://www2.de.FreeBSD.org/ — Germania/3. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Giappone. http://www.gr.FreeBSD.org/ — Grecia. + + http://www.hk.FreeBSD.org/ + — Hong Kong. + + http://www.ie.FreeBSD.org/ — Irlanda. http://www2.ie.FreeBSD.org/ — Irlanda/2. http://www.is.FreeBSD.org/ — Islanda. http://www.il.FreeBSD.org/ — Israele. http://www.it.FreeBSD.org/ — Italia. http://www.gufi.org/mirrors/www.freebsd.org/data/ — Italia/2. http://www.lv.FreeBSD.org/ — Lettonia. http://www.lt.FreeBSD.org/ — Lituania. http://rama.asiapac.net/freebsd/ — Malesia. http://www.no.FreeBSD.org/ — Norvegia. http://www2.no.FreeBSD.org/ — Norvegia/2. http://www.nz.FreeBSD.org/ — Nuova Zelanda. http://www.nl.FreeBSD.org/ — Olanda/1. http://www2.nl.FreeBSD.org/ — Olanda/2. http://www.pl.FreeBSD.org/ — Polonia/1. http://www2.pl.FreeBSD.org/ — Polonia/2. - - http://www.pt.FreeBSD.org/ - — Portogallo/1. - - http://www2.pt.FreeBSD.org/ — Portogallo/2. http://www3.pt.FreeBSD.org/ — Portogallo/3. http://www4.pt.FreeBSD.org/ — Portogallo/4. http://www.uk.FreeBSD.org/ — Regno Unito/1. http://www2.uk.FreeBSD.org/ — Regno Unito/2. http://www3.uk.FreeBSD.org/ — Regno Unito/3. http://www4.uk.FreeBSD.org/ — Regno Unito/4. http://www.cz.FreeBSD.org/ — Repubblica Ceca. http://www.sk.FreeBSD.org/ — Repubblica Slovacca. + + http://www2.sk.FreeBSD.org/ + — Repubblica Slovacca/2. + + http://www.ro.FreeBSD.org/ — Romania. + + http://www2.ro.FreeBSD.org/ + — Romania/2. + + + + http://www3.ro.FreeBSD.org/ + — Romania/3. + + + + http://www4.ro.FreeBSD.org/ + — Romania/4. + + http://www.ru.FreeBSD.org/ — Russia/1. http://www2.ru.FreeBSD.org/ — Russia/2. http://www3.ru.FreeBSD.org/ — Russia/3. http://www4.ru.FreeBSD.org/ — Russia/4. http://www.sm.FreeBSD.org/ — San Marino. http://www.sg.freebsd.org/ — Singapore. http://www2.sg.freebsd.org/ — Singapore/2. http://www.si.FreeBSD.org/ — Slovenia. http://www2.si.FreeBSD.org/ — Slovenia/2. http://www.es.FreeBSD.org/ — Spagna. http://www2.es.FreeBSD.org/ — Spagna/2. http://www3.es.FreeBSD.org/ — Spagna/3. http://www.za.FreeBSD.org/ — Sud Africa/1. http://www2.za.FreeBSD.org/ — Sud Africa/2. http://www.se.FreeBSD.org/ — Svezia. http://www2.se.FreeBSD.org/ — Svezia/2. http://www.ch.FreeBSD.org/ — Svizzera. http://www2.ch.FreeBSD.org/ — Svizzera/2. http://www.tw.FreeBSD.org/ — Taiwan. http://www2.tw.FreeBSD.org/ — Taiwan/2. http://www3.tw.FreeBSD.org/ — Taiwan/3. http://www4.tw.FreeBSD.org/ — Taiwan/4. http://www.tr.FreeBSD.org/ — Turchia. http://www2.tr.FreeBSD.org/ — Turchia/2. http://www.enderunix.org/freebsd/ — Turchia/3. http://www.ua.FreeBSD.org/www.freebsd.org/ — Ucraina/1. http://www2.ua.FreeBSD.org/ — Ucraina/2. http://www4.ua.FreeBSD.org/ — Ucraina/Crimea. http://www5.ua.FreeBSD.org/ — Ucraina/5. http://www.hu.FreeBSD.org/ — Ungheria. + + http://www2.hu.FreeBSD.org/ + — Ungheria/2. + + http://www2.FreeBSD.org/ — USA/Texas. http://www3.FreeBSD.org/ — USA/3. http://www7.FreeBSD.org/ — USA/7. Indirizzi Email I seguenti Gruppi Utenti forniscono indirizzi email per i propri membri. Gli amministratori di lista si riservano il diritto di revocare l'indirizzo assegnato se in alcun modo se ne fa cattivo uso. Dominio Offerta Gruppo utente Amministratore ukug.uk.FreeBSD.org Solo forwarding freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Shell Accounts I seguenti Gruppi utenti forniscono account di shell a persone che supportano attivamente il progetto FreeBSD. Gli amministratori elencati si riservano il diritto di cancellare l'account se viene in alcun modo usato male. Host Accesso Offerta Amministratore storm.uk.FreeBSD.org Solo SSH CVS a sola lettura, spazio web personale, email &a.brian; dogma.freebsd-uk.eu.org Telnet/FTP/SSH Email, spazio Web, FTP anonimo Lee Johnston lee@uk.FreeBSD.org diff --git a/it_IT.ISO8859-15/share/sgml/mailing-lists.ent b/it_IT.ISO8859-15/share/sgml/mailing-lists.ent index 93b8fd7c50..19dd86cb55 100644 --- a/it_IT.ISO8859-15/share/sgml/mailing-lists.ent +++ b/it_IT.ISO8859-15/share/sgml/mailing-lists.ent @@ -1,221 +1,224 @@ freebsd-advocacy@FreeBSD.org"> freebsd-afs@FreeBSD.org"> freebsd-aic7xxx@FreeBSD.org"> freebsd-alpha@FreeBSD.org"> freebsd-announce@FreeBSD.org"> freebsd-arch@FreeBSD.org"> freebsd-arm@FreeBSD.org"> freebsd-atm@FreeBSD.org"> freebsd-audit@FreeBSD.org"> freebsd-binup@FreeBSD.org"> freebsd-bugbusters@FreeBSD.org"> freebsd-bugs@FreeBSD.org"> freebsd-chat@FreeBSD.org"> freebsd-cluster@FreeBSD.org"> cvs-committers@FreeBSD.org"> freebsd-config@FreeBSD.org"> freebsd-core@FreeBSD.org"> freebsd-current@FreeBSD.org"> cvs-all@FreeBSD.org"> freebsd-database@FreeBSD.org"> freebsd-developers@FreeBSD.org"> freebsd-doc@FreeBSD.org"> doc-committers@FreeBSD.org"> freebsd-emulation@FreeBSD.org"> freebsd-firewire@FreeBSD.org"> freebsd-fs@FreeBSD.org"> freebsd-gnome@FreeBSD.org"> freebsd-hackers@FreeBSD.org"> freebsd-hardware@FreeBSD.org"> freebsd-hubs@FreeBSD.org"> freebsd-i18n@FreeBSD.org"> freebsd-ia64@FreeBSD.org"> freebsd-install@FreeBSD.org"> freebsd-ipfw@FreeBSD.org"> freebsd-isdn@FreeBSD.org"> freebsd-isp@FreeBSD.org"> freebsd-java@FreeBSD.org"> freebsd-jobs@FreeBSD.org"> freebsd-lfs@FreeBSD.org"> freebsd-libh@FreeBSD.org"> freebsd-mips@FreeBSD.org"> freebsd-mobile@FreeBSD.org"> freebsd-mozilla@FreeBSD.org"> freebsd-multimedia@FreeBSD.org"> freebsd-net@FreeBSD.org"> freebsd-newbies@FreeBSD.org"> new-bus-arch@bostonradio.org"> freebsd-platforms@FreeBSD.org"> freebsd-policy@FreeBSD.org"> freebsd-ports@FreeBSD.org"> freebsd-ports-bugs@FreeBSD.org"> ports-committers@FreeBSD.org"> freebsd-ppc@FreeBSD.org"> freebsd-qa@FreeBSD.org"> freebsd-questions@FreeBSD.org"> freebsd-realtime@FreeBSD.org"> freebsd-scsi@FreeBSD.org"> freebsd-security@FreeBSD.org"> freebsd-security-notifications@FreeBSD.org"> freebsd-small@FreeBSD.org"> freebsd-smp@FreeBSD.org"> freebsd-sparc@FreeBSD.org"> src-committers@FreeBSD.org"> freebsd-stable@FreeBSD.org"> freebsd-standards@FreeBSD.org"> freebsd-test@FreeBSD.org"> +freebsd-threads@FreeBSD.org"> + freebsd-tokenring@FreeBSD.org"> freebsd-user-groups@FreeBSD.org"> freebsd-vendors@FreeBSD.org"> freebsd-www@FreeBSD.org"> majordomo@FreeBSD.org">