Companion to COMPUTER_SYSTEMS_MASTERY_CURRICULUM.md Written April 30, 2026 — honest reflections, no sugar coating.
Opening Reflection #
You have been using operating systems concepts every single day for years. You just never had the vocabulary. When you configure Puma with 3 workers and 5 threads, you are making OS-level decisions about process isolation, shared memory, and scheduling. When you watch a Ruby process climb to 800MB and never shrink, you are watching virtual memory behave exactly as designed. When you hit the GVL and wonder why your threads do not actually parallelize CPU work, you are bumping into the same concurrency problem that OS researchers have studied since the 1960s.
This module puts names on all of it. That is both its gift and its danger — you will feel like you already know this material, and that feeling will make you lazy in exactly the spots where the real learning lives.
What Will Surprise You #
OSTEP is going to be the best technical book you have ever read. I am not hedging. It is funnier than most fiction, clearer than most tutorials, and deeper than most textbooks. Remzi and Andrea Arpaci-Dusseau wrote it as if they actually wanted you to understand, which is shockingly rare in academia.
The thing that will genuinely surprise you: how much of what you think is "Ruby behavior" is actually "OS behavior." Ruby processes growing and not shrinking? That is the OS memory allocator, not Ruby. Puma workers sharing file descriptors after fork? That is UNIX fork semantics, not Puma magic. Sidekiq jobs dying silently? That is signal handling, not Sidekiq's fault.
You will also be surprised how old these ideas are. Virtual memory, paging, scheduling algorithms — most of this was solved by the 1970s. We are still running on those solutions.
What Will Be Hard #
Concurrency. Full stop. Locks, semaphores, condition variables, deadlock detection — this is where experienced engineers stumble because the bugs are non-deterministic. You cannot puts-debug a race condition. You cannot write an RSpec test that reliably reproduces a deadlock.
The concurrency chapters in OSTEP will require you to sit with discomfort. You will read a section, think you understand it, then try to solve the homework problem and realize you do not. This is normal. Everyone goes through it. The gap between "I can read concurrent code" and "I can write correct concurrent code" is wider than any other gap in computer science.
File system internals will also be harder than you expect. You know PostgreSQL uses fsync for durability, but understanding why — write ordering, journaling, crash consistency — requires thinking about failure modes that Rails abstracts away completely.
What Will Be Easy #
Process management. You already understand fork-exec from Puma. You already understand signals from deploying Rails (SIGTERM, SIGUSR1 for restarts). You already think in terms of parent and child processes. The theory will click fast because you have the practical foundation.
Scheduling will feel intuitive. You have dealt with CPU-bound vs I/O-bound work in Rails — background jobs that hog CPU vs web requests that wait on the database. The scheduling algorithms are formalizations of tradeoffs you already make.
Memory hierarchy concepts — caches, TLBs, page tables — will be new vocabulary for familiar frustrations. Every time you have wondered why a benchmark was inconsistent, cache effects were probably the answer.
Predictions #
-
You will finish OSTEP faster than any other textbook in this curriculum because the writing pulls you forward. Budget time for the homework problems — they are where the actual learning happens.
-
The concurrency section will take you 3x longer than you estimate. You will underestimate it because you have used threads in Ruby. Using threads and understanding threads are different things entirely.
-
After this module, your Puma configuration will change. You will stop copying config from blog posts and start reasoning from first principles about workers vs threads for your workload.
-
You will start reading Ruby MRI source code. Once you understand how the OS handles processes and threads, you will want to see how Ruby maps onto those primitives. The GVL will stop being a mystery and become a design decision you can evaluate.
-
Six months after completing this module, you will debug a production issue using OS-level tools (strace, /proc, lsof) and it will feel like a superpower. That moment is when this module pays for itself.
This is the module where "I deploy Rails apps" becomes "I understand what happens when I deploy Rails apps." That shift is permanent. Once you see the OS layer, you cannot unsee it — and you will never want to.