Code Wrangling at its Best
Before we add paging, a heap, processes, filesystems, or user programs, the kernel must answer a basic question: Which physical 4 KiB pages of RAM are safe for me to use? Right now, our kernel can boot, print text, catch CPU exceptions, and receive timer/keyboard interrupts. But it still cannot safely allocate memory. This chapter
Continue Reading “Chapter 4 — Reading the Memory Map and Building a Physical Page Allocator”
In Chapter 2 we taught the CPU how to call our code when something goes wrong: Now we will teach the machine how to call our code when hardware wants attention: This is the first step toward a living kernel. A timer interrupt eventually gives us scheduling. Keyboard input eventually gives us a kernel monitor
Continue Reading “Chapter 3 — Hardware Interrupts: PIC, PIT Timer, and Keyboard Input”
In Chapter 1, we got control of the machine: Now we need something more important than printing text: we need the CPU to call our code when something goes wrong. Right now, if the kernel executes an invalid instruction, divides by zero, touches unmapped memory later, or faults during setup, the machine may reset, hang,
Continue Reading “Chapter 2 — GDT, IDT, and Surviving Your First Kernel Crash”
Today, we are beginning a new article series: “Writing a Linux-Style Operating System From Scratch.” In this series, we will walk step by step through the process of creating our own operating system from the ground up. Many operating system tutorials stop shortly after the system boots and prints a simple message on the screen.
Continue Reading “Writing a Linux-style Operating System From Scratch”
Together, these tools allow us to assemble, compile, link, inspect, and transform kernel binaries without using the host operating system’s normal compiler target.
Purpose This design describes a PocketFlow Creator workflow that accepts a software project folder containing a docs/ subfolder and a project specification, then uses a queue-driven RALF loop to implement the project in ordered, testable increments. The central idea is simple: The LLM may propose.The queue schedules.The gates decide.Git preserves.The human approves high-risk changes. This
Continue Reading “Designing a PocketFlow Creator Flow for Queue-Driven RALF Software Development”
The “Negative Load” Problem Standard linear regulators, like the ubiquitous LM7805, are designed to be “sinks” of power. They take a higher voltage and drop it down, pushing current out of their output pin to power your circuit. However, they are effectively “one-way valves.” In a modern project—especially one involving motors, large inductors, or external
The right to repair is not merely about fixing devices. It is about preserving a mindset — that we are builders, maintainers, and stewards.
Continue Reading “From Fixing to Throwing Away: What We Lost When We Stopped Repairing”
Every major shift in computing has triggered the same fear: “Is this the end of developers as we know them?” When compilers replaced handwritten machine code, some thought assembly programmers were finished. When high-level languages emerged, others predicted the death of low-level expertise. When frameworks abstracted enormous amounts of boilerplate, people claimed “anyone can build
In today’s developer landscape, many programmers—both new and seasoned—cling to a single coding paradigm as the “one true way,” dismissing others like object-oriented, functional, or event-driven programming as bloated or misguided. But real engineering maturity comes from knowing why each paradigm exists and when to use it. The most successful developers choose their tools based on risk, scalability, and maintainability—not ideology. This article explores why the refusal to evolve beyond one style limits growth, risks project failure, and ignores decades of hard-earned lessons in software design.
Recent Comments