Group: operating system

topic root > Group: computer science

computer science
computer hardware
distributed systems
parallel processing
computer architecture
decomposition of a system into levels
information as a hint
interprocess communication
non-preemptive task scheduling
open systems
operating system security
programming system
real time systems
software portability
virtual machine
virtual memory
virtualized hardware

all groups
map of the Thesa web site
topics n-r


Operating systems serve several functions: to isolate the user from difficult I/O protocols and timing constraints, to give uniform reference to storage files, to provide frequently required functions, to provide a clean machine interface, to fairly schedule multi-user environments, and to provide mechanisms for interfacing or combining user programs. The operating system may include an optimized kernel for frequently used operations.

Operating systems come at a high cost; both in resources and in internal complexity. This cost is worthwhile if the system matches its environment, is small, and performs only the actions required. One of the most successful operating systems has been UNIX developed at Bell Labs. This is largely due to its powerful user interface. (cbb 5/80)

Group members up

Group: file system
Group: memory management
Topic: device driver
Topic: extensible systems
Topic: multi-user systems
Topic: operating system kernel
Topic: owned resources and data objects
Topic: user-centered operating system
Topic: Unix pipes
Subtopic: OS layers up

Quote: an operating system should be constructed in layers; all interaction between modules should take place through defined paths only; a malfunction of one module cannot affect nor damage lower levels of the system [lampBW_1971]
Quote: each layer of an operating system creates a more convenient environment for the next higher layer; the lower layers create a large number of user machines that provide shared access to hardware resources [lampBW_1971]
Quote: as we rise through the layers of an operating system, the consequences of an error become less severe and the facilities become more elaborate [lampBW_1971]
Quote: study of device drivers in the Linux kernel; 70% of Linux code with over 5 million lines [kadaA3_2012]
Quote: the goal of an operating system is insensitivity to indeterminism; via layers that are insensitive to proceeding layers [dijkEW2_1971]
Quote: structure an operating system as layers of insensitive, abstract machines [dijkEW2_1971]

Subtopic: application specific operating system up

Quote: TinyOS is a flexible, application-specific operating system for sensor networks; limited resources, event-centric, concurrent, low-power, widely deployed [leviP_2005]

Subtopic: modeling up

Quote: build model-extraction algorithm from getstate(), setstate(), and getallstates(); for each state, determine effect of each system call [chenH8_2002]
Quote: build a finite state model by 1) identifying states as kernel variables and 2) finding transitions by trying every system call; collapse equivalent states [chenH8_2002]

Subtopic: distributed OS up

Quote: PlanetLab provides distributed virtualization for planetary-scale network services; unbundled management decouples the operating system from the network-wide services that define PlanetLab [baviA3_2004]
Quote: Inferno provides a complete operating system with identical, distributed applications on a wide variety of machines [dorwSM1_1997]
Quote: PlanetLab OS thoroughly audits, limits and accounts for resource usage; isolate slices from each other and audit actions [baviA3_2004]
Quote: PlanetLab users must understand how their services affect the Internet; this is a novel requirement, unlike traditional time-sharing systems [baviA3_2004]
Quote: definition of the PlanetLab OS that runs on each node; a Linux kernel with patches for vservers and hierarchical token bucket packet scheduling; includes CPU scheduling, safe raw sockets, and the node manager [baviA3_2004]

Subtopic: performance up

Quote: should build a computer system so that it has a good performance model [dennPJ9_1980]

Subtopic: OS crashes up

Quote: disk reliability model assumes processor malfunctions crash the system; consistency checking may not be sufficient [lampBW_1981]
Quote: actions in the presence of crashes should be restartable; i.e., the post conditions Q_ok and Q_crash imply the precondition P [lampBW_1981]
Quote: the Nooks reliability subsystem was particularly useful in kernel development; fast restart on extension failure [swifMM10_2003]
Quote: filesystem metadata must maintain its integrity despite unpredictable system crashes; no dangling pointers, no ambiguous resource ownership, no unreferenced live resources; requires sequenced or grouped updates [mckuMK6_1999]
Quote: most system crashes occur within 10 seconds of injecting 10 hardware and software faults; e.g., a memory bit flip or memory allocation error; about 40% of the time, no crash within 15 minutes [ngWT4_2001]
Quote: the reliability of a write-back file cache depends on syncing modified file data to disk; default FreeBSD sync is not robust during OS crashes (40% corrupted) [ngWT4_2001]
Quote: data corruption on OS crash due to file system hang before sync, page fault during sync, buffer locked during sync, double-faults, or repeated device timeouts [ngWT4_2001]

Subtopic: resource management up

Quote: PlanetLab OS thoroughly audits, limits and accounts for resource usage; isolate slices from each other and audit actions [baviA3_2004]
Quote: resource containers for fine-grained resource management in monolithic kernels; e.g., high-performance Web server; negligible overhead compared to HTTP transsactions [bangG2_1999]

Subtopic: binary vs. home filesystem up

Quote: cfengine distinguishes between binary filesystems for this host architecture and home filesystems for user data on any type of host [burgM7_1995]

Subtopic: operating system transactions up

Quote: transactions should be part of the operating system and widely available [grayJ11_1985]

Subtopic: high-level language up

Quote: an operating system should be written in a high-level language for portability [ritcDM7_1978b]
Quote: operating system research influenced C++: protection from access rights, initialization from capabilities, const from read/write access protection, exception handling from fault-tolerant systems [stroB_1994]
Quote: write an operating system with a high-level language and a system nucleus [brinP4_1970]
Quote: use the full ASCII character set within an operating system; simplifies input routines and avoids preconceived notions [stoyJE3_1972]

Subtopic: program activations tied together by disk files up

Quote: most operating systems run sequence(s) of program activations; free resources and store data in disk files between activations [wirtN9_1989]

Subtopic: boot initialization up

Quote: use system initialization code to insert trap doors as the system is booted; initialization is complex and poorly understood [kargPA6_1974]

Subtopic: global variables vs. files up

Quote: Oberon's interface between consecutive commands is primarily global variables; efficient and flexible; storage reclamation more difficult [wirtN9_1989]

Subtopic: user management up

Quote: each OS6 user has a name, unique number, and index; user may 'log in'; includes maximum disk allocation [stoyJE3_1972]

Subtopic: resource management up

Quote: with memory placement arguments, 'new' can assist with general resource management [stroB_1994]
Quote: resource acquisition is initialization: resources released in reverse order of acquisition, and exceptions release allocated resources [stroB_1994]
Quote: resource acquisition is initialization. Resources, like objects, are released in the reverse order of their acquisition; works well with exception handling [stroB_1991x]
Quote: on resource exhaustion, do not attempt to allocate needed resources and resume. It leads to complicated interactions between a library and its users [stroB_1994]
Quote: all operating system resources must be accounted for [shapJS1_2002]

Subtopic: UNIX up

Quote: Unix virtual address space: shared, write-protected program text, non-shared data, and stack at high end [ritcDM7_1978a]
Quote: 1000 UNIX systems even though it was developed by two people in an attic in a year [kernBW1_1979]

Subtopic: manual OS up

Quote: users punched their own tape and hanged the tape with a ticket on a horizontal wire; the operator processed the tapes in order [wilkMV_1951]

Subtopic: problems of traditional operating systems up

Quote: a traditional operating system cannot solve the problem of maximizing the performance of a given hardware system [bailGV8_1977]
Quote: an operating system erects barriers between users so that each has a private address space without interferences or contributions [coxBJ1_1983]
Quote: a single machine operating system is like a centrally planned economy; a distributed o.s. is like a free market [cherDR4_1984]

Related up

Group: computer hardware
Group: distributed systems
Group: input/output
Group: parallel processing
Group: security
Group: systems
Topic: computer architecture
Topic: decomposition of a system into levels
Topic: information as a hint
Topic: interprocess communication
Topic: non-preemptive task scheduling
Topic: open systems
Topic: operating system security
Topic: programming system
Topic: real time systems
Topic: software portability
Topic: virtual machine
Topic: virtual memory
Topic: virtualized hardware

Subtopics up

application specific operating system
binary vs. home filesystem
boot initialization
distributed OS
global variables vs. files
high-level language
manual OS
operating system transactions
OS crashes
OS layers
problems of traditional operating systems
program activations tied together by disk files
resource management
resource management
user management

Updated barberCB 10/05
Copyright © 2002-2023 by C.B. Barber
Thesa, Avev, and thid-... are trademarks of C.B. Barber