System Programming - Lecture 0, v3 - Intro, Linux, Unix, Standards

Summary

Course purpose and format

Vlad introduces system programming as both a systematic way to understand how software works and the study of low-level system features that help developers build and optimize backend software.

The course focuses especially on Linux and practical examples, connecting application code to the kernel and, at times, to hardware. It is planned as 11 lectures of roughly two to three hours each, with five homework assignments and an optional exam. Lectures include reproducible code examples, self-check questions, and online notes, combining practical demonstrations with theory.

Later topics include virtual memory, filesystems, devices, processes, and multithreading. C is used because it offers low-level access while remaining relatively accessible.

Setting up a development environment

To run the course examples and complete homework, students need access to a non-Windows environment. Windows users have two suggested options:

• Run Linux in a virtual machine, for example with VirtualBox and Ubuntu.
• Use Windows Subsystem for Linux (WSL). The instructor says either WSL 1 or WSL 2 should be adequate for the course.

The examples and homework are optional for viewers who only want to follow the lectures.

Unix, Multics, and the origins of Unix-like systems

The lecture explains that “Unix” can refer to several related things:

• The original operating system created at Bell Labs in 1969.
• A family of systems with related interfaces and concepts.
• A design tradition that influenced many operating systems.
• A trademark, now owned by The Open Group.

Unix grew out of Multics, an ambitious operating system project involving MIT, General Electric, and Bell Labs. Though Multics was considered too complex and demanding for its time, the lecture credits it with ideas that became common in later systems, including:

• A unified process address space that could be backed by different kinds of storage.
• Dynamic linking, which lets programs load executable code such as shared libraries.
• A command-line interpreter running as a user-space program.
• Hierarchical filesystems.
• Protection “rings,” a model for controlling access to system resources.

Unix was developed as a smaller, simpler system. It was initially a single-task system, received its name in 1970, and later gained documentation and versions as its use spread. The lecture notes that Unix was rewritten in C and grew into a widely used system.

The spread of Unix and the need for standards

As Unix-like systems proliferated, different implementations began to behave differently, making portable software difficult to write. The lecture describes two major influences on standardization:

• System V, promoted by AT&T, became an important commercial Unix lineage.
• BSD (Berkeley Software Distribution), developed at the University of California, Berkeley, became another major branch. The lecture highlights BSD’s built-in networking and the Berkeley sockets API, whose functions are also familiar on other platforms.

Standards such as POSIX address portability by specifying expected interfaces and behavior—for example, how certain APIs should work—rather than prescribing exactly how each operating system must implement them. A system can conform to a standard while using its own internal implementation.

There is no single standard that makes all operating systems identical. System calls and low-level features vary across platforms, so a program built for Linux generally will not run directly on Windows, or vice versa, without compatibility tools or a suitable cross-compilation setup. Within a given operating system family, however, backward compatibility often allows software built for older releases to work on newer ones.

Linux, GNU, and what an operating system includes

The lecture distinguishes the Linux kernel from a complete operating system. A kernel manages hardware, processes, scheduling, drivers, and filesystems, but a usable system also needs other components, such as libraries, utilities, compilers, editors, and often a graphical interface.

• Linux began as a kernel project by Linus Torvalds in 1991. The lecture recounts that Torvalds initially considered the name “Freax,” but the project was ultimately named Linux.
• GNU, started by Richard Stallman in 1983, developed free software tools and sought to build a complete free operating system. “GNU” is a recursive acronym for “GNU’s Not Unix.”
• The lecture describes GNU and Linux as complementary projects whose components came together in widely used systems. It also mentions GNU’s Hurd kernel as a separate project.
• Linux’s open development community allows individuals and companies to contribute changes. The instructor notes that companies may develop features commercially and later contribute them upstream, gaining community testing and broader adoption.

Kernel architecture: monolithic and microkernel designs

The lecture contrasts two broad kernel architectures:

• Monolithic kernels keep many kernel services in one kernel address space. Components can communicate through function calls, which the instructor presents as an advantage for performance. Linux is described as monolithic; Windows and Apple systems are also characterized as largely monolithic, though some components may run separately.
• Microkernels move more components into separate processes. This can improve isolation, maintainability, and fault containment: a failing component may be restarted without bringing down the entire system. The trade-off is that components must communicate through interprocess communication (IPC), which adds time and resource overhead.

The lecture frames the debate as a balance between modularity and isolation on one side, and communication overhead and performance on the other.

System calls and programming interfaces

User-space programs cannot directly perform every privileged operation, such as controlling hardware. They request kernel services through system calls. System calls are not unique to Linux; operating systems generally need them to provide controlled access to kernel functionality.

The lecture uses C as the main language because system interfaces are commonly exposed through C-style APIs, and C provides a practical way to study low-level behavior. Standards such as POSIX and the C and C++ standards help define portable behavior at higher levels. They do not erase platform differences in kernel interfaces or dictate internal implementation.

Main takeaways

• Unix is both a historical operating system and a broader family of related systems and design ideas. Linux, BSD, and Apple systems are Unix-like descendants or relatives, not the original Unix itself.
• A kernel is only one part of a complete operating system.
• Standards define shared interfaces and expected behavior, not one universal implementation.
• Understanding system calls, memory, processes, filesystems, and hardware interactions can help developers make better design and performance decisions.
• The course aims to connect practical programming with how systems operate underneath the application level.

Speakers and sources featured

Speakers

• Vlad — lecturer and course presenter.
• Linus Torvalds — heard in an inserted recording pronouncing “Linux.”

Books, standards, and materials mentioned

• Linux Kernel Development
• Advanced Programming in the UNIX Environment
• Andrew Tanenbaum’s Operating Systems: Design and Implementation
• POSIX, published by IEEE
• Unix man pages and online course notes, code examples, and homework materials

Historical figures and projects discussed

Dennis Ritchie and Ken Thompson; Multics; AT&T; System V; BSD; Linus Torvalds and Linux; Richard Stallman and GNU; Andrew Tanenbaum and Minix/Hurd.