From 68f259f776fb0dacf717d95068db7a4f4b5ba938 Mon Sep 17 00:00:00 2001 From: Marc Fonvieille Date: Sun, 22 Sep 2002 10:47:32 +0000 Subject: New translations: committers-guide, euro, explaining-bsd and multi-os. PR: docs/42926 Submitted by: Alex Dupre --- it_IT.ISO8859-15/articles/Makefile | 7 +- it_IT.ISO8859-15/articles/Makefile.inc | 2 +- .../articles/committers-guide/Makefile | 29 + .../articles/committers-guide/article.sgml | 1509 ++++++++++++++++++++ it_IT.ISO8859-15/articles/euro/Makefile | 14 + it_IT.ISO8859-15/articles/euro/article.sgml | 383 +++++ it_IT.ISO8859-15/articles/explaining-bsd/Makefile | 14 + .../articles/explaining-bsd/article.sgml | 593 ++++++++ it_IT.ISO8859-15/articles/multi-os/Makefile | 14 + it_IT.ISO8859-15/articles/multi-os/article.sgml | 761 ++++++++++ 10 files changed, 3323 insertions(+), 3 deletions(-) create mode 100644 it_IT.ISO8859-15/articles/committers-guide/Makefile create mode 100644 it_IT.ISO8859-15/articles/committers-guide/article.sgml create mode 100644 it_IT.ISO8859-15/articles/euro/Makefile create mode 100644 it_IT.ISO8859-15/articles/euro/article.sgml create mode 100644 it_IT.ISO8859-15/articles/explaining-bsd/Makefile create mode 100644 it_IT.ISO8859-15/articles/explaining-bsd/article.sgml create mode 100644 it_IT.ISO8859-15/articles/multi-os/Makefile create mode 100644 it_IT.ISO8859-15/articles/multi-os/article.sgml (limited to 'it_IT.ISO8859-15/articles') diff --git a/it_IT.ISO8859-15/articles/Makefile b/it_IT.ISO8859-15/articles/Makefile index 6e8de39901..a92958dd1c 100644 --- a/it_IT.ISO8859-15/articles/Makefile +++ b/it_IT.ISO8859-15/articles/Makefile @@ -1,10 +1,13 @@ # $FreeBSD$ SUBDIR = +SUBDIR+= committers-guide +SUBDIR+= euro +SUBDIR+= explaining-bsd SUBDIR+= filtering-bridges +SUBDIR+= multi-os SUBDIR+= new-users -# ROOT_SYMLINKS+= new-users - DOC_PREFIX?= ${.CURDIR}/../.. + .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/it_IT.ISO8859-15/articles/Makefile.inc b/it_IT.ISO8859-15/articles/Makefile.inc index 634a769c39..0ff2b6dcad 100644 --- a/it_IT.ISO8859-15/articles/Makefile.inc +++ b/it_IT.ISO8859-15/articles/Makefile.inc @@ -1,4 +1,4 @@ -# +# # $FreeBSD$ # diff --git a/it_IT.ISO8859-15/articles/committers-guide/Makefile b/it_IT.ISO8859-15/articles/committers-guide/Makefile new file mode 100644 index 0000000000..a48603f040 --- /dev/null +++ b/it_IT.ISO8859-15/articles/committers-guide/Makefile @@ -0,0 +1,29 @@ +# +# $FreeBSD$ +# +# Crea la Nuova Guida per i Committer di FreeBSD +# + +MAINTAINER=sysadmin@alexdupre.com + +DOC?= article + +FORMATS?= html + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +JADEFLAGS+= -V %generate-article-toc% + +# +# SRCS lista i singoli files SGML che compongono il documento. Modifiche +# a qualunque di questi files obbligano la ricreazione +# + +# Contenuto SGML +SRCS= article.sgml + +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" + diff --git a/it_IT.ISO8859-15/articles/committers-guide/article.sgml b/it_IT.ISO8859-15/articles/committers-guide/article.sgml new file mode 100644 index 0000000000..9744e83a5e --- /dev/null +++ b/it_IT.ISO8859-15/articles/committers-guide/article.sgml @@ -0,0 +1,1509 @@ + + + +%man; + + +%freebsd; + + +%authors; + + +%teams; + + +%mailing-lists; + + +%translators; +]> + +
+ + Guida del Committer + + + + The FreeBSD Italian Documentation Project + + + + $FreeBSD$ + + + 1999 + + 2000 + + 2001 + + 2002 + + 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 + + freefall.FreeBSD.org + + + + Metodi di Accesso + + &man.ssh.1; + + + + CVSROOT Principale + + /home/ncvs + + + + &a.cvs; Principali + + &a.peter; e &a.markm;, così come &a.joe; per i + ports/ + + + + Mailing List + + &a.developers;, &a.committers; + + + + 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 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 + + nik@ + + doc/, src/ documentazione + + + + 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 di tutte le sue modifiche dirette allo + scopo di ripulire o sistemare dei gravi abusi di CVS da parte di un + committer. Nessun altro deve provare a toccare il repository + direttamente. Nel caso dovessi causare qualche problema al repository, + diciamo una errata operazione di cvs import o + cvs tag, non cercare + di sistemarla da solo! + Invia un messaggio ai &a.cvs; (o chiama uno di loro) ed esponi il problema + ad uno di loro invece. Gli unici che hanno il permesso di manipolare + direttamente i bit del repository sono i + repomeister. + + Le operazioni sul CVS solitamente sono fatte loggandosi su + freefall, assicurandosi che la variabile di ambiente + CVSROOT sia impostata a /home/ncvs, 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. + + Tieni presente che quando usi CVS su freefall, devi + impostare la tua umask a 2, + così come la variabile di ambiente CVSUMASK a + 2. Questo assicura che ogni nuovo file creato tramite + cvs add abbia i corretti permessi. + Se aggiungi un file o una directory e scopri che il file nel repository + ha i permessi errati (per essere precisi, tutti i file nel repository + dovrebbero essere modificabili dal gruppo ncvs), + contatta uno dei meister del repository come descritto sopra. + + Se sei abituato ad usare CVS da remoto e ti consideri abbastanza + pratico di CVS in generale, puoi anche effettuare le operazioni sul CVS + direttamente dalla tua macchina e dai tuoi sorgenti locali. + Ricordati solo di impostare CVS_RSH a + ssh così da usare un metodo di trasferimento + relativamente sicuro ed affidabile. Se non hai idea del significato di + quello che ho appena detto, allora continua a loggarti su + freefall ed ad applicare le tue diff con + &man.patch.1;. + + 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 + 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, aggiornalo 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. + + + + 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 + + + + http://www.FreeBSD.org/send-pr.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:nik: + + + + 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; + + + 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 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; + + + 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; + + + developers comprende tutti i committer. 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 + + + + 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/euro/Makefile b/it_IT.ISO8859-15/articles/euro/Makefile new file mode 100644 index 0000000000..886e21cc9d --- /dev/null +++ b/it_IT.ISO8859-15/articles/euro/Makefile @@ -0,0 +1,14 @@ +# $FreeBSD$ + +DOC?= article + +FORMATS?= html + +INSTALL_COMPRESSED?=gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/it_IT.ISO8859-15/articles/euro/article.sgml b/it_IT.ISO8859-15/articles/euro/article.sgml new file mode 100644 index 0000000000..139ee91f58 --- /dev/null +++ b/it_IT.ISO8859-15/articles/euro/article.sgml @@ -0,0 +1,383 @@ + + + +%man; + +%translators; +]> + +
+ + Il simbolo dell'Euro su <systemitem + class="osname">FreeBSD</systemitem> + + + + Aaron + + Kaplan + + +
aaron@lo-res.org
+ + + + + + 2002 + + The FreeBSD Italian Documentation Project + + + $FreeBSD$ + + + Questo documento cercherà di aiutarvi ad usare il nuovo + simbolo dell'Euro presente sulla vostra nuova tastiera + comprata all'inizio del 2002 per l'avvento della nuova valuta comune. + Inizieremo dalle parti più importanti come essere in grado di + visualizzare correttamente il simbolo in console. Le sezioni successive + tratteranno la configurazione di specifici programmi come + X11. + + Molti utili suggerimenti sono stati forniti da Oliver Fromm, + Tom Rhodes e innumerevoli altri. + Grazie! Senza di voi non sarebbe stato possibile realizzare questo + articolo! + + Traduzione a cura di &a.it.dema;. + + + + + L'Euro in 5 minuti + + Se avete già familiarità con la + localizzazione come + descritta nel Manuale di FreeBSD + potreste essere interessanti solamente alle seguenti informazioni che + vi consentiranno di iniziare velocemente ad usare l'Euro: + + + + ISO8859-15 + + + Questa è una versione leggermente modificata della + più comune mappa caratteri ISO8859-1. + Include il simbolo dell'Euro. Usata per le variabili d'ambiente + LANG e LC_CTYPE. + + + + + iso15-8x16.fnt + + + Il font per la console da usare con &man.vidcontrol.1; + + + + + /usr/share/syscons/keymaps/*.iso.kbd + + + Mappe di tastiera per le diverse lingue. Impostate la vostra + variabile keymap in rc.conf + ad una di queste mappe. + + + + + LC_CTYPE + + + Usata per impostare il corretto tipo di caratteri nelle vostre + impostazioni locali. + + + + + XkbLayout + "lingua(euro)" + + + Opzione di configurazione di XFree86. + + + + + /usr/X11R6/lib/X11/fonts/*/fonts.alias + + + Assicuratevi di modificare i nomi dei vostri file dei font di + X11 a -*-..-*-iso8859-15 + + + + + + + Nota generale + + Nelle sezioni seguenti ci riferiremo spesso a + ISO8859-15. + Questa è la notazione standard a partire da + FreeBSD 4.5. + Nelle versioni più vecchie la notazione standard era invece + ISO_8859-15 oppure + DIS_8859-15. + + Se state usando una versione di + FreeBSD più vecchia, + assicuratevi di guardare in + /usr/share/locale/ per scoprire quale notazione + è in uso nel vostro sistema. + + + + La console + + + Configurare il font della console + + In base alla risoluzione e dimensione della vostra console + dovrete mettere una delle seguenti linee in + rc.conf: + + font8x16="iso15-8x16.fnt" # da /usr/share/syscons/fonts/* +font8x14="iso15-8x14.fnt" +font8x8="iso15-8x8.fnt" + + Questo imposterà effettivamente il font ISO8859-15 conosciuto + anche come Latin-9. ISO8859-15 è una variazione di ISO8859-1. + Potete notare la differenza tra i due esaminando il simbolo dell'Euro: + il suo valore decimale è 164. Nell'ISO8859-1 noterete un + cerchietto con quattro piccoli segnetti agli angoli. Questo è + spesso chiamato come "simbolo universale di valuta". Nell'ISO8859-15, + invece del cerchietto, avrete il simbolo dell'Euro. Per il resto i + font sono più o meno identici. + + + Al momento della stesura di questo articolo l'unico font + utilizzabile sembra essere l'iso15-8x16.fnt. + Gli altri sembrano avere l'aspetto dello ISO8859-1 sebbene il nome + suggerisca altrimenti. + + + + Impostando questo font alcune applicazioni da console avranno + un aspetto "rovinato". Questo è dovuto al fatto che esse si + aspettano di trovare un diverso set di font/caratteri come per esempio + l'ANSI 850. Un tipico esempio è + /stand/sysintall. + Comunque questo non dovrebbe essere un problema nella maggior parte + dei casi. + + + Il vostro prossimo passo dovrebbe essere o riavviare il vostro + sistema affinché i cambiamenti abbiano effetto oppure + (manualmente) effettuare le modifiche nello stesso modo in cui + avverrebbero all'avvio: + + &prompt.user; vidcontrol -f iso15-8x16.fnt + + Per controllare se il font è stato impostato eseguite il + seguente piccolo script + awk: + + #!/usr/bin/awk -f +BEGIN { + for(i=160;i<180;i++) + printf"%3d %c\n",i,i +} + + Il risultato dovrebbe mostrare il simbolo dell'Euro nella + posizione 164. + + + + Configurare la vostra tastiera per l'Euro + + La maggior parte delle mappe di tastiera dovrebbe essere già + correttamente impostata. Per esempio, se avete una tastiera + italiana e vi funzionano le lettere accentate, potete tranquillamente + saltare questa sezione visto che la tastiera mappa correttamente la + combinazioni di caratteri, qualunque essa sia, + (ad esempio: + Alt Gr + e + ) al valore decimale 164. + Se avete problemi la cosa migliore è controllare i file in + /usr/share/syscons/keymaps/*.kbd. + Il formato dei file delle mappe di tastiera è descritto in + &man.keyboard.4;. &man.kbdcontrol.1; può essere usato per + caricare una mappa personalizzata. + + Una volta che è stata trovata la corretta mappa di tastiera, + dovete aggiungerla a /etc/rc.conf con la + linea: + + keymap="it.iso" # o un'altra mappa + + Come spiegato in precedenza, questo passo probabilmente lo avete + già fatto al momento dell'installazione (con + sysinstall). + In caso contrario, riavviate oppure caricate la nuova mappa con + &man.kbdcontrol.1;. + + Per verificare la nuova mappatura della tastiera, passate ad una + nuova console e al prompt di login, invece di + loggarvi, provate a premere il tasto Euro. + Se non funziona assicuratevi di aver correttamente impostato la + giusta mappa di tastiera oppure inviate una segnalazione di bug + con &man.send-pr.1;. + + + Al momento il tasto Euro non funziona ancora in + bash o + tcsh. + + + + + Correggere le variabili d'ambiente + + Le shell (bash, tcsh) si basano sulla libreria &man.readline.3; + la quale a sua volta utilizza la variabile d'ambiente + LC_CTYPE. LC_CTYPE deve essere impostata + prima che la shell sia completamente operativa. + Fortunatamente è sufficiente aggiungere la linea: + + export LC_CTYPE=it_IT.ISO8859-15 + + al vostro file .bash_profile (bash), + oppure: + + setenv LC_CTYPE it_IT.ISO8859-15 + + al vostro file .login (tcsh). Naturalmente, + it_IT deve essere sostituito con la + vostra lingua. Poi, sloggatevi e riloggatevi nuovamente, e verificate + che il tasto Euro funzioni. + Già così la maggior parte delle applicazioni console + dovrebbe funzionare correttamente col tasto Euro. + Ulteriori configurazioni per programmi speciali come + pine potrebbero essere comunque + necessarie. + + + Un'alternativa alla modifica di .login e + .bash_profile è quella di impostare le + variabili d'ambiente tramite &man.login.conf.5;. Questo approccio + ha il vantaggio di assegnare classi di login a determinati utenti + (esempio, utenti Francesi, utenti Tedeschi, ecc.) + in un solo posto. + + + + + + Modificare X11 + + Modificate /etc/XF86Config secondo le + seguenti istruzioni: + + Option "XkbLayout" "it(euro)" + + Come sempre, rimpiazzate it con la + vostra lingua. Così facendo la tastiera dovrebbe essere + configurata correttamente. Come in console, deve essere scelto il font + adatto. Per le applicazioni KDE andate in + KDE control center -> + Personalization -> Country & Language -> Charset e + cambiatelo in ISO8859-15. + Simili modifiche si devono effettuare per + kmail e altre applicazioni. + + Un'altra buona idea è modificare i vostri file + fonts.alias. + In particolar modo il font fixed dovrebbe essere + modificato per usare la giusta mappa caratteri. Il file + /usr/X11R6/lib/X11/fonts/misc/fonts.alias + dell'autore è mostrato come esempio: + + ! $Xorg: fonts.alias,v 1.3 2000/08/21 16:42:31 coskrey Exp $ +fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 +variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-15 +(...) + + Come in console, applicazioni speciali hanno ancora i font + ISO8859-1 configurati nei loro rispettivi database xrdb. + Un esempio importante è xterm. + Come regola generale è sufficiente cambiare il corrispondente file + di configurazione in + /usr/X11R6/lib/X11/app-defaults + e aggiungere il font corretto. Ecco come fare per + xterm. + + &prompt.root; cd /usr/X11R6/lib/X11/app-defaults/ +&prompt.root; vi XTerm + + Aggiungete la seguente linea all'inizio del file: + + *font: -misc-fixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-15 + + Infine, fate ripartire X e assicuratevi che i font siano + visualizzati correttamente eseguendo il precedente + script awk. + Tutte le principali applicazioni dovrebbero rispettare la mappatura di + tastiera e l'impostazione del font. + + + + Problemi non ancora risolti + + Naturalmente, l'autore gradirebbe ricevere i vostri commenti. + Inoltre, fatemi almeno sapere se avete soluzioni per questi problemi + irrisolti. + + + + Descrivere metodi alternativi per configurare XFree86: + x11/xkeycaps + + + + Impostazioni in GNOME + + + + Impostazioni in XFCE + + + + Impostazioni per (X)Emacs + + + + Descrivere l'UTF-8 + + + + Descrivere libiconv come un buon + sistema per convertire applicazioni da ISO8859-15 a UTF-{8,16} + + + +
+ + diff --git a/it_IT.ISO8859-15/articles/explaining-bsd/Makefile b/it_IT.ISO8859-15/articles/explaining-bsd/Makefile new file mode 100644 index 0000000000..886e21cc9d --- /dev/null +++ b/it_IT.ISO8859-15/articles/explaining-bsd/Makefile @@ -0,0 +1,14 @@ +# $FreeBSD$ + +DOC?= article + +FORMATS?= html + +INSTALL_COMPRESSED?=gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml b/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml new file mode 100644 index 0000000000..b65bd92208 --- /dev/null +++ b/it_IT.ISO8859-15/articles/explaining-bsd/article.sgml @@ -0,0 +1,593 @@ + + + +%man; + +%translators; +]> + +
+ + Panoramica su BSD + + + Greg + + Lehey + + +
grog@FreeBSD.org
+ + + + + Nel mondo open source, la parola Linux è quasi + sinonimo di Sistema Operativo, ma non si tratta del solo + sistema operativo UNIX open source. Secondo + l'Internet + Operating System Counter, ad Aprile del 1999 il 31.3% delle + macchine connesse in rete ha in esecuzione Linux. + Il 14.6% fa girare BSD UNIX. + Alcuni dei più grandi operatori del web, come Yahoo!, usano BSD. Il server + FTP più affollato del mondo, ftp.cdrom.com, usa BSD per + trasferire 1.4 TB di dati al giorno. Chiaramente questo non è + un mercato di nicchia: BSD è un segreto ben mantenuto. + + Dunque, qual è il segreto? Perché BSD non è + conosciuto meglio? Questo documento risponde a questa e ad altre + domande. + + In questo documento, le differenze tra BSD e Linux verranno + evidenziate così. + + Traduzione a cura di &a.it.surrender;. + + + + + Cos'è BSD? + + BSD sta per Berkeley Software Distribution. È + il nome delle distribuzioni di codice sorgente dell'Università + della California, Berkeley, che erano originariamente estensioni al + sistema operativo UNIX del settore Ricerca della AT&T. + Molti progetti open source di sistemi operativi sono basati + su una versione di questo codice sorgente noto come + 4.4BSD-Lite. Inoltre, essi comprendono un gran numero di + pacchetti provenienti da altri progetti Open Source, incluso, in + particolare, il progetto GNU. L'intero sistema operativo + comprende: + + + + Il kernel BSD, che gestisce lo scheduling dei processi, l'utilizzo + della memoria, il supporto multiprocessore (SMP), i driver dei + vari dispositivi, ecc. + + Diversamente dal kernel Linux, ci sono differenti + kernel BSD con differenti caratteristiche. + + + + La libreria C, le API di base per il sistema. + + La libreria C BSD è basata su codice proveniente + da Berkeley, non dal progetto GNU. + + + + Utilità come shell, file manager, compilatori e + linker. + + Alcune delle applicazioni derivano dal + progetto GNU, altre no. + + + + L'X Window System, che gestisce la visualizzazione grafica. + + L'X Window System usato nella maggior parte delle versioni di + BSD viene mantenuto come un progetto separato, il + progetto XFree86. + Questo è lo stesso codice usato da Linux. BSD in genere non + specifica un desktop grafico come GNOME o KDE, + anche se questi sono disponibili. + + + + Molti altri programmi ed utilità. + + + + + + Cosa, un vero UNIX? + + I sistemi operativi BSD non sono cloni, ma derivati open source + del sistema operativo UNIX dell'AT&T Research, che è anche + l'antenato del moderno UNIX System V. Questo potrebbe sorprendere. Come + è potuto accadere questo, se la AT&T non ha mai rilasciato il + suo codice come open source? + + È vero che lo UNIX AT&T non è open source, e nel + senso del copyright BSD in definitiva non è + UNIX, ma d'altro canto l'AT&T ha importato sorgenti da altri progetti, + in maniera rilevante dal Computer Sciences Research Group + dell'Università della California a Berkeley, CA. Iniziato nel + 1976, il CSRG ha iniziato a rilasciare nastri con il loro software, + chiamandolo Berkeley Software Distribution o + BSD. + + Le versioni iniziali di BSD consistevano principalmente di programmi + utente, ma questo cambiò drammaticamente quando il CSRG + sottoscrisse un contratto con la + Defense Advanced Projects Research Agency (DARPA) per migliorare + i protocolli di comunicazione della loro rete, ARPANET. I nuovi + protocolli furono conosciuti come Internet Protocols, + e in seguito come TCP/IP, ai nomi dei protocolli + più importanti. La prima implementazione distribuita in maniera + estesa fu parte di 4.2BSD, nel 1982. + + Nel corso degli '80, sorsero un certo numero di compagnie + che producevano workstation. Molti preferirono usare UNIX su licenza + piuttosto che sviluppare da soli un nuovo sistema operativo. + In particolare, la Sun Microsystems rilicenziò UNIX ed + implementò una versione commerciale di 4.2BSD, che chiamò + SunOS. Quando alla AT&T stessa fu permesso di vendere UNIX + commercialmente, cominciarono con una implementazione ridotta all'osso + nota come System III, presto seguita da System V. + Il codice fondamentale di System V non comprendeva la parte di rete, + dunque tutte le implementazioni includevano software addizionale tratto + da BSD, incluso il software legato al TCP/IP, ma anche utilità come + la shell csh e l'editor vi. + Complessivamente, questi miglioramenti furono conosciuti + come le Estensioni Berkeley. + + Il nastro BSD conteneva codice AT&T e dunque richiedeva + una licenza per il sorgente UNIX. Dal 1990, il finanziamento del CSRG + si stava esaurendo, e se ne stava per affrontare la chiusura. + Alcuni membri del gruppo decisero di rilasciare il codice BSD, + che era Open Source, senza il codice proprietario della AT&T. + Ciò accadde infine con il Networking Tape 2, + in genere noto come Net/2. Net/2 non era un sistema + operativo completo: mancava circa il 20% del codice del kernel. Uno dei + membri del CSRG, William F. Jolitz, scrisse il codice rimanente e lo + rilasciò all'inizio del 1992 come 386BSD. + Allo stesso tempo, un altro gruppo di ex membri del CSRG formò una + compagnia chiamata Berkeley Software + Design Inc. e rilasciò una versione beta di un sistema + operativo chiamato BSD/386, + che era basato sugli stessi sorgenti. Il nome del sistema operativo + è cambiato di recente in BSD/OS. + + 386BSD non divenne mai un sistema operativo stabile. Invece, due + altri progetti se ne distaccarono nel 1993: + NetBSD e + FreeBSD. + I due progetti presero inizialmente direzioni divergenti, a causa della + differente pazienza nell'attendere miglioramenti a + 386BSD: la gente di NetBSD cominciò all'inizio dell'anno, + e la prima versione di FreeBSD non fu pronta fino alla fine + dell'anno. Nel frattempo, i codici erano diventati abbastanza differenti + da renderne difficile la fusione. Inoltre, i progetti avevano obiettivi + differenti, come vedremo in seguito. Nel 1996, un ulteriore progetto, + OpenBSD, si divise da + NetBSD. + + + + Perché BSD non è più conosciuto? + + Per un certo numero di ragioni, BSD è relativamente + sconosciuto: + + + + Gli sviluppatori BSD sono spesso più interessati + a ripulire il loro codice che a fagli pubblicità. + + + + Molta della popolarità di Linux è dovuta a fattori + esterni al progetto Linux, come la stampa, e le compagnie formate per + fornire servizi relativi a Linux. Fino a poco tempo fa, + la varie versioni di BSD open source non avevano tali spinte. + + + + Gli sviluppatori BSD tendono ad avere più esperienza + di quelli di Linux, ed hanno meno interesse nel rendere il sistema + facile da usare. + I nuovi arrivati tendono a sentirsi più a loro agio con + Linux. + + + + Nel 1992, l'AT&T citò in giudizio + BSDI, + il produttore di BSD/386, sostenendo che il prodotto conteneva + codice sotto copyright della AT&T. Il caso fu risolto in + tribunale nel 1994, ma lo spettro della causa continua a perseguitare + alcune persone. Nel marzo 2000 un articolo pubblicato sul web + sosteneva che il caso era stato concluso + recentemente. + + Un dettaglio che venne chiarito dall'azione legale fu il nome: + negli anni '80, BSD era stato conosciuto come BSD Unix. + Con l'eliminazione delle ultima vestigia del codice AT&T da BSD, + si era perso anche il diritto di usare il nome UNIX. Per questo + noterete riferimenti nei libri al sistema operativo 4.3BSD + UNIX ed al sistema operativo 4.4BSD. + + + + C'è una certa percezione che il progetto BSD sia + frammentato e belligerante. Il Wall + Street Journal parlò di + balcanizzazione dei progetti BSD. Come per l'azione + legale, questa percezione si basa principalmente su vecchie + storie. + + + + + + Paragone tra BSD e Linux + + Dunque qual'è l'effettiva differenza tra, diciamo, Debian + Linux e FreeBSD? Per l'utente medio, la differenza è + sorprendentemente piccola: entrambi sono sistemi operativi tipo UNIX. + Entrambi vengono sviluppati da progetti non commerciali (questo non si + applica a molte altre distribuzioni di Linux, ovviamente). Nella sezione + seguente, daremo un'occhiata a BSD e lo paragoneremo a Linux. + La descrizione si applica molto da vicino a FreeBSD, che conta per un 80% + delle installazioni BSD, ma le differenza da NetBSD ed OpenBSD sono + piccole. + + + Chi possiede BSD? + + Nessuna persona o società possiede BSD. Esso è creato + e distribuito da una comunità di persone con grande preparazione + tecnica e voglia di fare che contribuiscono da tutto il mondo. + Alcuni dei componenti di BSD sono progetti open source gestiti da + diversi responsabili. + + + + Come viene sviluppato ed aggiornato BSD? + + I kernel BSD vengono sviluppati ed aggiornati + seguendo il modello di sviluppo open source. Ogni progetto mantiene + un albero dei sorgenti liberamente accessibile in + un Concurrent Versions + System, un sistema di gestione delle versioni concorrenti, + che contiene tutti i file sorgenti del progetto, + inclusa la documentazione ed altri file inerenti. Il CVS + permette agli utenti di estrarre (in sostanza, + estrarre una copia di) ogni versione desiderata del sistema. + + Un grande numero di sviluppatori da tutto il mondo contribuisce al + miglioramento di BSD. Essi sono divisi in tre grandi gruppi: + + + + I contributor scrivono codice o + documentazione. Non gli è permesso di effettuare il commit + (aggiungere codice) direttamente all'albero dei sorgenti. + Affinché il loro codice sia incluso nel sistema, esso + deve essere rivisto e controllato da uno sviluppatore registrato, + noto come committer. + + + + I committer sono sviluppatori + con accesso in scrittura all'albero dei sorgenti. + Per poter divenire un committer, un individuo deve dimostrare + abilità nell'area nella quale è attivo. + + + È a discrezione del committer la volontà di + confrontarsi con qualcuno prima di effettuare cambiamenti. In + generale, un committer con esperienza può effettuare + cambiamenti che sono ovviamente corretti senza interrogare nessuno. + Ad esempio, un committer del progetto di documentazione può + correggere errori tipografici o grammaticali senza un confronto con + altri. D'altro canto, dagli sviluppatori che stanno per effettuare + cambiamenti profondi o complessi ci si aspetta che sottopongano i + cambiamenti a revisione prima di renderli effettivi. In casi + estremi, un membro del core team, con una funzione simile a un Capo + Architetto, può ordinare che i cambiamenti siano rimossi + dall'albero, un processo noto come marcia + indietro. + Tutti i committer ricevono una lettera che descrive ogni + modifica individuale, dunque non è possibile effettuare un + commit segretamente. + + + + Il Core Team. FreeBSD e NetBSD + hanno ognuno un core team che gestisce il progetto. I + core team si sono modificati nel corso del progetto, ed i loro + ruoli non sempre sono ben definiti. Non è necessario essere + uno sviluppatore per far parte del core team, anche se è + normale che sia così. Le regole + per il core team variano da un progetto ad un altro, ma in + generale chi ne fa parte ha più autorità + nell'indirizzamento del progetto rispetto agli altri membri. + + + + Questa organizzazione differisce da Linux in vari modi: + + + + Nessuna persona controlla il contenuto del sistema. In + pratica, questa differenza è sopravvalutata, poiché + il Capo Architetto può richiedere che il codice sia + rimosso, ed anche nel progetto Linux viene permesso a + molte persone di effettuare cambiamenti. + + + + D'altra parte, c'è un deposito + centrale, un punto singolo dove è possibile trovare i + sorgenti dell'intero sistema, incluse tutte le vecchie + versioni. + + + + I progetti BSD mantengono l'intero Sistema + Operativo, non solo il kernel. Questa distinzione + è utile solo marginalmente: né BSD né Linux + sono utili senza applicazioni. Le applicazioni usate su BSD sono + spesso le stesse usate su Linux. + + + + Come risultato di un mantenimento formalizzato + di un singolo CVS per l'albero dei sorgenti, lo sviluppo di BSD + è chiaro, ed è possibile accedere ad ogni versione del + sistema dal numero di release o dalla data. + Il CVS permette anche aggiornamenti incrementali del sistema: ad + esempio, il repository di FreeBSD viene aggiornato più o meno + 100 volte al giorno. La maggior parte dei cambiamenti sono + piccoli. + + + + + + Release di BSD + + Ogni progetto BSD fornisce il sistema in tre + release differenti. Come per Linux, alle release + vengono assegnati dei numeri come 1.4.1 o 3.5. Inoltre, il numero di + versione ha un suffisso che indica il suo scopo: + + + + la versione di sviluppo del sistema è chiamata + CURRENT. FreeBSD assegna un numero + alla CURRENT, ad esempio FreeBSD 5.0-CURRENT. NetBSD usa uno + schema di denominazione leggermente differente + ed aggiunge un suffisso di una singola lettera che indica + i cambiamenti nell'interfaccia interna, ad esempio NetBSD + 1.4.3G. OpenBSD non assegna un numero + (OpenBSD-current). + Tutti gli sviluppi del sistema vanno in questo ramo. + + + + A intervalli regolari, tra le due e le quattro volte all'anno, i + progetti fanno uscire una versione RELEASE + del sistema, disponibile su CD-ROM e come libero download da siti + FTP, ad esempio OpenBSD 2.6-RELEASE o NetBSD 1.4-RELEASE. + La versione RELEASE è intesa per gli utenti finali ed + è la versione normale del sistema. NetBSD fornisce anche + patch release, versioni con solo piccole + correzioni, con una terza cifra, ad esempio NetBSD 1.4.2. + + + + Quando vengono trovati dei bug in una versione RELEASE, + vengono corretti, e le correzioni vengono aggiunte all'albero del + CVS. In FreeBSD, la versione risultante viene detta + STABLE, mentre in NetBSD ed OpenBSD continua + a chiamarsi RELEASE. Caratteristiche minori possono essere aggiunte + a questo ramo dopo un periodo di test nel ramo CURRENT. + + + + In contrasto, Linux mantiene due alberi di codice + differenti: la versione stabile e la versione di sviluppo. + Le versioni stabili hanno un numero di versione pari, come 2.0, 2.2 o + 2.4. Le versioni di sviluppo hanno numero di versione dispari, come + 2.1, 2.3 o 2.5. In ogni caso, il numero è seguito da un + ulteriore numero che indica la versione esatta. Inoltre, ogni + venditore aggiunge i suoi programmi utente o le sue utilità, + dunque anche il nome della distribuzione è importante. Ogni + venditore di distribuzione assegna anche un numero di versione alla + distribuzione, dunque una descrizione completa dovrebbe essere una + cosa del tipo TurboLinux 6.0 con kernel + 2.2.14 + + + + Quali versioni di BSD sono disponibili? + + In contrasto alle numerose distribuzioni Linux, ci sono solo + tre BSD open source. Ogni progetto BSD mantiene il suo albero dei + sorgenti ed il suo kernel. In pratica, comunque, ci sono meno + divergenze tra i codici dei programmi utente dei vari progetti di quante + ce ne siano in Linux. + + È difficile catalogare gli obiettivi di ogni progetto: + le differenze sono molto soggettive. Di base, + + + + FreeBSD punta alle alte prestazioni e alla facilità d'uso + per l'utente finale, ed è molto usato dai fornitori di + contenuti web. Funziona su PC e processori Alpha della Compaq. + Il progetto FreeBSD ha nettamente più utenti degli + altri. + + + + NetBSD punta alla massima portabilità: of course + it runs NetBSD, ovviamente ci gira NetBSD. + Funziona su macchine che vanno dai palmtop ai grossi + server, ed è anche stato usato dalla NASA in alcune missioni + spaziali. È una scelta particolarmente buona per il vecchio + hardware non Intel. + + + + OpenBSD punta alla sicurezza e alla purezza del codice: usa una + combinazione dei concetti open source e un rigoroso controllo + del codice per creare un sistema la cui correttezza sia + dimostrabile, rendendolo la scelta di organizzazioni attente alla + sicurezza come banche, borse e dipartimenti del governo + statunitense. + Come NetBSD, funziona su un gran numero di piattaforme. + + + + Ci sono anche altri due sistemi operativi BSD che non sono open + source, BSD/OS e il Mac OS X della Apple: + + + + BSD/OS è il più antico dei derivati di 4.4BSD. + Non è open source, anche se licenze per il codice sorgente + sono disponibili ad un costo relativamente basso. Assomiglia a + FreeBSD in molti sensi. + + + + Mac OS + X è l'ultima versione del sistema operativo per + la linea Macintosh della Apple + Computer Inc.. Diversamente dal resto del sistema + operativo, il kernel è open source. Come parte di questo + sviluppo, gli sviluppatori chiave della Apple hanno accesso come + committer all'albero dei sorgenti di FreeBSD. + + + + + + Come differisce la licenza BSD dalla GNU Public? + + Linux è disponibile con licenza GNU General Public + License (GPL), che è pensata per eliminare il software + closed source. In particolare, ogni lavoro derivante da un prodotto + rilasciato sotto GPL deve essere fornito anche con il codice sorgente, + se richiesto. Al contrario, la licenza + BSD è meno restrittiva: le distribuzioni dei soli + binari sono permesse. Ciò è particolarmente attraente per + le applicazioni embedded. + + + + Cos'altro dovrei sapere? + + Poiché sono disponibili meno applicazioni per BSD che per + Linux, gli sviluppatori BSD hanno creato un pacchetto di + compatibilità con Linux, che permette ai programmi per Linux di + funzionare su BSD. Il pacchetto include sia modifiche al kernel, in + modo da permettere l'esecuzione corretta di chiamate di sistema + Linux, che file di compatibilità, come la libreria C. Non + c'è una differenza notevole nella velocità di esecuzione + tra una applicazione in esecuzione su una macchina Linux ed una + applicazione in esecuzione su una macchina BSD con pari + caratteristiche. + + La natura tutto da una sola fonte di BSD fa sì + che gli aggiornamenti siano molto più semplici da gestire + rispetto alla maggior parte dei casi in Linux. BSD gestisce gli + aggiornamenti della versione di libreria fornendo moduli di + compatibilità per le versioni precedenti, dunque è + possibile eseguire binari di parecchi anni prima senza problemi. + + + + Cosa dovrei usare, BSD o Linux? + + Cosa significa tutto questo in pratica? Chi dovrebbe usare BSD, chi + dovrebbe usare Linux? + + Questa è una domanda molto difficile a cui rispondere. Qui + ci sono alcune linee guida: + + + + Se non è rotto, non aggiustarlo: se usi + già un sistema operativo open source, e ne sei soddisfatto, + probabilmente non c'è ragione di cambiare. + + + + I sistemi BSD, in particolare FreeBSD, possono avere prestazioni + notevolmente migliori di Linux. Ma questo non avviene in tutti i + campi. In molti casi, c'è una differenza minima nelle + prestazioni. In alcuni casi, Linux può comportarsi meglio di + FreeBSD. + + + + In generale, i sistemi BSD hanno una reputazione migliore di + affidabilità, principalmente come risultato di una base di + codice più maturo. + + + + La licenza BSD può essere più attraente della + GPL. + + + + BSD può eseguire codice Linux, mentre Linux non + può eseguire codice BSD. Come risultato, c'è + più software disponibile per BSD che per Linux. + + + + + + Chi fornisce supporto, servizi, e training su BSD? + + BSD ha sempre supportato BSD/OS, e recentemente ha + annunciato contratti di supporto per FreeBSD. + + Inoltre, ognuno dei progetti ha una lista di consulenti a pagamento: + FreeBSD, + NetBSD, + e OpenBSD. + + +
+ + diff --git a/it_IT.ISO8859-15/articles/multi-os/Makefile b/it_IT.ISO8859-15/articles/multi-os/Makefile new file mode 100644 index 0000000000..886e21cc9d --- /dev/null +++ b/it_IT.ISO8859-15/articles/multi-os/Makefile @@ -0,0 +1,14 @@ +# $FreeBSD$ + +DOC?= article + +FORMATS?= html + +INSTALL_COMPRESSED?=gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/it_IT.ISO8859-15/articles/multi-os/article.sgml b/it_IT.ISO8859-15/articles/multi-os/article.sgml new file mode 100644 index 0000000000..d805111b84 --- /dev/null +++ b/it_IT.ISO8859-15/articles/multi-os/article.sgml @@ -0,0 +1,761 @@ + + + +%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 Jordan K. Hubbard + jkh@time.cdrom.com + + 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, HPFS, FFS (FreeBSD), ed EXT2 + (Linux). Farà anche partire partizioni FAT32. 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 filesystem FAT incluso nella Release + Beta SR2 di Microsoft, che dovrebbe essere installata + con Windows 95 a partire dalla fine del 1996. Converte il + normale filesystem 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 megabyte + (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 mega 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 528mb in un disco ipotetico, + il mio, di 720mb). 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 filesystem, 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 filesystem. + 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. + + 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. + + 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. + + + +
-- cgit v1.2.3