Milestone map
Milestone map
3 milestones
Understand Process Management and Implement a Shell
8–16 weeks (includes C and UNIX systems programming prerequisites)
Study process management: process states, the fork-exec model, process scheduling (FIFO, round-robin, priority scheduling), and inter-process communication (pipes, signals). Implement a simple UNIX shell in C or Python that supports: command execution (fork-exec), input/output redirection, pipes between two commands, and background processes with &.
Proof required
Submit: a public GitHub repository containing your shell implementation with a test script demonstrating: command execution, input/output redirection, a pipe between two commands, and a background process; and a 200-word explanation of why fork() creates a copy of the entire address space and what the OS does to make this efficient. A CS lecturer or systems programmer must confirm the implementation is correct and the explanation is accurate.
What gets checked
- Shell correctly handles all four features — command execution, redirection, pipes, background processes
- Test script demonstrates each feature independently — not just a single composite command
- A CS lecturer or systems programmer has confirmed the implementation is correct
Common mistakes
- Shell that uses os.system() or subprocess in Python to implement the fork-exec model — the proof requires implementing fork-exec
- Explanation of fork() that describes what it does without addressing copy-on-write efficiency
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the shell use fork-exec — not os.system() or equivalent?
- Does the test script demonstrate each of the four features independently?
- Does the fork() explanation address copy-on-write — not just 'it copies the process'?
You'll sign in first, then come straight back here.
Implement a Memory Allocator and Study Virtual Memory
8–14 weeks (after milestone 1)
Study virtual memory: page tables, TLBs, demand paging, and page replacement (LRU, clock). Implement a simple memory allocator in C using mmap or sbrk: support malloc, free, and realloc with a first-fit free list. Write a test harness demonstrating correct allocation, deallocation, and fragmentation behaviour.
Proof required
Submit: a public GitHub repository containing your memory allocator implementation with a test harness showing: correct allocation and deallocation, free list merging, and a fragmentation demonstration (alloc/free pattern that causes fragmentation, and your handling of it); and a 200-word explanation of why internal and external fragmentation occur and how your allocator addresses each. A CS lecturer or systems programmer must confirm the implementation is correct.
What gets checked
- Memory allocator uses mmap or sbrk — not wrapping the standard malloc
- Test harness demonstrates fragmentation explicitly — not just allocation and deallocation
- A CS lecturer or systems programmer has confirmed the implementation is correct
Common mistakes
- Memory allocator that wraps the standard malloc/free — the proof requires implementing the allocator using mmap or sbrk
- Test harness that only tests happy-path allocation without demonstrating fragmentation
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the allocator use mmap or sbrk — not the standard malloc?
- Does the test harness demonstrate fragmentation explicitly?
- Does the fragmentation explanation correctly distinguish internal and external fragmentation?
You'll sign in first, then come straight back here.
Present OS Knowledge and Answer Systems Programming Questions
4–6 weeks (after milestone 2)
Write a systems analysis (400 words) explaining how your shell and memory allocator interact with the operating system kernel — what system calls each makes, what the kernel does in response, and what the performance implications are. Present to a CS lecturer or systems programmer who poses at least two novel systems questions you must answer in real time.
Proof required
Submit: a systems analysis (at least 400 words) tracing the kernel interactions of your shell and allocator; and a recording or transcript of a live review with a CS lecturer or systems programmer where they posed at least two novel systems questions and you responded.
What gets checked
- Analysis names specific system calls (fork, exec, mmap, brk, etc.) and explains what the kernel does in response
- At least two novel systems questions were posed in the live review
- Responses to the novel questions used OS concepts — not just code recall
Common mistakes
- Analysis that describes the shell behaviour without naming the specific system calls
- Live review that becomes a code walkthrough without novel systems questions
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the analysis name specific system calls and explain kernel responses?
- Were at least two novel systems questions posed in the live review?
- Did responses use OS concepts — not just code descriptions?
You'll sign in first, then come straight back here.