\chapter{Errori, bug ed altre spiacevolezze}\label{error-chapter}
  
  %\begin{quote}
  %UNIX non \`e stato mai progettato per prevenire che la gente faccia cose 
  %stupide, perch\'e questo gli impedirebbe di fare cose intelligenti.\\
  %\raggedleft Doug Gwyn
  %\end{quote}
  
  \section{Evitare gli errori }
  
  Molti utenti si sentono in alcune occasioni frustrati con il sistema 
  operativo \unix, spesso a causa del loro proprio comportamento. Una 
  caratteristica del sistema operativo \unix, che molti utenti amano 
  quando stanno lavorando bene, e odiano dopo una sessione a tarda notte 
  \`e che molto pochi comandi chiedono conferma. Quando l'utente \`e sveglio 
  ed ha la mente fresca, raramente ci pensa, ed \`e una cosa positiva perch\'e 
  il lavoro \`e pi\`u fluido.
  
  Ci sono per\`o degli svantaggi. {\tt rm} e {\tt mv} non chiedono mai 
  conferma, e spesso questo porta a dei problemi. Vediamo quindi una 
  piccola lista di ci\`o che vi pu\`o essere utile per evitare il disastro 
  totale:
  
  \begin{itemize}
  \item Fate delle copie di riserva! Vale specialmente per i sistemi 
  monoutente---tutti gli amministratori di sistema dovrebbero fare backup 
  regolari del loro sistema! Una volta alla settimana \`e sufficiente per 
  salvare molti file. Vedete \ldpsa\ per ulteriori informazioni.
  \item Gli utenti individuali dovrebbero tenere i propri backup, se 
  possibile. Se usate regolarmente pi\`u di un sistema, tentate di tenere 
  copie aggiornate di tutti i vostri file su ciascun sistema. Se avete 
  accesso ad un drive per floppy, dovreste fare dei backup su floppy del 
  materiale pi\`u critico. Alla peggio, tenete delle copie aggiuntive del 
  materiale pi\`u importante in giro per il vostro account {\em in una 
  directory separata\/}!
  \item Pensate ai comandi, specialmente quelli ``distruttivi'' come {\tt
   mv}, {\tt rm}, e {\tt cp} prima di agire. Attenzione alla
   la redirezione ({\tt >})---sovrascriver\`a i file se non state attenti. 
   Anche il comando pi\`u innocuo pu\`o diventare sinistro.
  \begin{screen}\begin{verbatim}
  /home/larry/report# cp report-1992 report-1993 backups
  \end{verbatim}\end{screen}
  pu\`o facilmente provocare un disastro.
  \begin{screen}\begin{verbatim}
  /home/larry/report# cp report-1992 report-1993
  \end{verbatim}\end{screen}
  \item L'autore raccomanda anche, dalla sua esperienza personale, di
  non fare manutenzione dei file a tarda notte. La struttura delle vostre
  directory sembra un po' confusionaria alle 1:32 di notte? Lasciatela
  com'\`e---un po' di confusione non fa male al computer.
  \item Tenete conto della directory in cui siete. Talvolta il prompt che
  usate non mostra in quale directory state lavorando, ed il pericolo \`e
  pronto a colpire. \`E triste leggere dei messaggi su
  {\tt comp.unix.admin}\footnote{Un gruppo di discussione internazionale su
  Usenet, che tratta dell'amministrazione dei computer \unix.} di un utente 
  {\tt root} che era in {\tt /} invece che in {\tt /tmp}!  Ad esempio:
    \begin{screen}\begin{verbatim}
  mousehouse> pwd
  /etc
  mousehouse> ls /tmp
  passwd
  mousehouse> rm passwd
  \end{verbatim}\end{screen}
  
  La serie di comandi riportata qui sopra renderebbe qualsiasi utente molto
  infelice, dato che rimuove il file delle password del sistema. Senza questo
  file, non ci si pu\`o loggare!
  \end{itemize}
  
  \section{Cosa fare quando qualcosa va storto}
  
  
  
  \section{Non \`e colpa vostra}
  
  Sfortunatamente per i programmatori di tutto il mondo, non tutti i problemi
  sono causati da errori degli utenti. UNIX e Linux sono sistemi
  complessi, e tutte le versioni note hanno dei bug. Talvolta questi sono
  difficili da scovare, ed appaiono solo in determinate circostanze.
  
  Per prima cosa, cos'\`e un bug? Un esempio di bug \`e se chiedete al computer di
  calcolare ``5+3'' e lui dice ``7''. Anche se \`e un esempio banale, la maggior
  parte dei bug nei programmi di computer dipendono in qualche strano modo
  dalla matematica.
  
  \subsection{Quando c'\`e un bug}
  
  Se il computer d\`a una risposta sbagliata (verificate che sia veramente
  sbagliata!) o crasha, \`e un bug. Se un qualsiasi programma crasha o d\`a un
  errore di sistema, \`e un bug.
  
  Se un comando non smette di girare pu\`o essere un bug, ma accertatevi che non
  gli abbiate chiesto di fare quello che deve fare in un tempo lungo. Chiedete
  aiuto se non sapete cosa doveva fare il programma.
  
  Alcuni messaggi vi avviseranno della presenza di bug; altri messaggi non
  sono bug. Controllate la Sezione~\ref{kernel-messages} e qualsiasi altra
  documentazione per controllare che non siano normali messaggi di
  informazione. A esempio, messaggi come ``disk full'' (``disco pieno'') o 
  ``lp0 on fire'' (``la porta lp0 va a fuoco'') non sono problemi software, ma
  qualcosa che non va con l'hardware---non c'\`e sufficiente spazio su disco, o
  ci sono problemi con la stampante.
  
  Se non riuscite a trovare niente su un programma, \`e un bug nella
  documentazione, e dovreste contattare l'autore del programma ed offrirvi di
  scriverla voi stessi. Se qualcosa non \`e corretto nella documentazione
  esistente\footnote{Specialmente questa!}, \`e un bug del manuale. Se qualcosa
  sembra incompleto o non chiaro nel manuale, \`e un bug.
  
  Se non riuscite a vincere {\tt gnuchess}\ttindex{gnuchess} a scacchi, \`e una
  pecca del vostro algoritmo scacchistico, non necessariamente un bug del
  vostro cervello.
  
  \subsection{Notificare un bug}\label{error-reporting}
  
  Quando siete sicuri di aver trovato un bug, \`e importante accertarsi che
  questa informazione arrivi a chi di dovere. Cercate di scoprire quale
  programma sta causando il bug---se non ci riuscite, forse potete chiedere
  aiuto in {\tt comp.os.linux.help} o in {\tt comp.unix.misc}. Trovato il
  programma, leggete la pagina man per vedere chi l'ha scritto.
  
  Il metodo preferito di spedire le notifiche di bug nel mondo Linux \`e via
  posta elettronica. Se non avete accesso ad una casella di posta elettronica,
  potete contattare chi vi ha fornito \linux---alla fine dovrete trovare
  qualcuno che ha la posta elettronica, o che vende Linux commercialmente e
  quindi vuole rimuovere quanti bug possibili. Ricordatevi per\`o che nessuno \`e
  costretto ad eliminare bug a meno che non abbiate un contratto!
  
  Quando mandate una notifica di bug, includetevi tutte le informazioni che vi
  vengono in mente, compreso:
  \begin{itemize}
  \item Una descrizione di quello che pensate sia sbagliato. Ad esempio, 
    ``Mi d\`a 5 quando faccio 2+2'', e ``Dice {\tt segmentation
      violation -- core dumped}.'' \`E importante dire esattamente quello che
  accade, in modo che venga risolto il {\em vostro\/} bug!
  \item Includete qualsiasi variabile d'ambiente rilevante.
  \item La versione del kernel (vedere il file {\tt /proc/version})
  e delle librerie di sistema (vedere la directory {\tt /lib}---se non
  riuscite a decifrarla, mandate un elenco del contenuto di {\tt /lib}).
  \item Come facevate girare il programma in questione, o, se \`e un bug del
  kernel, quello che stavate facendo.
  \item {\bf Tutte} le informazioni secondarie. Ad esempio, il comando
    {\tt w}\ttindex{w} pu\`o non mostrare il processo corrente per alcuni utenti.
    Non dite semplicemente ``{\tt w} non funziona per un determinato utente''.
  Il bug pu\`o avvenire perch\'e il nome dell'utente \`e lungo pi\`u di 8 caratteri, o
  quando si collega attraverso la rete. Dite invece ``{\tt w} non mostra il
  processo corrente per l'utente {\tt greenfie} quando si collega via rete''.
  \item E, ricordatevi, siate educati. La maggior parte di chi lavora sul free
  software lo fa per il gusto di farlo, e perch\'e hanno dei cuori grandi cos\`{\i}.
  Non gli rovinate tutto---la comunit\`a Linux ha gi\`a distrutto le illusioni
  di troppi sviluppatori, ed \`e ancora agli inizi!
  \end{itemize}
  
  % Local Variables: 
  % mode: latex
  % TeX-master: "guide"
  % End: 
  
