Clarification and add more references

resources/typst/ch3-table-conclusion.typ

@@ -24,7 +24,7 @@
     [Environment],
     table.hline(stroke: .5pt),
   ),
-  table.cell(align: horizon + left)[1. #link(<ch3-tool1>)[Bare compilation]],
+  table.cell(align: horizon + left)[1. #link(<ch3-tool1>)[Bare\ compilation]],
   [
     - Full control over compilation
     - Direct understanding of dependencies inherited from host system
@@ -58,12 +58,12 @@
     - Immutable software environments
     - Isolation and environment reproducibility
     - No containerization overhead
+    - Prone to long-term reproducibility
   ],
   [
     - Steep learning curve
     - Paradigm shift from traditional package management systems required
-    - Very limited package availability
-    - Unfree packages are not officially allowed
+    - Limited repository of packages
   ],
   table.cell(align: horizon + center, rowspan: 2, text(size: 2em)[\u{2713}]),
   table.cell(align: horizon + center, rowspan: 2, text(size: 2em)[\u{2713}]),
@@ -76,7 +76,7 @@
     - Immutable software environments
     - Isolation and environment reproducibility
     - No containerization overhead
-    - Vast repository of packages, unfree packages are authorized.
+    - Vast repository of packages
   ],
   [
     - Steep learning curve

src/thesis/2-reproducibility.typ

@@ -115,7 +115,7 @@ According to @ESSAWY2020104753, reproducibility is organised in four levels:
 
 - *Repeatability*: Achieved upon obtaining consistent results using the same
   input data, computational steps, methods, and code on the original
-  researcher’s machine. This level is normally achieved in scientific papers.
+  researcher's machine. This level is normally achieved in scientific papers.
 - *Runnability*: Achieved when the author of the research can obtain consistent
   results using the same input data, computational steps, methods, code and
   conditions of analysis on a new machine.
@@ -176,7 +176,7 @@ necessitates an incremental investment of resources, time, and effort.
 
 #info-box(kind: "cite", footer: [@Barba2018])[
   In their vision of reproducible research, readers should be able to rebuild
-  published results using the author’s underlying programs and raw data.
+  published results using the author's underlying programs and raw data.
   Implicitly, they are advocating for open code and data.
 ]
 
@@ -230,7 +230,7 @@ distinct category.
   using the same measurement procedure, the same measuring system, under the
   same operating conditions, in the same or a different location on multiple
   trials. For computational experiments, this means that an independent group
-  can obtain the same result using the author’s own artefacts.
+  can obtain the same result using the author's own artefacts.
 ]
 
 The term #emph[reproducibility] in the context of #gls("CS") has been refined
@@ -490,7 +490,7 @@ and #emph[Reproducible] boundaries.
 
 #info-box(kind: "cite", footer: [@Donoho2009])[
   If everyone on a research team knows that everything they do is going to
-  someday be published for reproducibility, they’ll behave differently from day
+  someday be published for reproducibility, they'll behave differently from day
   one. Striving for reproducibility imposes a discipline that leads to better
   work.
 ]
@@ -529,7 +529,7 @@ and trust in scientific research.
 
 Furthermore, open-source software promotes a culture of collaboration and
 community involvement. Active communities that grow around open-source projects
-contribute to the software’s continual improvement. This community-driven
+contribute to the software's continual improvement. This community-driven
 development leads to the identification and resolution of bugs, thereby
 enhancing the software's reliability and, consequently, the reproducibility
 outcomes that depend on it.
@@ -1469,10 +1469,11 @@ Package managers are tools that automate the process of installing, upgrading,
 configuring, and removing packages, typically from a central repository or
 package registry. They are widely used in software development to manage
 dependencies and facilitate the build process. For example, `Cargo` for Rust,
-`Composer` for PHP, `NPM` for NodeJS, `Dune` for OCaml. They are also used to
-manage software at the operating system level like: `apt` in Debian based
-distributions, `pacman` in Arch Linux, `dnf` in Fedora, `brew` in macOS,
-`chocolatey` in Windows.
+`Composer` for PHP, `NPM` for NodeJS, `Dune` for OCaml, `tlmgr` for #LaTeX.
+Package managers are also used to manage software at the operating system level
+like: `apt` in Debian based distributions, `pacman` in Arch Linux, `dnf` in
+Fedora, `brew` in macOS, `chocolatey` in Windows
+#cite(<9403875>, form: "normal", supplement: [p. 10]).
 
 Package managers can inadvertently introduce non-determinism by automatically
 downloading or updating dependencies to their latest versions. This process can
@@ -1526,21 +1527,26 @@ issue applies to operating system's package managers. For example, in Debian
 based distributions, there are multiple package managers: `apt`, `aptitude`,
 `dpkg`.
 
-The solution would be to use a universal package manager that would work for all
-Linux distributions and programming languages. This is what tools like
-`AppImage`, `snap` and `flatpak` are trying to solve, only at the level of the
-operating system. These tools are partially fixing the issue by just being
-available only for installing package at the operating system level.
-
-These tools, while being a step in the right direction, are also coming with
-their own set of issues, like the lack of standardisation between them, the lack
-of adoption and the lack of support from major distributions.
-
-There are also package managers like `Nix` and `Guix` that are trying to solve
-the issue by being universal. They provide a way to build and install packages
-in a sandboxed environment, which means that packages are isolated from the rest
-of the system at build time. This is a great way to ensure reproducibility, we
-will discover them in @chapter4
+A potential solution would be to use a universal package manager that would work
+across all Linux distributions and programming languages. Tools like `AppImage`,
+`snap` and `flatpak` aim to address this challenge, albeit at the operating
+system level. These tools simplify the process of transferring a single piece of
+software and its pre-built dependencies to various systems. However, they do not
+include the C library, leading to potential compatibility issues on newer or
+older systems, depending on the version on which the software was originally
+built #cite(<9403875>, form: "normal", supplement: [p. 11]). Furthermore, while
+these tools represent a step in the right direction, they introduce their own
+set of challenges, such as a lack of standardisation among them, limited
+adoption, and insufficient support from major distributions.
+
+There are also package managers such as `Nix` and `Guix` that tackle the issue
+by being independent and universal. These can be installed and used on GNU/Linux
+operating systems, with Nix additionally supporting macOS and FreeBSD. These
+package managers offer a method to build and install packages within a sandboxed
+environment, thereby isolating them from the rest of the system during build
+time #cite(<9403875>, form: "normal", supplement: [p. 11]). This approach
+significantly enhances reproducibility. We will explore these package managers
+further in @chapter4.
 
 ==== Version Information
 

src/thesis/3-tools.typ

@@ -360,10 +360,11 @@ container images and a runtime environment, aiming to create a standard that
 supports portability and consistency across various platforms and cloud
 environments.
 
-Due to its popularity, Docker is a key player in modern software development,
-enabling efficient, consistent, and scalable applications through
-containerization, supporting agile and #gls("DevOps") practices, and
-accelerating the transition from development to production.
+Due to its popularity #cite(<9403875>, form: "normal", supplement: [p. 9]),
+Docker is a key player in modern software development, enabling efficient,
+consistent, and scalable applications through containerization, supporting agile
+and #gls("DevOps") practices, and accelerating the transition from development
+to production.
 
 #figure(
   sourcefile(
@@ -413,7 +414,8 @@ reliable in the short term, can face challenges over time. Docker images are
 built on layers, often starting from base images provided by specific vendors.
 These base images can receive updates that alter their contents, meaning a
 `Dockerfile` that successfully built an image at one time might not produce an
-identical image later due to changes in its base layers. Additionally, not
+identical image later due to changes in its base layers
+#cite(<9403875>, form: "normal", supplement: [p. 1]). Additionally, not
 pinning specific versions of base images and external dependencies in the
 `Dockerfile` can lead to inconsistencies, making the exact reproduction of a
 Docker environment challenging if not managed carefully. Therefore, while Docker
@@ -491,7 +493,7 @@ closer to achieving true reproducibility in containerised environments.
 user-controlled, and transparent package management. It leverages functional
 programming concepts to ensure reproducibility and reliability, using the GNU
 Guile #cite(<guile>, form:"normal") programming language for its core daemon,
-package definitions and system configurations (@courtes2013functional).
+package definitions and system configurations #cite(<courtes2013functional>,form:"normal").
 
 Central to Guix's philosophy is the concept of reproducible builds and
 environments. This ensures that software can be built in a deterministic manner,
@@ -501,15 +503,41 @@ and libraries, in a way that they can be precisely recreated. It supports
 transactional package upgrades and rollbacks, making system modifications
 risk-free by allowing users to revert to previous states easily.
 
-Guix uses @guile, a Scheme #cite(<dybvig2009scheme>, form:"normal")
-implementation, allowing for more expressive and programmable package
-definitions. This choice reflects Guix’s emphasis on customization and alignment
-with the @fsfwebsite project's philosophy, rejecting proprietary blobs and
-aiming for complete software freedom, which may limit hardware compatibility.
-Guix’s approach can pose a high entry barrier due to its use of a
-general-purpose functional programming language but offers extensive flexibility
-for those familiar with Lisp-like languages. That said, users are free to extend
-Guix with custom packages, free or not.
+Guix uses GNU Guile #cite(<guile>,form:"normal"), a Scheme
+#cite(<scheme>,form:"normal") implementation, allowing for more expressive and
+programmable package definitions. This choice reflects Guix's emphasis on
+customization and alignment with the @fsfwebsite project's philosophy, rejecting
+proprietary blobs and
+aiming for complete software freedom, which may limit hardware compatibility but
+enhance long-term reproducibility #cite(<9403875>,form:"normal"). Nonetheless,
+users have the liberty to extend Guix with custom packages, whether free or not,
+without compromising the tool's reproducibility capabilities. In case of
+disappearing upstream sources, Guix can leverage Software Heritage
+#cite(<swh>, form:"normal") to retrieve source code, ensuring long-term
+accessibility even if the original source disappears. While Guix's reliance on a
+general-purpose functional programming language may present a steep learning
+curve, it offers extensive flexibility for those proficient in Lisp-like
+languages.
+
+#info-box(kind: "note", ref: "info-box-proprietary-software")[
+  Proprietary software does not expose its source code to the public, which may
+  seem counter-intuitive to the principles of reproducibility. Proprietary
+  software "typically cannot be distributed, inspected, or modified by others.
+  It is, thus, reliant on a single supplier and prone to proprietary
+  obsolescence" #cite(<9403875>, form: "normal", supplement: [p. 3]).
+
+  Ensuring the reproducibility of such software is challenging, as users lack
+  access to the build process and the software's lifespan is often limited due
+  to its proprietary nature. Pre-built binaries will work only as long as there
+  are no breaking changes in dependencies like the GNU C library, making their
+  reproducibility capabilities time-limited.
+
+  Being aware of the broader implications of using proprietary software is
+  crucial but does not necessarily compromise reproducibility at short term.
+  However, relying on proprietary software for long-term reproducibility is
+  risky due to the lack of transparency and control over the software's
+  evolution.
+]
 
 Guix is committed to ensuring reproducibility and reliability, based on the
 functional deployment model first introduced by @Dolstra2006. It assures