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'?
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?
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?