From 6ab5696481366659f0120f05033b5ed7bbd944a8 Mon Sep 17 00:00:00 2001
From: Mohammad Akhlaghi <mohammad@akhlaghi.org>
Date: Wed, 12 May 2021 02:38:15 +0100
Subject: Implemented changes of first proof by CiSE

A few days, CiSE gave us a proof of the edited text and formatted
PDF. After comparing the edited text with our text, I noticed some minor
editorial issues that have been corrected in this commit. The parts that
were wrong (or could be improved in the proof) have been listed and will be
submitted to the journal.

In particular, following the recommendation from the editor, the
biographies were extended with a full listing of each author's affiliation,
I also added our ORCID IDs in the biographies.
---
 tex/src/appendix-existing-tools.tex | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'tex/src/appendix-existing-tools.tex')

diff --git a/tex/src/appendix-existing-tools.tex b/tex/src/appendix-existing-tools.tex
index 8ad97ef..3aba534 100644
--- a/tex/src/appendix-existing-tools.tex
+++ b/tex/src/appendix-existing-tools.tex
@@ -193,8 +193,8 @@ This allows for multiple versions of the software to co-exist on the system, whi
 
 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 criteria).
 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 bit-wise identical (for example when they are installed in other locations, because the installation location is hard-coded in the software binary or for a different CPU architecture).
+This is because the focus in Nix or Guix is to create bitwise 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 hard-coded in the software binary or for a different CPU architecture).
 
 Finally, while Guix and Nix do allow precisely reproducible environments, the inherent detachment from the high-level computational project (that uses the environment) requires extra effort to keep track of the changes in dependencies as the project evolves.
 For example, if users simply run \inlinecode{guix install gcc} (the most common way to install a new software) the most recent version of GCC will be installed.
@@ -253,7 +253,7 @@ However, these same factors are major caveats in a scientific scenario, where lo
 
 \subsubsection{Spack}
 Spack\citeappendix{gamblin15} is a package manager that is also influenced by Nix (similar to GNU Guix).
-But unlike Nix or GNU Guix, it does not aim for full, bit-wise reproducibility and can be built without root access in any generic location.
+But unlike Nix or GNU Guix, it does not aim for full, bitwise reproducibility and can be built without root access in any generic location.
 It relies on the host operating system for the C library.
 
 Spack is fully written in Python, where each software package is an instance of a class, which defines how it should be downloaded, configured, built, and installed.
-- 
cgit v1.2.1

