Vorbereitung:

• Syntakisch korrektes HTML. Insbesondere sollen geschachtelte Listen innerhalb des Elements der übergeordneten Liste stehen, nicht danach. Dieser Fehler in HTML-SourceCode wird von Netscape Composer erzeugt und von weblint nicht erkannt. Wird er nicht behoben, bringt normalize durch Einfügen von EndTags die Gliederung durcheinander.
• HTML, in dem nicht manuell ein anderes Einrückungsschema als das von normalize verwendet wurde. Dieses würde verworfen, so dass man besser grundsätzlich keine anderen Schemata verwendet.
• Man darf HTML-Source unordentlich schreiben und lässt sie gelegentlich von normalize ordnen. Das macht das Schreiben von HTML-Source effizient!

Aufruf von:

Dabei nie für input.html und output.html denselben Dateinamen verwenden, sonst ist diese Datei nach normalize 0 Byte lang. Durch normalize werden alle Bezeichner im HTML-Code in Kleinbuchstaben geschrieben.

Dies kann zum Beispiel notwendig sein, wenn auf eine Testinstallation einer Internetseite zugegriffen werden soll, deren Name noch nicht in den »offiziellen« Nameservern verzeichnet ist. Etwa weil ein KK-Umzug der Domain noch nicht abgeschlossen ist. Manchmal kann man in solchen Fällen statt dem Domainnamen die IP-Adresse angeben, das funktioniert jedoch nicht wenn der Server virtual hosting verwendet. In solch einem Fall setze man den Server oder einen anderen Server als DNS-Server so auf, dass der Name korrekt aufgelöst wird, und trägt dann diesen Server als alleinigen Nameserver in /etc/resolv.conf ein. Es ist nicht möglich, nur für eine einzige Domain einen besonderen Nameserver zu verwenden. Auch ist es aufgrund divergierender Nameserver-Einträge (wobei man den Eintrag auf einem ganz bestimmten Nameserver benötigt) nicht möglich, mehrere Zeilen in /etc/resolv.conf einzutragen. Denn der erste Eintrag wird zwar bevorzugt behandelt (etwas früher kontaktiert), parallel werden aber auch die anderen Nameserver kontaktiert und die erste Antwort wird verwendet. Von wem sie stammt, ist nicht determiniert.
Der Eintrag in resolv.conf ist sofort wirksam und wird automatisch (auf einem Debian-System) wieder gelöscht bei der Neukonfiguration der Netzwerkkarte (z.B. mit ifup).

Nur wenn dieses DVD-Laufwerk beim Booten des Systems eingesteckt war, kennt das System die Laufwerksparameter dieses Laufwerks und kann es mounten. Bootet man mit Akku im UltraBay 200 Schacht, erscheint eine Fehlermeldung wie »/dev/hdc: no such file or device« in den Bootmeldungen. Wenn man aber stets mit dem Laufwerk bootet, kann man es auch stets mounten, selbst wenn zwischenzeitlich während der Laufzeit des Systems mal stattdessen der Akku eingesteckt war.

Nur über den Hardware-Mixer (d.h. über die drei Tasten rechts neben der ThinkPad-Sondertaste). Bisher ist keine Möglichkeit bekannt, diese Lautstärke über den Software-Mixer (bei Verwendung der ALSA-Treiber) einzustellen.

Problem: im vorliegenden lokalen Netzwerk fungiert eine FritzBox! FON WLAN als DHCP-Server und Nameserver. Sie zeigt die vorliegenden IP/Namenszuordnungen im Bereich »System -> Netzwerkgeräte« korrekt an. Auf einem angeschlossenen Computer sind diese Zuordnungen jedoch falsch:

• »ping name_1« führt zu 192.168.178.22 statt 192.168.178.20 wie in der FritzBox! angegeben. 192.168.178.20 ist ein WLAN-Netzwerkgerät. Sogar trotz dass »hostname« ausgibt, »name_1« sei der Rechnername des aktuellen Rechners (also der mit 192.168.178.20)!
• »ping name_2« ergibt »ping: unknown host name_2« trotz dass in der FritzBox! 192.168.178.22 als zugehörige IP-Adresse angegeben ist. 192.168.178.20 ist Netzwerkgerät, das über kabelgebundenes Netzwerk angebunden ist.

Die Neukonfiguration des lokalen Rechners über DHCP passiert, wenn man ein Netzwerkdevice (zu dem Konfiguration über dhcp in /etc/network/interfaces angegeben ist) neu konfiguriert, z.B. »ifdown eth1; ifup eth1=wlan_name«. Neukonfigurieren des Netzwerk-Devices wurde in der FritzBox! auch als Neuanmeldung des entsprechenden WLAN-Devices registriert.

Den toten symbolischen Link »/etc/dhcpc/resolv.conf -> /var/lib/dhcpc/resolv.conf« auf das korrekte Ziel
/etc/resolv.conf zu ändern behob das Problem nicht. Es scheint, dass die FritzBox! manchmal gar nicht als Nameserver verwendet wird, trotz dass dies so angegeben ist in /etc/resolv.conf: »nameserver 192.168.178.1«.
Jedoch manchmal schon: »ping fritz.box« löst den Namen zu 192.168.178.1 auf und alle Namen im Internet werden korrekt aufgelöst.

Das Problem könnte also bei resolvconf zu suchen sein. Ein einfacher Neustart »/etc/init.d/resolvconf restart« oder ein Neustart des gesamten Systems ergab jedoch keine Änderung. Es könnte sein, dass zuerst der Nameserver auf dem lokalen System versucht wird, der (für ihm bekannte Namen) falsche Informationen liefert. Etwa weil es ein Nameserver-Cache wie dnsmasq oder pdnsd ist, der noch Informationen zwischengespeichert hat, die gültig waren als sich der Computer (hier ein Notebook) in einer anderen Umgebung befand. Das war im vorliegenden Fall jedoch nicht das Problem, da kein DNS-Cache installiert war und der lokale DNS-Server nicht verwendet wird, wenn mindestens ein »nameserver«-Eintrag in /etc/resolv.conf besteht. Das Problem könnte also an der FritzBox! liegen.

Ein Neustart der FritzBox! erbrachte tatsächlich eine Verbesserung: der Hostname »name_2« wird jetzt gefunden, aber umgeleitet an den Hostnamen name_2:

Der Hostname »name_1« wird weiterhin falsch aufgelöst:

Insgesamt ist das Problem jetzt nur noch: falsche DNS-Einträge zum jeweils eigenen Hostnamen. Von anderen Hosts aus wird dieser Hostname jedoch jeweils korrekt aufgelöst, das heißt das noch vorhandene Problem liegt nicht am externen Nameserver (der FritzBox!), sondern wohl am lokalen Nameserver. Bei Reverse-DNS-Lookups wirkt sich das Problem nur aus, wenn zufällig der eigene Rechnername fälschlicherweise mit einer IP-Adresse verbunden ist, die einem anderen Rechner im Netzwerk gehört. Das heißt, der lokale Nameserver wird jeweils vor dem externen Nameserver kontaktiert, auch bei Reverse-DNS-Lookups.

Der lokale Nameserver wird über /etc/hosts konfiguriert. Vielleicht stehen hier noch alte Einträge, die aus einer Zeit vor Umstellung auf DHCP stammen? Wenn ja, lösche man diese und das Problem ist gelöst.

Zuerst einmal muss diese Auflösung in /etc/X11/XF86Config-4 eingestellt werden. Einfache Möglichkeit: man löscht alle Auflösungen höher als 800×600 aus allen Mode-Zeilen aller Subsections der verwendeten Screen-Section. Außerdem muss man mit Hilfe von Fn+F7 derart auf den externen Monitor umschalten, dass der interne Monitor abgeschaltet ist. Ansonsten wird wieder per Hardware auf die Auflösung des internen Monitors interpoliert (z.B. von 800×600 auf 1024×768) und diese interpolierte Auflösung am externen Monitorausgang zur Verfügung gestellt.

Man verwende »dpkg -i «. »apt-get install « dagegen dient dazu, Pakete aus Archiven zu installieren. Diese können sich zwar auch in Verzeichnissen des lokalen Systems befinden, jedoch müssen diese Verzeichnisse eine bestimmte Struktur aufweisen (Paketlisten usw.), so dass es wesentlich einfacher ist, »dpkg -i« zu verwenden.