Spell check on main body and appendices

I ran a simple Emacs spell check over the main body and the two
appendices. All discovered typos have been fixed.

1 files changed, 4 insertions, 4 deletions

diff --git a/tex/src/appendix-existing-tools.tex b/tex/src/appendix-existing-tools.tex
index 5920fbd..d923d5f 100644
--- a/tex/src/appendix-existing-tools.tex
+++ b/tex/src/appendix-existing-tools.tex
@@ -120,7 +120,7 @@ However, attempting to archive the actual binary container or VM files as a blac
 \subsubsection{Independent build in host's file system}
 \label{appendix:independentbuild}
 The virtual machine and container solutions mentioned above, have their own independent file system.
-Another approach to having an isolated analysis environment is to use the same filesystem as the host, but installing the project's software in a non-standard, project-specific directory that does not interfere with the host.
+Another approach to having an isolated analysis environment is to use the same file system as the host, but installing the project's software in a non-standard, project-specific directory that does not interfere with the host.
 Because the environment in this approach can be built in any custom location on the host, this solution generally does not require root permissions or extra low-level layers like containers or VMs.
 However, ``moving'' the built product of such solutions from one computer to another is not generally as trivial as containers or VMs.
 Examples of such third-party package managers (that are detached from the host OS's package manager) include Nix, GNU Guix, Python's Virtualenv package, and Conda, among others.
@@ -189,7 +189,7 @@ This allows for multiple versions of the software to co-exist on the system, whi
 As mentioned in \citeappendix{courtes15}, one major caveat with using these package managers is that they require a daemon with root privileges.
 This is necessary ``to use the Linux kernel container facilities that allow it to isolate build processes and maximize build reproducibility''.
 This is because the focus in Nix or Guix is to create bit-wise reproducible software binaries and this is necessary for the security or development perspectives.
-However, in a non-computer-science analysis (for example natural sciences), the main aim is reproducible \emph{results} that can also be created with the same software version that may not be bitwise identical (for example when they are installed in other locations, because the installation location is hardcoded in the software binary).
+However, in a non-computer-science analysis (for example natural sciences), the main aim is reproducible \emph{results} that can also be created with the same software version that may not be bit-wise identical (for example when they are installed in other locations, because the installation location is hard-coded in the software binary).
 
 Finally, while Guix and Nix do allow precisely reproducible environments, it requires extra effort.
 For example, simply running \inlinecode{guix install gcc} will install the most recent version of GCC that can be different at different times.
@@ -310,7 +310,7 @@ For example \inlinecode{f4953cc\-f1ca8a\-33616ad\-602ddf\-4cd189\-c2eff97b} is a
 Commits are is commonly summarized by the checksum's first few characters, for example, \inlinecode{f4953cc}.
 
 With Git, making parallel ``branches'' (in the project's history) is very easy and its distributed nature greatly helps in the parallel development of a project by a team.
-The team can host the Git history on a webpage and collaborate through that.
+The team can host the Git history on a web page and collaborate through that.
 There are several Git hosting services for example \href{http://codeberg.org}{codeberg.org}, \href{http://gitlab.com}{gitlab.com}, \href{http://bitbucket.org}{bitbucket.org} or \href{http://github.com}{github.com} (among many others).
 Storing the changes in binary files is also possible in Git, however it is most useful for human-readable plain-text sources.
 
@@ -488,7 +488,7 @@ Integration of directional graph features (dependencies between the cells) into
 The fact that the \inlinecode{.ipynb} format stores narrative text, code, and multi-media visualization of the outputs in one file, is another major hurdle and against the modularity criteria proposed here.
 The files can easily become very large (in volume/bytes) and hard to read.
 Both are critical for scientific processing, especially the latter: when a web browser with proper JavaScript features is not available (can happen in a few years).
-This is further exacerbated by the fact that binary data (for example images) are not directly supported in JSON and have to be converted into much less memory-efficient textual encodings.
+This is further exacerbated by the fact that binary data (for example images) are not directly supported in JSON and have to be converted into a much less memory-efficient textual encoding.
 
 Finally, Jupyter has an extremely complex dependency graph: on a clean Debian 10 system, Pip (a Python package manager that is necessary for installing Jupyter) required 19 dependencies to install, and installing Jupyter within Pip needed 41 dependencies.
 \citeappendix{hinsen15} reported such conflicts when building Jupyter into the Active Papers framework (see Appendix \ref{appendix:activepapers}).