EuroSys 2024是EuroSys会议包括Artifact Evaluation（AE）流程的第四届，其中，允许作者提交与论文中讨论的研究工作相关的实物。

科学论文通常包含超出论文范围的实物：软件、硬件、数据和文档、原始调查结果、机械化证明、模型、测试套件、基准测试等等。AE流程促进了科学论文实验结果的可重现性。

实物的传播有益于整个科学。首先，它鼓励复制和复现，使科学家能够扩展先前的工作，并解决原始作者未考虑到的问题。对于作者来说，发表一个实物可以影响同行们在其基础上构建、使用它作为比较点，并提出合作建议的便利程度。

EuroSys的AE流程承认那些努力使他们的工作对他人可重用和可复制的作者，帮助社区快速验证和比较替代方法。这包括作者公开提供实物的努力，以及以便于重用的方式记录和打包他们的工作，并设计实验使其可以被其他研究人员重复并重现结果。

在EuroSys 2024中，AE是可选的。被接受的论文的作者可以选择在接收通知后不久提交他们的实物，尽管鼓励作者提前准备好实物。每个实物在作者通知和最终提交截止日期之间由Artifact Evaluation Committee（AEC）进行审查。通过实物评估流程的论文会在附录中详细说明实物，并在论文的首页上展示一个或多个徽章以示认可。

Badges

已提交的实物可以选择根据ACM Artifact Review and Badging policy v1.1评估以下徽章：

• 工件可访问：与本论文相关的作者创建的实物已放置在可公开访问的存档库中。提供该存储库的DOI或链接以及对象的唯一标识符。
• 工件可评估：与研究相关的实物被发现有文档记录，一致，完整，可执行，并包含适当的验证和验证证据。
• 工件可复现：论文的主要结果已由第三方在后续研究中获得，其中部分使用了作者提供的实物。

Checklists

不幸的是，工件有时会错过徽章，因为它们没有在干净的设置上进行测试，或者没有充分的记录，或者因为运行实验由于复杂的手动步骤而太容易出错。 下面我们为作者提供了清单，以最大限度地降低工件不必要地丢失徽章的风险。

工件可访问

• 该工件可在具有特定版本（如 git commit）的公共网站上获得
• 工件有一个“自述”文件，其中包含对论文的引用
• 工件具有关联的许可证，理想情况下，该许可证至少允许用于比较目的
• 工件在评估时必须满足这些标准。 对未来可用性的承诺，例如“临时”封闭在提供给评估人员的凭据后面的工件，没有资格获得徽章。

工件可评估

• 包含高级文档的“自述”文件
  • 描述，例如哪些文件夹对应于代码、基准测试、数据等
  • 支持的环境列表，包括操作系统、特定硬件（如有必要）
  • 编译和运行说明，包括依赖项和预安装步骤，具有合理程度的自动化，例如下载和构建异国情调依赖的脚本
  • 配置说明，例如选择 IP 地址或磁盘
  • 使用说明，例如分析新数据集
  • “最小工作示例”的说明
• 工件有解释模块高级组织的文档，以及解释不明显代码的代码注释，以便其他研究人员可以完全理解它
• 该工件包含论文使用与论文相同的术语描述的所有组件，并且没有过时的代码/数据 如果项目包含容器/VM，则它还必须包含从头开始创建它的脚本
• 工件必须可在作者以外的其他计算机上使用，尽管它们可能需要特定网卡等硬件。不得对 IP 地址等信息进行硬编码。

工件可复现

• 有一个“自述文件”，其中记录了
  • 作者使用的确切环境，包括操作系统版本和任何特殊硬件
  • 运行以重现论文中每个声明的确切命令
  • 每个声明使用的近似资源，例如“5分钟，1GB磁盘空间”
  • 复制声明的脚本被记录在案，使研究人员能够确保它们与声明相对应；仅仅产生正确的输出是不够的
• 工件的外部依赖项是从官方网站或GitHub存储库等知名来源获取的
• 对此类依赖项的更改应明确分开，例如使用具有清晰提交历史记录的补丁文件或存储库分支
• 应合理减少手动工作量，例如编写配置文件。特别是，不应有冗余的手动步骤，例如在多个位置写入相同的配置值，因为这不可避免地会导致人为错误。

Artifact Packaging

必须对工件进行打包以简化评估和使用，包括工件说明和工件附录。 打包不仅关乎评估，还关乎其他研究人员未来对工件的使用，他们可能希望在工件之上进行构建或将其用作基线。

我们在下面提供了一些关于打包工件的指南。 如果您对如何最好地包装您的工件有其他疑问，请联系 [email protected] 的 AEC 主席。

注意：某些项目可能会尝试通过设计执行恶意或破坏性操作。 这些情况应在提交时（在项目说明和附录中）进行大胆且明确的详细标记，以便 AEC 可以在安装和运行这些项目之前采取适当的预防措施。如果您认为您的文物属于此类别，请联系 AEC 主席。

Instructions

工件包必须包含明显的“自述”文档，其中包含适当的说明和文档。 没有快速教程的工具通常很难使用。同样，如果没有一些关于如何浏览数据的解释，数据集是无用的。 请参阅徽章页面，了解有关说明应包含的内容的更多详细信息。

Artifacts Appendix

工件附录是一个独立的文档，它描述了评估人员的路线图。这尤其包括对硬件、软件和配置要求的描述，以及论文中可通过工件复制的主要声明列表。

将论文的声明与工件联系起来是必要的步骤，允许工件评估人员重现您的结果。最重要的是，你要清楚地陈述你的论文的关键结果和主张。此外，要具体说明您对文物的主张。 如果您认为这些主张与您的论文设定的期望不同，这一点尤其重要。 AEC 仍将评估您的工件与您的论文相关，但您的解释有助于预先设定期望，尤其是在可能让评估人员感到沮丧的情况下，恕不另行通知。 例如，告诉 AEC 他们在使用工件时可能遇到的困难或其相对于论文内容的成熟度。

工件附录必须提供有关在论文中运行实验所需的时间和硬件资源（例如存储）的详细信息。 如果可能的话，附录还应该描述如何将复制的实验结果与论文中发现的结果进行比较（例如，通过提供对结果的基础数据集的访问）。

工件附录的意图是与您的工件一起发布。 工件附录的模板可以在这里找到：LaTeX 模板（与 EuroSys'24 模板结合使用，用于研究论文）。

工件附录限制为 2 页。

Format

作者应考虑以下方法之一来打包其工件的软件组件 （尽管 AEC 也对其他合理的格式开放）：

• 容器/虚拟机：这是首选方法。我们建议使用易于评估器使用的格式，例如 Docker 映像或 OVF 虚拟机（例如，在 VirtualBox 中运行）。 AWS EC2 实例也是可能的。在任何情况下，用于初始化虚拟机的 Dockerfile 或脚本都应该可用。 Docker 映像或虚拟机应已设置正确的工具链和运行时环境。例如：
  • 对于原始数据，容器/虚拟机将包含数据和分析脚本。
  • 对于机械化证明，容器/VM 将包含相关定理证明器的正确版本
  • 对于移动电话应用程序，VM 将安装电话模拟器
• 源代码：如果您的项目具有很少的依赖项，并且可以轻松安装在多个操作系统上， 您可以提交源代码和构建脚本。但是，如果您的项目有一长串依赖项，请使用以下其他格式之一。
• Web 上的实时实例：确保它在项目评估过程中可用。
• 可上网的硬件：如果您的项目需要特殊硬件（例如，SGX 或其他受信任的执行环境），或者如果您的项目实际上是一个硬件，请确保评估器可以访问该设备。可以选择对设备进行基于 SSH 或 VPN 的访问。
• 截屏视频：如果以下特殊情况之一适用，可以选择工具的详细截屏视频以及结果：
  • 工件需要专有/商业软件或专有数据，这些软件或专有数据不容易获得或无法分发给委员会。
  • 工件需要大量的计算资源（例如，超过 24 小时的执行时间来生成结果）或需要庞大的数据集。
  • 项目需要特定的硬件或软件，这些硬件或软件在典型实验室中通常不可用，并且无法以合理的方式提供访问权限。
  • 如果您的文物属于此类别，请尽快联系 [email protected] 的 AEC 主席。

Tools

GitHub 和 GitLab 是托管工件的 Git 存储库的不错选择。Zenodo 为特定版本提供长期存储和 DOI，这在评估您的工件后非常有用。Docker 允许您创建包含所有项目依赖项的轻量级容器，甚至可以编写脚本以在本地管理多个容器，而不是使用云提供商。

有关具体提示，请参阅提示部分。

还有越来越多的工具和机制是专门为满足研究可重复性的需求而设计的;作者可能要考虑在适当的时候使用此类工具。部分列表包括：

• Popper：用于自动化工作流的容器原生系统
• CloudLab 配置文件：一种在 CloudLab 设施上封装和共享研究环境的机制（如果您打算使用 CloudLab，请事先联系 AEC 主席）
• Chameleon Jupyter 笔记本：在Chameleon Cloud设施上运行的共享研究机制（如果您打算使用Chameleon Cloud，请事先联系AEC主席）

Tips

我们感谢 EuroSys'22 AEC 主席提供以下材料。

在准备项目时，以下指南将非常有用：

• AEC 提交者的指南，作者：Dan Barowy、Charlie Curtsinger、Emma Tosch、John Vilk 和 Emery Berger
• 工件评估：给作者的提示，作者：Rohan Padhye

您可能还会发现这些过去工件的示例很有用：

• Bundler，一个中间盒及其多机器基准测试（EuroSys'21）
• Serval，一种验证工具，具有正确且有缺陷的代码来测试它 （SOSP'19）
• TinyNF，具有低级多计算机基准测试 （OSDI'20） 的网络驱动程序

以下是一些一般提示，可使工件作者和评估者的工作更轻松：

• 尽可能地自动化，最终您将节省大量时间，而不必重新运行遭受人为错误的实验。 即使对于需要多个节点或在多个位置复制配置的项目，这也是可行的。 有关使用 Docker 实现项目自动化的示例，请参阅此存储库。

• 按照您记录的步骤，在空白环境中试用您自己的项目。 执行此操作的一种轻量级方法是从基本操作系统映像创建 Docker 容器，例如 . 如果具有基础结构，还可以使用虚拟机，甚至可以预配真实计算机。ubuntu:latest

• 记录成功和失败，以便用户知道发生了某些事情。 避免记录不必要或令人困惑的信息，例如实际预期的详细输出或故障。 记录潜在问题，例如不存在可选但推荐的库。

使用 mpstat, iostat, vmstat, 和 ifstat 等工具测量资源使用情况，并在 Linux 上分别测量 CPU、I/O、内存和网络使用情况。 或用 /usr/bin/time -v 在 Linux 上测试使用的时间和内存。 这让用户知道会发生什么。

最后更新于 2024-03-07 13:46:36 并被添加「EuroSys 文章发表」标签，已有 717 人阅读过。