From b988331159a0fb1a552231e133a2c192713de7c3 Mon Sep 17 00:00:00 2001
From: axtloss <axtlos@getcryst.al>
Date: Sun, 3 Mar 2024 19:22:52 +0100
Subject: Fix typos in assignment

---
 doc/class-assignment/reflexion/reflexion.tex | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

(limited to 'doc/class-assignment/reflexion/reflexion.tex')

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.
-- 
cgit v1.2.3

