ReproZip, Popper: minor fixes

This commit contains minor fixes in Appendix B.

ReproZip: As Vicky Rampin points out [1], ReproZip typically also
includes non-binary files, so I removed "just" and improved
the wording.

Popper: the Popper URL that we gave is obsolete; at Wayback
Machine it redirects to getpopper.io [2], so I've updated this;
and I've fixed up the wording ('off of' only exists in US
English).

[1] https://octodon.social/@VickyRampin/106298214313216228
[2] https://web.archive.org/web/20210425223605/http://falsifiable.us/

1 files changed, 4 insertions, 4 deletions

diff --git a/tex/src/appendix-existing-solutions.tex b/tex/src/appendix-existing-solutions.tex
index 62c98e6..75285eb 100644
--- a/tex/src/appendix-existing-solutions.tex
+++ b/tex/src/appendix-existing-solutions.tex
@@ -429,7 +429,7 @@ The tracked files can be packaged into a \inlinecode{.rpz} bundle that can then
 ReproZip is therefore very good to take a ``snapshot'' of the running environment into a single file.
 However, the bundle can become very large when many/large datasets are involved, or if the software environment is complex (many dependencies).
 Since it copies the binary software libraries, it can only be run on systems with a similar CPU architecture to the original.
-Furthermore, ReproZip just copies the binary/compiled files used in a project, it has no way to know how the software was built.
+Furthermore, ReproZip copies the binary/compiled files used in a project, without a way of knowing how the software was built.
 As mentioned in this paper, and also Oliveira et al. \citeappendix{oliveira18} the question of ``how'' the environment was built is critical for understanding the results, and simply having the binaries cannot necessarily be useful.
 
 For the data, it is similarly not possible to extract which data server they came from.
@@ -470,7 +470,7 @@ However, there is one directory that can be used to store files that must not be
 
 \subsection{Popper (2017)}
 \label{appendix:popper}
-Popper\footnote{\inlinecode{\url{https://falsifiable.us}}} is a software implementation of the Popper Convention\citeappendix{jimenez17}.
+Popper\footnote{\inlinecode{\url{https://getpopper.io}}} is a software implementation of the Popper Convention\citeappendix{jimenez17}.
 The Popper team's own solution is through a command-line program called \inlinecode{popper}.
 The \inlinecode{popper} program itself is written in Python.
 However, job management was initially based on the HashiCorp configuration language (HCL) because HCL was used by ``GitHub Actions'' to manage workflows at that time.
@@ -484,8 +484,8 @@ See Appendix \ref{appendix:independentenvironment} for more on containers, and A
 Popper does not comply with the completeness, minimal complexity, and including the narrative criteria.
 Moreover, the scaffold that is provided by Popper is an output of the program that is not directly under version control.
 Hence, tracking future low-level changes in Popper and how they relate to the high-level projects that depend on it through the scaffold will be very hard.
-In Maneage, users start their projects by branching-off of the core \inlinecode{maneage} git branch.
-Hence any future change in the low level features will directly propagated to all derived projects (and be clear as Git conflicts if the user has customized them).
+In Maneage, users start their projects by branching off the core \inlinecode{maneage} git branch.
+Hence any future change in the low level features will be directly propagated to all derived projects (and will appear prominently as Git conflicts if the user has customized them).