<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Oci on *scratch*</title>
    <link>https://www.scrivano.org/tags/oci/</link>
    <description>Recent content in Oci on *scratch*</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 06 Jun 2026 10:03:54 +0000</lastBuildDate>
    <atom:link href="https://www.scrivano.org/tags/oci/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The journey to speed up running OCI containers</title>
      <link>https://www.scrivano.org/posts/2022-10-21-the-journey-to-speed-up-oci-containers/</link>
      <pubDate>Wed, 21 Sep 2022 16:30:00 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2022-10-21-the-journey-to-speed-up-oci-containers/</guid>
      <description>&lt;p&gt;When I started working on crun, I was looking at a faster way to start up and stop containers by improving the OCI runtime, the component in the OCI stack that is responsible for talking to the kernel and setting up the environment where the container runs. Over roughly five years, a combination of kernel patches and userspace fixes reduced the time to start and stop a container from around 160 ms to just over 5 ms — nearly a 30x improvement — through targeted work on network namespace teardown, mqueue mount overhead, IPC namespace cleanup, and seccomp profile compilation.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Crun moved to github.com/containers</title>
      <link>https://www.scrivano.org/2019/08/12/crun-moved-to-github-com-containers/</link>
      <pubDate>Mon, 12 Aug 2019 09:54:25 +0000</pubDate>
      <guid>https://www.scrivano.org/2019/08/12/crun-moved-to-github-com-containers/</guid>
      <description>&lt;p&gt;The giuseppe/crun github project was moved under &lt;a href=&#34;https://github.com/containers/crun&#34;&gt;https://github.com/containers/crun&lt;/a&gt;. Moving to the containers organization means the project is no longer a personal experiment but a community-maintained component of the container stack, alongside tools like Podman, Buildah, and fuse-overlayfs. This makes it easier to coordinate changes across the ecosystem and signals that crun is a supported alternative OCI runtime for production use.&lt;/p&gt;&#xA;&lt;p&gt;Similarly libocispec, used internally by crun for parsing the OCI configuration file was moved to &lt;a href=&#34;https://github.com/containers/libocispec&#34;&gt;https://github.com/containers/libocispec&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>New COPR repository for crun</title>
      <link>https://www.scrivano.org/2017/11/15/new-copr-repository-crun/</link>
      <pubDate>Wed, 15 Nov 2017 19:25:46 +0000</pubDate>
      <guid>https://www.scrivano.org/2017/11/15/new-copr-repository-crun/</guid>
      <description>&lt;p&gt;I made a new COPR repository for crun so that it can be easily tested on Fedora without having to build from source. crun is a lightweight OCI container runtime written in C, intended as a faster and lower-overhead alternative to runC. The COPR repository tracks the upstream development branch, making it straightforward to try out new features and report issues before they land in a distribution package.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://copr.fedorainfracloud.org/coprs/gscrivano/crun/&#34;&gt;https://copr.fedorainfracloud.org/coprs/gscrivano/crun/&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;To install crun on Fedora, it is enough to:&lt;/p&gt;</description>
    </item>
    <item>
      <title>C is a better fit for tools like an OCI runtime</title>
      <link>https://www.scrivano.org/2017/10/23/c-still-makes-sense-low-level-tools-oci-runtime/</link>
      <pubDate>Mon, 23 Oct 2017 21:21:19 +0000</pubDate>
      <guid>https://www.scrivano.org/2017/10/23/c-still-makes-sense-low-level-tools-oci-runtime/</guid>
      <description>&lt;p&gt;I’ve spent some of the last weeks working on a replacement for runC, the most used/known OCI runtime for running containers. It might not be very well known, but it is a key component for running containers. Every Docker container ultimately runs through runC. The OCI runtime is the thin layer between the container engine and the kernel: it reads a JSON configuration file, creates the necessary namespaces and cgroups, sets up mounts and capabilities, and finally execs the container process. Because it runs for such a short time and its workload is almost entirely syscalls, the implementation language matters for startup latency.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
