diff --git a/src/docs/parts/context/context.tex b/src/docs/parts/context/context.tex
index 34ed968..6306b4f 100644
--- a/src/docs/parts/context/context.tex
+++ b/src/docs/parts/context/context.tex
@@ -5,13 +5,18 @@ This thesis is a scientific approach to analyze and solve the practical problems
 For a lack of an official definition and common understanding what this technology is, the term \gls{sac} is defined in this chapter as a reference for the rest of the thesis.
 The technology combines \gls{virt} techniques with new approaches to \gls{app} development and deployment.
 
-The two main drivers for this technology have been long standing problems in information technology; optimal utilization of hardware and correct deployment of software to said hardware, both without sacrificing security.  
+The two main drivers for this technology have been long standing problems in information technology; optimal utilization of hardware and correct deployment of software to said hardware, both without sacrificing security.
 
 The optimal utilization of hardware is done by collocating and running multiple \glspl{app} simultaneously on the same hardware.
-In order to increase security, these applications are separated by applying \gls{virt} techniques. By developing \gls{virt} techniques into the \gls{OS} and thereby providing low-level security mechanisms, the foundation of \glspl{sac} was formed. In the next chapter an introduction to \gls{virt} is given, as it is important to understand this aspect of the \gls{sac} technology. 
+In order to increase security, these applications are separated by applying \gls{virt} techniques.
+By developing \gls{virt} techniques into the \gls{OS} and thereby providing low-level security mechanisms, the foundation of \glspl{sac} was formed.
+In the next chapter an introduction to \gls{virt} is given, as it is important to understand this aspect of the \gls{sac} technology.
 
 The correctness of software deployment is not easily measurable by quantity like hardware utilization, but is of qualitative nature.
-The \gls{sac} approach is to deploy self-contained bundles for \glspl{app} in form of \glspl{saci}. The creation of these \glspl{saci} is the main concern of this thesis and will be the subject to research and development in part \ref{part:research}. The underlying problems related to conventional \gls{app} deployment are covered in chapter \ref{chap:sdd}. State of the art attempts to solve these problems using \glspl{saci} are introduced and critically discussed in chapter \ref{chap:saci}, detailing the problem statement for this thesis.
+The \gls{sac} approach is to deploy self-contained bundles for \glspl{app} in form of \glspl{saci}.
+The creation of these \glspl{saci} is the main concern of this thesis and will be the subject to research and development in part \ref{part:research}.
+The underlying problems related to conventional \gls{app} deployment are covered in chapter \ref{chap:sdd}.
+State of the art attempts to solve these problems using \glspl{saci} are introduced and critically discussed in chapter \ref{chap:saci}, detailing the problem statement for this thesis.
 
 \chapter{\Gls{virt}}
 \label{chap:virt}
@@ -24,7 +29,8 @@ Virtualization techniques can be grouped by two categories: \glspl{hypervisor} a
 The term \gls{hypervisor} is synonymous to the more self-explanatory terms control program \cite[p. 217]{Sarton1975} and \gls{VM} Monitor.
 The \gls{hypervisor} operates on a host machine and can control multiple \glspl{VM}.
 The principle is easy to understand, because one can simply picture one or many virtual computers running on a real computer.
-\glspl{VM} are presented with a set of virtual hardware resources. These don't necessarily exist in the presented form on the underlying hardware machine.
+\glspl{VM} are presented with a set of virtual hardware resources.
+These don't necessarily exist in the presented form on the underlying hardware machine.
 
 \subsection{Guest \glspl{OS}}
 In order to be able to boot the virtual hardware and run \glspl{app}, \glspl{VM} need an \gls{OS} to run applications.
@@ -38,7 +44,9 @@ This allows to create heterogeneous scenarios like running an ARM \gls{VM} using
 
 \subsection{\Gls{fs} Storage Isolation}
 \label{sect:vm-fs-isolation}
-The \gls{OS} running inside a \gls{VM} is typically presented with a virtual disk drive. The guest \gls{OS} has to implement the driver for this virtual disk drive. The drive backed by a file on the host system, which can either be a file on a \gls{fs} or point to a block device.
+The \gls{OS} running inside a \gls{VM} is typically presented with a virtual disk drive.
+The guest \gls{OS} has to implement the driver for this virtual disk drive.
+The drive backed by a file on the host system, which can either be a file on a \gls{fs} or point to a block device.
 By exclusively assigning one virtual disk drive per \gls{VM}, \glspl{VM} not access other \glspl{VM} data.
 
 As a result, the \gls{hypervisor} features full isolation between guest's \gls{fs} and also prevents them from accessing the host's files.
@@ -47,7 +55,8 @@ As a result, the \gls{hypervisor} features full isolation between guest's \gls{f
 \label{sect:virt-overhead-app-virt}
 Compared to running services directly on the host machine, one obvious overhead is that an additional \gls{OS} is required to be installed and configured once upfront, and virtually booted to enable execution of applications within.
 In case that multiple \glspl{VM} are supposed to run the same application, e.g. with different configuration, each of them will have a separate copy of the \gls{OS} and the application itself, differing only by configuration and runtime data.
-For this thesis, the use-case is in which solely the applications running on top of the virtualized \gls{OS} is the required subject to gls{virt} is of highest interest. Further the focus lies on applications that can run on \gls{Linux}.
+For this thesis, the use-case is in which solely the applications running on top of the virtualized \gls{OS} is the required subject to gls{virt} is of highest interest.
+Further the focus lies on applications that can run on \gls{Linux}.
 
 Running a separate virtualized \glspl{OS} in the use-case of virtualizing \gls{Linux} applications involves considerable and unnecessary overhead.
 In addition there are several performance aspects that are slowed down when running software inside \Glspl{VM}\cite{Felter2014}.
@@ -77,22 +86,23 @@ On \gls{Linux}, there are many different mechanisms to regulate a process's acce
 It is important to understand that not all of these mechanisms contribute to security, and that \gls{osvirt} is more difficult to secure compared to \Glspl{VM}.
 
 \subsubsection{The chroot System Functionality}
+\label{sect:lpc-chroot}
 The oldest mechanism contributing a core functionality to realizing containers is the \textit{change root} functionality\cite{Reshetova2014}.
 It allows a privileged process to change its effective root \gls{fs}, which can be any directory on the host.
 Effectively every file accessed by path changing the root \gls{fs} will be prefixed with the new root path automatically by the \gls{OS}.
 As an example, when a process changes its root \gls{fs} to \textit{/newroot} and then requests to open the file \textit{/file}, the application will transparently access \textit{/newroot/file}.
 As a usage example, this allows to easily have a completely separate userspace file structure under \textit{/newroot}.
-It could have an application and different libraries installed, which would possibly be in conflict with other libraries if they were installed in the \gls{rootfs} that's in use by host \gls{OS}.
+Hence, the chroot-path could contain an application and different libraries installed, which would otherwise be in conflict with other libraries if they were installed in the \gls{rootfs} that's in use by host \gls{OS}.
 
 Note that \textit{chroot} has not been designed as a security feature, so if no countermeasures are taken, privileged \textit{chroot}'ed applications can still access files outside of the chroot-path if they have the intention to.
-% TODO practical example?
+
 
 \subsubsection{Namespaces}
 \Glspl{lxns} were designed in 2007 and described as lightweight in-kernel virtualization/isolation\cite{Menage2007}.
 The authors chose to invent a new name instead of using the descriptive term in order to clarify the distinction from the more heavyweight technology of \gls{VM} \glspl{hypervisor}.
 The various \Glspl{lxns} all represent different attributes related to the process and resource model on \gls{Linux}.
 Each namespace can contain one or more processes, allowing for arbitrary grouping of processes sharing.
-Table \ref{tab:lxns} shows 7 different \Glspl{lxns} that are available at the time of writing. 
+Table \ref{tab:lxns} shows 7 different \Glspl{lxns} that are available at the time of writing.
 Collectively, they represent the context of a process, and changes to resources within the respective namespace will only affect processes that share the same namespace.
 
 \ctable[