pith. sign in

arxiv: 2604.10411 · v1 · submitted 2026-04-12 · 💻 cs.DC

CIR: Lightweight Container Image for Cross-Platform Deployment

Fengzhi Li , Xiaohui Peng , Qingru Xu , Qisong Shi , Tuo Zhou , Yongxuan Dai , Yifan Wang , Ninghui Sun
show 1 more author
Zhiwei Xu
This is my paper

Pith reviewed 2026-05-10 16:12 UTC · model grok-4.3

classification 💻 cs.DC
keywords container imagecross-platform deploymentlazy buildinterpreted languagesmachine learning deploymentcloud computingedge computingdependency resolution
0
0 comments X

The pith

A single lightweight container image can run on any platform by storing only dependency identifiers and assembling the rest at launch.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Developers typically build and store separate large container images for each target platform when deploying machine learning code written in interpreted languages such as Python. The paper introduces a lazy-build method that keeps the image itself platform-independent by recording only the identifiers of direct dependencies rather than the full platform-specific packages. At deployment time on a given machine, a builder resolves those identifiers into the correct local components and starts the container. This approach matters for cloud, edge, and sky-computing settings where the same workload must move across heterogeneous hardware without repeated image preparation.

Core claim

The authors present CIR, a container intermediate representation that stores the application and the identifiers of its direct dependencies while leaving platform adaptation to a lazy-builder invoked at deployment. A pre-builder creates the CIR once, after which the lazy-builder fetches and installs the appropriate platform-specific dependencies on the target system to produce a runnable container. This separation allows one CIR file to serve multiple platforms.

What carries the argument

The lazy-builder, which receives the stored dependency identifiers and assembles the matching platform-specific packages into a container at deployment time.

If this is right

  • One CIR file suffices for deployment on any supported heterogeneous platform.
  • Stored image size drops by 95 percent compared with conventional images that bundle full dependencies.
  • Deployment time decreases by 40 to 60 percent relative to using pre-built platform-specific images.
  • The method outperforms existing container systems including Docker, Buildah, and Apptainer on the reported metrics for interpreted-language workloads.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Teams running the same application across cloud and edge devices could maintain and distribute fewer image files.
  • Registry storage and transfer costs would fall for organizations supporting many hardware architectures.
  • The separation of identifier storage from runtime assembly could simplify updates when new platform versions become available.

Load-bearing premise

The lazy-builder can always correctly resolve and assemble the platform-specific dependencies from the stored identifiers at deployment time without errors, version conflicts, or missing base components across all target platforms and dependency graphs.

What would settle it

A deployment of a CIR image on a target platform whose package repository has updated or renamed a required dependency, causing the lazy-builder to fail with a resolution or installation error.

Figures

Figures reproduced from arXiv: 2604.10411 by Fengzhi Li, Ninghui Sun, Qingru Xu, Qisong Shi, Tuo Zhou, Xiaohui Peng, Yifan Wang, Yongxuan Dai, Zhiwei Xu.

Figure 1
Figure 1. Figure 1: (Up) Conventional container image is platform￾specific, and multiple images have to be built for each CPU and GPU combination. (Down) CIR is cross-platform, and a single CIR can be built into different container instances in different deployment platforms. In contrast, emerging distributed computing paradigms such as sky computing [52], multi-cloud computing [23], and edge com￾puting [50] advocate cross-pl… view at source ↗
Figure 2
Figure 2. Figure 2: When deploying the YOLO11 project, the lazy-build [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Building the image of YOLO11 project with Docker. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: (Left) Current image builder manages container con￾tent via environment managers. (Right) Lazy-builder directly assembles containers from uniform components. platform, the cross-platform application and its dependency speci￾fication are pre-built into a CIR. Then on the deployment platform, the dependency specification guides the lazy-builder to combine the actual required software components with the appl… view at source ↗
Figure 5
Figure 5. Figure 5: Overview of the CIR build system. (Upper Left) On the development platform, the pre-builder packages the application into a CIR. (Lower Left) On the deployment platform, the lazy-builder resolves dependencies described in the CIR and assembles uniform components into a container. If a required component is locally unavailable, the deployment platform sends the request to the uniform component service. (Rig… view at source ↗
Figure 6
Figure 6. Figure 6: The image size for CPU and GPU platforms. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: Build times of YOLO11 project under different num [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Build times for the benchmark suite on CPU and GPU servers, showing build time ( [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Pairwise sharing rate within benchmark suite. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
read the original abstract

In modern cloud and heterogeneous distributed infrastructures, container images are widely used as the deployment unit for machine learning applications. An image bundles the application with its entire platform-specific execution environment and can be directly launched into a container instance. However, this approach forces developers to build and maintain separate images for each target deployment platform. This limitation is particularly evident for widely used interpreted languages such as Python and R in data analytics and machine learning, where application code is inherently cross-platform, yet the runtime dependencies are highly platform-specific. With emerging computing paradigms such as sky computing and edge computing, which demand seamless workload migration and cross-platform deployment, traditional images not only introduce inefficiencies in storage and network usage, but also impose substantial burdens on developers, who must repeatedly craft and manage platform-specific builds. To address these challenges, we propose a lazy-build approach that defers platform-specific construction to the deployment stage, thus keeping the image itself cross-platform. To enable this, we introduce a new image format, CIR (Container Intermediate Representation), together with its pre-builder and lazy-builder. CIR targets interpreted-language applications and only stores the identifiers of the application's direct dependencies, leaving platform adaptation to the lazy-builder, which at deployment time assembles the actual dependencies into runnable containers. A single CIR can therefore be deployed across heterogeneous platforms while reducing image size by 95% compared to conventional images that bundle all dependencies. In our evaluation, CIR reduces deployment time by 40-60% compared with pre-built images, outperforming state-of-the-art systems such as Docker, Buildah, and Apptainer.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript proposes CIR, a new lightweight container image format for interpreted-language ML applications (e.g., Python/R). CIR stores only identifiers of direct dependencies rather than full platform-specific bundles; a pre-builder creates the CIR while a lazy-builder assembles runnable containers at deployment time. The central claim is that one CIR can be deployed across heterogeneous platforms, yielding a 95% image-size reduction versus conventional images and 40-60% faster deployment than Docker, Buildah, or Apptainer.

Significance. If the lazy-builder mechanism and performance numbers are rigorously validated, the work could meaningfully reduce storage, network, and maintenance costs for cross-platform deployment in cloud, edge, and sky-computing settings. The deferral of platform adaptation is a conceptually clean idea that directly targets the mismatch between cross-platform code and platform-specific runtimes.

major comments (2)
  1. [Abstract / Evaluation] Abstract (and evaluation section): the central quantitative claims of '95% size reduction' and '40-60% faster deployment' are asserted without any description of experimental methodology, datasets, hardware platforms, baseline configurations, measurement procedures, or statistical reporting (error bars, number of runs). These assertions are load-bearing for the paper's contribution and cannot be assessed from the given text.
  2. [Lazy-builder / System Design] Lazy-builder description: the cross-platform claim rests on the assumption that the lazy-builder can always correctly fetch, resolve transitive dependencies, handle version conflicts, and locate missing base components from the stored identifiers for every target platform and dependency graph. No algorithm, pseudocode, conflict-resolution strategy, or error-handling mechanism is supplied, leaving the weakest assumption unverified.
minor comments (1)
  1. [Abstract] The acronym CIR is introduced without an explicit expansion on first use in the abstract; later text should clarify whether 'Container Intermediate Representation' is the intended meaning.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed comments. We address each major comment below and will revise the manuscript to incorporate the suggested improvements.

read point-by-point responses

  1. Referee: [Abstract / Evaluation] Abstract (and evaluation section): the central quantitative claims of '95% size reduction' and '40-60% faster deployment' are asserted without any description of experimental methodology, datasets, hardware platforms, baseline configurations, measurement procedures, or statistical reporting (error bars, number of runs). These assertions are load-bearing for the paper's contribution and cannot be assessed from the given text.

    Authors: We agree that the experimental methodology must be described in sufficient detail for the performance claims to be assessed. The current manuscript presents the results at a high level without the requested specifics on setup and measurement. In the revised version we will expand the Evaluation section with a dedicated 'Experimental Setup' subsection. This will specify the hardware platforms (x86_64 Intel Xeon and aarch64 AWS Graviton instances with exact CPU, memory, and OS versions), the benchmark applications and dependency graphs (Python ML workloads with listed direct dependencies and their transitive closures), baseline configurations (exact Docker, Buildah, and Apptainer build commands and image tags), measurement procedures (image size via filesystem inspection and 'docker images', deployment latency via scripted container launches with warm/cold-start distinction), and statistical reporting (means and standard deviations over 10 independent runs). We will also add a brief reference to this setup in the abstract. These additions will make the 95% size reduction and 40-60% deployment-time claims fully verifiable. revision: yes

  2. Referee: [Lazy-builder / System Design] Lazy-builder description: the cross-platform claim rests on the assumption that the lazy-builder can always correctly fetch, resolve transitive dependencies, handle version conflicts, and locate missing base components from the stored identifiers for every target platform and dependency graph. No algorithm, pseudocode, conflict-resolution strategy, or error-handling mechanism is supplied, leaving the weakest assumption unverified.

    Authors: The referee correctly notes that the cross-platform functionality depends on a well-specified lazy-builder. While the manuscript describes the overall architecture and the division of labor between pre-builder and lazy-builder, it does not supply the algorithmic details, pseudocode, or conflict-resolution strategy. In the revision we will add a new subsection to the System Design section containing: (1) pseudocode for the main lazy-build procedure, (2) the platform-detection and package-resolution steps (using pip for Python and CRAN for R with platform-specific index queries), (3) a conflict-resolution strategy based on version pinning followed by a lightweight backtracking search for compatible transitive dependencies, and (4) explicit error-handling paths (network failures, missing base images, unresolvable conflicts). We will also state the assumptions (internet access at deployment time, availability of public package repositories) and discuss failure modes. This will directly address the verification concern. revision: yes

Circularity Check

0 steps flagged

No circularity: CIR is a new systems format with empirical claims, not a derivation reducing to inputs

full rationale

The paper introduces CIR as a new container image format that stores only direct dependency identifiers and defers platform adaptation to a lazy-builder at deployment time. No equations, fitted parameters, or mathematical derivation chain exist. Size reduction (95%) and deployment time improvements (40-60%) are stated as evaluation outcomes rather than predictions derived from prior fits or self-referential definitions. No self-citations load-bear uniqueness theorems, ansatzes, or renamings of known results. The central premise is a design proposal whose correctness rests on the lazy-builder's runtime behavior, which the paper evaluates empirically rather than deriving tautologically from its own inputs. This is a standard non-circular systems paper.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 2 invented entities

The central claim rests on the domain assumption that interpreted-language application code is inherently cross-platform while its runtime dependencies are platform-specific, plus the new entities of the CIR format and lazy-builder.

axioms (1)
  • domain assumption Application code in interpreted languages such as Python and R is cross-platform while runtime dependencies are highly platform-specific.
    Stated directly in the abstract as the motivation for separating code from dependencies.
invented entities (2)
  • CIR (Container Intermediate Representation) no independent evidence
    purpose: Lightweight cross-platform image format that stores only dependency identifiers.
    New format introduced to enable lazy platform adaptation.
  • lazy-builder no independent evidence
    purpose: Tool that assembles platform-specific dependencies at deployment time from CIR identifiers.
    Core mechanism for achieving cross-platform deployment.

pith-pipeline@v0.9.0 · 5610 in / 1385 out tokens · 60744 ms · 2026-05-10T16:12:27.130347+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

67 extracted references · 67 canonical work pages

  1. [1]

    Murray, Benoit Steiner, Paul Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng

    Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Man- junath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek G. Murray, Benoit Steiner, Paul Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. 2016. TensorFlow: A System f...

    work page 2016

  2. [2]

    2023.RDNA3 Shader Instruction Set Architecture

    Advanced Micro Devices. 2023.RDNA3 Shader Instruction Set Architecture. Advanced Micro Devices, Inc. https://www.amd.com/content/dam/amd/en/ documents/radeon-tech-docs/instruction-set-architectures/rdna3-shader- instruction-set-architecture-feb-2023_0.pdf

    work page 2023

  3. [3]

    Neil Brown. 2019. Overlay Filesystem. https://www.kernel.org/doc/ Documentation/filesystems/overlayfs.rst

    work page 2019

  4. [4]

    Jun Lin Chen, Daniyal Liaqat, Moshe Gabel, and Eyal de Lara. 2022. Starlight: Fast Container Provisioning on the Edge and over the WAN. In19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22). USENIX Association, Renton, WA, 35–50. https://www.usenix.org/conference/nsdi22/ presentation/chen-jun-lin

    work page 2022

  5. [5]

    Lorenzo Civolani, Guillaume Pierre, and Paolo Bellavista. 2019. FogDocker: Start Container Now, Fetch Image Later. InProceedings of the 12th IEEE/ACM International Conference on Utility and Cloud Computing(Auckland, New Zealand) (UCC’19). Association for Computing Machinery, New York, NY, USA, 51–59. doi:10.1145/3344341.3368811

    work page doi:10.1145/3344341.3368811 2019

  6. [6]

    Cloud Native Computing Foundation and The Linux Foundation. 2023. Cloud Native Computing Foundation Annual Survey 2023. https://www.cncf.io/reports/ cncf-annual-survey-2023/ Accessed: 2024-11-08

    work page 2023

  7. [7]

    Marcin Copik, Eiman Alnuaimi, Alok Kamatar, Valerie Hayot-Sasson, Alberto Madonna, Todd Gamblin, Kyle Chard, Ian Foster, and Torsten Hoefler. 2025. XaaS Containers: Performance-Portable Representation With Source and IR Containers. InProceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC ’25). Asso...

    work page doi:10.1145/3712285.3759868 2025

  8. [8]

    Steve Crago, Kyle Dunn, Patrick Eads, Lorin Hochstein, Dong-In Kang, Mikyung Kang, Devendra Modium, Karandeep Singh, Jinwoo Suh, and John Paul Walters

    work page

  9. [9]

    In2011 IEEE International Conference on Cluster Computing

    Heterogeneous Cloud Computing. In2011 IEEE International Conference on Cluster Computing. 378–385. doi:10.1109/CLUSTER.2011.49

    work page doi:10.1109/cluster.2011.49 2011

  10. [10]

    Thomas Durieux. 2024. Empirical Study of the Docker Smells Impact on the Image Size. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering(Lisbon, Portugal)(ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 208, 12 pages. doi:10.1145/3597503.3639143

    work page doi:10.1145/3597503.3639143 2024

  11. [11]

    Gölge Eren and The Coqui TTS Team. 2023. Coqui TTS. doi:10.5281/zenodo. 10363832

    work page doi:10.5281/zenodo 2023

  12. [12]

    Hadi Esmaeilzadeh, Adrian Sampson, Luis Ceze, and Doug Burger. 2012. Neural Acceleration for General-Purpose Approximate Programs. In2012 45th Annual IEEE/ACM International Symposium on Microarchitecture. 449–460. doi:10.1109/ MICRO.2012.48

    work page 2012

  13. [13]

    Hao Fan, Shengwei Bian, Song Wu, Song Jiang, Shadi Ibrahim, and Hai Jin. 2021. Gear: Enable Efficient Container Storage and Deployment with a New Image Format. In2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS). 115–125. doi:10.1109/ICDCS51616.2021.00020

    work page doi:10.1109/icdcs51616.2021.00020 2021

  14. [14]

    Cloud Native Computing Foundation. [n. d.]. Cloud Native Buildpacks. https: //buildpacks.io. Accessed: 2024-12-10

    work page 2024

  15. [15]

    Martin Gebser, Benjamin Kaufmann, and Torsten Schaub. 2012. Conflict-driven answer set solving: From theory to practice.Artificial Intelligence187-188 (2012), 52–89. doi:10.1016/j.artint.2012.04.001

    work page doi:10.1016/j.artint.2012.04.001 2012

  16. [16]

    genuinetools. [n. d.]. img: Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder. https://github.com/genuinetools/img. Accessed: 2024-12-10

    work page 2024

  17. [17]

    Lisa Gerhardt, Wahid Bhimji, Shane Canon, Markus Fasel, Doug Jacobsen, Mustafa Mustafa, Jeff Porter, and Vakho Tsulaia. 2017. Shifter: Containers for HPC. Journal of Physics: Conference Series898, 8 (oct 2017), 082021. doi:10.1088/1742- 6596/898/8/082021

    work page doi:10.1088/1742- 2017

  18. [18]

    Panagiotis Gkikopoulos, Valerio Schiavoni, and Josef Spillner. 2021. Analysis and Improvement of Heterogeneous Hardware Support in Docker Images. In Distributed Applications and Interoperable Systems, Miguel Matos and Fabíola Greve (Eds.). Springer International Publishing, Cham, 125–142

    work page 2021

  19. [19]

    Distroless

    GoogleContainerTools. [n. d.]. "Distroless" Container Images. https://github.com/ GoogleContainerTools/distroless. Accessed: 2024-12-10

    work page 2024

  20. [20]

    GoogleContainerTools. [n. d.]. Jib: Containerize your Java application. https: //github.com/GoogleContainerTools/jib. Accessed: 2024-12-10

    work page 2024

  21. [21]

    GoogleContainerTools. [n. d.]. kaniko - Build Images In Kubernetes. https: //github.com/GoogleContainerTools/kaniko. Accessed: 2024-12-10

    work page 2024

  22. [22]

    Lin Gu, Deze Zeng, Jie Hu, Hai Jin, Song Guo, and Albert Y. Zomaya. 2021. Ex- ploring Layered Container Structure for Cost Efficient Microservice Deployment. InIEEE INFOCOM 2021 - IEEE Conference on Computer Communications. 1–9. doi:10.1109/INFOCOM42981.2021.9488918

    work page doi:10.1109/infocom42981.2021.9488918 2021

  23. [23]

    Yuhao Gu, Haoquan Chen, Xianjie Chen, Jiangsu Du, Zhiguang Chen, Nong Xiao, Xianwei Zhang, and Yutong Lu. 2025. coMtainer: Compilation-assisted HPC Container Images with Enhanced Adaptability. InProceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC ’25). Association for Computing Machinery, New Yo...

    work page doi:10.1145/3712285.3759790 2025

  24. [24]

    Carlos Guerrero, Isaac Lera, and Carlos Juiz. 2018. Resource optimization of container orchestration: a case study in multi-cloud microservices-based applications.The Journal of Supercomputing74, 7 (1 July 2018), 2956–2983. doi:10.1007/s11227-018-2345-2

    work page doi:10.1007/s11227-018-2345-2 2018

  25. [25]

    Arpaci-Dusseau, and Remzi H

    Tyler Harter, Brandon Salmon, Rose Liu, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. 2016. Slacker: Fast Distribution with Lazy Docker Containers. In14th USENIX Conference on File and Storage Technologies (FAST 16). USENIX Association, Santa Clara, CA, 181–195. https://www.usenix.org/conference/ fast16/technical-sessions/presentation/harter

    work page 2016

  26. [26]

    Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. 2022. LoRA: Low-Rank Adaptation of Large Language Models. InInternational Conference on Learning Representations. https: //openreview.net/forum?id=nZeVKeeFYf9

    work page 2022

  27. [27]

    Zhuo Huang, Song Wu, Song Jiang, and Hai Jin. 2019. FastBuild: Accelerating Docker Image Building for Efficient Development and Deployment of Container. In2019 35th Symposium on Mass Storage Systems and Technologies (MSST). 28–37. doi:10.1109/MSST.2019.00-18

    work page doi:10.1109/msst.2019.00-18 2019

  28. [28]

    Patil, Joseph E

    Paras Jain, Sam Kumar, Sarah Wooders, Shishir G. Patil, Joseph E. Gonzalez, and Ion Stoica. 2023. Skyplane: Optimizing Transfer Cost and Throughput Using Cloud-Aware Overlays. In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 1375–1389. https://www.usenix.org/conference/nsdi23/presentation/jain

    work page 2023

  29. [29]

    Glenn Jocher, Jing Qiu, and Ayush Chaurasia. 2023. Ultralytics YOLO. https: //github.com/ultralytics/ultralytics AGPL-3.0 License

    work page 2023

  30. [30]

    Norman P. Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh Bhatia, Nan Boden, Al Borchers, Rick Boyle, Pierre-luc Cantin, Clifford Chao, Chris Clark, Jeremy Coriell, Mike Daley, Matt Dau, Jeffrey Dean, Ben Gelb, Tara Vazir Ghaemmaghami, Rajendra Gottipati, William Gulland, Robert Hagmann, C. Richard ...

    work page doi:10.1145/3140659.3080246 2017

  31. [31]

    LLC LF Projects. [n. d.]. Apptainer: Application containers for Linux. https: //apptainer.org. Accessed: 2024-12-10

    work page 2024

  32. [32]

    Huiba Li, Zhihao Zhang, Yifan Yuan, Rui Du, Kai Ma, Lanzheng Liu, Yiming Zhang, and Windsor Hsu. 2024. Block-level Image Service for the Cloud.ACM Trans. Storage20, 1, Article 1 (January 2024), 28 pages. doi:10.1145/3620672

    work page doi:10.1145/3620672 2024

  33. [33]

    Meelis Lootus, Kartik Thakore, Sam Leroux, Geert Trooskens, Akshay Sharma, and Holly Ly. 2021. A VM Containerized Approach for Scaling TinyML Applica- tions. InResearch Symposium on Tiny Machine Learning. https://openreview.net/ forum?id=m7Aqzt7Xf4S

    work page 2021

  34. [34]

    Zhigang Lu, Yuewen Wu, Jiwei Xu, and Tao Wang. 2019. An Acceleration Method for Docker Image Update. In2019 IEEE International Conference on Fog Computing (ICFC). 15–23. doi:10.1109/ICFC.2019.00010

    work page doi:10.1109/icfc.2019.00010 2019

  35. [35]

    Leung, Bong Jun Ko, and Theodoros Salonidis

    Andrew Machen, Shiqiang Wang, Kin K. Leung, Bong Jun Ko, and Theodoros Salonidis. 2018. Live Service Migration in Mobile Edge Clouds.Wireless Commun. 25, 1 (Feb. 2018), 140–147. doi:10.1109/MWC.2017.1700011

    work page doi:10.1109/mwc.2017.1700011 2018

  36. [36]

    Dirk Merkel. 2014. Docker: lightweight Linux containers for consistent develop- ment and deployment.Linux J.2014, 239, Article 2 (March 2014)

    work page 2014

  37. [37]

    Sparsh Mittal. 2019. A Survey on optimized implementation of deep learning models on the NVIDIA Jetson platform.Journal of Systems Architecture97 (2019), 428–442. doi:10.1016/j.sysarc.2019.01.011

    work page doi:10.1016/j.sysarc.2019.01.011 2019

  38. [38]

    Omogbai Oleghe. 2021. Container Placement and Migration in Edge Computing: Concept and Scheduling Models.IEEE Access9 (2021), 68028–68043. doi:10.1109/ ACCESS.2021.3077550

    work page arXiv 2021

  39. [39]

    Containers organization. [n. d.]. Buildah: A tool that facilitates building OCI container images. https://buildah.io/. Accessed: 2024-12-10

    work page 2024

  40. [40]

    Reid Priedhorsky and Tim Randles. 2017. Charliecloud: unprivileged contain- ers for user-defined software stacks in HPC. InProceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (Denver, Colorado)(SC ’17). Association for Computing Machinery, New York, NY, USA, Article 36, 10 pages. doi:10.1145/3126908...

    work page doi:10.1145/3126908.3126925 2017

  41. [41]

    Alec Radford, Jong Wook Kim, Chris Hallacy, Aditya Ramesh, Gabriel Goh, Sandhini Agarwal, Girish Sastry, Amanda Askell, Pamela Mishkin, Jack Clark, Gretchen Krueger, and Ilya Sutskever. 2021. Learning Transferable Visual Models From Natural Language Supervision. InProceedings of the 38th Inter- national Conference on Machine Learning (Proceedings of Machi...

    work page 2021

  42. [42]

    Alec Radford, Jong Wook Kim, Tao Xu, Greg Brockman, Christine McLeavey, and Ilya Sutskever. 2023. Robust speech recognition via large-scale weak supervision. InProceedings of the 40th International Conference on Machine Learning(Honolulu, Hawaii, USA)(ICML’23). JMLR.org, Article 1182, 27 pages

    work page 2023

  43. [43]

    Antonin Raffin, Ashley Hill, Adam Gleave, Anssi Kanervisto, Maximilian Ernestus, and Noah Dormann. 2021. Stable-Baselines3: Reliable Reinforcement Learning Implementations.Journal of Machine Learning Research22, 268 (2021), 1–8. http://jmlr.org/papers/v22/20-1364.html

    work page 2021

  44. [44]

    Vaibhav Rastogi, Drew Davidson, Lorenzo De Carli, Somesh Jha, and Patrick McDaniel. 2017. Cimplifier: automatically debloating containers. InProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering(Paderborn, Germany)(ESEC/FSE 2017). Association for Computing Machinery, New York, NY, USA, 476–486. doi:10.1145/3106237.3106271

    work page doi:10.1145/3106237.3106271 2017

  45. [45]

    Thomas Rausch, Alexander Rashed, and Schahram Dustdar. 2021. Optimized con- tainer scheduling for data-intensive serverless edge computing.Future Generation Computer Systems114 (2021), 259–271. doi:10.1016/j.future.2020.07.017

    work page doi:10.1016/j.future.2020.07.017 2021

  46. [46]

    Nikhila Ravi, Valentin Gabeur, Yuan-Ting Hu, Ronghang Hu, Chaitanya Ryali, Tengyu Ma, Haitham Khedr, Roman Rädle, Chloe Rolland, Laura Gustafson, Eric Mintun, Junting Pan, Kalyan Vasudev Alwala, Nicolas Carion, Chao-Yuan Wu, Ross Girshick, Piotr Dollar, and Christoph Feichtenhofer. 2025. SAM 2: Segment Anything in Images and Videos. InThe Thirteenth Inter...

    work page 2025

  47. [47]

    Robin Rombach, Andreas Blattmann, Dominik Lorenz, Patrick Esser, and Bjorn Ommer. 2022. High-Resolution Image Synthesis with Latent Diffusion Models . In2022 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). IEEE Computer Society, Los Alamitos, CA, USA, 10674–10685. doi:10.1109/ CVPR52688.2022.01042

    work page arXiv 2022

  48. [48]

    Sartakov, Lluís Vilanova, Munir Geden, David Eyers, Takahiro Shina- gawa, and Peter Pietzuch

    Vasily A. Sartakov, Lluís Vilanova, Munir Geden, David Eyers, Takahiro Shina- gawa, and Peter Pietzuch. 2023. ORC: Increasing Cloud Memory Density via Object Reuse with Capabilities. In17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). USENIX Association, Boston, MA, 573–587. https://www.usenix.org/conference/osdi23/presentati...

    work page 2023

  49. [49]

    Tim Shaffer, Nicholas Hazekamp, Jakob Blomer, and Douglas Thain. 2020. Solving the Container Explosion Problem for Distributed High Throughput Computing. In2020 IEEE International Parallel and Distributed Processing Symposium (IPDPS). 388–398. doi:10.1109/IPDPS47924.2020.00048

    work page doi:10.1109/ipdps47924.2020.00048 2020

  50. [50]

    Tim Shaffer, Thanh Son Phung, Kyle Chard, and Douglas Thain. 2023. Landlord: Coordinating Dynamic Software Environments to Reduce Container Sprawl. IEEE Transactions on Parallel and Distributed Systems34, 5 (May 2023), 1376–1389. doi:10.1109/TPDS.2023.3241598

    work page doi:10.1109/tpds.2023.3241598 2023

  51. [51]

    Weisong Shi, Jie Cao, Quan Zhang, Youhuizi Li, and Lanyu Xu. 2016. Edge Computing: Vision and Challenges.IEEE Internet of Things Journal3, 5 (2016), 637–646. doi:10.1109/JIOT.2016.2579198

    work page doi:10.1109/jiot.2016.2579198 2016

  52. [52]

    Dimitris Skourtis, Lukas Rupprecht, Vasily Tarasov, and Nimrod Megiddo. 2019. Carving perfect layers out of docker images. In11th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 19)

    work page 2019

  53. [53]

    Ion Stoica and Scott Shenker. 2021. From cloud computing to sky computing. InProceedings of the Workshop on Hot Topics in Operating Systems(Ann Arbor, Michigan)(HotOS ’21). Association for Computing Machinery, New York, NY, USA, 26–32. doi:10.1145/3458336.3465301

    work page doi:10.1145/3458336.3465301 2021

  54. [54]

    Kun Suo, Junggab Son, Dazhao Cheng, Wei Chen, and Sabur Baidya. 2021. Tack- ling Cold Start of Serverless Applications by Efficient and Adaptive Container Runtime Reusing. In2021 IEEE International Conference on Cluster Computing (CLUSTER). 433–443. doi:10.1109/Cluster48925.2021.00018

    work page doi:10.1109/cluster48925.2021.00018 2021

  55. [55]

    Nydus Development Team. [n. d.]. Nydus: Acceleration Framework for Container Image. https://nydus.dev/. Accessed: 2024-12-10

    work page 2024

  56. [56]

    SlimToolkit Development Team. [n. d.]. SlimToolkit: Optimize Your Experience with Containers. https://github.com/slimtoolkit/slim. Accessed: 2024-12-10

    work page 2024

  57. [57]

    Jörg Thalheim, Pramod Bhatotia, Pedro Fonseca, and Baris Kasikci. 2018. CNTR: lightweight OS containers. In2018 USENIX Annual Technical Conference (USENIX ATC 18). 199–212

    work page 2018

  58. [58]

    Katrine Wist, Malene Helsem, and Danilo Gligoroski. 2021. Vulnerability Analysis of 2500 Docker Hub Images. InAdvances in Security, Networks, and Internet of Things, Kevin Daimi, Hamid R. Arabnia, Leonidas Deligiannidis, Min-Shiang Hwang, and Fernando G. Tinetti (Eds.). Springer International Publishing, Cham, 307–327

    work page 2021

  59. [59]

    Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Remi Louf, Morgan Funtowicz, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gugger, Mariama Drame, Quentin Lhoest, and Alexander Rush. 2020. Transformers: State-of-the-...

    work page doi:10.18653/v1/2020 2020

  60. [60]

    Karaoui, Wei Wang, and Binoy Ravindran

    Tong Xing, Antonio Barbalace, Pierre Olivier, Mohamed L. Karaoui, Wei Wang, and Binoy Ravindran. 2022. H-Container: Enabling Heterogeneous-ISA Container Migration in Edge Computing.ACM Trans. Comput. Syst.39, 1–4, Article 5 (July 2022), 36 pages. doi:10.1145/3524452

    work page doi:10.1145/3524452 2022

  61. [61]

    Dali Yang and Wenbin Dai. 2022. A Lightweight Container Design for Microservice-based Industrial Edge Applications. In2022 IEEE 17th Conference on Industrial Electronics and Applications (ICIEA). 858–863. doi:10.1109/ICIEA54703. 2022.10006175

    work page doi:10.1109/iciea54703 2022

  62. [62]

    Zongheng Yang, Zhanghao Wu, Michael Luo, Wei-Lin Chiang, Romil Bhardwaj, Woosuk Kwon, Siyuan Zhuang, Frank Sifei Luan, Gautam Mittal, Scott Shenker, and Ion Stoica. 2023. SkyPilot: An Intercloud Broker for Sky Computing. In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 437–455. https://www.u...

    work page 2023

  63. [63]

    Deze Zeng, Hongmin Geng, Lin Gu, and Zhexiong Li. 2023. Layered Structure Aware Dependent Microservice Placement Toward Cost Efficient Edge Clouds. InIEEE INFOCOM 2023 - IEEE Conference on Computer Communications. 1–9. doi:10.1109/INFOCOM53939.2023.10229030

    work page doi:10.1109/infocom53939.2023.10229030 2023

  64. [64]

    Ahmed Zerouali, Tom Mens, Alexandre Decan, Jesus Gonzalez-Barahona, and Gregorio Robles. 2021. A multi-dimensional analysis of technical lag in Debian- based Docker images.Empirical Softw. Engg.26, 2 (March 2021), 45 pages. doi:10. 1007/s10664-020-09908-6

    work page 2021

  65. [65]

    Zhicong Zhang, Heqing Huang, Shaowen Xu, Qihang Zhou, Tianshu Zhang, Xiaoqi Jia, and Weijuan Zhang. 2024. SummSlim: A Universal and Auto- mated Approach for Debloating Container Images. In2024 IEEE 30th Inter- national Conference on Parallel and Distributed Systems (ICPADS). 132–141. doi:10.1109/ICPADS63350.2024.00027

    work page doi:10.1109/icpads63350.2024.00027 2024

  66. [66]

    Nannan Zhao, Hadeel Albahar, Subil Abraham, Keren Chen, Vasily Tarasov, Dim- itrios Skourtis, Lukas Rupprecht, Ali Anwar, and Ali R. Butt. 2020. DupHunter: Flexible High-Performance Deduplication for Docker Registries. In2020 USENIX Annual Technical Conference (USENIX ATC 20). USENIX Association, 769–783. https://www.usenix.org/conference/atc20/presentation/zhao

    work page 2020

  67. [67]

    Paul, Zhijie Huan, Subil Abraham, Keren Chen, Vasily Tarasov, Dimitrios Skourtis, Ali Anwar, and Ali Butt

    Nannan Zhao, Muhui Lin, Hadeel Albahar, Arnab K. Paul, Zhijie Huan, Subil Abraham, Keren Chen, Vasily Tarasov, Dimitrios Skourtis, Ali Anwar, and Ali Butt. 2024. An End-to-end High-performance Deduplication Scheme for Docker Registries and Docker Container Storage Systems.ACM Trans. Storage20, 3, Article 18 (June 2024), 35 pages. doi:10.1145/3643819 13

    work page doi:10.1145/3643819 2024