Unix is a general-purpose, multi-user, interactive operating system for the larger Digital Equipment Corporation PDP-11 and the Interdata 8/32 computers. It offers a number of features seldom found even in larger operating systems, including i A hierarchical file system incorporating demountable volumes, ii Compatible file, device, and inter-process I/O, iii The ability to initiate asynchronous processes, iv System command language selectable on a per-user basis, v Over 100 subsystems including a dozen languages, vi High degree of portability. This paper discusses the nature and implementation of the file system and of the user command interface. I.

A compositional style of programming is often advocated by functional programmers. However, there is a certain efficiency penalty involved in creating the requisite intermediate structures. Deforestation is a program transformation technique which removes such structures for some such programs. This paper is an investigation into the issues of termination of the transformation process. 1

The program Amoeba Make, or Amake, is being designed to fulfil the need of a make-like configuration manager capable of exploiting the potentials of the Amoeba distributed operating system. The major design goal is to create a software configuration manager that is both easy to use and efficient. The specification and maintenance of a large configuration should be easy, and should be automated as much as possible. Furthermore, the build process should exploit Amoeba's capabilities and resources when creating or updating a target. In this paper we show how a smart file server can contribute to Amake's efficiency. We also show how a declarative configuration description allows Amake to take full advantage of parallelism and to determine the commands needed for building and maintaining targets. 1. INTRODUCTION The program Amake was designed to fulfil the need of a make-like configuration manager that tries to overcome make's inability to maintain large and complex systems in a convenien...

Abstract: This article examines the academic substance of software engineering. It identifies the basic research questions and the methods used to solve them. What is learned during this research constitutes the body of knowledge of software engineering. The article then discusses at length what about software makes its production so difficult and makes software engineering so challenging an intellectual discipline. 1

This paper describes in high-level terms the implementation of the resident UNIX+ kernel. This discussion is broken into three parts. The first part describes how the UNIX system views processes, users, and programs. The second part describes the I/O system. The last part describes the UNIX file system. 1. INTRODUCTION The UNIX kernel consists of about 10,000 lines of C code and about 1,000 lines of assembly code. The assembly code can be further broken down into 200 lines included for the sake of efficiency (they could have been written in C) and 800 lines to perform hardware functions not possible in C. This code represents 5 to 10 percent of what has been lumped into the broad expression "the UNIX operating system." The kernel is the only UNIX code that cannot be substituted by a user to his own liking. For this reason, the kernel should make as few real decisions as possible. This does not mean to allow the user a million options to do the same thing. Rather, it means to allow o...

project of the late sixties that involved at one time the MIT, General Electric and AT&T. It was designed by programmers for programmers and used simple solutions whenever feasible. It had no virtual memory. Process sizes in the earlier versions were limited to 64K, the size of the PDP-11 address space. As a result, UNIX has evolved along a toolbox approach: large tasks are normally accomplished by combining existing small programs rather than developing complex subsystems. Almost from the beginning, UNIX was written in a high-level language and its source code made available to licensees, which explains the numerous ports and variants. The fact that the command interpreter---or shell---is a separate program has allowed it to be easily modified or replaced. The UNIX file system is one of UNIX most durable legacies. While its file naming mechanism based on a hierarchy of directories and sub-directories was borrowed from MULTICS, the inclusion of devices in this hierarchy

Rc is a command interpreter for Plan 9. It also runs on a variety of traditional systems, including SunOS and the Tenth Edition. It provides similar facilities to Bourne's /bin/sh, with some small additions and mostly less idiosyncratic syntax. This paper introduces rc's highlights with numerous examples, and discusses its design and why it varies from Bourne's. 1. Introduction Plan 9 needs a command-programming language. As porting the Bourne shell to an incompatible new environment seemed a daunting task, I chose to write a new command interpreter, called rc because it runs commands. Although tinkering with perfection is a dangerous business, I could hardly resist trying to `improve' on Bourne's design. Thus rc is similar in spirit but different in detail from Bourne's shell. The bulk of this paper describes rc's principal features with many small examples and a few larger ones. We close with a discussion of the principles guiding rc's design and why it differs from Bourne's desig...

This work studies the use of customization in a campus UNIX computing environment where a large computing culture exists, but one that has many diverse interests rather than focusing on a cohesive project. We found there to be a gap between the core system users who use customization facilities and periphery users who show an interest in customization, but are unaware of how to pursue it. These results point to the need for better means for connecting novice users with useful customizations.

Submitted as part of the requirements for the award of the MSc in