ECE344 Fall 2026 (Sec 1) Lec 1 - Why Operating Systems?

Overview

Jon Eyolfson introduces ECE344 as a practical study of how operating systems manage hardware and provide abstractions that make programs safer and easier to write. The course uses Linux and the teaching OS xv6, with C-based labs, two tests, a final exam, and a paired project; its core themes are virtualization, concurrency, and persistence.

Key takeaways

Understanding operating systems improves programming across languages because programs written in C, Python, JavaScript, Rust, or Java ultimately interact with OS services.
ECE344's three recurring concepts are virtualization, which creates apparent independent resources; concurrency, which manages overlapping activities; and persistence, which protects data across power loss.
A process is not merely a program file: it is a running instance with state such as registers, a stack, and a heap.
The course's practical work centers on Linux and xv6, connecting real system use with modifications to a small, readable teaching operating system.
Memory is byte-addressable: each address identifies one byte, or eight bits, and a pointer acts as an index into memory; unrestricted access would threaten process isolation.
AI tools are permitted and encouraged as study aids, but students need enough operating-systems knowledge to detect faulty explanations and understand code they submit.

Chapters

0:00 Welcome to ECE344 and Meet Jon Eyolfson

Jon Eyolfson welcomes students to the Fall 2026 ECE344 operating systems course.
He suggests calling him Jon rather than attempting to spell or pronounce his Icelandic surname.

4:54 Why Learn Operating Systems? Linux, xv6, and Better Programming

Eyolfson argues that software either interacts with an operating system or is itself an operating system.
The course uses Linux for concrete study while teaching principles that also apply to Windows and macOS.
Students will modify xv6, a small teaching OS, and build on low-level experience from ECE243.

6:36 Self-Hosting, Home Labs, and the Course Server Rack

Eyolfson describes home labs as a way to practice self-hosting, retain control of data, and understand cloud services.
He says course infrastructure runs on servers in his office, using a messy-but-working setup as a programmer's to-do item.
The course concepts can help students build a small cluster from spare machines and host services themselves.

8:16 ECE344 Grading: Labs, Tests, and a 45% Final

Labs account for 25%: Lab 1 is a short setup exercise worth 2%, followed by labs generally worth 4.4% each.
Two tests are worth 15% apiece; their dates are tentative, and students should email Eyolfson about conflicts.
The final exam is worth 45%, and its date is set by the university.
The class earns a shared 1% when course-evaluation response reaches 75%.

11:26 Lab 6: Pair Project, Proposal, and Demonstration

Labs 1–5 are individual; Lab 6 is completed in pairs from the same practical session.
The project can create new OS-interacting software or improve an existing program using course concepts.
Teams meet with a TA to scope proposals November 16–18 and demonstrate finished work November 30–December 2.
The proposal and demo practicals require in-person attendance; other practicals are optional help sessions.

13:12 Course Infrastructure, Recordings, and Lecture Participation

Course materials are hosted on Eyolfson's self-managed platform at ece.gg, with the course at ece.gg/c/ece344.
The course also self-hosts chat and code, so its services do not depend on GitHub or other external platforms.
Lectures are livestreamed and recorded, but Eyolfson encourages in-person attendance for feedback, questions, and live coding.
Students can suggest ways to make attending lectures more useful rather than ending recordings.

17:01 Zulip, Academic Honesty, and Anonymous Questions

ECE344 uses Zulip instead of Discord because its topic-based conversations make older answers easier to find.
Students can post in the section's lecture-one topic, and an anonymity bot is planned for questions without attached names.
Students may discuss concepts and share non-lab code, but must not post direct lab solutions or cheat.

19:40 AI Guidance, OSTEP, and C Programming Prerequisites

Eyolfson encourages AI use as a learning aid, while warning that students must evaluate incorrect or confused outputs.
Operating Systems: Three Easy Pieces is a free optional companion resource, available online as PDF or HTML.
The course mainly uses C; students should practice reading and debugging C, with a brief possible introduction to Rust.
Expected background includes binary, hexadecimal, decimal, endianness terminology, and byte-addressed memory with pointers.

26:10 The OS as Resource Manager: Virtualization, Concurrency, Persistence

Eyolfson frames an operating system as a manager between applications and hardware, handling requests such as memory allocation through malloc.
Virtualization makes one physical resource appear as multiple independent resources; register saving and restoring provides a small-scale example.
Concurrency concerns managing multiple activities, such as Chrome and other programs running at once.
Persistence concerns retaining consistent files and data even when a machine loses power.

31:20 Processes, Memory Layout, and the Need for Isolation

A program is a file of instructions and data; a process is an executing instance, a distinction that anchors the semester's study.
Eyolfson reviews process state such as virtual registers, a stack for local variables, and a heap for malloc-allocated memory.
A live counting program and a separate Hello World process run without disrupting each other, prompting questions about how each gets memory.
The discussion raises the security risk of treating physical memory as directly accessible: a process might read or overwrite another process's data.

Summary, takeaways, and chapters were generated by AI from the video's transcript and may contain errors. The video belongs to its creator, Jon Eyolfson.