DEV Community: Cheikh Seck

I built a Docker Image Factory From Scratch in Go

Cheikh Seck — Thu, 30 Jul 2026 15:21:11 +0000

Most teams treat container images as something a build tool produces on their behalf. You write a Dockerfile, hand it to BuildKit, and a few hundred megabytes later you have an image. The build process itself is a black box — a daemon, a cache, a base image you didn’t author, and a format you rarely inspect.

This post takes the opposite stance: an image builder is just a program. Given a tarball and a few JSON blobs, any code that can compute a SHA-256 and write files can manufacture a valid OCI image. So instead of reaching for Docker, we’ll build an image factory — a small Go program that ingests layer tarballs, content-addresses them, assembles a manifest, and emits a spec-compliant OCI layout. The same factory can push to a registry and pull images back.

The result is a reusable tool, not a one-off trick. As a bonus, the images it produces are tiny — around 8MB for a Go server — because the factory adds nothing you didn’t ask for. But the real value is ownership: you understand and control every byte of the image format.

Read the rest here: https://cheikhhseck.medium.com/building-a-docker-image-factory-from-scratch-in-go-e3c2e7127106?sk=42cbfc6c5981a5acc6ac1e617bf932be

eBPF vs Traditional Observability: Why Kernel-Level Debugging Wins for AI Services

Cheikh Seck — Fri, 26 Jun 2026 09:13:01 +0000

eBPF vs Traditional Observability: Why Kernel-Level Debugging Wins for AI Services

Originally published on Medium: https://cheikhhseck.medium.com/ebpf-in-go-observability-for-ai-generated-services-9aae7573b823

The Problem: Your AI-generated service is running in production. Latency spikes from 40ms to 4 seconds. Your application logs show nothing unusual. Traditional observability tools (APM, logs, metrics) are blind to what's happening.

The Solution: eBPF gives you kernel-level visibility without modifying your code or restarting services.

Why eBPF Matters for AI-Generated Code

AI-generated services often lack context about kernel interactions. When things go wrong at the system level, you need observability that goes beyond application-level metrics.

Real-world scenario:

P95 latency jumped from 40ms to 4s
No errors in application logs
Traditional tools showed nothing
eBPF revealed the root cause: syscall overhead from AI-generated file operations

Key Takeaways from the Original Article

Installation & Setup - Getting started with Cilium's eBPF library in Go
Writing eBPF Programs - Using C for kernel-level tracing
Loading from Go - Practical patterns for loading and attaching programs
Tracing syscalls, network events, and file I/O - Real examples you can run
Compilation tips - Making it work in production environments

The Code Example

The original article includes a working example you can run in 10 minutes. It demonstrates:

Attaching kprobes to kernel functions
Using perf-event ringbuffers for efficient data collection
Tracing file I/O and network events from Go

Link to the full tutorial with code

Why This Matters Now

As AI-generated code becomes more prevalent, we need observability tools that can debug at the system level. eBPF provides that capability without requiring changes to existing applications.

Godex: AI assistance in the terminal

Cheikh Seck — Fri, 01 May 2026 10:35:55 +0000

Hi folks,

I recently wrote an article I feel has some insight in how LLMs work and the best way to apply it to your day-2-day work. "AI will not take your job, but somebody using it will"

https://medium.com/dev-genius/godex-ai-assisted-coding-in-the-terminal-1d5182edecde?sk=b850044334e8b97720277dfdf458a17f

Don't pay for an AI sandbox — build one locally with Docker

Cheikh Seck — Thu, 26 Mar 2026 11:32:21 +0000

Don't pay for an AI sandbox. Build one locally that's secure with Docker.

Here's a practical guide that spins up a locked-down environment with a TUI, a persistent config volume, and a proxy to your local Ollama:

https://github.com/cheikh2shift/godex/tree/main#running-securely-with-docker

Why this setup?

Runs locally (no vendor lock-in)
Sandboxed tools (bash, filesystem, webscraper)
Config persisted in a Docker volume
Works from any project directory via WORKSPACE_DIR

Quick start

UID=$(id -u) GID=$(id -g) WORKSPACE_DIR="$PWD" docker compose -f $HOME/godex/docker-compose.yml up -d && docker attach godex && docker compose -f $HOME/godex/docker-compose.yml down

Ollama note
If you're using a host Ollama instance via the nginx proxy, make sure Ollama listens on 0.0.0.0:11434 (not just 127.0.0.1).

security #docker #opensource

Go 1.23’s Iter package

Cheikh Seck — Sat, 28 Dec 2024 13:48:00 +0000

A post about writing a custom iterator that returns a map’s values in a constant order.

Maps are notoriously known for changing their iteration order during each range loop. “When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next.” The solution proposed by the Go team was to define a separate data structure that explicitly specifies the order of iteration; this may be a slice or array with the keys in the desired order.

In this post, we’ll look at a recent approach to solving the iteration order problem; as well as understand how to define a really basic iterator with the iter package.

You can read the rest here:

https://cheikhhseck.medium.com/go-1-23s-iter-package-f6b44dfb9b7b?source=friends_link&sk=1cbef6905c4acaa7b816e661068f967a