AI output seldom meets the intent on the first prompt, so iteration is necessary. Today, iteration usually means providing feedback in a follow-up prompt, which leads to a rewrite of the whole document. The prompt that explains the intent behind the revision remains buried in the chat.

Imagine sending a colleague a five page document. They read it and have some concerns. The workflow would not be:

• Email me a prose description of everything you dislike
• I send you a completely rewritten document
• Then compare the two files and figure out whether I understood you

That is absurd—this workflow has been solved for decades by comments and tracked changes in Word, or by Suggesting mode in Google Docs.

Want to see it in action? spoiler

In the previous post, we followed the white rabbit down into Git's .git folder. We understood: Git uses zlib's deflate algorithm to compress objects.

The Problem: Each range of zlib-compressed data depends on reading all the data before it. A 1Gb sqlite database compressed with zlib must read the whole file to access a single row[^1].

In this article we're going to build a mental model on how zlib compresses and we're going to use Z_FULL_FLUSH to compress data in a way which is compatible with Git and allows us to random access data in objects stored in git.

TL;DR I use an Excalidraw, wrap the elements of interest with a frame, name it with export_ prefix, my forked excalidraw extension automatically generates SVGs for light and dark mode.

Join me on a jump right into the rabbit hole on what we find when we look closer at the .git folder. We'll explore how git stores your code in loose objects and discover a flag in a 30yr old library used by git that could let us run databases inside git.

In the upcoming series of blogposts I'm going to share the results of my research over the last years.

The result: A way to enable random read and write access in git's storage, driving a version controlled fs that allows to run versioned sqlite database on top of git's internal storage.

Network File System (NFS) provides a powerful way to built a vfs on OSx, but it has a fundamental limitation when it comes to event asdasdpropagation. This article explores how event delegation works in NFS, the challenges with remote changes, and an approach to ensure proper notificatioasdn delivery to client applications using a side-channel.