Block I builds the machine from the bottom up: from transistors and the internal datapath of a microprocessor, through the memory hierarchy and the bus/DMA fabric that feeds it, to the toolchain (compilers, virtual machines), the boot sequence and the specialized accelerators that sit beside the CPU. The recurring theme is the fetch–decode–execute cycle and how every layer above it either feeds the pipeline faster or extends what it can do.

By the end of Block I you can

• name the core blocks of a CPU (ALU, control unit, register file, buses) and trace one instruction through fetch–decode–execute.
• compare the major ISAs (x86/x64 CISC vs ARM/RISC-V RISC) and read simple assembly.
• reason about the memory hierarchy quantitatively — locality, cache hits/misses and average memory access time.
• explain how a C program becomes machine code, and how virtualization layers a guest machine on host hardware.
• describe interrupts, the stack/heap split, address maps and the power-on → bootloader → OS sequence.

• 1

  Course Introduction

  live in-person

  Orientation to the module: scope, expectations, the GenAI policy, and how the architecture → OS → networks journey fits together.

  • Course structure, assessment and attendance Continuous evaluation (60% written, 30% presentations, 10% participation) and the mandatory 80% attendance rule are set out up front so expectations are clear.
  • From the transistor to global networks — the big picture The course is one continuous stack: a switch becomes a logic gate, gates become a CPU, the CPU runs an OS, and OSes talk over networks.
  • Responsible, acknowledged use of generative AI GenAI is allowed but must be disclosed and verified — you own any error it introduces.

  Key idea: abstraction layers. Each layer hides the one below behind a clean interface, so you can reason about a web request without thinking about electrons — yet every layer is still physically there.

• 2

  Introduction to Computer Architecture

  live in-person

  The internal anatomy of a machine and how architectures evolved.

  • Internal components of a basic microprocessor ALU (arithmetic/logic), control unit (sequences instructions), register file, and the buses that connect them form the datapath.
  • History and evolution of computer architectures From the stored-program von Neumann model, through Moore's-law scaling, to the multicore era once single-thread frequency stalled.
  • Alternative computational architectures Harvard (separate instruction/data memory), dataflow, SIMD/vector and GPU-style massively parallel designs depart from the classic von Neumann machine.
  • Peripherals Devices outside the CPU/memory core — storage, I/O — reached over buses and controllers.

  Core mechanism: the von Neumann cycle — fetch → decode → execute → write-back, repeated billions of times per second, with the program counter (PC) holding the address of the next instruction.

  demo · fetch–execute read · Patterson & Hennessy ch.1 — Computer Abstractions & Technology
• 3

  Microprocessors

  live in-person

  Look inside the CPU and meet the major instruction-set architectures.

  • Internal components of a basic microprocessor Pipelining overlaps the stages of consecutive instructions so the CPU retires roughly one per clock instead of one every few clocks.
  • x86, x64, ARM, RISC-V x86/x64 are CISC (rich, variable-length instructions); ARM and RISC-V are RISC (small, fixed-length, load/store) — RISC-V is fully open.
  • Introduction to assembly language The human-readable form of machine code: mnemonics like MOV/ADD/JMP map 1:1 to the instructions the CPU actually executes.

  Key idea — CISC vs RISC: CISC packs complex work into single instructions; RISC keeps instructions simple and uniform so they pipeline cleanly. Modern x86 chips are CISC on the outside but decode into RISC-like micro-ops internally.

  demo · fetch–execute demo · number rep read · ISA reference manuals (Intel SDM, ARM ARM, RISC-V spec)
• 4

  Memory

  live in-person

  Memory technologies and how data moves between CPU and memory.

  • Memory types and technologies SRAM (fast, expensive, used for caches) vs DRAM (dense, cheaper, main memory) vs non-volatile flash/SSD — each trades speed for cost and persistence.
  • Data buses Address, data and control lines carry where, what and when; bus width and clock set peak bandwidth.
  • DMA (direct memory access) A DMA controller moves data between a device and memory without the CPU copying each byte, freeing it for compute.
  • Addressing Every byte of memory has a numeric address; the CPU places it on the address bus to read or write.

  Core formula — AMAT (average memory access time): AMAT = hit time + miss rate × miss penalty. The whole memory hierarchy exists to keep the effective access time close to the fast cache's hit time despite slow DRAM.

  demo · cache read · Patterson & Hennessy ch.5 — The Memory Hierarchy
• 5

  Compilers and Virtualization

  live in-person

  From C source to machine code, and the layers that virtualize hardware.

  • C compiler structure A pipeline: preprocess → lex/parse → semantic analysis → optimize (IR) → code-gen → assemble → link into an executable.
  • Virtual machines and byte code A VM (e.g. JVM) runs portable byte code on an interpreter or JIT, so the same binary runs on any host with that VM.
  • Virtualization technology A hypervisor multiplexes real hardware among guest OSes; type-1 runs on bare metal, type-2 on a host OS.

  Key idea: "compile vs interpret" is a spectrum. Ahead-of-time compilers (C) translate once to native code; VMs translate to byte code and run it later, trading raw speed for portability and safety.

  read · Aho et al. Compilers (the "Dragon Book") ch.1; hypervisor primers
• 6

  Interrupts

  live in-person

  How the CPU stores state and reacts to asynchronous events.

  • Registers The CPU's fastest storage — general-purpose plus special ones: PC (next instruction), SP (stack top), status/flags.
  • Interrupts A hardware or software signal that pauses the current code, saves state, and jumps to a handler via the interrupt vector table — then resumes.
  • Heap and stack The stack holds call frames and locals (grows/shrinks with calls); the heap holds dynamically allocated, long-lived data.

  Core mechanism: on an interrupt the CPU pushes PC and flags, switches to the handler, then a return-from-interrupt restores them — this is also how pre-emptive multitasking and system calls hand control to the kernel.

  read · Patterson & Hennessy — exceptions/interrupts; Bryant & O'Hallaron ch.8
• 7

  Memory Addressing

  live in-person

  How addresses are laid out and how the CPU reaches operands and devices.

  • Memory address maps The physical address space is carved into regions — RAM, ROM/firmware, and memory-mapped device registers.
  • Assembly addressing modes Ways an instruction names its operand: immediate, register, direct, indirect, and base+index+displacement.
  • Peripherals interaction In memory-mapped I/O a device's registers appear at fixed addresses, so ordinary loads/stores drive the hardware.

  Example: MOV AX, [BX+SI+4] uses base+index+displacement — the effective address is computed as BX + SI + 4, exactly the pattern used to walk arrays and structs.

  demo · paging read · ISA manuals — addressing modes; Bryant & O'Hallaron ch.3
• 8

  Booting Process

  live in-person

  What happens between power-on and a running operating system.

  • Baremetal startup At reset the CPU begins executing firmware from a fixed address with no OS, drivers or memory management yet in place.
  • Bootloaders A small program (e.g. GRUB) that locates the kernel, loads it into memory and hands over control.
  • BIOS — UEFI Firmware that initialises hardware and finds a boot device; UEFI is the modern replacement for legacy BIOS (GPT disks, secure boot).

  Key sequence: power-on → firmware (BIOS/UEFI) POST → bootloader → kernel → init/systemd → user space. Each stage sets up just enough to launch the next.

  read · UEFI specification overview; GRUB documentation
• 9

  Heterogeneous Computers

  live in-person

  Specialized processors that complement the CPU.

  • Co-processors Dedicated units (originally the FPU) that offload work the main CPU does slowly.
  • Advanced instruction sets SIMD extensions (SSE, AVX, NEON) apply one instruction to many data lanes at once for media and ML workloads.
  • GPU Thousands of simple cores optimised for data-parallel throughput — graphics, and now the workhorse of deep learning.
  • Crypto processors Hardware for encryption/hashing (e.g. AES-NI, TPM, secure enclaves) — faster and more tamper-resistant than software.

  Key idea — latency vs throughput: a CPU optimises latency for one thread; a GPU optimises throughput across thousands. "Heterogeneous computing" puts the right work on the right processor.

  read · NVIDIA CUDA programming guide (intro); GPU architecture notes

Block II treats the OS as the manager that turns raw hardware into a usable, shared machine. Using Unix/Linux as the running example, it covers the four classic responsibilities — the file system, memory, processes and devices — plus the kernel that mediates them and the shell that scripts them. The throughline is the user/kernel boundary: unprivileged code asks for resources via system calls, and the kernel arbitrates safely between competing programs.

By the end of Block II you can

• navigate a Unix/Linux file system and explain inodes, mount points and file-system types.
• describe virtual memory, paging and segmentation, and compute page/offset splits and page-table sizes.
• trace a process through its life-cycle states and apply scheduling algorithms (FIFO, round robin) to compute waiting/turnaround time.
• reason about IPC, synchronization and the four conditions for deadlock.
• distinguish user space from kernel space, and explain system calls, kernel modules, threads and the /dev–/proc interfaces.

• 10

  Introduction to Operating Systems

  live in-person

  What an OS is and how Unix/Linux came to be.

  • Understanding what an operating system is and its role A resource manager and abstraction layer: it shares CPU, memory, storage and devices among programs and presents them a clean API.
  • The history and evolution of Unix/Linux Unix (Bell Labs, 1969) → POSIX standard → GNU + Linux kernel (1991) → today's servers, Android and macOS lineage.
  • Basic Unix/Linux commands The everyday toolkit: ls, cd, cp, mv, rm, cat, grep, chmod — small tools composed with pipes.
  • Introduction to the Unix/Linux file system A single hierarchical tree from /, where "everything is a file" — including devices and kernel state.

  Key idea: the Unix philosophy — small programs that each do one thing well and combine through text streams and pipes (cmd1 | cmd2).

  read · Silberschatz ch.1–2; The Unix Programming Environment (Kernighan & Pike)
• 11

  File Systems and Memory Management

  live in-person · Lab 1: Computer Assembly

  How files are organized on disk and how the OS manages memory.

  • Understanding file systems: structure and types An inode stores a file's metadata and block pointers; directories map names to inodes. Types: ext4, NTFS, FAT32, ZFS.
  • Memory management in operating systems The OS allocates and protects each process's memory and reclaims it on exit, preventing one process from reading another's.
  • Virtual memory, paging, and segmentation Each process sees a private virtual address space; the MMU translates pages to physical frames, paging unused ones to disk.
  • Basic Unix/Linux file operations The open / read / write / close / lseek system-call interface underlying all file access.

  Core math: with 4 KiB pages a 32-bit virtual address splits into a 20-bit page number + 12-bit offset (2¹² = 4096). A single-level page table then needs 2²⁰ ≈ 1M entries — which is why real systems use multi-level or inverted page tables.

  demo · paging read · Silberschatz ch.9–10 — Main Memory & Virtual Memory
• 12

  Process Management and Scheduling Algorithms

  live in-person

  Processes, their states, and how the CPU is shared between them.

  • Understanding processes in Unix/Linux A process = program + its address space + a PCB (registers, PID, open files); created with fork() and replaced with exec().
  • Process life cycle and states new → ready → running → waiting (blocked) → terminated, with the scheduler moving processes between ready and running.
  • CPU scheduling: concepts and criteria Optimise throughput, CPU utilisation, and average waiting/turnaround/response time — usually trading some against the others.
  • Scheduling algorithms: LIFO, FIFO, round robin FIFO runs to completion in arrival order; round robin gives each process a fixed time quantum, cycling for fairness.

  Worked example: three jobs of burst 4/2/6 under FIFO finish at 4/6/12, so waiting times are 0/4/6 and the average wait is (0+4+6)/3 ≈ 3.3. Round robin with a small quantum lowers response time but adds context-switch overhead.

  demo · scheduling demo · process states read · Silberschatz ch.3 & 5 — Processes & CPU Scheduling
• 13

  Advanced Process Management

  live in-person

  How processes talk to each other and avoid getting stuck.

  • Inter-process communication (IPC) Mechanisms to exchange data: pipes, message queues, shared memory, sockets and signals.
  • Process synchronization and deadlocks Locks, semaphores and mutexes protect critical sections; misused, they cause deadlock where processes wait on each other forever.
  • Implementing process scheduling algorithms in Unix/Linux Linux's CFS (Completely Fair Scheduler) and nice values decide who runs next in practice.

  Core rule — the four Coffman conditions for deadlock, all of which must hold: mutual exclusion, hold-and-wait, no pre-emption, and circular wait. Break any one (e.g. impose a global lock ordering) and deadlock is impossible.

  demo · deadlock demo · scheduling read · Silberschatz ch.6–8 — Synchronization & Deadlocks
• 14

  Unix Kernel Architecture and Boot Process

  live in-person

  Inside the kernel and the boundary between user and kernel space.

  • Kernel architecture in Unix/Linux Linux is monolithic but modular — all core services share one address space, vs a microkernel that pushes services to user space.
  • Understanding the boot process The kernel initialises, mounts the root file system and starts PID 1 (init/systemd), which brings up everything else.
  • Kernel modules and device drivers Code loaded into the running kernel (insmod/modprobe) to add drivers or features without a reboot.
  • System calls and kernel space vs user space A syscall (read, write, fork…) traps from unprivileged user mode into privileged kernel mode.

  Core mechanism: the privilege boundary. User code runs in ring 3 and cannot touch hardware directly; a system call is a controlled trap into ring 0 where the kernel does the privileged work and returns a result — the foundation of OS protection.

  read · Silberschatz ch.2; Linux Kernel Development (Love)
• 15

  Multithreading and Concurrent Programming

  live in-person

  Threads and the patterns and pitfalls of running them concurrently.

  • Introduction to threads, fibers, coroutines, and multi-threading Threads share their process's memory (cheaper than processes); fibers/coroutines are cooperatively scheduled in user space.
  • Thread management and synchronization in Unix/Linux POSIX threads (pthread) plus mutexes and condition variables coordinate access to shared data.
  • Concurrent programming challenges and patterns Race conditions, starvation and the producer–consumer / reader–writer patterns recur across concurrent systems.

  Key idea — concurrency vs parallelism: concurrency is dealing with many tasks at once (interleaving on one core); parallelism is doing them at once (multiple cores). A race condition is when the result wrongly depends on the unpredictable interleaving.

  demo · deadlock read · Silberschatz ch.4 — Threads & Concurrency
• 16

  Device Mapping and /proc Filesystem

  live in-person

  How Unix exposes devices and kernel state as files.

  • Understanding device files in Unix/Linux Entries in /dev are character (stream) or block (random-access) devices, identified by major/minor numbers.
  • Exploring the /proc filesystem A virtual file system exposing live kernel and per-process data — e.g. /proc/cpuinfo, /proc/<pid>/status.
  • Mapping and managing devices in Unix/Linux udev creates and names device nodes dynamically as hardware appears.
  • Practical exercises with /proc Reading these pseudo-files is how tools like ps and top learn what the system is doing.

  Key idea: "everything is a file" taken literally — devices and even kernel state are read and written through the same open/read/write interface as ordinary files, so existing tools just work.

  read · proc(5) man page; Linux device-driver docs
• 17

  Bash Programming

  live in-person

  Automating the system from the shell.

  • Basics of bash scripting Variables, quoting, conditionals (if), loops (for/while) and exit codes turn commands into programs.
  • Automating tasks with bash scripts Chaining tools with pipes and redirection, scheduled via cron, to do repetitive work hands-free.
  • Advanced bash scripting techniques Functions, command substitution $(…), arrays, traps and parameter expansion for robust scripts.

  Example: for f in *.log; do gzip "$f"; done compresses every log in one line — the shell as glue between the small tools learned in session 10.

  read · GNU Bash Reference Manual; The Linux Command Line (Shotts)

Block III connects the machines from Blocks I–II into networks and the global Internet. It works down the layered model: from the OSI/TCP-IP framework, through IP addressing and subnetting, the TCP and UDP transport protocols, the translation and naming glue (NAT, DNS), ports, and finally security (TLS/HTTPS) and the tooling to inspect a live network. The throughline is encapsulation — each layer wraps the one above in its own header and trusts the layer below to deliver it.

By the end of Block III you can

• map a function to the right OSI/TCP-IP layer and explain encapsulation header-by-header.
• perform IPv4 subnetting — derive network/broadcast addresses, host counts and masks from CIDR notation.
• contrast TCP (reliable, connection-oriented) with UDP and walk through the three-way handshake and key TCP states.
• explain NAT, DNS resolution, common ports, and the role of port forwarding.
• describe how TLS secures HTTPS, and use Nmap/Wireshark to discover and inspect a network.

• 18

  Networking

  live in-person

  Foundations of computer networking and how the Internet came to be.

  • Overview of the module and key objectives Framing networking as the discipline of moving bits reliably between independent machines.
  • Basic concepts of computer networking Nodes, links, packets vs circuits, bandwidth vs latency, and topologies (LAN/WAN); the Internet is a packet-switched network of networks.
  • History of the Internet: from ARPANET to the World Wide Web ARPANET (1969) → TCP/IP standardised (1983) → the Web (Berners-Lee, 1991) layered HTTP on top.
  • Evolution of networking technologies and protocols From dial-up to fibre and 5G, but the protocol stack (IP at the waist) stayed remarkably stable.

  Key idea — packet switching: data is chopped into independently routed packets that share links and can take different paths, which is far more robust and efficient than holding a dedicated circuit open end-to-end.

  read · Kurose & Ross ch.1; Tanenbaum ch.1 — Introduction
• 19

  OSI Model and TCP/IP Basics

  live in-person

  The layered models that structure all network communication.

  • Understanding the OSI model: layers and functions Seven layers — physical, data link, network, transport, session, presentation, application — each with a defined job.
  • Introduction to the TCP/IP model The practical 4-layer model the Internet actually runs: link, internet (IP), transport (TCP/UDP), application.
  • Comparison between OSI and TCP/IP models OSI is the teaching reference; TCP/IP is the deployed stack — OSI's top three layers collapse into TCP/IP's application layer.
  • Basic networking protocols and their roles IP routes, TCP/UDP transport, Ethernet/Wi-Fi link, and HTTP/DNS at the application layer.

  Core mechanism — encapsulation: sending down the stack adds headers ([Ethernet [ IP [ TCP [ data ] ] ] ]); receiving strips them back off. Each layer talks only to its peer on the other host.

  demo · OSI / TCP-IP read · Tanenbaum ch.1.4; Kurose & Ross ch.1.5 — Protocol layers
• 20

  Understanding Ports and Port Management

  live in-person

  IP addressing schemes and how networks are partitioned.

  • Introduction to IP addressing An IPv4 address is 32 bits (four dotted octets); a subnet mask marks which bits are network vs host.
  • Differences between IPv4 and IPv6 IPv4 has ~4.3 billion addresses (2³²) and is exhausted; IPv6 uses 128 bits — effectively unlimited — and drops the need for NAT.
  • Addressing schemes and subnetting CIDR /n notation sets the prefix length; subnetting borrows host bits to split one network into many.
  • Transition strategies from IPv4 to IPv6 Dual-stack, tunnelling (6to4) and translation let the two coexist during migration.

  Worked example: a /24 mask (255.255.255.0) leaves 8 host bits → 2⁸ − 2 = 254 usable hosts (minus the network and broadcast addresses). A /26 leaves 6 → 62 hosts per subnet, four subnets per /24.

  demo · subnetting read · Kurose & Ross ch.4 — The Network Layer (IP, addressing)
• 21

  TCP/IP and UDP

  live in-person

  The two core transport protocols and when to use each.

  • Deep dive into TCP (Transmission Control Protocol) Connection-oriented and reliable: sequence numbers, acknowledgements, retransmission and sliding-window flow/congestion control.
  • Understanding UDP (User Datagram Protocol) Connectionless and best-effort: a thin wrapper over IP with no handshake or retransmission — minimal overhead.
  • Differences and use-cases of TCP vs UDP TCP for web, email, file transfer (correctness matters); UDP for DNS, VoIP, games, streaming (speed beats perfection).
  • Practical examples and applications Watching a real handshake and teardown in Wireshark ties the theory to the wire.

  Core mechanism — the 3-way handshake & states: SYN → SYN-ACK → ACK moves a connection through LISTEN → SYN-SENT/SYN-RECEIVED → ESTABLISHED; closing walks FIN/ACK → … → TIME-WAIT → CLOSED.

  demo · TCP handshake read · RFC 9293 (TCP), RFC 768 (UDP); Kurose & Ross ch.3 — Transport
• 22

  NAT, DNAT, DNS, and DynDNS

  live in-person

  Address translation and the naming system of the Internet.

  • Network Address Translation (NAT) and Dynamic NAT (DNAT) A router rewrites private addresses to one public IP (and tracks ports), so a whole LAN shares a single address — softening IPv4 exhaustion.
  • Understanding DNS (Domain Name System) A distributed hierarchy (root → TLD → authoritative) that resolves example.com to an IP, mostly over UDP port 53.
  • Dynamic DNS (DynDNS) and its applications Automatically updates a hostname's record when a home/server IP changes, so the name keeps working.
  • Configuring and troubleshooting DNS Record types (A, AAAA, CNAME, MX) and tools like dig/nslookup to diagnose resolution.

  Key idea: DNS is the Internet's phone book and NAT is its address-sharing trick. A typical request first does a DNS lookup to get an IP, then NAT lets your private host reach that IP through the router's single public address.

  read · Kurose & Ross ch.2.4 (DNS); RFC 1631/3022 (NAT)
• 23

  Understanding Ports and Port Management

  live in-person

  Well-known ports, their roles, and the security implications of opening them.

  • Overview of network, ports and their importance A 16-bit port number (0–65535) plus an IP identifies an endpoint; the pair lets one host run many services at once.
  • Common ports: SSH (22), HTTP (80) and others HTTPS 443, DNS 53, SMTP 25 — the well-known ports (0–1023) map standard services so clients know where to connect.
  • Reserved ports and their uses Binding to ports below 1024 requires privilege, limiting who can impersonate a standard service.
  • Port forwarding and security implications Forwarding maps an external port to an internal host (e.g. through NAT) — convenient, but every open port widens the attack surface.

  Key idea — the socket: a connection is uniquely identified by the 4-tuple (src IP, src port, dst IP, dst port), which is exactly how the OS demultiplexes incoming packets to the right process.

  demo · ports read · IANA Service Name & Port Number Registry
• 24

  Secure Networking, HTTPS and Security Practices

  live in-person

  Encrypting traffic and securing communication on the wire.

  • Basics of HTTPS and SSL/TLS HTTPS is HTTP inside a TLS tunnel; TLS provides confidentiality, integrity and server authentication via certificates.
  • Implementing secure web communication A certificate signed by a trusted CA proves the server's identity and carries its public key.
  • Best practices for network security Defence in depth: least privilege, patching, firewalls, strong ciphers and minimising open ports.
  • Port forwarding and security implications Revisited from a security lens — exposed ports must be justified, monitored and locked down.

  Core mechanism — the TLS handshake: asymmetric crypto (the certificate's key pair) authenticates the server and securely agrees a shared symmetric session key; the bulk data is then encrypted with the fast symmetric key. Hybrid crypto = the security of public-key with the speed of symmetric.

  demo · ports read · RFC 8446 (TLS 1.3); Kurose & Ross ch.8 — Network Security
• 25

  Network Scanning and Analysis with Nmap and Wireshark

  live in-person

  Discovering and auditing networks with practical tooling.

  • Introduction to Nmap (Network Mapper) A scanner that probes hosts to find which are up and which ports/services are open.
  • Basic and advanced scanning techniques From a TCP-connect scan to stealthier SYN scans, OS fingerprinting and version detection.
  • Network discovery and security auditing with Nmap Mapping a network's live hosts and exposed services is the first step of both defence and attack.
  • Using Nmap in various scenarios (with Wireshark) Wireshark captures and decodes individual packets, showing the handshakes and headers from earlier sessions on the wire.

  Example: nmap -sS 192.168.1.0/24 SYN-scans a whole /24 to list reachable hosts and open ports — pair it with a Wireshark capture to see exactly which packets it sends. Only scan networks you are authorised to test.

  read · Nmap Reference Guide; Wireshark User's Guide

Block IV is where the theory becomes practice and is assessed. Three hands-on labs consolidate each preceding block (assemble a machine, install an OS, configure a network); the mid-term and final written exams (together 60% of the grade) test mastery; and the individual and group presentations (30%) develop the skill of explaining technical work clearly. The global review knits the whole stack back together before the final.

By the end of Block IV you can

• apply Block I–III theory hands-on — assemble hardware, install/partition an OS, and configure working connectivity.
• perform under closed-book exam conditions across the full syllabus.
• present technical work individually and as a team, and field questions on it.
• synthesise architecture, OS and networking into a single end-to-end mental model.

• 26

  Lab Session 1 — Computer Architecture

  live in-person · hands-on lab

  Applied lab consolidating Block I: working hands-on with computer architecture.

  • Computer assembly and component identification Physically seating CPU, RAM, storage and expansion cards on a mainboard — the abstract datapath made tangible.
  • Connecting architecture theory to real hardware Matching sockets, buses and the memory hierarchy from sessions 2–9 to actual parts.

  Lab goal: see that the von Neumann diagram is real silicon — the CPU socket, the DRAM DIMMs of the memory hierarchy, and the buses that connect them.

  demo · fetch–execute
• 27

  Lab Session 2 — Operating System Installation

  live in-person · hands-on lab

  Applied lab consolidating Block II: installing and configuring an OS.

  • Operating system installation Walking the boot → installer → first-boot path from session 8/14 on a real or virtual machine.
  • File system layout, partitioning and the boot process in practice Partitioning a disk, choosing a file system and installing the bootloader make sessions 8, 11 and 14 concrete.

  Lab goal: carry a machine from bare firmware to a running OS yourself — the same power-on → bootloader → kernel → init sequence covered in theory.

  demo · paging
• 28

  Lab Session 3 — Networking Configuration

  live in-person · hands-on lab

  Applied lab consolidating Block III: configuring a working network.

  • Networking configuration Assigning IP addresses, masks and gateways and bringing up interfaces on a real or virtual topology.
  • Addressing, subnetting and connectivity testing in practice Applying the session-20 subnetting math, then verifying with ping, traceroute and a packet capture.

  Lab goal: take two configured hosts from session 27 and make them talk — proving the OSI stack, addressing and transport layers from Block III actually carry your packets.

  demo · subnetting
• 29

  Mid-term Exam

  live in-person · closed book

  Mid-term examination covering the material to date (intermediate tests, 30%).

  • Closed-book assessment of architecture, OS and networking fundamentals Tests block-by-block mastery mid-course so gaps surface while there is still time to fix them.

  Expect: conceptual questions plus short calculations — AMAT, a FIFO/round-robin schedule, a page/offset split, a subnetting problem.

• 30

  Group Presentations

  live in-person · assessed

  Teams present their project work (group presentation, 15%).

  • Group project presentation and peer discussion Assessed on correctness, depth, clear division of labour and how well the team answers questions.

  Key idea: explaining a system well is its own skill — being able to teach a concept is the strongest evidence you actually understand it.

• 31

  Group Presentations

  live in-person · assessed

  Continuation of group and individual presentations.

  • Remaining group / individual presentations (individual presentation, 15%) The solo slot rewards individual technical depth and the ability to defend your own work under questioning.

  Reminder: any GenAI used to prepare slides or research must be acknowledged, and you remain responsible for verifying everything you present.

• 32

  Global Course Review

  live in-person

  Synthesis across all three blocks and preparation for the final exam.

  • Comprehensive review of architecture, operating systems and networking Revisiting the highest-leverage concepts and the calculations most likely to appear on the final.
  • Connecting the full stack — transistor to global network Tracing one request end-to-end: gates → CPU → OS scheduler → socket → IP/TCP → the wire and back.

  Key idea: the whole course is one story. A single web request touches every block — the CPU executes the browser, the OS schedules it and opens a socket, and the network stack carries it across the world.

• 33

  Final Exam

  live in-person · final assessment

  Comprehensive final examination (final exam, 30%).

  • Final assessment across the entire syllabus Closed-book and cumulative; the single largest individual grade component.

  Note: a June/July re-sit, if needed, is one comprehensive exam worth 100% of the re-sit grade (min pass 5.0, capped at 8.0) — continuous evaluation does not carry over.