<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Development on *scratch*</title>
    <link>https://www.scrivano.org/categories/development/</link>
    <description>Recent content in Development 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/categories/development/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>GitChronicler: Write commit messages with AI</title>
      <link>https://www.scrivano.org/posts/2025-04-30-git-chronicler/</link>
      <pubDate>Wed, 30 Apr 2025 16:12:00 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2025-04-30-git-chronicler/</guid>
      <description>&lt;p&gt;I started working on GitChronicler mostly to learn how I could integrate AI into my workflow in a way that would actually spare me doing boring stuff, like writing the git commit message. The tool feeds a patch to a language model via the OpenRouter API and gets back a commit message that reflects what the code actually does — saving the mechanical step of describing changes that are already fully visible in the diff, while still leaving the developer in control of what gets committed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why do I have two /sys/fs/cgroup in my container</title>
      <link>https://www.scrivano.org/posts/2024-1-26-why-do-i-have-two-cgroup/</link>
      <pubDate>Fri, 26 Jan 2024 14:12:00 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2024-1-26-why-do-i-have-two-cgroup/</guid>
      <description>&lt;p&gt;It happened a few times in the past that users wonder why they see two &lt;code&gt;/sys/fs/cgroup&lt;/code&gt; mounts in their unprivileged container. When working with unprivileged containers in Podman, users often notice two &lt;code&gt;/sys/fs/cgroup&lt;/code&gt; mounts if the container is not using a new network namespace. The duplication is not a bug but an intentional consequence of how the kernel handles bind mounts that cross user namespace boundaries, combined with the need to provide the container with a writable cgroup view that is scoped to its own slice.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Hide the current process executable file</title>
      <link>https://www.scrivano.org/posts/2022-12-21-hide-self-exe/</link>
      <pubDate>Wed, 21 Dec 2022 22:15:00 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2022-12-21-hide-self-exe/</guid>
      <description>&lt;p&gt;I have been working on a new functionality for the &lt;code&gt;prctl&lt;/code&gt; syscall that addresses a common security concern with container runtimes. The &lt;code&gt;/proc/self/exe&lt;/code&gt; symlink, which points to the executable of the running process, was the key ingredient in CVE-2019-5736, a vulnerability that allowed a malicious container to overwrite the container runtime binary on the host. The workaround deployed at the time — re-execing from a copy or using a read-only bind mount — treats the symptom rather than the cause.&lt;/p&gt;</description>
    </item>
    <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>An interesting issue handling the seccomp listener</title>
      <link>https://www.scrivano.org/posts/2022-09-05-seccomp-listener/</link>
      <pubDate>Mon, 05 Sep 2022 21:59:12 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2022-09-05-seccomp-listener/</guid>
      <description>&lt;p&gt;A &lt;a href=&#34;https://github.com/containers/crun/issues/1002&#34;&gt;bug report&lt;/a&gt; filed against crun a few days ago exposed a deadlock: under certain seccomp profiles, the runtime would hang indefinitely before the container process ever started. The root cause is a subtle sequencing problem between installing a seccomp filter that intercepts a syscall and then immediately using that same syscall to hand off the resulting listener file descriptor to the userspace handler — the very handler that has not yet received the descriptor it needs to process the interception.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Composefs - a file system for container images</title>
      <link>https://www.scrivano.org/posts/2021-10-26-compose-fs/</link>
      <pubDate>Tue, 26 Oct 2021 16:02:56 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2021-10-26-compose-fs/</guid>
      <description>&lt;p&gt;For the last couple of weeks, I&amp;rsquo;ve been playing on a PoC implementation of a file system for the Linux kernel. The goal is to address a fundamental limitation in how container images are stored: the existing overlay model deduplicates at the layer level, but once you want per-file deduplication — so that identical files across different images share a single copy on disk and in the page cache — the current architecture gets in the way and requires awkward workarounds involving hard links or filesystem-specific reflinks.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Seccomp made easy</title>
      <link>https://www.scrivano.org/posts/2021-01-30-easyseccomp/</link>
      <pubDate>Sat, 30 Jan 2021 21:10:14 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2021-01-30-easyseccomp/</guid>
      <description>&lt;p&gt;Seccomp is a kernel feature that restricts what syscalls can be used by a process. The allowed syscalls are described as a BPF program that the kernel evaluates on every syscall entry. While effective, writing and maintaining seccomp profiles in the JSON format expected by OCI runtimes is tedious, and the underlying libseccomp API has surprising constraints — particularly around combining per-argument rules for the same syscall — that make complex policies difficult to express correctly.&lt;/p&gt;&#xA;&lt;p&gt;Almost every container runs with seccomp enabled to restrict its&#xA;access to syscalls.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cgroup v2 OOM group</title>
      <link>https://www.scrivano.org/posts/2020-08-14-oom-group/</link>
      <pubDate>Fri, 14 Aug 2020 19:49:32 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2020-08-14-oom-group/</guid>
      <description>&lt;p&gt;One annoying issue with setting a memory limit for a container is that the OOM killer can leave the container in an inconsistent state with only some of its processes terminated. When a cgroup hits its memory limit, the kernel selects a single process to kill based on a badness score, not all the processes in the cgroup. This means that a multi-process container — for example, one running a web server and several worker processes — may continue running in a broken state after the OOM event rather than being cleanly torn down.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Playing with seccomp notifications in the OCI runtime</title>
      <link>https://www.scrivano.org/posts/2020-08-10-seccomp-notifications/</link>
      <pubDate>Mon, 10 Aug 2020 10:40:19 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2020-08-10-seccomp-notifications/</guid>
      <description>&lt;p&gt;A couple weekends ago I&amp;rsquo;ve played with seccomp user notifications and how they can be used in the OCI containers stack. Seccomp user notifications are a Linux kernel feature that lets a privileged monitor process intercept specific syscalls made by a less-privileged container, inspect the arguments, and either emulate the syscall or return an error. This opens up possibilities for safely expanding what unprivileged containers can do — for example, emulating &lt;code&gt;mknod&lt;/code&gt; — without granting broad kernel capabilities to the container itself.&lt;/p&gt;&#xA;&lt;p&gt;Seccomp user notifications are a powerful Linux kernel feature, that&#xA;delegates syscalls handling to a userland program.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Avoid a memory page allocation on mount(2)</title>
      <link>https://www.scrivano.org/2019/12/27/avoid-a-memory-page-allocation-on-mount/</link>
      <pubDate>Fri, 27 Dec 2019 16:16:33 +0000</pubDate>
      <guid>https://www.scrivano.org/2019/12/27/avoid-a-memory-page-allocation-on-mount/</guid>
      <description>&lt;p&gt;While working on crun, I got surprised by how much time the kernel spent in the &lt;code&gt;copy_mount_options&lt;/code&gt; function. A container runtime issues a large number of &lt;code&gt;mount(2)&lt;/code&gt; syscalls during startup — bind mounts, proc, sysfs, devtmpfs, and more — many of them with no extra options to pass. It turned out that passing an empty string instead of &lt;code&gt;NULL&lt;/code&gt; for the data argument caused the kernel to allocate a full memory page and attempt a copy from user space on every one of those calls, adding measurable overhead.&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>
    <item>
      <title>OpenShift on system containers</title>
      <link>https://www.scrivano.org/2017/02/23/openshift-system-containers/</link>
      <pubDate>Thu, 23 Feb 2017 18:26:43 +0000</pubDate>
      <guid>https://www.scrivano.org/2017/02/23/openshift-system-containers/</guid>
      <description>&lt;p&gt;It is still an ongoing work not ready for production, but the upstream&#xA;version of OpenShift origin has already an experimental support for&#xA;running OpenShift Origin using system containers. The&#xA;“latest” Docker image for origin, node and openvswitch,&#xA;the 3 components we need, are automatically pushed to docker.io, so we&#xA;can use these for our test. The rhel7/etcd system container image&#xA;instead is pulled from the Red Hat registry.&lt;/p&gt;&#xA;&lt;p&gt;This demo is based on these blog posts&#xA;&lt;a href=&#34;http://www.projectatomic.io/blog/2016/12/part1-install-origin-on-f25-atomic-host/&#34;&gt;www.projectatomic.io/blog/2016/12/part1-install-origin-on-f25-atomic-host/&lt;/a&gt;&#xA;and&#xA;&lt;a href=&#34;http://www.projectatomic.io/blog/2016/12/part2-install-origin-on-f25-atomic-host/&#34;&gt;www.projectatomic.io/blog/2016/12/part2-install-origin-on-f25-atomic-host/&lt;/a&gt;&#xA;with some differences for the provision of the VMs and obviously&#xA;running system containers instead of Docker containers.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Use bubblewrap as an unprivileged user to run systemd images</title>
      <link>https://www.scrivano.org/2016/10/22/use-bubblewrap-unprivileged-user-run-systemd-images/</link>
      <pubDate>Sat, 22 Oct 2016 13:21:25 +0000</pubDate>
      <guid>https://www.scrivano.org/2016/10/22/use-bubblewrap-unprivileged-user-run-systemd-images/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://github.com/projectatomic/bubblewrap/&#34;&gt;bubblewrap&lt;/a&gt; is a sandboxing tool that allows unprivileged users to run containers. I was recently working on a way to allow unprivileged users to take advantage of bubblewrap to run regular system images that use systemd. To do so, it was necessary to modify bubblewrap to retain a controlled set of Linux capabilities inside the sandbox. Without those capabilities, systemd cannot perform the privilege-separation steps it needs at startup, even when running as UID 0 inside a user namespace.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Brainfuc**d brainf**k</title>
      <link>https://www.scrivano.org/2016/05/11/brainfucd-brainfk/</link>
      <pubDate>Wed, 11 May 2016 21:15:43 +0000</pubDate>
      <guid>https://www.scrivano.org/2016/05/11/brainfucd-brainfk/</guid>
      <description>&lt;p&gt;Every programmer at some point gets in touch with the Brainfuck programming language and how surprising is that very few instructions are needed to have a Turing complete language, 6 is the case of Brainfuck (plus other 2 for I/O operations). The language operates on a tape of memory cells using only increment, decrement, pointer movement, and conditional loop instructions. Writing a GCC frontend for it turns out to be a manageable project, and the result is a good template for understanding how language frontends hook into the GCC middle-end and optimization passes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ostree-docker-builder</title>
      <link>https://www.scrivano.org/2015/09/30/ostree-docker-builder/</link>
      <pubDate>Wed, 30 Sep 2015 13:25:56 +0000</pubDate>
      <guid>https://www.scrivano.org/2015/09/30/ostree-docker-builder/</guid>
      <description>&lt;p&gt;rpm-ostree, used together with OStree, is a powerful tool to generate immutable images for .rpm based systems, so why not use it for generating Docker images as well? rpm-ostree already has support for composing a container tree, but the steps to go from an OStree commit to a ready-to-run Docker image involve several manual operations. ostree-docker-builder is a small tool that automates this workflow, taking a JSON package description and producing a tagged Docker image with a minimal Dockerfile.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Summer of Code 2015 for wget</title>
      <link>https://www.scrivano.org/posts/2015-04-30-summer-of-code-2015-wget/</link>
      <pubDate>Thu, 30 Apr 2015 21:40:25 +0000</pubDate>
      <guid>https://www.scrivano.org/posts/2015-04-30-summer-of-code-2015-wget/</guid>
      <description>&lt;p&gt;Coming as a surprise, this year we have got 4 students to work full-time during the summer on wget. More than all the students who have ever worked for wget before during a Summer of Code! The projects span a broad range of improvements: HSTS and FTPS security hardening, TCP Fast Open and conditional GET for performance, HTTP/2 support on top of nghttp2, and an expanded FTP test suite. Each student is expected to keep their work rebased on the current development branch to ease eventual integration.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Create a QCOW2 image for Fedora 22 Atomic</title>
      <link>https://www.scrivano.org/posts/2015-04-20-create-a-qcow2-image-for-fedora-22-atomic/</link>
      <pubDate>Mon, 20 Apr 2015 15:50:30 +0000</pubDate>
      <guid>https://www.scrivano.org/posts/2015-04-20-create-a-qcow2-image-for-fedora-22-atomic/</guid>
      <description>&lt;p&gt;This tutorial shows how to create a QCOW2 image that can be directly imported via virt-install to test out Fedora 22 Atomic starting from a custom OStree repo. The process involves composing an OStree repository from a Fedora Atomic tree definition, serving it over HTTP so the installer can reach it, then driving an unattended installation through a kickstart file. This gives you full control over the package set and tree composition rather than relying on a pre-built official image.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to deploy a WordPress Docker container using docker-compose</title>
      <link>https://www.scrivano.org/posts/2015-04-19-wordpress-in-a-docker-container/</link>
      <pubDate>Sun, 19 Apr 2015 23:25:49 +0000</pubDate>
      <guid>https://www.scrivano.org/posts/2015-04-19-wordpress-in-a-docker-container/</guid>
      <description>&lt;p&gt;These are the steps to setup the current website in a Docker container. The setup uses docker-compose to declaratively describe a two-container application: a MySQL 5.5 database and a WordPress frontend. Docker links tie them together so that the web container can reach the database by hostname, without needing to hard-code any IP addresses or manage networking manually. A single &lt;code&gt;docker-compose up&lt;/code&gt; command downloads the required images and starts both containers, with port 80 on the host forwarded into the WordPress container.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
