Appendix A: minor edits to clarify text

While having a fast glance at Appendix A, I noticed two small parts that
could be improved by adding a 'from' and using 'Maneage' instead of "the
proposed solution". They are corrected with this commit.

1 files changed, 2 insertions, 2 deletions

diff --git a/tex/src/appendix-existing-tools.tex b/tex/src/appendix-existing-tools.tex
index 1db9b3f..f22b4ba 100644
--- a/tex/src/appendix-existing-tools.tex
+++ b/tex/src/appendix-existing-tools.tex
@@ -188,7 +188,7 @@ GNU Guix is based on the same principles of Nix but implemented differently, so
 The Nix approach to package management is unique in that it allows exact dependency tracking of all the dependencies, and allows for multiple versions of software, for more details see Dolstra et al.\citeappendix{dolstra04}.
 In summary, a unique hash is created from all the components that go into the building of the package (including the instructions on how to build the software).
 That hash is then prefixed to the software's installation directory.
-As an example Dolstra et al.\citeappendix{dolstra04}: if a certain build of GNU C Library 2.3.2 has a hash of \inlinecode{8d013ea878d0}, then it is installed under \inlinecode{/nix/store/8d013ea878d0-glibc-2.3.2} and all software that is compiled with it (and thus need it to run) will link to this unique address.
+As an example from Dolstra et al.\citeappendix{dolstra04}: if a certain build of GNU C Library 2.3.2 has a hash of \inlinecode{8d013ea878d0}, then it is installed under \inlinecode{/nix/store/8d013ea878d0-glibc-2.3.2} and all software that is compiled with it (and thus need it to run) will link to this unique address.
 This allows for multiple versions of the software to co-exist on the system, while keeping an accurate dependency tree.
 
 As mentioned in Court{\'e}s \& Wurmus\citeappendix{courtes15}, one major caveat with using these package managers is that they require a daemon with root privileges (failing our completeness criterion).
@@ -278,7 +278,7 @@ In conclusion for all package managers, there are two common issues regarding ge
   This is another consequence of the detachment of the package manager from the project doing the analysis.
 \end{itemize}
 
-Addressing these issues has been the basic reason behind the proposed solution: based on the completeness criterion, instructions to download and build the packages are included within the actual science project, and no special/new syntax/language is used.
+Addressing these issues has been the basic reason behind Maneage: based on the completeness criterion, instructions to download and build the packages are included within the actual science project, and no special/new syntax/language is used.
 Software download, built and installation is done with the same language/syntax that researchers manage their research: using the shell (by default GNU Bash in Maneage) for low-level steps and Make (by default, GNU Make in Maneage) for job management.