Fix style and spell errors.

1 files changed, 12 insertions, 13 deletions

diff --git a/document.asciidoc b/document.asciidoc
index 12a160d..e8580f0 100644
--- a/document.asciidoc
+++ b/document.asciidoc
@@ -81,7 +81,7 @@ Als Parameter bekommt die Funktion die Startadressen von Quelle und Ziel im
 Speicher.
 Der Funktion ist dabei die Groesse der jeweiligen Speicherplaetze nicht bekannt.
 Es wird nun eine Speicherzelle nach der Anderen kopiert, solange bis in der
-Quelle ein NUL-Byte auftaucht.
+Quelle ein Null-Byte auftaucht.
 Dabei kann die Funktion weder sicherstellen, dass sie nicht ueber den
 Quellpuffer hinaus Bytes kopiert, sowie dass sie nicht ueber die Grenzen des
 Zielpuffers hinaus schreibt.
@@ -173,16 +173,16 @@ und übergibt beim Start den Deskriptor für den Kommunikationskanal.
 
 Wenn nun zur Laufzeit weston ein Eingabe-Hotplug-Ereignis erhält
 und das Gerät öffnen möchte, so nutzt weston nicht -- wie andere Programme --
-open(2), denn um das Gerät direkt zu Öffnen fehlen die Rechte.
++open(2)+, denn um das Gerät direkt zu Öffnen fehlen die Rechte.
 Stattdessen wird eine Nachricht über den Kommunikationskanal gesendet,
 die mit einem OpCode beschreibt, dass ein Gerät geöffnet werden soll,
-und als Parameter den Pfad zum Gerät, z.b. /dev/input/event0 enthält.
+und als Parameter den Pfad zum Gerät, z.b. +/dev/input/event0+ enthält.
 Weston-launch empfängt diese Anfrage und prüft, ob es ein zur Öffnung erlaubter
-Pfad ist (z.B. beginnend mit /dev/input/).
+Pfad ist (z.B. beginnend mit +/dev/input/+).
 Falls erlaubt, wird das Gerät geöffnet und der Deskriptor über den
 Kommunikationskanal als Socket-Control-Message an ``weston'' als Antwort
 übertragen. Weston erhält damit einen Deskriptor, der sich nicht
-von einem durch direkten Aufruf von open(2) geöffneten unterscheidet.
+von einem durch direkten Aufruf von +open(2)+ geöffneten unterscheidet.
 // TODO: Ähnliches Szenario: DRM Set Master
 
 Weston läuft somit im User-Mode und kann bestimmte Operationen,
@@ -227,7 +227,7 @@ explizit gefiltert, um die Beeinflussung von anderen Prozessen zu verhindern.
 
 Um verschiedene Prozesse voneinander zu trennen, kann auch die
 UNIX-Rechte-Verwaltung verwendet werden.
-Jeder Service sollte unter einem separaten Nutzer-Konto laufen.
+Jeder Service sollte unter einem separaten Nutzerkonto laufen.
 Es sollte vermieden werden, mehrere Dienste mit den gleichen Nutzungsrechten
 auszuführen, da sich diese untereinander beeinflussen koennen.
 Sollte ein Dienst keine eigenen Dateien benoetigen, kann dieser unter dem
@@ -250,10 +250,9 @@ kommuniziert und wo sich die Kommumikationspartner befinden.
 Kommunikation innerhalb eines Hosts sollte ueber das Loopback-Interface
 oder UNIX-Domain-Sockets gefuehrt werden.
 Ein Dienst, welcher ueber das Loopback-Interface kommuniziert, kann von jedem
-Prozess erreicht werden, der einen Netzwerk-Socket oeffnen kann.
-//FIXME: Gibt es Programme, die keinen Socket öffnen können?
+Prozess erreicht werden.
 UNIX-Domain-Sockets sind an Dateien gebundene Verbindungen,
-mit den gewöhnlichen Berechtigungs-Parametern, durch die sich ueber die
+mit den gewöhnlichen Berechtigungsparametern, durch die sich ueber die
 systeminterne Benutzer- und Rechteverwaltung der Zugriff auf die Verbindung
 steuern lässt.
 //FIXME: geeignet?
@@ -266,7 +265,7 @@ fuer die verschiedensten Zwecke genutzt werden koennen.
 
 In jedem Fall sollte die Erreichbarkeit von Diensten soweit wie moeglich
 eingeschraenkt werden.
-Auch Tunnel-Techniken wie IPSec und andere VPN-Loesungen koennen verwendet
+Auch Tunneltechniken wie IPSec und andere VPN-Loesungen koennen verwendet
 werden, um einen Dienst ausschliesslich ausgewaehlten Nutzern zugaenglich
 zu machen.
 
@@ -288,7 +287,7 @@ das Gesamtsystem betrachtet.
 
 === Kernel-Architektur
 
-Die meisten Betriebssysteme verwenden ein monolitisches Kernel-Design.
+Die meisten Betriebssysteme verwenden ein monolithisches Kernel-Design.
 In diesem werden viele Aufgaben des Betriebssystems im Kernel erledigt.
 Das bedeutet, dass der Programm-Code mit sehr hohen Berechtigungen
 ausgefuehrt wird.
@@ -320,14 +319,14 @@ So werden z. B. Speicherbereichsverletzungen vom Prozessor erkannt.
 Ein fehlerhaft programmierter Treiber kann so nicht mehr das gesamte System
 gefaehrden.
 Dieses Kernel-Architektur hat grosse Performence-Nachteile gegenueber eines
-Monolitischen-Designs.
+monolithischen Designs.
 Denn will einen Anwendung Beispielsweise mit der ueber das Netzwerk ein Paket
 versenden, so muss fuer dieses Paket zwei mal der Userspace-Kernelspace-Kontext
 gewechselt werden.
 Dieses kostet enorm viel Zeit, da der gesamte Prozessorkontext fuer den
 Uebergang von Anwendung zum Kernel, sowie vom Kernel zum Netzwerkkartentreiber
 gesichert werden muss.
-In einem monolitischen Design gaebe es nur einen Kontextwechsel von zum Kernel,
+In einem monolithischen Design gaebe es nur einen Kontextwechsel von zum Kernel,
 welche das Netzwerkmodule enthaelt.
 Somit muss man an dieser Stelle Performence und Sicherheit abwiegen und fuer
 den konkreten Einzelfall entscheide welches wichtiger ist.