<chapter id="error-chapter">
<title>Fouten, Bugs en andere onvolkomenheden</title>

<blockquote>
<attribution>Doug Gwyn</attribution>
<literallayout>
&unix; was never designed to keep people from doing stupid things,
because that policy would also keep them from doing clever things.
</literallayout>
</blockquote>

<sect1 id="prevent-errors"><title>Fouten Voorkomen</title>
<para>
Veel gebruikers geven, vaak door hun eigen toedoen, op een gegeven moment aan
gefrustreerd te raken van het &unix;-besturingssysteem. Een faciliteit van het
&unix; besturingssysteem die veel gebruikers prettig vinden wanneer
ze lekker aan het werken zijn en haten na een sessie in de late avond
is hoe zeer weinig opdrachten vragen om bevestiging.
Wanneer een gebruiker wakker is en goed functioneert wordt hier zelden
over nagedacht, en het is een pluspunt, want het laat hem/haar het werk
vlotter doen.
</para>

<para>
Er zijn echter een aantal nadelen. <command>rm</command> en 
<command>mv</command> vragen nooit
om bevestiging en dit leidt vaak tot problemen.
Laten we dus een kleine lijst doornemen die er toe bij zou kunnen dragen
een algehele catastrofe te voorkomen:

<itemizedlist>
<listitem><para>
 Houd backups bij! Dit geldt vooral voor die ene gebruiker van het
systeem. Alle systeembeheerders zouden regelmatig backups van hun systeem
moeten maken! E&eacute;nmaal per week is voldoende om heel wat bestanden 
te redden. Zie voor meer informatie de &ldpsa;.
</para></listitem>
<listitem><para>
Individuele gebruikers zouden zo mogelijk hun eigen backups bij
moeten houden. Als je regelmatig meer dan &eacute;&eacute;n systeem gebruikt, 
probeer dan bijgewerkte kopie&euml;n van al je bestanden op ieder systeem 
bij te houden. Als je toegang hebt tot een diskettestation, wil je wellicht 
backups op diskettes aanmaken van je kritieke materiaal. Houd in het 
slechtste geval <emphasis>in een aparte directory</emphasis> extra 
kopie&euml;n bij van het belangrijkste materiaal van je account!
</para></listitem>
<listitem><para>
 Denk na over opdrachten, vooral "destructieve" opdrachten zoals 
<command>mv</command>, <command>rm</command> en <command>cp</command>
voordat je ook maar iets doet. Je moet ook
voorzichtig te werk gaan bij omleidingen (<command>></command>). 
Hiermee zullen je
bestanden worden overschreven als je niet oplet. Zelfs de meest onschuldige
opdrachten kunnen sinister worden:

<screen>
<prompt>/home/larry/report# </prompt><userinput> cp report-1992 report-1993 backups</userinput>
</screen>
</para>
<para>
kan eenvoudig op een ramp uitdraaien:
</para>
<para>
<screen>
<prompt>/home/larry/report# </prompt><userinput>cp report-1992 report-1993</userinput>
</screen>
</para></listitem>

<listitem><para>
 De auteur raadt je uit eigen ervaring tevens aan 's-avonds laat
niet aan bestandsbeheer te doen. Ziet je directorystructuur er om 1:32
's nachts wat rommelig uit? Laat het dan zoals het is. Een beetje rommel
heeft een computer nog nooit kwaad gedaan.
</para></listitem>
<listitem><para>
 Houd bij wat je huidige directory is. Soms geeft de prompt niet
de directory aan waarin je aan het werken bent, en slaat het gevaar toe.
Het is triest te moeten lezen in een bericht in 
<literal>comp.unix.admin</literal>
<footnote><para>Een internationale groep op Usenet, 
die gaat over het beheren van &unix;-computers.</para></footnote> dat 
een <literal>root</literal> gebruiker die zich in <filename>/</filename> 
bevond in plaats van in <filename>tmp</filename>!  Bijvoorbeeld:</para>

<para>
<screen>
<prompt>mousehouse> </prompt><userinput>pwd</userinput>
<computeroutput>/etc</computeroutput>
<prompt>mousehouse> </prompt><userinput>ls /tmp</userinput>
<computeroutput>passwd</computeroutput>
<prompt>mousehouse> </prompt><userinput>rm passwd</userinput>
</screen>
</para>

<para>
De hierbovenstaande serie opdrachten zou de gebruiker zeer ongelukkig
achterlaten, constaterend hoe zojuist het password bestand voor het
systeem werd verwijderd. Mensen kunnen zonder niet inloggen!
</para></listitem>
</itemizedlist>
</para>
</sect1>

<sect1 id="todo-when-wrong"><title>Wat te doen als er iets mis gaat</title>
<para>
Helaas worden voor programmeurs in de wereld niet alle problemen door
fouten van gebruikers veroorzaakt. &unix; en Linux zijn gecompliceerde
systemen, en alle bekende versies bevatten fouten. Soms zijn deze 
programmeerfouten moeilijk te vinden en verschijnen deze alleen onder 
bepaalde omstandigheden.
</para>

<para>
Ten eerste, wat is een fout? Een voorbeeld van een programmeerfout is wanneer je
de computer vraagt "5+3" te berekenen en het antwoordt met "7". Alhoewel 
dat een onbeduidend voorbeeld is van wat er mis kan gaan, bestaan de meeste 
fouten in computerprogramma's uit op &eacute;&eacute;n of andere uiterst 
vreemde manier toegepaste rekenkunde.
</para>

<sect2 id="its-an-error"><title>Wanneer het een fout is</title>
<para>
Als de computer een onjuist antwoord geeft (verifieer dat het antwoord
onjuist is!) of crasht, is het een fout. Als een programma vastloopt of
een besturingssysteemfoutmelding geeft, is het een fout.
</para>

<para>
Als een opdracht nooit eindigt met de uitvoering kan dit een fout zijn,
maar je moet er zeker van zijn dat je het niet opgaf het een lange tijd
te doen wat je wilde dat het deed. Vraag om hulp als je niet weet wat de
opdracht deed.
</para>

<para>
Een aantal meldingen zullen je van fouten op de hoogte brengen.
Een aantal meldingen zijn geen fouten. Kijk in de 
<xref linkend="kernel-messages"/> en enige andere documentatie om er
zeker van te zijn dat het geen gewone informatieve meldingen zijn.
Meldingen zoals bijvoorbeeld "disk full" of "lp0 on fire" zijn geen
softwareproblemen, maar iets dat mis is met je hardware, niet genoeg
diskruimte of een slechte printer.
</para>

<para>
Als je niets over een programma kunt vinden, dan is het een fout in
de documentatie, en zou je contact op moeten nemen met de auteur van
dat programma en aanbieden het zelf te schrijven. Als iets niet klopt
in bestaande documentatie<footnote><para>Vooral in deze documentatie!</para>
</footnote>, is dat
een fout in die handleiding. Als iets lijkt te ontbreken of onduidelijk is
in de handleiding, dan is dat een fout.
</para>

<para>
Als je met schaken niet van <application>gnuchess</application>
<indexterm><primary>gnuchess</primary></indexterm> kunt winnen,
is dat een leemte in je schaakalgoritme, maar niet noodzakelijk een
fout in je brein.
</para>
</sect2>

<sect2 id="error-reporting">
<title>Rapporteren van een fout</title>
<para>
Als je er zeker van bent dat je een fout hebt gevonden, dan is het van
belang dat deze informatie op de juiste plaats terechtkomt. Probeer
uit te zoeken welk programma de fout veroorzaakte. Als je het niet
kunt vinden, zou je hulp kunnen vragen in
<literal>comp.os.linux.help</literal> of <literal>comp.unix.misc</literal>. 
Lees de manual page om erachter te komen wie het schreef zodra je weet 
om welk programma het gaat.
</para>

<para>
De methode om foutverslagen te versturen die de voorkeur heeft in de Linux 
wereld is via elektronische mail. Als je geen toegang hebt tot
elektronische mail, dan kun je contact opnemen met degene van wie je
Linux hebt. Het kan zelfs zijn dat je geen andere keus hebt dan
contact op te nemen met iemand bij wie je kunt mailen, of met iemand
die Linux commercieel verkoopt en die om die reden zoveel mogelijk fouten
wil verwijderen. Denk er echter aan dat niemand verplicht is enige fouten te
corrigeren, tenzij je een contract hebt!
</para>

<para>
Voeg bij het versturen van een foutverslag alle informatie in waaraan
je maar denkt. Hieronder valt:
<itemizedlist>
<listitem><para>
 Een beschrijving van wat je denkt dat niet juist is. Zoals bijvoorbeeld:
"Ik krijg 5 wanneer ik 2+2 bereken" of "Ik krijg de melding 
<errorname>segmentation violation -- core dumped</errorname>." 
Het is van belang dat je exact aangeeft wat er gebeurt zodat de beheerder
het kan corrigeren!
</para></listitem>
<listitem><para>
Voeg alle relevante omgevingsvariabelen in.
</para></listitem>
<listitem><para>
De kernelversie (zie het bestand <filename>/proc/version</filename>)
en je systeemlibrary's (zie de directory <filename>/lib</filename>; stuur een
listing van <filename>/lib</filename> als je het niet kunt ontcijferen).
</para></listitem>
<listitem><para>
 Hoe je het programma in kwestie draaide, of als het een kernelfout
was, wat je op dat moment aan het doen was.
</para></listitem>
<listitem><para>
<emphasis>Alle</emphasis> extra informatie. Het kan bijvoorbeeld zijn dat 
de opdracht <command>w</command><indexterm><primary>w</primary></indexterm> 
het huidige proces niet laat zien voor bepaalde gebruikers. Zeg dan niet 
slechts, "<command>w</command> werkt niet voor 
een bepaalde gebruiker". De fout zou kunnen plaatsvinden omdat de naam 
van de gebruiker uit 8 tekens bestaat, of wanneer hij inlogt via het netwerk.
Geef in plaats daarvan aan, "<command>w</command> laat het huidige proces 
voor gebruiker <literal>greenfie</literal> niet zien wanneer hij via 
het netwerk inlogt."
</para></listitem>
<listitem><para>
En denk eraan, blijf beleefd. De meeste mensen werken voor hun plezier
aan vrije software, en omdat ze hun hart op de goede plaats hebben zitten.
Verknal het niet voor hen. De Linux gemeenschap heeft reeds teveel
ontwikkelaars gedesillusioneerd, en Linux bevindt zich nog maar in een
vroeg stadium!
</para></listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
</chapter>
<!--
% Local Variables: 
% mode: latex
% TeX-master: "guide"
% End: 
-->