Implement an OS Component to Prove Systems Understanding

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

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.

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

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.

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

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.