Chapter 1: Introduction

"An operating system is the layer of software that manages a computer's resources for its users and their applications."

Roles

An operating system plays three main roles for the computer.

• Referee. Operating systems must fairly distribute resources between applications, and ensure the applications are isolated from each other. This includes protecting itself and other applications from malicious programs. It must also, however, allow inter-process communication in a safe, controlled manner.
  
  
• Illusionist. Operating systems must also provide an abstraction of physical hardware for the user applications. It also hides other inner system workings, like physical memory management and processor hardware sharing between processes. This is called virtualization, an illusion of resources that are not physically present.
  
  
• Glue. Operating systems also enable user applications to execute some common instructions and view common data (e.g. file system). They also provide a layer of abstraction between hardware I/O and applications, e.g. gluing the two together without needing applications to worry about hardware-specific operations and vice versa.

Goals

An operating system should satisfy the following criteria as best as possible.

• Reliability and Availability.
  Reliability means that the operating system should minimize errors to the extreme, since errors in the OS can be devastating for users. This is especially true with regards to security.

  Availability means the operating system should minimize crashes, since the OS should ideally be available as frequently as possible. It's typically measured by the frequency of failures (mean time to failure (MTTF)) and the time required to restore the system after a failure (mean time to repair (MTTR)). Higher MTTF or lower MTTR increases availability.
  
  

• Security. Self-explanatory.
  
  

• Portability.
  A highly portable operating system is one that should change minimally between different hardware. That is, it should be easy to adapt a portable OS to run on different graphics cards, processors, etc. A portable OS should also be designed (or require minimal changes) to support applications and hardware that have not been developed yet, i.e. forward compatible.

  This is typically accomplished by providing an abstract virtual machine (AVM)—an interface for system calls (API), a memory abstraction, etc. This allows applications and hardware to develop entirely independently.

  Portability is also frequently enabled by a hardware abstraction layer (HAL). Basically, an AVM is to applications as an HAL is to the operating system.
  
  

• Performance.
  Performance is a surprisingly difficult concept to easily judge. There are several different measurements to consider:

  • Overhead: the added resource cost of an abstraction for applications (less overhead = more efficient). That is, how much faster would the application be if run directly on the hardware.
  • Fairness: how to equitably allocate resources between users/applications.
  • Response time: how long it takes a single task to run. This is especially important for computers that people work on, as responsiveness for I/O dominated processes is extremely important.
  • Throughput: how quickly the system completes tasks. This is often in opposition to response time, due to the overhead of context switches. (Ideally, the processor prioritizes processes that don't spend a lot of time waiting on I/O, as interactive processes typically do).
  • Predictability: how consistent the system's performance (across the other metrics) is over time.
    
    
    

• Adoption.
  This is just how many users use the OS. More users == more resources, more success.

  There's also the issue of proprietary vs. open source operating systems. In other words, why Linux >> Windows/Mac.

In general, many of these criteria may oppose each other. Improvements in performance can impact security and portability negatively, for instance.

Operating Systems: Past, Present, and Future

Moore's Law

In previous decades, Moore's Law allowed operating system developers to ignore performance to some extent, as hardware got faster and faster, year by year. However, as Moore's Law slows down, OS maintainers increasingly have to consider performance, and how to best design an OS to not sacrifice the other qualities.

Multi-User Operating Systems

After the development of early operating systems, for the purpose of reducing programmer errors, came multi-user operating systems. This allowed sharing of resources between different users and applications.

A batch operating system worked on a queue of tasks, that could allow two tasks to "run" in tandem, one fetching from I/O devices using direct memory access (DMA). Next came multiprogramming, which was essentially just concurrency. batch operating systems introduced challenges. though, in the lack of program isolation and the difficulty of debugging the operating system (required to turn the computer into a single-user system temporarily).

Time-Sharing Operating Systems

These were operating systems developed for interactive use, rather than processor-heavy jobs. This is your typical personal computer, which spends much of the time waiting for I/O from hardware like a keyboard or mouse. This required designing operating systems to handle bursts of activity, rather than consistent, sustained activity as seen in batch processing.

Modern Operating Systems

Lots of different types of operating systems for different applications, now. Too many to talk about.