DEV Community: Ronald Gosso

My friend failed his OS exam by 4 marks and passed a cloud cert with 912 the same week

Ronald Gosso — Tue, 20 Oct 2026 09:00:00 +0000

My friend failed operating systems by 4 marks. Same week, he passed his first cloud certification with a score of 912.

I keep thinking about that week. Not because of the gap between the two numbers, but because I was living in the same gap. I just hadn't admitted it yet.

Two worlds that refused to talk

On one side you have the university. Lecture halls with 200 students, a projector, and a lecturer drawing a process state diagram on a whiteboard for the ninth time. Theory, proofs, exam papers, marks.

On the other side you have the cloud. A terminal at 2 AM. A dashboard turning red. A teammate asking why the function that worked yesterday now times out. Nobody there asks you to define a semaphore. They ask you to make the red thing green.

For a long time I assumed one of those worlds was a waste of my time. Some days I blamed the lectures. Other days I blamed the tutorials that taught me how to click through a console but never why anything behaved the way it did. I had a quiet theory that I only needed one of them, and I kept changing my mind about which.

I was wrong, and the way I found out was slow and a little embarrassing.

Deadlocks on paper, timeouts in production

In the OS course, deadlock is a tidy little story. Two processes, two resources. Process A holds one and waits for the other. Process B holds the other and waits for the first. Neither moves. You draw a resource allocation graph, find the cycle, and get your marks.

Then you meet a Lambda function that times out and the logs say nothing useful.

Here is what it looked like in my case. The function opened a database connection, grabbed a lock on a row, and then called another service that was also waiting on that same row. Different code, different runtime, same shape as the diagram on the whiteboard. A cycle. Two things holding and waiting. The timeout was the platform's way of killing the stalemate after a fixed number of seconds.

Once I saw it as a hold-and-wait problem, the fixes were already in my notes. Break the circular wait by always acquiring locks in the same order. Stop holding a resource while you wait on something slow. Add a timeout of your own so you fail early instead of hanging until the platform pulls the plug.

# Same idea as the textbook fix: one global order for locks
def transfer(a, b, amount):
    first, second = sorted([a, b], key=lambda acct: acct.id)
    with first.lock:
        with second.lock:
            first.debit(amount)
            second.credit(amount)

I did not learn that from a cloud tutorial. I learned it from a lecture I had half ignored.

Normalization and the DynamoDB bill

Normalization is the other chapter I used to treat as exam fodder. First normal form, second, third, the whole ladder. Remove repeated groups, remove partial dependencies, remove transitive ones. You split tables so each fact lives in exactly one place.

It is a great habit for a relational database. It is a terrible habit to carry unchanged into DynamoDB.

I did carry it over. I modeled my data the way I had been trained to, with small clean tables and relationships stitched together at read time. DynamoDB has no joins, so my application did the stitching. One screen in the app meant five or six separate reads, and a few queries that quietly turned into scans. Reads cost money. Scans on a growing table cost a lot of money. The bill told me, rather loudly, that my model was wrong for the tool.

What fixed it was understanding why normalization exists in the first place. It exists to avoid update anomalies and wasted storage in a system where joins are cheap. In a key-value store where reads are the expensive part, the trade flips. You design around your access patterns, you duplicate data on purpose, and you accept that updates get harder because reads get cheaper.

If I had only memorized the rules, I would have been stuck. Because I understood the reasoning behind them, I could see exactly where the reasoning stopped applying. That is the whole difference between knowing a rule and knowing a tradeoff.

Scheduling, and how Kubernetes picks a pod's home

Every OS course spends weeks on CPU scheduling. First come first served, shortest job first, round robin, priority queues, starvation, aging. You compute average waiting times by hand until you hate Gantt charts.

Then you read how the Kubernetes scheduler works and it feels strangely familiar.

A new pod arrives and sits in a queue. The scheduler filters out nodes that cannot run it, for example nodes without enough CPU or memory left. Then it scores the survivors and picks the best one. Pods carry priorities. A high priority pod can preempt a lower one when the cluster is full. Resource requests and limits decide what a pod is promised and what it is allowed to burn.

Swap the word process for pod and the word CPU for node, and half of it reads like my old lecture notes. Priority inversion, starvation, preemption. These were not abstract words anymore. They explained why a low priority batch job kept getting evicted, and why a pod with no resource requests behaved like a noisy neighbor.

Nobody told me this would happen. I found out because a pod stayed Pending and I knew which questions to ask.

What the rebuild actually was

I did not wake up one morning and decide to connect the two worlds. It happened in small collisions. A production problem would stall me, I would remember a diagram from a lecture, and the problem would crack open.

Over time I started doing it on purpose. When I met a new cloud service, I asked what operating systems idea it was built on. Queues, caches, locks, schedulers, file systems, virtual memory. Almost every managed service is an old idea with a pricing page attached.

That rebuild is the reason I can debug a distributed system today. Not because I memorized more services. Because I stopped treating each one as a separate magic trick.

Back to my friend

I should be fair to him. A cloud certification and an operating systems exam test different things. One rewards breadth and a clear head under a clock. The other rewards depth and patience with ugly details. Failing one by 4 marks and acing the other says very little about how good an engineer he will be.

But it did make me see my own situation more clearly. I felt split. Half my week belonged to coursework that felt disconnected from my job, and the other half belonged to a job that felt disconnected from my coursework.

Living in both worlds at once feels like a handicap. It runs like a double lab nobody else gets to use. The lecture hall is where you learn why things work. The terminal is where you learn what happens when they don't. If you only have one, you are guessing at the other.

So if you are a student who also ships things, stop apologizing for the overlap. Open your old notes the next time something breaks at 2 AM. There is a decent chance the answer is already in there, written in a boring diagram you drew while half asleep.

What is the strangest place a textbook idea has shown up in your production work?

I got tired of fighting ffmpeg for basic video trimming, so I built clipflow

Ronald Gosso — Wed, 07 Oct 2026 03:06:10 +0000

I got tired of fighting ffmpeg for basic video trimming. So I built clipflow.

You know the drill. You just want to trim a 10-minute video.

You open a terminal and type:
ffmpeg -i input.mp4 -ss 00:30 -to 02:15 -c copy output.mp4

Then you pray you got the flags right.

But wait, you need frame-accurate cutting. So you scrap -c copy. Now you are re-encoding a 4 GB file. Twenty minutes later, you are still staring at a progress bar.

I hit this wall for the fifteenth time last month. Honestly, enough was enough. I decided to build a better way.

What `clipflow` actually does

clipflow is a typed Python API and CLI for video clipping.

It manages ffmpeg for you. It auto-downloads the binary on first use, caches it locally, and falls back to your system PATH if you already have it installed.

No manual setup. No "install ffmpeg first" warnings.

Here is the core idea. It builds and runs ffmpeg commands directly as subprocess calls.

No NumPy array conversions. No memory-heavy frame processing. Just clean, typed dataclasses going in and structured results coming out.

Three things I obsessed over

Lossless stream-copy by default. Trimming a 10 GB file takes seconds with zero quality loss. Need frame-accurate cuts? Just flip a compress flag and it re-encodes properly.
Highlights as a first-class concept. Most Python video libraries treat highlights as an afterthought. In clipflow, you mark a clip with highlight=True. It automatically copies that slice to a highlights/ directory. That is it.
Zero runtime dependencies. The library uses only the Python standard library plus the ffmpeg binary it manages. No bloated dependency tree to debug.

Quick taste

Here is what the Python API looks like:

import clipflow
from clipflow import ClipSpec, parse_range

results = clipflow.trim(
    "raw_footage.mp4",
    ClipSpec(
        parse_range("05:00", "06:30"),
        highlight=True,
        compress=COMPRESS_HIGH,
        aspect_ratio=AR_9_16,
        label="hero_moment"
    ),
    output_dir="out"
)

print(results[0].highlight_path)
# out/highlights/hero_moment.mp4

And the CLI is just as straightforward:

# Lossless trim
clipflow trim lecture.mp4 01:00-02:30

# Compress + crop + highlight
clipflow trim concert.mp4 05:00-06:30 --compress high --aspect 9:16 --highlight

# Inspect metadata
clipflow inspect documentary.mp4

Why not just use `moviepy` or `ffmpeg-python`?

Good question. I asked myself the same thing.

Most Python video libraries convert frames to NumPy arrays. That is slow. It is memory-heavy. And it is completely unnecessary for simple trimming.

clipflow does not touch a single frame. It just constructs the ffmpeg command and runs it as a subprocess.

The entire subprocess layer is isolated in clipflow/_ffmpeg.py. You can audit exactly what is being executed. No magic.

Under the hood

Pure Python (requires ≥ 3.9). No Swift or Rust wrappers.
Cross-platform support for macOS 14+, Windows, and Linux.
ffmpeg auto-downloaded and cached per platform.
82 tests with >90% coverage.
Docker-ready for instant local development.

What is next

I am currently working on batch processing improvements and a highlight-reel example script.

The repo is open and MIT licensed.

If you have ever spent more time fighting ffmpeg than actually editing video, give it a shot. And if something breaks, open an issue. I read every single one.

Links:

GitHub: github.com/ronaldgosso/clipflow
Docker Hub: ronaldgosso/clipflow
PyPI: pip install clipflow