Fix typos in assignment

10 files changed, 78 insertions, 78 deletions

diff --git a/doc/class-assignment/fsverify.pdf b/doc/class-assignment/fsverify.pdf
index aec0e07..0cc00b3 100644
--- a/doc/class-assignment/fsverify.pdf
+++ b/doc/class-assignment/fsverify.pdf
diff --git a/doc/class-assignment/idee/gewaehlte_implementation.tex b/doc/class-assignment/idee/gewaehlte_implementation.tex
index 38f5b5c..c41a763 100644
--- a/doc/class-assignment/idee/gewaehlte_implementation.tex
+++ b/doc/class-assignment/idee/gewaehlte_implementation.tex
@@ -1,15 +1,15 @@
 \subsection{Gewählte Implementation}
-Im anbetracht existierender Dateiverifizierungsprogrammen wie Androids dm-verity und mein vorheriges, ähnliches Projekt \href{https://github.com/linux-immutability-tools/FsGuard}{FsGuard}.
+In Anbetracht existierender Dateiverifizierungsprogramme wie Androids dm-verity und mein vorheriges, ähnliches Projekt \href{https://github.com/linux-immutability-tools/FsGuard}{FsGuard}.
 \\
-Für die Implementation habe ich die Blockverifizierung ausgewählt, da sie durch Multithreading sehr schnell sein kann, aber auch neue Datein bemerkt, welches die Per-Datei Verifizierung nicht gewährleistet.
+Für die Implementation habe ich die Blockverifizierung ausgewählt, da sie durch Multithreading sehr schnell sein kann, aber auch neue Dateien bemerkt, welche die Per-Datei-Verifizierung nicht gewährleistet.
 \\
-Um die Hashes zu Speichern wird ein eigenes Partitionsschema benutzt, welches alle Metadaten und die Datenbank beinhaltet. Der minisign öffentliche Schlüssel kann durch mehrere Methoden gespeichert werden, wie einer Textdatei oder einem gerät welches über USB-Serial den Schlüssel übergibt.
+Um die Hashes zu speichern, wird ein eigenes Partitionsschema benutzt, welches alle Metadaten und die Datenbank beinhaltet. Der minisign öffentliche Schlüssel kann durch mehrere Methoden gespeichert werden, wie einer Textdatei oder einem Gerät, welches über USB-Serial den Schlüssel übergibt.
 \\
-Weitere Eintscheidungen für die Implementation sind:
+Weitere Entscheidungen für die Implementation sind:
 \begin{itemize}
 \item Programmiersprache: go\\
-  go ist mir vertraut und memory safe, welches für die Sicherheit des Programmes eine große Rolle spielt.
+  go ist mir vertraut und Memory Safe, welches für die Sicherheit des Programmes eine große Rolle spielt.
 \item Datenbank: bbolt\\
-  bbolt ist eine Datenbank welche direkt in go geschrieben wurde und somit ein Robusteren API als sqlite hat, zudem ist bbolt unter einer richtigen lizens lizensiert und wirkt moderner.
+  bbolt ist eine Datenbank, welche direkt in go geschrieben wurde und somit eine robustere API als sqlite hat; zudem ist bbolt unter einer richtigen Lizenz lizenziert und wirkt moderner.
 \end{itemize}
   
diff --git a/doc/class-assignment/idee/hashquellen.tex b/doc/class-assignment/idee/hashquellen.tex
index 5d6e3c1..130d06b 100644
--- a/doc/class-assignment/idee/hashquellen.tex
+++ b/doc/class-assignment/idee/hashquellen.tex
@@ -1,21 +1,21 @@
 \subsection{Hash Quellen}
 Wie bereits gesagt, braucht das Verifizierungsprogramm eine vertraute Quelle für die korrekten Hashes.
-Hier gibt es auch verschiedene Lösungsansätze, was jedoch alle gemeinsam haben ist, dass sie eine Quelle und eine sichere Methode um diese Quelle zu verifizieren brauchen.
+Hier gibt es auch verschiedene Lösungsansätze, was jedoch alle gemeinsam haben ist, dass sie eine Quelle und eine sichere Methode, um diese Quelle zu verifizieren, brauchen.
 \\
-Für die Quellen gibt es viele verschieden möglichkeiten, bei der Entwicklung von fsverify hatte ich die Wahl auf zwei möglichkeiten begrenzt, da beide sehr einfach zu implementieren sind, und dadurch die Verifizierung der Quellen auch einfach ist.
+Für die Quellen gibt es viele verschiedene Möglichkeiten; bei der Entwicklung von fsverify hatte ich die Wahl auf zwei Möglichkeiten begrenzt, da beide sehr einfach zu implementieren sind und dadurch die Verifizierung der Quellen auch einfach ist.
 \begin{description}
 \item[Externe Partition]
-  Hier wird eine Datenbank an Hashes zusammen mit allen Metadaten in eine extra Partition geschrieben, diese Partition kann auf ein Externes medium geschrieben werden, und nur dann angeschlossen sein, wenn das System die Verizifizierung durchführt.
-  Jedoch braucht dies entweder eine seperate Partition auf der Festplatte, wodurch die nutzbare Speicherkapazität sich verringert, oder ein externes Medium, welches nicht immer vorhanden ist.
+  Hier wird eine Datenbank an Hashes zusammen mit allen Metadaten in eine extra Partition geschrieben; diese Partition kann auf ein externes Medium geschrieben werden und nur dann angeschlossen sein, wenn das System die Verifizierung durchführt.
+  Jedoch braucht dies entweder eine separate Partition auf der Festplatte, wodurch die nutzbare Speicherkapazität sich verringert, oder ein externes Medium, welches nicht immer vorhanden ist.
 \item[Einfache Datei]
-  Hier wird die Datenbank einfach in einem Ort gespeichert, auf die das Program während der Verifizierung zugreifen kann. Dies ist sehr einfach zu implementieren und benötigt keine externen Partitionen oder Speichermedien. Das Problem ist es jedoch, die Datei an einem ort zu speichern, bei der man nicht unverifizierte Dateisysteme anhängen muss oder ungeschützt ohne schreibschutz offen ist.
+  Hier wird die Datenbank einfach in einem Ort gespeichert, auf den das Programm während der Verifizierung zugreifen kann. Dies ist sehr einfach zu implementieren und benötigt keine externen Partitionen oder Speichermedien. Das Problem ist es jedoch, die Datei an einem Ort zu speichern, bei der man nicht unverifizierte Dateisysteme anhängen muss oder ungeschützt ohne Schreibschutz offen ist.
 \end{description}
 \pagebreak
-Um die Quelle zu schützen beziehungsweise zu Verifizieren, gibt es zwei Methoden:
+Um die Quelle zu schützen beziehungsweise zu verifizieren, gibt es zwei Methoden:
 \begin{description}
 \item[Kryptographische Verifizierung]
-  Die Entwickler des Betriebssystems müssen hierbei bei dem aufsetzen des Verifizierungsprogramms die Hash Quelle Kryptographisch mit ihren privaten Schlüsseln signieren (zum Beispiel mit GnuPG oder Minisgin), das Verifizierungsprogramm erhält den öffentlischen Schlüssel der Entwickler, die Signatur und die Quelle, wodurch es anhand der Signatur verifizieren kann, dass die Quelle von den Entwicklern stammt und nicht modifiziert wurde.\\
+    Die Entwickler des Betriebssystems müssen hierbei bei dem Aufsetzen des Verifizierungsprogramms die Hash Quelle kryptografisch mit ihren privaten Schlüsseln signieren (zum Beispiel mit GnuPG oder Minisgin), das Verifizierungsprogramm erhält den öffentlichen Schlüssel der Entwickler, die Signatur und die Quelle, wodurch es anhand der Signatur verifizieren kann, dass die Quelle von den Entwicklern stammt und nicht modifiziert wurde.\\
   Hierbei ist das größte Problem, dass der öffentliche Schlüssel gut geschützt werden muss, damit die Signatur und Schlüssel nicht mit der eines Attackers ersetzt werden kann.
 \item[Verschlüsselung]
-  Die Quelle ist mit einem zufällig generierten Schlüssel verschlüsselt, welcher in dem Quellcode des Verifizierungsprogrammes geschrieben wird, um somit den Schlüssel direkt im Programm zu speichern. Dadurch können keine Schlüssel ersetzt werden, jedoch ist es immer möglich, den Schlüssel aus dem Programm zu extrahieren, ohne überhaupt auf das System zugreifen zu müssen, da man das Betriebssystem selber installieren kann. Sobald der Schlüssel bekannt ist, kann die Datei einfach verschlüsselt und ohne Probleme modifiziert werden.
+  Die Quelle ist mit einem zufällig generierten Schlüssel verschlüsselt, welcher in den Quellcode des Verifizierungsprogramms geschrieben wird, um somit den Schlüssel direkt im Programm zu speichern. Dadurch können keine Schlüssel ersetzt werden, jedoch ist es immer möglich, den Schlüssel aus dem Programm zu extrahieren, ohne überhaupt auf das System zugreifen zu müssen, da man das Betriebssystem selber installieren kann. Sobald der Schlüssel bekannt ist, kann die Datei einfach verschlüsselt und ohne Probleme modifiziert werden.
 \end{description}
diff --git a/doc/class-assignment/idee/idee.tex b/doc/class-assignment/idee/idee.tex
index e8c0092..717ca72 100644
--- a/doc/class-assignment/idee/idee.tex
+++ b/doc/class-assignment/idee/idee.tex
@@ -1,9 +1,9 @@
-Die Idee einer Dateisystem verifizierung ist nichts neues, oft wird sie in embedded geräten oder handys implementiert, wo die sicherheit und integrität des systems von großer bedeutung ist.
-Jedoch ist sie bei Desktop betriebssystemen wie Windows, MacOS oder Linux Distributionen nicht sehr herkömmlich. Dies liegt meißt daran, dass eine effektive verifizierung des Dateisystems sich darauf verlässt, dass das Dateisystem sich nicht über zeit verändert, welches man bei Desktop-Betriebssystemen nicht gewährleisten kann, da Programme oft direkt in den Root des Betriebssystems schreiben (/usr in *nix, C:/Program Files in windows).
+Die Idee einer Dateisystemverifizierung ist nichts Neues; oft wird sie in embedded Geräten oder Handys implementiert, wo die Sicherheit und Integrität des Systems von großer Bedeutung sind.
+Jedoch ist sie bei Desktop-Betriebssystemen wie Windows, macOS oder Linux Distributionen nicht sehr herkömmlich. Dies liegt meist daran, dass eine effektive Verifizierung des Dateisystems sich darauf verlässt, dass das Dateisystem sich nicht über Zeit verändert, welches man bei Desktop-Betriebssystemen nicht gewährleisten kann, da Programme oft direkt in den Root des Betriebssystems schreiben (/usr in *nix, C:/Program Files in Windows).
 \\
-Mittlerweile gibt es jedoch in der Linux-welt eine neue art von Distribution, die sogenannten 'Immutable' Distributionen, welche sich darin unterscheiden, dass der Root schreibgeschützt ist, oder wie bei NixOS oder Gnu GUIX garnicht erst richtig existiert. Dadurch können Programme nur direkt in den Homeordner des Nutzers installiert werden, und das eigentliche System bleibt original bestanden.
+Mittlerweile gibt es jedoch in der Linux-Welt eine neue Art von Distribution, die sogenannten 'Immutable' Distributionen, welche sich darin unterscheiden, dass der Root schreibgeschützt ist oder wie bei NixOS oder Gnu GUIX gar nicht erst richtig existiert. Dadurch können Programme nur direkt in den Homeordner des Nutzers installiert werden, und das eigentliche System bleibt original bestanden.
 
-Hierdurch wird Dateisystem-verifizierung möglich, da der originale zustand sich nie ändern wird, kann ein Programm ohne probleme verizieren, dass sich nichts verändert hat.
+Hierdurch wird Dateisystem-Verifizierung möglich, da der originale Zustand sich nie ändern wird, kann ein Programm ohne Probleme die Partition verifizieren, dass sich nichts verändert hat.
 
 \input{idee/implementierungen}
 \input{idee/hashquellen}
diff --git a/doc/class-assignment/idee/implementierungen.tex b/doc/class-assignment/idee/implementierungen.tex
index a7a4db3..cdee8f2 100644
--- a/doc/class-assignment/idee/implementierungen.tex
+++ b/doc/class-assignment/idee/implementierungen.tex
@@ -4,11 +4,11 @@ Für die Verifizierung eines Dateisystems gibt es verschiedene Methoden:
 \item[Per-Datei verifizierung]
   Bei der Per-Datei Verifizierung wird der Hash von jeder Datei die verifiziert werden soll mit einem vorbestimmten, vertrauten, Hash verglichen, falls der Hash übereinstimmt ist Datei unmodifiziert, wenn sie jedoch abweichen, ist die Datei modifiziert und kann nicht vertraut werden.
 \item[Festplattenverifizierung]
-  Hier wird ein Hash von der ganzen Festplatte oder Partition mit einem vorgegebenen Wert verglichen. Im vergleich zu der Per-Datei verifizierung werden hier auch neue Dateien erkannt, welche eine Per-Datei verifizierung ignoriert hätte. Jedoch kann dies auch erheblich langsamer sein, da die ganze Partition, welche sehr groß werden kann, in einem Thread gehasht wird.
+  Hier wird ein Hash von der ganzen Festplatte oder Partition mit einem vorgegebenen Wert verglichen. Im Vergleich zu der Per-Datei-Verifizierung werden hier auch neue Dateien erkannt, welche eine Per-Datei-Verifizierung ignoriert hätte. Jedoch kann dies auch erheblich langsamer sein, da die ganze Partition, welche sehr groß werden kann, in einem Thread gehasht wird.
 \item[Blockverifizierung]
-  Dies ist ähnlich zu der Festplattenverifizierung, jedoch werden hier nur einzelne Blöcke gehasht und verifiziert, dies ermöglicht es, die Verifizierung durch Multithreading zu beschleunigen, während man weiterhin die ganze Festplatte/Partition verifiziert.
+  Dies ist ähnlich zu der Festplattenverifizierung, jedoch werden hier nur einzelne Blöcke gehasht und verifiziert. Dies ermöglicht es, die Verifizierung durch Multithreading zu beschleunigen, während man weiterhin die ganze Festplatte/Partition verifiziert.
 \end{description}
-Alle drei arten der Verifizierung haben eine Sache gemeinsam, sie brauchen eine vertraute quelle von der sie den korrekten Hash für eine Datei/Partition/Block lesen können.
+Alle drei Arten der Verifizierung haben eine Sache gemeinsam, sie brauchen eine vertraute quelle, von der sie den korrekten Hash für eine Datei/Partition/Block lesen können.
 %%% Local Variables:
 %%% mode: LaTeX
 %%% TeX-master: "../fsverify.tex"
diff --git a/doc/class-assignment/realisierung/fbwarn.tex b/doc/class-assignment/realisierung/fbwarn.tex
index 097145d..1c9559c 100644
--- a/doc/class-assignment/realisierung/fbwarn.tex
+++ b/doc/class-assignment/realisierung/fbwarn.tex
@@ -1,8 +1,8 @@
 \subsection{fbwarn}
-Falls die Festplattenverifizierung Fehlschlägt, muss der Nutzer gewarnt werden (es ist auch möglich das Gerät einfach auszuschalten, jedoch sollte dies aus UX gründen nicht gemacht werden).
+Falls die Festplattenverifizierung fehlschlägt, muss der Nutzer gewarnt werden (es ist auch möglich, das Gerät einfach auszuschalten, jedoch sollte dies aus UX Gründen nicht gemacht werden).
 
 \subsubsection{Grafischer Output}
-Die Warnung ist am besten grafisch zu tun, jedoch gibt es keinen display server wie Wayland oder X11, deshalb muss direkt auf den Framebuffer /dev/fb* geschrieben werden, um graphischen Output zu zeigen.\\
+Die Warnung ist am besten grafisch zu tun, jedoch gibt es keinen Display-Server wie Wayland oder X11, deshalb muss direkt auf den Framebuffer /dev/fb* geschrieben werden, um grafischen Output zu zeigen.\\
 Da jeder verfügbare framebuffer als /dev/fbX verfügbar ist, kann man ganz einfach die Datei öffnen und mit mmap manipulieren:
 
 \begin{minted}[fontsize=\footnotesize]{c}
@@ -36,15 +36,15 @@ Da jeder verfügbare framebuffer als /dev/fbX verfügbar ist, kann man ganz einf
      return 0;
  }
 \end{minted}
-Dies genügt, wenn man einfache Formen in den Framebuffer zeichnen möchte, wie im Bild zu sehen ist
+Dies genügt, wenn man einfache Formen in den Framebuffer zeichnen möchte, wie im Bild zu sehen ist.
 \begin{figure}[h]
   \centering
   \includegraphics[scale=0.7]{realisierung/images/framebuffer-rectangle.png}
   \caption{C Programm welches einen Quadrat mit Gradient direkt in den Framebuffer schreibt}
 \end{figure}
 
-Jedoch wird es komplizierter, wenn man auch Text anzeigen möchte, da man jeden Pixel manuell schreiben muss welches bei Sätzen wie ``System Verification Failed'' bereits sehr umständlich ist.\\
-Deshalb ist eine bessere lösung nötig, eine Bibliothek die in den Framebuffer schreiben kann und alle Rendering funktionen abstrahiert. Die Bibliothek die ich benutzt habe ist Raylib, eine C bibliothek welche hauptsächlich für die Entwicklung von Spielen gedacht ist, jedoch, nicht wie andere Engines, keine besonderen Features hat, sondern jediglich verschiedene Aspekte wie Grafik, Physik und Audio abstrahiert. Glücklicherweise kann mit der Compilerflag \texttt{-DEGL\_NO\_X11} raylib so kompiliert werden, dass es direkt in den Framebuffer schreibt, anstatt versucht ein Fenster zu öffnen.
+Jedoch wird es komplizierter, wenn man auch Text anzeigen möchte, da man jedes Pixel manuell schreiben muss, welches bei Sätzen wie ``System Verification Failed'' bereits sehr umständlich ist.\\
+Deshalb ist eine bessere Lösung nötig, eine Bibliothek, die in den Framebuffer schreiben kann und alle Rendering-Funktionen abstrahiert. Die Bibliothek, die ich benutzt habe, ist Raylib, eine C-Bibliothek, welche hauptsächlich für die Entwicklung von Spielen gedacht ist, jedoch, nicht wie andere Engines, keine besonderen Features hat, sondern lediglich verschiedene Aspekte wie Grafik, Physik und Audio abstrahiert. Glücklicherweise kann mit der Compilerflag \texttt{-DEGL\_NO\_X11} raylib so kompiliert werden, dass es direkt in den Framebuffer schreibt, anstatt versucht, ein Fenster zu öffnen.
 \bigbreak \noindent
 \begin{figure}[h]
   \centering
@@ -52,25 +52,25 @@ Deshalb ist eine bessere lösung nötig, eine Bibliothek die in den Framebuffer
   \caption{Raylib Beispielprogramm \texttt{shapes\_basic\_shapes} in einer VM mit output direkt zum Framebuffer}
 \end{figure}
 
-Hiermit wird es um einiges Einfacher eigene Bilder zu erstellen, die angezeigt werden wenn nötig.
+Hiermit wird es um einiges einfacher, eigene Bilder zu erstellen, die angezeigt werden, wenn nötig.
 
 \subsubsection{Grafikformat}
-Da es recht umständlich wär, das Bild immer manuell in C zu programmieren, ist es am besten ein Grafikformat zu benutzen welches extern geladen werden kann. Der erste gedanke wäre, einfach jpg-xl oder png bilder zu benutzen, jedoch sind Rasterbasierte Grafikformate hier nicht sehr nützlich, da die Warnung auf viele verschiedene Bildschirmgrößen angezeigt werden muss, also sind Vektorbasierten Grafikformate nötig. Die bekannteste wäre SVG, eine XML basiertes Format mit dem Bilder geschrieben werden können, die unendlich groß skaliert werden können. SVG ist jedoch sehr komplex und hat features die hier nicht nötig sind.\\
-Da ich kein Vektorbasiertes Grafikformat gefunden habe, welches auch sehr Simpel gehalten ist, habe ich mich entschlossen ein eigenes Format zu entwickeln.\\
+Da es recht umständlich wär, das Bild immer manuell in C zu programmieren, ist es am besten, ein Grafikformat zu benutzen, welches extern geladen werden kann. Der erste Gedanke wäre, einfach JPG-XL oder PNG-Bilder zu benutzen, jedoch sind rasterbasierte Grafikformate hier nicht sehr nützlich, da die Warnung auf viele verschiedene Bildschirmgrößen angezeigt werden muss, also sind vektorbasierte Grafikformate nötig. Die bekannteste wäre SVG, ein XML-basiertes Format, mit dem Bilder geschrieben werden können, die unendlich groß skaliert werden können. SVG ist jedoch sehr komplex und hat Features, die hier nicht nötig sind.\\
+Da ich kein vektorbasiertes Grafikformat gefunden habe, welches auch sehr simpel gehalten ist, habe ich mich entschlossen, ein eigenes Format zu entwickeln.\\
 \\
-Das Format hat eine Funktionsbasierte Syntax, das heißt, dass im gegensatz zu SVG man einfach Funktionen aufruft um Formen zu zeichen oder Text zu schreiben:
+Das Format hat eine funktionsbasierte Syntax, das heißt, dass im Gegensatz zu SVG man einfach Funktionen aufruft, um Formen zu zeichnen oder Text zu schreiben:
 \begin{verbatim}
 rectangle (x=100,y=100,height=100,width=100,color="#FFFFFFFF",fill=true)
 \end{verbatim}
-Da diese art von Syntax sehr simpel zu Parsen ist, kann es alles direkt in POSIX-C implementiert werden, ohne externe Bibliotheken verwenden zu müssen.\\
-Der nächste Schritt ist festzulegen, welche Funktionen benötigt werden. Mit betracht auf die Unterstützten Funktionen in raylib, habe ich die folgenden Funktionen implementiert:
+Da diese Art von Syntax sehr simpel zu parsen ist, kann es alles direkt in POSIX-C implementiert werden, ohne externe Bibliotheken verwenden zu müssen.\\
+Der nächste Schritt ist, festzulegen, welche Funktionen benötigt werden. Mit Betracht auf die unterstützten Funktionen in raylib habe ich die folgenden Funktionen implementiert:
 \begin{itemize}
 \item IMG\\
-  Funktion um ein Bild zu Initialisieren, muss immer die erste Funktion in einem Bild sein.
+  Funktion, um ein Bild zu initialisieren, muss immer die erste Funktion in einem Bild sein.
 \item rectangle\\
-  Funktion um ein Rechteck zu zeichnen, unterstützt ausegfüllte und nicht ausgefüllte Rechtecke.
+  Ein Rechteck, unterstützt ausgefüllte und nicht ausgefüllte Rechtecke.
 \item roundedrectangle\\
-  Ein Rechteck aber mit abgerundeten Ecken.
+  Ein Rechteck, aber mit abgerundeten Ecken.
 \item circle\\
   Ein Kreis.
 \item circlesegment\\
@@ -84,7 +84,7 @@ Der nächste Schritt ist festzulegen, welche Funktionen benötigt werden. Mit be
 \item text\\
   Text.
 \end{itemize}
-Mit diesen Funktionen kann eine Bild ungefähr so aussehen:\\
+Mit diesen Funktionen kann ein Bild ungefähr so aussehen:\\
 
 \begin{verbatim}
 // The IMG function is always required
@@ -104,7 +104,7 @@ fill=true, thickness=0)
 
 circle (x=100,y=100,radius=10,color="#CfCfCf")
 \end{verbatim}
-Trotz des sehr simplen Aufbaus und kleinen Arsenal an Funktionen, ist es möglich viele verschiedene Dinge zu zeichnen, Perfekt um Grafiken für die Warnung von Nutzern zu erstellen.
+Trotz des sehr simplen Aufbaus und kleinen Arsenals an Funktionen ist es möglich, viele verschiedene Dinge zu zeichnen, perfekt um Grafiken für die Warnung von Nutzern zu erstellen.
 
 \hypersetup{pageanchor=false}
 \begin{figure}[h]
diff --git a/doc/class-assignment/realisierung/fsverify.tex b/doc/class-assignment/realisierung/fsverify.tex
index 6c61313..4e077e9 100644
--- a/doc/class-assignment/realisierung/fsverify.tex
+++ b/doc/class-assignment/realisierung/fsverify.tex
@@ -1,10 +1,10 @@
 \subsection{fsverify}
-Da das Konzept der Festplattenverifizierung nichts neues ist, habe ich mir erstmals bereits existierende Projekte angeschaut, um zu sehen, wie es in anderen Betriebssystemen realisiert ist.
-Hierbei war google's dm-verity, welches in Android und ChromeOS geräten genutzt wird, die beste Hilfe, da es am besten dokumentiert und ausgetestet ist.
+Da das Konzept der Festplattenverifizierung nichts Neues ist, habe ich mir erstmals bereits existierende Projekte angeschaut, um zu sehen, wie es in anderen Betriebssystemen realisiert ist.
+Hierbei war Google's dm-verity, welches in Android und ChromeOS Geräten genutzt wird, die beste Hilfe, da es am besten dokumentiert und ausgetestet ist.
 
 \subsubsection{Partitionslayout}
-Inspiriert an dm-verity, entschied ich mich dafür, die Datenbank auf eine eigene Partition zu speichern, also war das erste Ziel ein gutes Partitionslayout zu Entwickeln, in der die Datenbank und Metadata so gut wie möglich gespiechert werden kann.\\
-Die erste Version des Layouts war recht simpel, es hatte alles was wirklich wichtig war, eine magic number, die signatur, größe des Dateisystems und größe der Datenbank:
+Inspiriert an dm-verity, entschied ich mich dafür, die Datenbank auf eine eigene Partition zu speichern; also war das erste Ziel, ein gutes Partitionslayout zu entwickeln, in der die Datenbank und Metadaten so gut wie möglich gespeichert werden können.\\
+Die erste Version des Layouts war recht simpel, es hatte alles, was wirklich wichtig war, eine magic number, die Signatur, Größe des Dateisystems und Größe der Datenbank:
 \begin{verbatim}
 <magic number> <signature> <filesystem size> <table size>
 \end{verbatim}
@@ -24,8 +24,8 @@ Die erste Version des Layouts war recht simpel, es hatte alles was wirklich wich
     \hline
   \end{tabular}
 \end{center}
-In der implementierung dieses Layouts fiel dann auf, dass es keinen Sinn macht, die Datenbankgröße in MB festzulegen
-Die zweite Version fügt aus diesem Grund ein weiteres Feld hinzu um die Einheit der Datenbankgröße festzulegen:
+In der Implementierung dieses Layouts fiel dann auf, dass es keinen Sinn macht, die Datenbankgröße in MB festzulegen.
+Die zweite Version fügt aus diesem Grund ein weiteres Feld hinzu, um die Einheit der Datenbankgröße festzulegen:
 \begin{verbatim}
 <magic number> <signature> <filesystem size> <table size> <table unit>
 \end{verbatim}
@@ -48,7 +48,7 @@ Die zweite Version fügt aus diesem Grund ein weiteres Feld hinzu um die Einheit
   \end{tabular}
 \end{center}
 \hfill \break
-Die nächste version teilte die Signatur in zwei teile auf. Da minisign signaturen aus einem kommentar, einer vertrauten signatur, einem weiteren kommentar und einer nicht vertrauten signatur
+Die nächste Version teilte die Signatur in zwei Teile auf. Da minisign Signaturen aus einem Kommentar, einer vertrauten Signatur, einem weiteren Kommentar und einer nicht vertrauten Signatur.
 \begin{verbatim}
 <magic number> <untrusted signature hash> <trusted signature hash>
 <filesystem size> <table size> <table unit>
@@ -76,9 +76,9 @@ Die nächste version teilte die Signatur in zwei teile auf. Da minisign signatur
 
 \subsubsection{Datenbanklayout}
 Nachdem der Header der Partition festgelegt wurde, muss festgelegt werden, wie die Datenbank festgelegt ist.
-bbolt, die Datenbankbibliothek die fsverify nutzt, hat ein key/value system, das heißt, dass jeder Wert mit einem Schlüssel verbunden ist. Zudem benutzt bbolt das konzept von ``Buckets'', einem Eimer in dem Datenpaare sortiert werden können.
+bbolt, die Datenbankbibliothek, die fsverify nutzt, hat ein key/value System, das heißt, dass jeder Wert mit einem Schlüssel verbunden ist. Zudem benutzt bbolt das Konzept von ``Buckets'', einem Eimer, in dem Datenpaare sortiert werden können.
 \bigbreak \noindent
-Das erste Layout war für eine implementation von fsverify die nur auf einem Thread läuft, besteht aus einem Bucket ``Nodes'', in dem jede Node gespeichert wird.
+Das erste Layout war für eine Implementation von fsverify, die nur auf einem Thread läuft, besteht aus einem Bucket ``Nodes'', in dem jede Node gespeichert wird.
 Eine Node sieht wie folgt aus:
 
 \begin{minted}{go}
@@ -106,8 +106,8 @@ type Node struct {
     \hline
   \end{tabular}
 \end{center}
-Jeder Block bekommt eine Node zugewiesen, diese Nodes werden in der Datenbank aneinandergereiht, mit dem wert von PrevBlockSum als den key.
-Der Wert PrevBlockSum erlaubt es, während der Verifizierung Fehler in der Datenbank zu finden. Wird eine Node verändert, stimmt der PrevBlockSum der nächsten Node nicht mehr, dass heißt, dass es nicht mehr möglich ist, den Key zu der nächsten Node zu berechnen, wodurch die Verifizierung fehlschlägt.
+Jeder Block bekommt eine Node zugewiesen; diese Nodes werden in der Datenbank aneinandergereiht, mit dem Wert von PrevBlockSum als den Key.
+Der Wert PrevBlockSum erlaubt es, während der Verifizierung Fehler in der Datenbank zu finden. Wird eine Node verändert, stimmt der PrevBlockSum der nächsten Node nicht mehr, das heißt, dass es nicht mehr möglich ist, den Key zu der nächsten Node zu berechnen, wodurch die Verifizierung fehlschlägt.
 \pagebreak
 \begin{verbatim}
 +-----+     +------+     +------+        +------+
@@ -117,7 +117,7 @@ Der Wert PrevBlockSum erlaubt es, während der Verifizierung Fehler in der Daten
 |     |     |adBfa |     |1Ab3d |        |bAd31 |
 +-----+     +------+     +------+        +------+
 \end{verbatim}
-Wird hier eine Node verändert, stimmt die restliche Kette nicht mehr
+Wird hier eine Node verändert, stimmt die restliche Kette nicht mehr.
 \begin{verbatim}
                          Hash passt nicht mehr
                                     |
@@ -130,21 +130,21 @@ Wird hier eine Node verändert, stimmt die restliche Kette nicht mehr
                        |
                  Veränderter Wert
 \end{verbatim}
-Da die erste Node keinen vorränger hat, von dem es PrevNodeSum berechnen kann, wird ihr der wert ``Entrypoint'' gegeben.
+Da die erste Node keinen Vorgänger hat, von dem es PrevNodeSum berechnen kann, wird ihr der Wert ``Entrypoint'' gegeben.
 \bigbreak \noindent
-Diese Datenbankstruktur hat ohne Probleme funktioniert, jedoch war fsverify viel zu langsam wenn es auf einem Thread läuft. Das Problem bei dem Multithreading jedoch ist, dass man Nodes nicht wahrlos aufgreifen kann, sondern eine vorherige Node oder die entrypoint Node braucht. Die Lösung ist recht einfach, die anzahl der Threads wird in verifysetup bereits angegeben und somit in fsverify fest einprogrammiert. Somit gibt es in der Datenbank mehrere entrypoint Nodes, die sich durch eine hinzugefügte Nummer unterscheiden. Dadurch ist es weiterhin möglich die Datenbank zu verifizieren, während es multithreaded läuft.
+Diese Datenbankstruktur hat ohne Probleme funktioniert, jedoch war fsverify viel zu langsam, wenn es auf einem Thread läuft. Das Problem bei dem Multithreading jedoch ist, dass man Nodes nicht wahrlos aufgreifen kann, sondern eine vorherige Node oder die entrypoint Node braucht. Die Lösung ist recht einfach, die Anzahl der Threads wird in verifysetup bereits angegeben und somit in fsverify fest einprogrammiert. Somit gibt es in der Datenbank mehrere entrypoint Nodes, die sich durch eine hinzugefügte Nummer unterscheiden. Dadurch ist es weiterhin möglich, die Datenbank zu verifizieren, während es multithreaded läuft.
 
 \subsubsection{Datenbanksignatur}
-Um sicherzustellen, dass die Datenbank nicht modifiziert wurde, wird eine Signatur generiert die mit der gelesenen Datenbank verglichen wird.\\
-Wie bereits erwähnt, wird für die Signatur das Programm minisign benutzt. Minisign beruht auf ein public/private key system, wodurch eine Signatur von dem privaten Schlüssel generiert wird und durch den öffentlichen Schluss verifiziert werden kann.\\
-Die Signatur wurde bereits im Partitionsheader gespeichert, was übrig bleibt ist der öffentliche Schlüssel.\\
-Da der öffentliche Schlüssel und die Signatur gebraucht werden, um eine Datenbank zu verifizieren, muss sichergestellt werden, dass beide seperat gespeichert werden und zumindest der öffentliche Schlüssel nicht bearbeitet werden kann.\\
-Die erste Idee um dies zu lösen wäre, dass man einfach den Schlüssel in eine Datei schreibt, und die Datei schreibgeschutzt Speichert. Jedoch ist bei diesem weg der speicherort der Datei das problem, wie soll man sicher sein, dass nicht das ganze Dateisystem verändert wurde um einen neuen Schlüssel zu beinhalten?
+Um sicherzustellen, dass die Datenbank nicht modifiziert wurde, wird eine Signatur generiert, die mit der gelesenen Datenbank verglichen wird.\\
+Wie bereits erwähnt, wird für die Signatur das Programm minisign benutzt. Minisign beruht auf einem public/private key System, wodurch eine Signatur von dem privaten Schlüssel generiert wird und durch den öffentlichen Schluss verifiziert werden kann.\\
+Die Signatur wurde bereits im Partitionsheader gespeichert. Was übrig bleibt, ist der öffentliche Schlüssel.\\
+Da der öffentliche Schlüssel und die Signatur gebraucht werden, um eine Datenbank zu verifizieren, muss sichergestellt werden, dass beide separat gespeichert werden und zumindest der öffentliche Schlüssel nicht bearbeitet werden kann.\\
+Die erste Idee, um dies zu lösen, wäre, dass man einfach den Schlüssel in eine Datei schreibt und die Datei schreibgeschützt speichert. Jedoch ist bei diesem Weg der Speicherort der Datei das Problem. Wie soll man sicher sein, dass nicht das ganze Dateisystem verändert wurde, um einen neuen Schlüssel zu beinhalten?
 \bigbreak \noindent
-Das heißt, dass man ein Schreibgeschütztes, möglichst seperates und immer vertraubares Speichermedium braucht, auf der man den Schlüssel speichert.\\
-Die lösung: Microcontoller. Sie können über usb-serial (also /dev/ttyACM* in Linux) Daten übertragen, können durch das Modifizieren bestimmter Sektoren permanent schreibgeschützt werden, und sind sehr klein, also können sie von dem Nutzer mitgetragen werden oder in dem Gerät direkt verbaut sein.
+Das heißt, dass man ein schreibgeschütztes, möglichst separates und immer vertrautes Speichermedium braucht, auf dem man den Schlüssel speichert.\\
+Die Lösung: Mikrocontroller. Sie können über usb-serial (also /dev/ttyACM* in Linux) Daten übertragen, können durch das Modifizieren bestimmter Sektoren permanent schreibgeschützt werden und sind sehr klein, also können sie von dem Nutzer mitgetragen werden oder in dem Gerät direkt verbaut sein.
 \\
-Um dieses konzept zu testen, habe ich einen Arduino UNO genutzt, dieser ist zwar immer schreibbar, hat aber keine Technischen unterschiede die die Datenübertragung ändern würden.
+Um dieses Konzept zu testen, habe ich einen Arduino UNO genutzt. Dieser ist zwar immer schreibbar, hat aber keine technischen Unterschiede, die die Datenübertragung ändern würden.
 \\
 Der Code für den Arudino sieht wie folgt aus:
 \begin{verbatim}
@@ -156,16 +156,16 @@ void setup() {
 void loop() {}
 \end{verbatim}
 
-Es wird eine Serielle Konsole auf einer Baudrate von 9600 geöffnet, auf der einmalig der öffentliche Schlüssel ausgegeben wird. Es ist wichtig zu beachten, dass der Schlüssel mit Tabstops (\symbol{92} t) ausgegeben wird, diese benutzt fsverify um zu wissen, ob der volle Schlüssel aufgenommen wird, fehlt der Tabstop am anfang oder am Ende, ist es sehr wahrscheinlich, dass der Schlüssel auch nicht vollständig aufgenommen wurde.
+Es wird eine serielle Konsole auf einer Baudrate von 9600 geöffnet, auf der einmalig der öffentliche Schlüssel ausgegeben wird. Es ist wichtig zu beachten, dass der Schlüssel mit Tabstopp (\symbol{92} t) ausgegeben wird, diese benutzt fsverify um zu wissen, ob der volle Schlüssel aufgenommen wird, fehlt der Tabstopp am Anfang oder am Ende, ist es sehr wahrscheinlich, dass der Schlüssel auch nicht vollständig aufgenommen wurde.
 
 \subsubsection{Optimierung}
-Wie bereits gesagt, lief die erste version von fsverify auf einem Thread, dies führte zu einer laufzeit von über einer Stunde bei einer Partitionsgröße von 1gb. Da fsverify beim booten des systems ausgeführt werden soll, ist eine laufzeit von einer Stunde nicht akzeptabel.
+Wie bereits gesagt, lief die erste Version von fsverify auf einem Thread, dies führte zu einer Laufzeit von über einer Stunde bei einer Partitionsgröße von 1 GB. Da fsverify beim Booten des Systems ausgeführt werden soll, ist eine Laufzeit von einer Stunde nicht akzeptabel.
 \\
-Die ersten schritte der Optimierung war es, die größe der Blocks zu verringern und von sha256 zu sha1 zu wechseln. Da das lesen von daten viel schneller erfolgt als das hashen von daten, ist es besser mehr zu lesen und dadurch kleinere Datenmengen zu hashen, der wechsel von sha256 zu sha1 mag erstmal schlecht wirken, jedoch macht dies keine Probleme, da hier keine Passwörter oder ähnliches verschlüsselt werden, also sind bruteforce attacken hier kein risiko.\\
+Die ersten Schritte der Optimierung war es, die Größe der Blocks zu verringern und von sha256 zu sha1 zu wechseln. Da das Lesen von daten viel schneller erfolgt als das hashen von daten, ist es besser mehr zu lesen und dadurch kleinere Datenmengen zu hashen, der wechsel von sha256 zu sha1 mag erstmal schlecht wirken, jedoch macht dies keine Probleme, da hier keine Passwörter oder ähnliches verschlüsselt werden, also sind Bruteforceattacken hier kein Risiko.\\
 Mit diesen Optimierungen hat sich die Laufzeit etwas verbessert, von 60 Minuten zu ungefähr 50. Nicht viel besser.
 \\
-Der nächste schritt war es, fsverify mit multithreading zu implementieren, die dafür notwendigen änderungen in der Datenbank wurden bereits erklärt. In fsverify selber hat sich die art geändert, wie die Daten von der Partition gelesen werden. Anstatt alles auf einmal zu lesen und durchzugehen, wird die größe der Partition genommen, durch die anzahl der Threads geteilt, und somit für jeden Thread genau die anzahl an bytes gelesen, die für die Node-kette nötig ist. Dies stellt sicher, dass keine Kette sich überlappt und korruptionen von Nodes in ketten auffallen, da sie durch Korruptionen versuchen könnten, bytes zu lesen die sie garnicht lesen sollten.\\
-Durch das multithreading hat sich die Laufzeit von den singlethreaded 50 Minuten zu nur 6 Sekunden verringert.
+Der nächste Schritt war es, fsverify mit Multithreading zu implementieren; die dafür notwendigen Änderungen in der Datenbank wurden bereits erklärt. In fsverify selber hat sich die Art geändert, wie die Daten von der Partition gelesen werden. Anstatt alles auf einmal zu lesen und durchzugehen, wird die Größe der Partition genommen, durch die Anzahl der Threads geteilt, und somit für jeden Thread genau die Anzahl an Bytes gelesen, die für die Node-kette nötig ist. Dies stellt sicher, dass keine Kette sich überlappt und korrupte Nodes in Ketten auffallen, da sie durch Korruption versuchen könnten, Bytes zu lesen, die sie gar nicht lesen sollten.\\
+Durch das Multithreading hat sich die Laufzeit von den singlethreaded 50 Minuten zu nur 6 Sekunden verringert.
 \bigbreak \noindent
 Fsverify hatte eine Laufzeitoptimierung von 60000\% in einer Woche:
 \begin{verbatim}
diff --git a/doc/class-assignment/realisierung/realisierung.tex b/doc/class-assignment/realisierung/realisierung.tex
index 64e00f1..9b54ff6 100644
--- a/doc/class-assignment/realisierung/realisierung.tex
+++ b/doc/class-assignment/realisierung/realisierung.tex
@@ -1,4 +1,4 @@
-Das Projekt kann in drei Unterprojekte eingeteilt werden. Fsverify, also die verifizierung selber, verifysetup, ein Program um das system richtig zu Konfigurieren um die nutzung von fsverify möglich zu machen und fbwarn, ein program welches den Nutzer graphisch über eine fehlgeschlagene Verifizierung informiert.
+Das Projekt kann in drei Unterprojekte eingeteilt werden. Fsverify, also die Verifizierung selber, verifysetup, ein Programm, um das System richtig zu konfigurieren, um die Nutzung von fsverify möglich zu machen und fbwarn, ein Programm, welches den Nutzer grafisch über eine fehlgeschlagene Verifizierung informiert.
 
 \input{realisierung/fsverify.tex}
 \input{realisierung/verifysetup.tex}
diff --git a/doc/class-assignment/realisierung/verifysetup.tex b/doc/class-assignment/realisierung/verifysetup.tex
index 2b79012..42d5c91 100644
--- a/doc/class-assignment/realisierung/verifysetup.tex
+++ b/doc/class-assignment/realisierung/verifysetup.tex
@@ -1,11 +1,11 @@
 \subsection{verifysetup}
-Nachdem fsverify vollständig implementiert war und alle Speicherkonzepte vollständig Entwickelt sind, braucht fsverify auch ein Programm um alles richtig aufzusetzen.\\
-Das Programm muss eine Datenbank von Nodes anhand der zu verifizierenden Partition erstellen, den Header entsprechend Konfigurieren und alles auf eine Datei schreiben, die der Nutzer (oder eher Distribution Entwickler) auf die für fsverify vorgesehene Partition schreiben kann.
+Nachdem fsverify vollständig implementiert war und alle Speicherkonzepte vollständig entwickelt sind, braucht fsverify auch ein Programm, um alles richtig aufzusetzen.\\
+Das Programm muss eine Datenbank von Nodes anhand der zu verifizierenden Partition erstellen, den Header entsprechend konfigurieren und alles auf eine Datei schreiben, die der Nutzer (oder eher Distributions-Entwickler) auf die für fsverify vorgesehene Partition schreiben kann.
 
 \subsubsection{Optimierung}
-Genauso wie fsverify, benutzt verifysetup erstmal nur einen Thread um die Datenbank zu erstellen. Dies führte zu einer laufzeit von über 2 Stunden für 1gb.\\
-Die schritte zur optimierung sind die gleichen wie bei fsverify. Jedoch verbesserte sich die Laufzeit um einiges bereits bei dem wechsel zu 2kb Blocks und sha1 hashing, von 2 Stunden zu einer Stunde.\\
-Mit dem wechsel zu multithreading ging dies dann runter zu 19 Sekunden mit 12 Threads.
+Genauso wie fsverify benutzt verifysetup erstmal nur einen Thread, um die Datenbank zu erstellen. Dies führte zu einer Laufzeit von über 2 Stunden für 1 GB.\\
+Die Schritte zur Optimierung sind die gleichen wie bei fsverify. Jedoch verbesserte sich die Laufzeit um einiges, bereits bei dem Wechsel zu 2 KB Blocks und sha1 hashing, von 2 Stunden zu einer Stunde.\\
+Mit dem Wechsel zu Multithreading ging dies dann runter zu 19 Sekunden mit 12 Threads.
 \\
 Die Laufzeit von verifysetup verbesserte sich um 33846\% in einer Woche.
 \begin{verbatim}
diff --git a/doc/class-assignment/reflexion/reflexion.tex b/doc/class-assignment/reflexion/reflexion.tex
index 197cbee..7d6997d 100644
--- a/doc/class-assignment/reflexion/reflexion.tex
+++ b/doc/class-assignment/reflexion/reflexion.tex
@@ -1,16 +1,16 @@
-Insgesamt gibt es keine großen mängel, die mir während der Implementierung aufgefallen sind, die meisten Kritikpunkte liegen in fbwarn, welche teilweise der kurzen Entwicklungszeit (~7 Tage) zu schulden sind. 
+Insgesamt gibt es keine großen Mängel, die mir während der Implementierung aufgefallen sind. Die meisten Kritikpunkte liegen in Warnen, welche teilweise der kurzen Entwicklungszeit (~7 Tage) zuschulden sind.
 
 \subsection{Bessere Datenbank}
-Die Datenbank welche ich zurzeit nutze, bbolt, hat mehrere Probleme, zum einen ist die Lese und Schreibgeschwindigkeit nicht sehr schnell, trotz bestmöglicher Optimierungen durch nutzen von Batch-operations und einmaligen öffnen und Schreiben der Datenbank, fügt die Datenbank ungefähr 2 Sekunden an Laufzeit zu verifysetup, 22\% der ganzen Laufzeit.\\
-Dazu kommt auch, das bbolt es zurzeit nicht unterstützt, eine Datenbank direkt aus einer Variable zu lesen, die Datenbank muss als Pfad im Dateisystem angegeben werden, welches dazu führt, das fsverify die Datenbank von der Partition in eine Variable liest, und die Variable direkt wieder in einer Datei in \texttt{/tmp} schreibt. Dies führt zu unnötigen Write-cycles die durch das Verwenden einer anderen Datenbank oder einem Patch für den bbolt Quellcode gelöst werden könnte.
+Die Datenbank welche ich zurzeit nutze, bbolt, hat mehrere Probleme, zum einen ist die Lese und Schreibgeschwindigkeit nicht sehr schnell, trotz bestmöglicher Optimierungen durch Nutzen von Batch-Operation und einmaligen öffnen und Schreiben der Datenbank, fügt die Datenbank ungefähr 2 Sekunden an Laufzeit zu verifysetup, 22\% der ganzen Laufzeit.\\
+Dazu kommt auch, das bbolt es zurzeit nicht unterstützt, eine Datenbank direkt aus einer Variable zu lesen, die Datenbank muss als Pfad im Dateisystem angegeben werden, welches dazu führt, das fsverify die Datenbank von der Partition in eine Variable liest, und die Variable direkt wieder in einer Datei in \texttt{/tmp} schreibt. Dies führt zu unnötigen Write-cycles, die durch das Verwenden einer anderen Datenbank oder einem Patch für den bbolt Quellcode gelöst werden könnte.
 
 \subsection{Nutzung vom TPM2 für öffentliche Schlüssel}
-Dieses Feature war geplant, und ich hatte bereits einen Schlüssel durch verschiedene Linux Tools in den TPM geschrieben, jedoch konnte ich keine gute go Bibliothek für TPMs finden, weshalb ich das Feature auslassen musste, hätte ich dies noch bevore ich mit der Implementierung gewusst, hätte ich entweder eine andere Programmiersprache für fsverify gewählt, oder eine eigene Bibliothek für TPMs als teil des Projekts entwickelt.
+Dieses Feature war geplant, und ich hatte bereits einen Schlüssel durch verschiedene Linux Tools in den TPM geschrieben, jedoch konnte ich keine gute go Bibliothek für TPMs finden, weshalb ich das Feature auslassen musste, hätte ich dies noch bevor ich mit der Implementierung gewusst, hätte ich entweder eine andere Programmiersprache für fsverify gewählt, oder eine eigene Bibliothek für TPMs als teil des Projekts entwickelt.
 
 \subsection{Besserer Parser für fbwarn}
-Zur zeit benutzt fbwarn einfaches string matching mit Funktionen aus \texttt{stdlib.h} und \texttt{strings.h}, dies Funktioniert, jedoch bringt es viele Probleme mit sich, sodass zum Beispiel ein Leerzeichen am falschen Platz bereits vieles Zerstören kann, welches sehr schwer zu debuggen ist, da man Fehler solcher art nicht sofort erkennt.\\
-Hätte ich mir für fbwarn mehr Zeit gegeben, hätte ich Programme benutzt, die Speziell für das Parsen von Dateien in C gedacht sind, wie \texttt{yacc(1)} und \texttt{lex(1)}.
+Zurzeit benutzt fbwarn einfaches String Matching mit Funktionen aus \texttt{stdlib.h} und \texttt{strings.h}, dies Funktioniert, jedoch bringt es viele Probleme mit sich, sodass zum Beispiel ein Leerzeichen am falschen Platz bereits vieles Zerstören kann, welches sehr schwer zu debuggen ist, da man Fehler solcher Art nicht sofort erkennt.\\
+Hätte ich mir für fbwarn mehr Zeit gegeben, hätte ich Programme benutzt, die speziell für das Parsen von Dateien in C gedacht sind, wie \texttt{yacc(1)} und \texttt{lex(1)}.
 
 \subsection{Mehr Funktionen in bvg}
-bvg unterstützt zurzeit neun Funktionen, wie bereits gezeigt ist dies zwar genug um recht viel zu Zeichnen, jedoch unterstützen die Funktionen alle nur solide Farben, also keine Farbübergänge oder ähnliches, welches das Design der Bilder einschränkt und rehc ``alt'' erscheinen lässt, da Farbübergänge für elemente wie Schatten in modernen Designs sehr oft genutzt werden.\\
-Zudem unterstützt bvg keinen Bézier Kurven, die das Zeichnen von beinahe jeder Form erlauben. Das fehlen ist jedoch ein Zeitproblem, da raylib bereits Funktionen für Bézier Kurven hat und die Implementierung in bvg recht simple wäre.
+bvg unterstützt zurzeit neun Funktionen, wie bereits gezeigt ist dies zwar genug, um recht viel zu zeichnen, jedoch unterstützen die Funktionen alle nur solide Farben, also keine Farbübergänge oder ähnliches, welches das Design der Bilder einschränkt und recht ``alt'' erscheinen lässt, da Farbübergänge für Elemente wie Schatten in modernen Designs sehr oft genutzt werden.\\
+Zudem unterstützt bvg keinen Bézier Kurven, die das Zeichnen von beinahe jeder Form erlauben. Das Fehlen ist jedoch ein Zeitproblem, da raylib bereits Funktionen für Bézier Kurven hat und die Implementierung in bvg recht simple wäre.