问题标签 [binary-reproducibility]

在 $DAYJOB，我正在尝试使用 reproducible-builds.org 中的提示实现可重现的构建，以使调试已发布的软件变得更容易，因为我们的构建服务器上不再有完整的调试版本。

在 GCC 中使用-ffile-prefix-map=/path/to/build=src选项来避免泄漏内部文件路径确实有助于使一些错误消息更清晰，但在使用 GDB 时会产生问题。我在 /path/to/build/some/binary/ 并在 /path/to/build/lib/cclib/ 中遇到断点：

作为一种解决方法，我可以符号链接src到构建树的根目录，但是有没有更好的方法来确保 gdb 理解映射？

为什么keras.Model.save()每次运行都会产生不同的二进制文件，什么时候，AFAIU，我已经采取了所有必要的步骤来完全重现结果甚至二进制文件？

您可以通过简单地在 docker 容器中执行以下脚本来验证这一点。目录的saved_model.pb和 内容variables总是变化的。创建一个容器：
docker run --rm --volume=/host/dir/with/script:/workspace -it tensorflow/tensorflow:2.4.1 bash

谢谢。

通过 nix 包管理器（在 nixos 上）安装了乳胶，\today 总是扩展到 1979 年 12 月 31 日。我如何让它返回正确的日期？

MWE 创建一个目录并添加 mwe.tex 和 flake.nix（基于https://flyx.org/nix-flakes-latex/）。

-- mwe.tex --

-- mwe.tex 到此结束 --

-- flake.nix --

-- flake.nix 到此结束 --

然后nix build "."在新目录中运行。结果应该是包含 1979 年 12 月 31 日的 pdf 文件（或者当我刚刚运行它时，我实际上得到了 1980 年 1 月 1 日）。

是否有一个 linter/helper 警告 Go 程序中的非确定性行为？我的目标是在用于可重现构建的工具中获得可重现的输出。我希望 linter 警告使用随机数生成器、使用time.Now()、遍历映射和选择语句的循环等。

我在 Docker 容器中运行一些 Python statsmodel 代码。当我在两台不同的计算机上运行此代码时（使用从 DockerHub 中提取的同一个 Docker 容器，而不是在本地构建 2x），我得到了不同的结果。差异很小 - 第 10 位或第 15 位发生变化。但它正在破坏我们可重现的构建。这是 Python statsmodel 问题吗？一个 Docker 问题？

我认为这是 Python，因为在从这些 Docker 映像生成的容器中运行着 1000 多条其他行，并且它们是可重现的。

这是一个 MWE，以及差异示例：

并且差异out.csv很小。例如，

显示以下内容。请注意，只有最后一位数字发生了变化。

我担心将来正在运行的代码可能会失败。我已经看到tidyverse运行良好但一段时间后返回错误的函数，因为它们已经失效了。要给出一些可重现的示例，请尝试如何制作一个伟大的 R 可重现示例中的这段代码，具有讽刺意味的是，它不再可重现（比较原始帖子的值age和x与原始帖子的值）：

问题

是否只有在更新相同的代码返回不同输出的情况下？换句话说：包及其R本身通常不会自动更新，这是否意味着只要我不手动更新任何东西，我就可以重新运行一个“永恒”的功能？有什么例外吗？

为什么我问

我bcrypt使用R. 我们需要加密数据并删除原始数据。一旦完成，就没有回头路了，即我真的必须相信代码。我不使用 pacakges 但bcrypt,shiny和shinydashboard.

编辑

我的问题假设代码在同一系统上运行而不更改全局设置（在@qdread 的评论后编辑）而不更改 R 版本。

我的工作细节：我处理患者数据。首先，我为每位患者选择一个由字母和数字组成的随机 ID，A72CV例如Max Cooper 1987-05-03. 在下一步中，我使用bcrypt为每个患者创建盐，然后使用盐创建 ID 的散列/加密版本（盐 + ID = 加密 ID）。因此，每个患者都有姓名 + 出生日期、随机字母/数字 ID、盐（使用 生成salt <- bcrypt::gensalt(log_rounds = 12)）和加密 ID（使用生成id_encrypted <- bcrypt::hashpw(id, salt = salt)）。我将数据保存在三个单独的文件中：(i) 患者数据，即姓名和出生日期，以及加密的 ID，(ii) ID 和盐以及 (iii) 带有 ID 和一些感兴趣的变量的实际数据库，例如吸烟者/重量，... 这种方法是在我工作的环境中被一些机构推荐的，它被称为假名化（一种可逆加密）。它确保即使存在数据泄漏，识别变量名称 + 生日与所有感兴趣的变量（吸烟者，...）之间也没有明显的联系。我制作了一个 ShinyApp，允许我的同事（1）提供 ID 并查找姓名 + 出生日期，（2）提供姓名 + 出生日期并查找 ID，以及（3）为新患者生成一个 ID。这一切都有效，因为具有相同盐的相同 ID 会产生相同的加密（散列）ID - 至少现在是这种情况。但是，如果将来由于某些原因，相同的输入（例如 ID）不会返回相同的输出（例如姓名 + 生日），那我就完蛋了。另一方面，如果随机ID的生成会随着时间而改变，这不是一个大问题，因为每个ID只被创建和保存一次，即这个过程不必是可重现的。所描述的加密方法将应用于我的机构多年收集的一些数据库。如果我们不能重新创建数据，一切都会丢失。这就是为什么代码稳定性对我如此重要的原因。我会在同事的windows电脑上安装shinyApp。他们只会打 如果随机 ID 的生成会随着时间而改变，这不是一个大问题，因为每个 ID 只创建和保存一次，即这个过程不必是可重现的。所描述的加密方法将应用于我的机构多年收集的一些数据库。如果我们不能重新创建数据，一切都会丢失。这就是为什么代码稳定性对我如此重要的原因。我会在同事的windows电脑上安装shinyApp。他们只会打 如果随机 ID 的生成会随着时间而改变，这不是一个大问题，因为每个 ID 只创建和保存一次，即这个过程不必是可重现的。所描述的加密方法将应用于我的机构多年收集的一些数据库。如果我们不能重新创建数据，一切都会丢失。这就是为什么代码稳定性对我如此重要的原因。我会在同事的windows电脑上安装shinyApp。他们只会打run AppR然后执行前面描述的选项之一（1 到 3）。