CS 736 Reviews - Spring 2015

1. Summary
This paper is an introduction to the Unix time-sharing operating system in aspects of file system and its implementation, process execution and management, system shell and traps.

2. Problems
The problems they are trying to solve should be that operating systems at that time are not that easy to use. They are not flexible in the file system, doesn’t support multi-user and not very portable. Unix is designed for easier write, test and run programs.

3. Contributions
Generally, Unix provides a solution of interactive operating system that is in general purpose and supports multi-user.

File System: files are categorized into three kinds, ordinary files, directories and special files, which makes file and device I/O as similar as possible for easier access and maintenance. What’s more, protections are offered to control access in different files. Disk mount gives flexibility of the whole file system.

Process: Using fork() and execute() is a more flexible, safe and efficient way in accepting and executing user input command.

Shell: Shell provides an interactive approach for users to interact with the os. It also have features such as redirect, pipe and run program in background.

Traps: Using interrupts to inform the system is more efficient than continuously pinging.

4. Evaluation
The paper evaluate Unix os as a general functional system and provides data concerns with Unix. There is no evaluation of the Unix compared with other contemporary operating systems.

5. Confusions
The fork and execute mechanism is still used nowadays, are there any competing mechanisms in interacting with the kernel?

It is a makeup submit as I just got enrolled on Jan 28, thanks.

1. Summary
Ritchie and Thompson, in this paper have provided a high-level overview of fourth generation Unix OS run on PDP-11 machines, by layering out the important features from the implementation of the file system, hardware-software interface, process abstraction to the shell command interface. On an important note, authors also discuss the key design decisions and how by adapting certain good old features from other system softwares, influenced them to make Unix simpler, elegant, cost effective yet powerful operating system.

2. Problem
Earlier operating systems were bulk in size as a system software and implementing them on machines with memory size constraint (for example PDP machines) was a huge challenge. Most of them ran on mainframes and programmers were supposed to use the systems in batch mode instead of interactive mode. Adding to that, maintaining these bulky system softwares was itself a complex and time consuming task. Authors, have tried to solve these design problems, thus making Unix OS programmer friendly and adaptable to any real-time applications.

3. Contributions
- Unix provides a convenient and easier interface of file systems to programmers without creating a distinction between the devices and files. The removable file systems help for system scalability and need not always depend on a single storage device.
- Advanced protection features are enabled compared to previous operating systems, thus respecting users’ access privileges.
- Lowest possible interface is provided between the programmers and the system calls, thus avoiding an extra layer of insulation to open, create, read or to write files. File systems’ metadata and heirarchy is neatly encapsulated and maintained by using a feature called i-node.
- Unix provides no distinction between random and sequential I/O and read/write calls appear to be synchronous and unbuffered.
- Virtualization feature of OS is supported by process abstraction and memory images. Many system calls life fork, exec, wait along with processes and hardware interrupts makes Unix a multiprogramming and multitasking OS.
- The greatest contribution of Unix is the interactive environment with shell command line interface, which has standard I/O, input-output redirection and background process making the programming framework much more convenient and easier.

4. Evaluation
The authors have not presented any solid backing of Unix system software being evaluated. Although, some statistics have been included to support the scalability feature of Unix OS, there are no details of performance evaluation or the memory usage reports. Most of the Unix design decisions have been derived out of the problems faced in previous system softwares and a proper evaluation with empirical data would have been better to support all their claims.

5. Confusion
A much more detailed explanation of how linking is done across the file systems would have been better (hard and soft linking). Also, how does Unix achieve consistency of file systems when two users simultaneously write or unlink the files is not explained. When authors speak about the scalability feature in Section IX, a detailed performance comparison with other OSes and machines for real-time applications should have been given.

1. Summary
This paper is an introduction to features of the fourth generation of UNIX operating system, including file system, device and I/O management, process management, shell program, and interrupt and exception handling. It emphasizes the simplicity and elegancy of the design of a general-purpose operating system.
2. Problem
UNIX is the general-purpose operating system; it is not designed to satisfy any specific tasks. However, it is designed to be able to deal with various user scenarios. Several problems arise around this design. First, this operating system should be interactive, as it should respond differently to different tasks. Second, it should fit in the size constraints at that time. Third, it should be able to maintain itself, thus being sustainable.
3. Contributions
On file system, the notion of file is an abstract idea that captures the behavioral aspect of read/write operations. Files could be organized in a tree hierarchy with the notion of directories. I/O devices, provided they share the behavior of ordinary files, could be viewed as a special kind of files. Each file/directory is guarded by protection bits to control access.
Process executes an image which is essentially a snapshot of system status such as registers, memory, open files, etc. Process could communicate to each other and create child processes.
The shell is a special interactive program that allows the user talks to the operating system. It provides a set of general purpose commands and user can write scripts of their own. It could handle multitasking, piping, background execution etc.
Interrupt is a mechanism to stop execution of a process or termination. It could be invoked by hardware exceptions, software exceptions or user.
4. Evaluation
This paper does not provide evaluation section. However, my idea is that the paper addresses the new ideas in their design rather than implementation and performance compared to other operating systems.
5. Confusion
I was wondering whether pipe is viewed as files in UNIX. The term file defined in this paper focuses on its behavioral characteristics rather than essential implementations. In this notion, devices can be abstracted as “files” provided they behave the same as files. For pipes, I suppose it is also a file because the read/write behavior is just the same as a file. However, the paper indicates that “Neither process need to know that, a pipe, rather than an ordinary file, is involved.” Does it imply that pipe is a file, but a special file?

1. Summary
This paper is an introduction to features of the fourth generation of UNIX operating system, including file system, device and I/O management, process management, shell program, and interrupt and exception handling. It emphasizes the simplicity and elegancy of the design of a general-purpose operating system.
2. Problem
UNIX is the general-purpose operating system; it is not designed to satisfy any specific tasks. However, it is designed to be able to deal with various user scenarios. Several problems arise around this design. First, this operating system should be interactive, as it should respond differently to different tasks. Second, it should fit in the size constraints at that time. Third, it should be able to maintain itself, thus being sustainable.
3. Contributions
On file system, the notion of file is an abstract idea that captures the behavioral aspect of read/write operations. Files could be organized in a tree hierarchy with the notion of directories. I/O devices, provided they share the behavior of ordinary files, could be viewed as a special kind of files. Each file/directory is guarded by protection bits to control access.
Process executes an image which is essentially a snapshot of system status such as registers, memory, open files, etc. Process could communicate to each other and create child processes.
The shell is a special interactive program that allows the user talks to the operating system. It provides a set of general purpose commands and user can write scripts of their own. It could handle multitasking, piping, background execution etc.
Interrupt is a mechanism to stop execution of a process or termination. It could be invoked by hardware exceptions, software exceptions or user.
4. Evaluation
This paper does not provide evaluation section. However, my idea is that the paper addresses the new ideas in their design rather than implementation and performance compared to other operating systems.
5. Confusion
I was wondering whether pipe is viewed as files in UNIX. The term file defined in this paper focuses on its behavioral characteristics rather than essential implementations. In this notion, devices can be abstracted as “files” provided they behave the same as files. For pipes, I suppose it is also a file because the read/write behavior is just the same as a file. However, the paper indicates that “Neither process need to know that, a pipe, rather than an ordinary file, is involved.” Does it imply that pipe is a file, but a special file?

1. Summary:
This paper discusses the major features of the Unix Operating System like File system, Processes and images, user command interface i.e, Shell, and briefly explains their implementation details. The paper presents a high-level overview of the design abstractions chosen which made UNIX highly successful. Due to it's simple design and interface, it is extremely convenient for a program or a user to interact with it.

2. Problem:
The motivation behind writing Unix was to develop an inexpensive, interactive, powerful OS which is economical in terms of equipment, effort and can be self-supported. Perhaps secondary motivation were to have lesser size constraints in terms of software.

3. Contributions:
- Unix made the system interactive by providing shell. The users can just type in the command in the simplest form, execute it and see the result.
- The design treats normal files, directories and special files, all in the same manner which leads to a cleaner abstraction.
- I-number and I-list makes the design simpler. I-number makes file access and protection easier. I-list enables easier free space management.
- The command-line interpreter: shell program, comprising various useful operators that allows for easy inter-process communication, I/O destination specification, output redirection to another program’s input and multitasking.
- Mounting of different file hierarchies under a single root directory to give a single unified view to the end user.

4. Evaluation:
The author did not provide any evaluation of the system such as the time to access files etc, to show the effectiveness and performance statistics of the various mechanisms implemented. Nor does the paper goes on to compare Unix with the existing operating systems statistically. It still provides us with statistics that show that the system was able to handle a reasonable number of simultaneous users, run concurrent programs and also provide environment for different user applications.

5. Confusions:
The interlock mechanism used to maintain logical consistency when multiple users access the same file is a bit unclear to me. Even though the overall use and goal of mount is obvious, but the implementation of how the system keeps track of external file systems is a bit confusing to me.

Summary: This paper introduces the design and implementation of the UNIX operating system. It focuses on the file system, multiprocessing, the shell, and traps.

Problem: Existing operating systems have the following inconveniences:
1. Each file system must fully resides on one physical storage device;
2. Complicated and separate IO interfaces for devices and files;
3. Can run only one program a time;
4. Poor portability.

Contribution:
1. The structure of the UNIX file system is like a tree. UNIX allows each volume to be mounted or unmounted to the file system during execution. Mounting a file system causes a leaf of the tree to be replaces be a new subtree representing the file system to be mounted.

2. UNIX provides unified interface to read/write both on files and on devices. Every IO device is shown as a special file on UNIX under the directory /dev. Reading or writing that file essentially applies to the read/write to that corresponding device. This greatly simplified the IO interfaces that needs to be provided by the OS.

3. Process can create child process by invoking the fork primitive. fork will split the calling process into two identical copies, where one is the child of the other. Processes sharing a common ancestor can communicate with each other with pipes. After calling fork, the child process can choose to replacing itself with another program by calling execute. Calling execute will cause the entire address space to be replaced, but opened files will be remained so that pipes can still be used to communicate with parent processes.

4. UNIX also provides a shell program which serves as the platform for the user to access various resources and programs on the machine. The shell program is capable of redirecting input and output from one program to file or to another program, so as to keep the responsibilities of every single program dedicated and simple.

5. The UNIX OS is a general-purpose OS designed to operate on a variety of hardware, making it very portable.

Evaluation
The authors did not explicitly evaluate UNIX. However, considering the popularity of the UNIX then and now, the design and philosophies of UNIX is being generally accepted.

Confusion
The title of this paper calls UNIX the "time-sharing" system. How is "time-sharing" reflected in the OS?

1. Summary

The paper discusses the structure and features of Unix as initially implemented on the PDP-11. In particular it details the features of the file system and processes and shell, and how simple and consistent interfaces helped create a simple and powerful operating system.

2. Problem

The paper itself says that Unix was not designed to meet any particular objective. Nonetheless, this paper does present Unix, as an attempt at a general purpose operating system, aimed at being both powerful and simple. It was designed to run on relatively cheap hardware, and have a relatively small and simple code base, in contrast to many other systems of the time.

3. Contributions

The major contributions of the paper are in relation to the file system and command shell.

Within the file system, there were really only three objects the kernel was aware of. There were regular files, which simply contained unstructured data, the interpretation of which was entirely up to the user programs. There were directories, which allowed for a hierarchical structure to the file names. And then devices, which for most purposes acted like regular files.

By placing devices on the filesystem hierarchy, they avoid the complexity of having a separate interface for devices, instead the devices can be accessed using the same calls as file are accessed by. In addition device names are simply file names, and thus many of the same routines that work on files could also be used on devices, without any particular consideration for devices.

Another important piece of the implementation of the file system is the mount call, which itself simply took a path name for a device, and a path name to mount the file system at. This feature allowed the a priori monolithic file system to be composed of multiple physical drives, mostly transparent to the user of the filesystem. The users of the file system after all would only ever work with file names, never worrying about which device the file with that name might be on, with only the minor annoyance that links from one drive to another were not allowed.

The command shell itself is not part of the kernel, so in some sense is not integral to the operating system. And in fact we are given examples, in section 6.7, where one might instead replace the standard shell with ed, or perhaps a game. But shell was an important contribution, because it provided a powerful interface to the operating system, and its design continued to reflect an emphasis on simplicity. In particular, the features of the shell encouraged small programs, each with one task, which then could be chained together via standard input and output, to achieve complex results.

4. Evaluation

There was relatively little in the way of formal evaluation of the implementation. Rather the paper tended to focus on more subjective measurements. Which is perhaps not particularly surprising, because the main feature touted by the paper, simplicity, is relatively subjective. There are some metrics which the paper mentions, for example they mention that a minimal functional version of the operating system could fit within 96K, And they mention some statistics on the usage of their own installation of Unix. However, these metrics are both imprecise, and in the absence of data about other operating systems, not particularly comparable. In particular, they do mention several systems from which they draw influence, and it would have been useful to see a more direct comparison of these with Unix, especially if these comparisons could show in what ways the design decisions have lead to a simpler or more powerful system.

5. Confusions

The paper does not make clear what the MOO accounting problem is nor how it solves it, although a quick Google search was able to direct me to an answer, and nor was it a particularly critical part of the paper

1. Summary
Ritchie and Thompson explain the core features present in UNIX systems through this paper. The features the authors have described in this paper such as File system management and implementation, creating, executing and synchronizing processes, the Shell program and its features form the base for modern day UNIX systems. Authors have explained these fundamental features of UNIX systems in good clarity also providing their implementation and usage details.

2. Problem

The main motivation for the authors for coming up with a new version of UNIX operating system was to make it easier to understand (by converting assembly code to High level language C), write, test and run programs and make the system interactive instead of having a batch system. Other important goals were to have a small and economic system give the size constraints and to have a system that can maintain itself.

3. Contributions

The contributions by the authors in this paper are beyond measure. Their work in this paper reflects on modern day UNIX systems without almost no modifications. Some of the key features are,

a. Redesigned File system - The new file system provided lots of features related to file management such as removable file systems(mount feature), protection, I/O calls to create, open, read, write and seek files. The authors also explain the implementation of the file system by having a i-node which contains all details for a file.

b. Process - The paper explains how a process is created using fork, communicates using pipes, executes a program using the exec command and synchronizes using wait commands.

c. Shell - The most basic features of a Shell are explained such as standard commands, redirection, filters, command separators and executing multiple commands in shell present in a file. It also describes the Init process and how to works for different users.

d. Traps - Traps occur when their is an interrupt and a small system routine has to be executed. illegal instructions or wrong address access can cause the system to TRAP, terminate the process and write the output to a core file for debugging.

4. Evaluation
The authors did not provide comparison or evaluate the system with other operating systems at that time. They provide statistics on the number of people using it, number of commands, cpu hours run and other system information such as number of file and directories.

5. Confusion
Im unclear about how set-user-id feature works and what scenario it is useful. Author mentions the file system maintains no locks and has sufficient internal interlocks to maintain logical consistency. How does this work?

1. Summary
Ritchie and Thompson explain the core features present in UNIX systems through this paper. The features the authors have described in this paper such as File system management and implementation, creating, executing and synchronizing processes, the Shell program and its features form the base for modern day UNIX systems. Authors have explained these fundamental features of UNIX systems in good clarity also providing their implementation and usage details.

2. Problem

The main motivation for the authors for coming up with a new version of UNIX operating system was to make it easier to understand (by converting assembly code to High level language C), write, test and run programs and make the system interactive instead of having a batch system. Other important goals were to have a small and economic system give the size constraints and to have a system that can maintain itself.

3. Contributions

The contributions by the authors in this paper are beyond measure. Their work in this paper reflects on modern day UNIX systems without almost no modifications. Some of the key features are,

a. Redesigned File system - The new file system provided lots of features related to file management such as removable file systems(mount feature), protection, I/O calls to create, open, read, write and seek files. The authors also explain the implementation of the file system by having a i-node which contains all details for a file.

b. Process - The paper explains how a process is created using fork, communicates using pipes, executes a program using the exec command and synchronizes using wait commands.

c. Shell - The most basic features of a Shell are explained such as standard commands, redirection, filters, command separators and executing multiple commands in shell present in a file. It also describes the Init process and how to works for different users.

d. Traps - Traps occur when their is an interrupt and a small system routine has to be executed. illegal instructions or wrong address access can cause the system to TRAP, terminate the process and write the output to a core file for debugging.

4. Evaluation
The authors did not provide comparison or evaluate the system with other operating systems at that time. They provide statistics on the number of people using it, number of commands, cpu hours run and other system information such as number of file and directories.

5. Confusion
Im unclear about how set-user-id feature works and what scenario it is useful. Author mentions the file system maintains no locks and has sufficient internal interlocks to maintain logical consistency. How does this work?

1. Summary
The paper talks about a high-level overview of the hardware and software environment of the early UNIX systems. It also introduces us to the cost of building those systems and the various types of programs that the system can run. But the main focus is on describing the features of the file system, the shell and their implementation and also the justification behind the design choices that were made.

2. Problem:
At the time this system was proposed, there were various flavors of operating systems but all of them were developed for some specific purpose. Each one of them had a few good features but overall none was simple or easy to use to the user. Unix solved this problem because it took the good ideas from the existing systems but did not commit to a specific purpose. Hence, a general-purpose, interactive operating system was developed that was simple, small and easy to use, but also with features far greater than all the existing systems.

3. Contributions

The Unix system at its fourth version provides many more features when compared to the then existing systems. Apart from providing an easily modifiable code base in C, it supports multiprogramming (and hence, multi-user and interactivity). The design of the hierarchical file-system provides an user friendly and uniform way of interacting with both files on any disk (through the concept of removable file systems) and other devices (through the concept of special files). The file system provides the concept of file with short, unambiguous names and in the implementation they are considered as an object encapsulating its related protection, addressing, etc. A highly reduced set of I/O calls were developed and it provides an uniform way of interacting with any file or device, regardless of random or sequential I/O. To offer multiprogramming, a set of systems call is provided for the task of creation, deletion, IPC, synchronization and loading of new processes. For interactivity, a command line interpreter , i.e. a shell is developed. It made it very easy for the user to interact with the machine by typing commands at the terminal. Each command entered by the user executes by forking a new process and it provides functionalities for I/O redirection, filters and asynchronous execution. This version also included the functionality to act on a hardware or software interrupt.

4. Evaluation

The authors have just provided statistics to show the scale at which Unix was used for research purpose. There was no information about its performance or any comparison to other existing systems.

5. Confusion

I have a confusion in understanding the implementation of mount system call. Specifically, what does "device name of ordinary file" mean.

Summary: This paper describes how the designers of the Unix operating system were able to create a simple, general purpose, interactive OS by treating everything like a file. The authors explain the concept behind the Unix file system, it's implementation and present a brief description of the processes by which these files can be manipulated to execute general purpose tasks by interacting with the shell.

Problem: The problem, as the authors state it, was simply that one of them was dissatisfied with their existing computing infrastructure and set out to make a programmer friendly OS. Their aim was to simplify the interaction with hardware and create a means for further research.

Contributions: The fact that this paper can almost pass for a Linux distribution's manual even today speaks of its contributions.

In my opinion, the file system is one of the major contributions of this paper. Treating devices like they're part of the file system simplified the task of communicating with peripheral hardware. This allows all peripheral interactions to be governed with the same protection and I/O mechanisms as the rest of the file system. In addition, the use of file descriptors allows the intuitive redirection of I/O by switching from standard input and output to peripherals.

By limiting the kernel to 90KB, the designers were able to create a portable OS with a minimum requirement of 96KB. This portable nature allows for limited working versions of Unix with an even smaller footprint as well as larger, more complex installations.

There are a few more contributions which include a buffering mechanism for disk I/O and a mountable file system which can be made part of the file hierarchy. In addition, the designers of Unix incorporated their favorite features from existing systems, creating something they would like to use.

Evaluation: An interesting facet of this paper is that the designers of Unix didn't really set out to achieve any particular objectives, as they point out in section 8. In fact, the three considerations that they point out are also retrospective and barring the second (working with resource constraints) are subjective. The authors do provide usage statistics in an effort to give the reader an idea of the scale of Unix adoption. However, these statistics aren't helpful without a historical context of the adoption of other systems.

Confusion: The authors set out to create a multi-user system but don't really seem to assign any real importance to the issues created with multiple users accessing the same file. They don't really explain their "internal interlocks" either.

It would have been interesting if the authors explained why Multics dropped the idea of a process for each shell command and why Unix persisted with it.

1) Summary
This paper discusses the design and implementation of some of the key features of the UNIX operating system such as the file system, process, shell (user command interface), signals, etc. The paper describes how the authors were able to design a simple and elegant system meant for interactive use by fully exploiting a set of clear ideas and showing that they can be keys to the implementation of a small yet powerful operating system.

2) Problem
The idea was to build a system that is more convenient to use and less expensive in terms of the hardware and effort to maintain compared to the other systems that existed at that time. Even though there were no predefined objectives while designing the system, on retrospect the following considerations seemed to have influenced its design: make it convenient for programmers to develop, test and run their programs; reduce the consumption of system resources by the OS; and design a self-maintaining system.

3) Contributions
The authors describe key features of the file system like file abstraction, mountable file systems, file protection and I/O system calls. The interface to the file system is extremely convenient for a programmer. The lowest possible interface is designed to abstract the distinction between files, directories and devices and between direct and sequential access. User programs call systems calls or libraries to access file using human-readable paths and the system internally uses an efficient mechanism to lookup the file in the tree-hierarchy by using internal data structures like i-list, i-number and i-node. The I/O is buffered by the system to ensure optimal read-write performance. The file system provides a robust protection mechanism by making use of a few protection bits stored in the i-node corresponding to each file. These features of the file-system has gone a long way in reducing the effort required by programmers to handle miscellaneous things like access methods, security, performance, etc.
The shell provides a convenient way for the users to interact with the system. The users can write programs that they can spawn from the shell. The shell provides mechanisms to manage the program's input, output and communication with other processes. This promotes the convenience of programming using the shell.
The fact that Unix was designed to be a self-maintaining systems with a community contributing to the development and maintenance of the system has probably been the cornerstone for the open-source softwares that are popular today.

4) Evaluation
There is no comparison of the Unix operating system made to the other operating systems in this paper. The purpose of this paper seems to be designing a few salient features of the OS to make it more convenient to use for programmers and other applications like research and documenting. And hence, there is no statistics provided comparing its performance with other systems that existed at that time. The paper however provides some statistics regarding the scale and reach of the OS. And again, there is no comparison made to any other OS in this regard. The authors somewhat infer that the success of the Unix lies not much in its new inventions but rather in the design of a clear set of ideas in its sub-systems to build a simple yet powerful operating system.

5) Confusions
Does the internal interlocks to maintain the logical consistency of the file system refer to the sequencing of I/O operations at the lower most layer?
What is an example of the absence of "control blocks" maintained by the file system that promotes programming convenience?
Multics dropped off the design of creating a new process for each command invoked by the shell for efficiency reasons. Is the same efficiency reason not a concern in the Unix system?

1. Summary

This paper presents essential design principles and implementation techniques of several important functionalities in the UnixOS such as file system, processes and images, shell program, and etc. Through examining these system design and implementation issues, authors show that the success of UnixOS lies in its simple and maintainable design that draws upon the exploitation of numerous ideas from existing OS designs.

2. Problem

The problem concerns the design and implementation of a general purpose, multiple-user, and interactive operating system that builds on top of many existing fertile ideas of operating system. While initially the authors have no predefined objectives for the UnixOS, they eventually consider the system design problem from the exploitation of principles such as simplicity, maintainability, and elegance.

3. Contributions

Contributions of this paper focuses on author's opinion that simplicity, easy of use and elegance are essential in building small yet powerful operating system for interactive use that is also not costly. The main contribution includes hierarchical file system that treat everything as ordinary files, directories or special files. Special files are treated in the same fashion as ordinary files in the sense that programs that expect file names can also expect device names. Each file has protection bits set to denote who has privilege access to it. File system calls are also designed to be simple to use and there are calls such as mount that make it easy to manipulate the hierarchy. Finally, the idea of i-number and i-list are convenient for implementing directory structure of the file system and accessing important information related to a file in an unambiguous and simple fashion.

Other features of the system including processes, shell program, and traps and interrupts follow similar design principle that strives to provide simple and easy of use interface to application programmer.

4. Evaluation

The authors do not conduct any rigorous and systematic evaluations for the UnixOS, despite the discussion of the statistics of system's scale at the end of the paper. It would be more convincing if authors can provide comparison between existing operating systems and UnixOS and how UnixOS outperforms current system under various workloads.

5. Confusions

When authors are discussing considerations that influence the design of Unix, they mention size constraints on the system and software without giving specific examples that explain what is size constraints and how it influence the 'elegance of design' as claimed by authors. In addition, I am also confused by the introduction of term 'control blocks'. What does it means?

It would be better if authors can also discuss if and how virtual memory techniques such as paging is used in the system.

SUMMARY

The paper describes the key features of the then state-of-the-art UNIX operating system and their usage and implementation, while also expanding on the key benefits the operating system provides to its users. In particular, features such as the hierarchical file system,
the I/O interface and the command line are discussed in greater detail.

PROBLEMS

There does not seem to be any single pressing problem that motivated the development of the UNIX OS. Instead, the primary initial goal is vaguely described as wanting to create a "more hospitable environment". From the following discussion, it appears that the aim was to create a platform which would be more conducive for all stages of programming - writing, testing and running programs. Accordingly, all the key features of UNIX are oriented towards elevating the programming burden. A secondary goal appears to be the development of a size efficient system without forsaking the capabilities of the system.

CONTRIBUTIONS

A main contribution is that of a hierarchical file system. A file provides an intuitive abstraction and an easy way to access and write information on the disk (through the file name). The directories can be used to group files conveniently treated together and so "induce a structure on the file system as a whole". Crucially, the directories are structured to have the form of a rooted tree, with a root directory (/) which contains everything else. The reason for this rooted tree structure is explained as to "simplify the writing of programs that visit subtrees of the directory structure" and "to avoid the separation of portions of the hierarchy". This also simplifies the mount feature as a leaf of a tree can be readily replaced by a whole new subtree from a removable disk.

Another key contribution is the abstractions provided for I/O which provide a simple and unified interface for random and sequential access. This again aids in programming convenience as the programmer is able to treat all reads and write operations as being done on a file, without being concerned about the underlying device / disk and the I/O differences between them.

Finally is the notion of the shell which is a command-line interpreter. A key use of the shell is to act as a process which helps spawn other new processes (through the fork mechanism). Besides this, the shell also provides many other capabilities to the programmer such as I/O redirection, filters and multitasking.

EVALUATION

There is not much evaluation of the success of UNIX from the author themselves in the paper. They mention that the OS is able to run on inexpensive hardware giving a ballpark figure of $40000 (yes, apparently that was cheap) but do not indicate the hardware requirements for other comparable operating systems. Likewise, at the end, the give a number of statistics that aim to show the capabilities of the system. However, these statistics are not impressive by modern standards and so a reader now has no way to understand how the UNIX compared to other
operating systems at that time.

CONFUSIONS

The question of who is charged for the space a file occupies remains unanswered. The authors note that it is unfair to charge only the owner of the file and the most fair solution would be disperse the charges across all the users. However, they do not explicitly mention how the problem is handled in UNIX.

It is also perplexing that there is no locks utilised in the file system. This seems to be because in the case of the UNIX system back then, there were not many situations whereby users would read/write to the same file at the same time. However, the authors go on to mention that
such locks even if present, would also be insufficient which I do not see why. They also mention internal interlocks which are not elaborated on much.

Summary – This paper presents an overview of the UNIX operating system at the time. Authors highlight significantly important features of the OS and also mention the basis of their design decision. A fair amount of implementation details of the shell and usage of system calls to perform file operations has also been included in this paper.

Problem – Building a simple, easy to use and maintainable Operating system were the key motivation towards development of UNIX. In addition, the challenge was in designing a system that allowed multiprogramming and provided excellent user interface.

Contributions – The biggest contribution of this paper is straightforward – UNIX! Some salient features from this paper which make unix simple and noteworthy are:

1. Unix – a time sharing system, allows several users to run processes asynchronously on the system.


2. The file system is hierarchal i.e. it’s built in the form of a rooted tree. This may seem trivial but it makes visiting subtrees very easy (using ‘.’ and ‘..’ entries)


3. The idea of i-node is very novel to Unix. Every file can be identified uniquely by its i-number. The entire metadata (last accessed time, owner, size etc.) of the file is then accessible from the i-node. The existence of i-list permits a simple and quick algorithm for checking consistency of the file system.


4. By treating devices as (special) files, very similar I/O operations and protection mechanisms can be used for both ordinary files as well as devices.


5. Users can perform file operations using various system calls outlined in this paper. Processes also need to communicate and this flexibility is provided using shell. Because an OS without a good interface is not an OS!

Evaluation – The paper mentions various concepts that got introduced in Unix operating systems, their implementation and at places authors justified their approach. This research work was not meant to focus on Unix’s ability to perform better or worse over other OSs or even its previous versions. This overview simply explains the most important pieces of the Unix OS and hence an ‘evaluation’ is not necessary in this context.

Confusion – How does the set-user id bit actually work? If this bit is not set, does it mean that no other user but the creator can execute a program?

Summary
The paper titled, The UNIX Time Sharing System" written by some of the rarest computer jewels of their time, Thompson and Ritchie, describes the new UNIX system briefly mainly concentrating on the file system and the shell part of it. In the arena of file systems, topics like kinds of files, representation of files, protection and system calls are described. About shells, it talks about how the fork/exec mechanism along with the standard descriptors can be exploited to execute parallel programs and filters.

Problem
The first version of UNIX grew out of the dissatisfaction of the of one of the authors (Thompson) with the existing computing facilities. The aim was to develop a system that was friendly to programmers. It should be easy to write, test and execute code and should support multiple users and program as opposed to batch systems. The aim was always to provide small but powerful abstractions to the system.

Contributions
There are several contributions to the computer science community through the invention of the UNIX operating system as outlined in this paper. The are as follows.

a - Portability - Since this version of UNIX as written in C, it was widely portable across various hardware platforms. This did reduce the speed of execution over an image written in purer assembly, but the man-hours required to port and maintain a pure assembly level implemented OS was vastly reduced.
b - File systems - Including a single file structure tree rooted at / was on of the most instrumental design decisions of UNIX, The ability to mount a device anywhere in the tree without having t create a new tree for every new hardware device is very effective. The idea of treating everything (almost everything as a file) resulted in simplicity of user programs while dealing with there various kinds of files, Also the idea of association a file with an i-node allowed the same physical file to be present in many different directories and that prevents duplication of space.
c - Protection - Since they know they were designing a multi-user time-sharing system, the authors paid much attention to protection. This provided isolation of a user from another user in terms of who can access/modify files and running programs.
d - Small but powerful system calls - The UNIX interface gives a small set of powerful complete system calls. These calls are very easy. Some examples include open, read, write and lseek.
e - Shell and processes - The UNIX OS includes a simple shell used to launch processes. Processes use fork to fork a copy of themselves and the child later executes exec to replace the process image, The shell exploits this along with file descriptions and pipes, to implement constructs like filters.

Evaluation
The paper does not include measured/benchmarked statistics of the performance of the UNIX system like file system IO speeds, etc. It does but include statistics about adaptation of the system by people. It mentions how many people started using UNIX, amount of space being used and the number of commands being executed amongst other things.

Confusions
a - The setuid feature is a bit confusing. If the file system is not implemented properly a malicious user can set that bit (without being root) and assume privileges not deserved by him
b - The authors assume that locks are not required for file access. But there are internal mechanisms to handle such cases. What are those mechanisms?
c - The mention of control blocks is confusing as I could not understand the concept of the control block. Did they mean the entries of a process table?

1. summary
This paper “The UNIX Time-Sharing System” presents a very high level overview of the Unix operating system. Authors provide the structure of underlying File system, Process abstraction and the life cycle of Unix OS. They also provide a brief implementation details on the file system and shell. In the process of explaining the above mentioned structures, authors also explain the reason behind choosing them.
2. Problem
The motivation upon which led to the development of this version of UNIX OS are as follows
- Create a simple general purpose OS
- Allow Multiple users to operate
- Build a Interactive interface for the users
- Should run on inexpensive hardware and small in size.
3. Contributions
This paper has a significant amount of contributions,
- Implemented in C
Makes code 3x larger but it became easier to read and modify also with many improvements.
- Same abstraction for files, directories and I/O devices

This makes the file system very simple. The program for interfacing with these devices and protection schemes are the same, which makes OS lighter.
- Hierarchal File system 
makes it easier to mount and unmount independent file systems.
- Protection schemes for privacy control
Protection bits for privacy control in a multiuser environment. Setuid bit allows programs to be executed in the privacy environment of the user who is executing it.
- A good locking scheme to keep the files consistent during concurrent access.
- Interprocess Communication via pipes and redirection.
- Shell
, a command line interpreter, which enables the user to communicate with the system to execute other process(with | > () & abilities).

4. Evaluation
There is very minimal evaluation done in the performance aspect of this proposed operating system. Because of the absence of evaluation it lacks the ability to back up the design decisions that were made. Some statics on the usage and adoption of their OS is presented.
5. Confusion
- What is the programming convenience got from not having a control block ?
- Relation between “ Time sharing “ and the proposed System ?
- How does internal locks work when a file is concurrently accessed ?

The Unix Time-Sharing System

Summary:
The paper “The UNIX Time-Sharing System” by Ritchie and Thomson, which follows their previous paper focussing on multiprogramming, summarizes the revisions made on the process execution, interactive shell by briefly explaining their working. The major contribution of this paper though was the implementation details of a simple and elegant file system.

Problem:
The main focus of the developers was to implement a simple file system keeping in mind the programming convenience and the size constraints on the system and the software. They also ended up making certain revisions to the already existing system.

Solution:
1. The file system consisted of three kinds of files - ordinary files, directories and special files.
2. Directories were created to create a hierarchical file system structure.
3. Each I/O device supported by the system was considered a special file.
4. The concept of i-number was bought in to uniquely identify the files.
5. File systems were made mountable on another file system allowing it to maintain the hierarchical structure across file systems.
6. Protection bits were added to the files allowing owners to restrict certain actions by other users.
7. A simple interface to open, read, write and seek files was created.
8. The i-nodes represented by the inumber of the file contains the description of the files like details about owner, protection bits, modified time etc.
9. The paper also describes the process image and how a process is executed.
10. The implementation of shell, an interactive program, is discussed in detail. The shell executes each command in a separate process.
11. The shell interprets the commands entered by the user and executes it.
12. The shell also takes care of redirection to and from output and input files.
13. The shell allows concurrent execution of several commands by using ‘&’.
14. The paper also explains how the init process authenticates user during the first boot of the system and how the init process ends up spawning the shell process. Init process is considered the parent of all processes.

Evaluation:
The paper provides no metric or comparisons to talk about the performance of the file system. They have provided though the statistics of the usage of the system which they are probably using to say that the system was efficient as they didn't face issues with so many users. Though the main objective was to develop a simple and file system interface which I think they have achieved here.

Confusions:
1. The paper speaks about certain internal locking mechanisms which prevents multiple users from creating a file with same name in the same directory or prevent a user from deleting a file which another is reading. How does Unix achieve this?
2. Certain processes communicate with each other through pipes. From the perspective of a process, pipes are nothing but another file. They have the file descriptor to which they read or write. But a file descriptor structure in a file table, consists of details like inode number and offset for a file. What does it contain for pipe? Is it some memory location in the kernel address space which multiple processes can access?
3. The init process authorizes the user by looking at a password file which also contains details about which is the first program that is to be executed for a given user. Where is this password file stored?
4. Towards the end, the paper says the idea of the Shell spawning new process for each command was not implemented in previous version due to efficiency reasons. What exactly was the problem?

Summary:

This paper, “The Unix Time-Sharing System” provides implementation details of the file system used in UNIX. It includes the implementation details of protection mechanism, handling IO devices and IO calls. Also it discusses the command line interface called shell, its implementation details and its features.

The authors’ state, the system was not designed to meet any predefined objectives but on the course of implementation they were able to address many problems. The design was influenced by the need for an operating system which provided a convenient environment for programming with a stringent constraint on the size and cost. The need to easily revise or rewrite a system also influenced the design.

This paper describes a simple but effective file hierarchy in the form of files and directories. The file system provided a layer of abstraction to interact with different IO devices in the form of special files which eased the onus on programs to handle the IO devices by themselves. A solution to incorporate a new file system as part of the existing file hierarchy is implemented in the form of mount feature. The structure of the i-node and idea of indirect blocks provided an elegant solution for handling large files. The shell provided an interface through which the users can effectively interact with the system through predefined commands. The redirection of I/O is easily implemented using the notion of file descriptors. The use of ‘&’ to execute commands/programs on the background saves time for users. The use of pipes helps to establish an easy flow of I/O through a series of programs. Debugging becomes easy when an image file is forced to be produced by quit signal.

The authors only provide statistics on the usage of the system. The performance was not recorded against any metric and there were no direct comparisons made with other systems that existed. I believe this was because the authors’ intention was about describing the idea of the new file system and command line interface.

There is a little ambiguity about the inode-device pair that is searched in the system table. Is each inode-device pair searched or only when an inode of a special file is encountered?

1. Summary -

Ritchie and Thompson provide an overview of the nascent UNIX operating system and its implementation specifics. Introducing the hardware and software infrastructure that was in place at that point of time, they dive right into, explaining the file system implementation, which evolved with this version 4 of the OS. They also dwell into the user interface developed, in considerable detail and conclude with a perspective on the whole effort.

2. Problem

What began as a single user's disappointment with the prevalent computer facilities, developed into an interactive design for systems, that piqued the interest of several people, aiding development of that initial version. So, to develop a better user experience with computer systems and explore different arenas of software development is the overall idea of the paper.

3. Contributions

This is one of the pioneering papers of the computing industry that forms the backbone of subsequent software based programming. To say, every major system today has evolved from one of the fundamental versions of the UNIX operating system, might not be exaggerating. To list, in no particular order,

i) Concept of creating a better user experience with computing systems ( But for this idea, computers could still be massive computational machines that universities and corporations used, unknown to the average Joe)
ii) Implementation of hierarchical file systems and the ease of adding volumes to the existing layout
iii) A straight forward interface to the said file system, which eases programming to a great extent. On the same note, the protection schemes, which now seem intuitive, have eased many permission issues we might have otherwise had.
iv) The idea that every device could be treated as a file and device I/O could just be the same as file I/O with the exception that the file is now, a special file
v) Demonstration of a working implementation of these very inspired concepts.

4. Evaluation

If we are evaluating the paper on the basis of solving said problems, it goes far beyond what it hoped to solve. This OS serving as a key stone piece for all future developmental works marks its importance. However, if we are looking to evaluate based on certain performance metrics, we do not have anything to go by except for user statistics provided therein, which might or might not be an indicator of the paper's evaluation

5. Confusions

Why has linking between file system hierarchies been discounted as too cumbersome? Doesn't one find themselves often in a place where soft and hard links need to be created between different servers / file systems ? How has this consideration changed in the present era?

Summary:

In broad terms, the paper discusses the various features present in the fourth version of UNIX operating. Specifically, it discusses in considerable detail the implementation of the file system, process management and the user command interface. The paper also discusses some considerations that influenced the design of UNIX.

Problem:

The authors admit that UNIX was not designed to meet any predefined objectives. It started out as a pet project by one of the authors, who was dissatisfied with the available computer facilities and set out to create a hospitable software environment. This later turned into a more systematic approach to build a simple yet powerful interface to the hardware. The other considerations that influenced the design of UNIX were ease of writing and testing programs, size constraints on system and its software and ease of maintenance

Contributions:
Ease of implementation: Most of the operating systems at that time were written in assembly language. UNIX was written in C which made it simple to implement and maintain

File System: One of the major contributions of this paper is file as a layer of abstraction. In UNIX, ordinary disk files, directories and devices are all treated as files. This facilitates the file and device I/O to be treated as similar as possible and also facilitates the same protection mechanism to be implemented to both disk files and I/O. UNIX also introduced the concept of i node for a file and i-list, which helped in efficient organization of the file system and management of the file system.

Easy I/O calls: The use of file descriptors coupled with simple system calls like open, create, read, write, lseek enables a simple yet powerful way to support I/O calls

Process management: UNIX provides process as one of the fundamental abstractions to the user. Some powerful system calls like execute and wait were provided to facilitate interprocess communication and synchronization.

User command interface: Shell, the command line interpreter in UNIX provides a means to communicate with the system. Shell included some novel features such as filters and & operator, that made possible background processing.

Evaluation:

Though the paper does provide some statistics to suggest the scale of the system, there have been no evaluations carried out to compare their design choices against those of the previous versions of UNIX or of the other operating systems of that time.

Confusions:

The one thing in the paper that confused me the most was the statement that locks were neither necessary nor sufficient to prevent interference between users of the same file. I don’t understand why this is the case.

.

1. Summary
The paper describes some of the design principles of Unix Operating System, mostly concerning with the user or programmer interface. It discusses the file system implementation and the user command interface in detail, with an emphasis on the underlying simplicity and usability of the design.
2. Problem
The paper addresses problems about the design of user interfaces and abstractions, such that they are flexible, programmable and easy to use. The prior systems were designed in assembly and did not focus on these issues. But with more applications, larger memory systems and multi user interfaces, it became necessary to define interfaces to ensure efficiency, usability, flexibility, security and portability.
3. Contributions
There are several interesting and key ideas in the paper. It defines abstractions like a process, image, file, pipe, filters. By building a file system interface based on the file abstraction, it not only makes the file management easier and efficient to handle, but also makes the I/O device management, security and performance seem easier and seamless. The user just deals with the intuitive filename interface, which are, through several layers of abstraction, mapped to disk blocks.
The command line interface is implemented through a combination of fork, execute and wait. This combination of system calls provides flexibility in implementation. The Shell interface provides a user interface to execute commands, scripts, batch programs, background processes through a combination of abstractions like filters, pipes and processes. I like the idea of introducing simple interfaces to enables complex behaviors.
4. Evaluation
Since this was paper was focused on the design principles, the authors did not provide any evaluation in this paper.
5. Confusion
Why is setuid feature required? This can be accomplished with the use of the existing group access controls right? They seem to like create additional security problems.

1. Summary
This paper is an introduction to the (at the time) newly-minted Unix operating system. It covers the hardware it runs on, the filesystem that was developed for it, and the user environment it runs. Security, multitasking, and IO are the major focuses of the paper as it describes both the filesystem and the shell environment that was developed for Unix.
2. Problem
The authors of this paper looked to demonstrate that a powerful operating system does not need gargantuan requirements either in the hardware it runs on or the manpower needed to develop and maintain it. Additionally, the paper looked to present a 1000-foot overview of the Unix system for others who might have been interested in its applications.
3. Contributions
The author provides a good overview of the hierarchical filesystem developed for Linux and the privilege model that provides security for it. Two features that seem to be unique for the time are the use of special files to represent devices and the use of i-node and linked directory entries for files. The wording of the paper makes both seem rather novel for the time and it would have been if some context had been included, for example describing how other systems handled device IO that made treating them as files an improvement. From the "Perspective" section at the end of the paper it sounds like this was to avoid programmers having to include device-specific code in their applications, but I would be curious to know what other possible solution were considered or used in other operating systems.
4. Evaluation
The author provides examples of the flexibility of the Unix system in terms of the memory requirements for running it. Although the author provides hard numbers, some of the context is lost for today's readers, who might not know what a large memory requirement would have looked like in 1971. The author also states that Unix is self-supporting, which is a good indication that it's filesystem, IO performance, and included tools are up to the task of managing large development endeavors. Not mentioned specifically are how other operating systems of the day were in this regard, did being self-supporting make Unix stand out or was it more of a requirement for any serious OS?
5. Confusion
One thing that maybe wasn't confusing but certainly made me stop and think was the idea that the system idle process was not simply executing the "HLT" instruction or something similar but was instead keeping the CPU running at full tilt doing extraneous work on semi-infinite math problems. I realized I didn't know if CPUs at the time had a concept of temporary halting or sleep states, or did they just expect to be kept processing at all times? If so, was there such a thing as reduced power states when a processor was idle, or did power consumption and heat generation stay constant? It seems likely they did have these things to some extent but the authors of this paper simply felt that idle time could be used in more interesting ways.

1. Summary:

The authors present Unix, a general-purpose and interactive operating system written primarily in C. Unix can be used for programming, document preparation and formatting, processing of data or research. The paper presents the file-system design, implementation of the file-system using certain mechanisms and policies and describes I/O capabilities via a shell. The aim of this paper is to primarily present the idea of the operating system and to describe its key implementation features.

2. Problem:

The authors mention that Unix was not designed with a set of objectives in mind to begin with. However, it was more concerned with providing programming convenience and an interactive interface to the user in comparison to a "batch" system.

3. Contributions:

-The authors convince the reader that it is possible to achieve a powerful interactive self-maintained operating system which is capable of running on low cost hardware and which does not need a lot of compute resources.
-The most important contribution of the paper would be the structure of the file-system design and its implementation. With the help of three main file types: special files, directories and disk files, the entire idea of the file system can be conceived.
-Open, read and write are some basic systems calls described in the paper, with emphasis on how users can take advantage of these I/O capabilities of the system.
-The operating system provides security with the use of protection bits in the file system as described in section 3.5.
-Another highlight of the paper would be the shell and its implementation, which helps in providing an interactive interface to the user. The shell is a command-line interpreter, which interprets user input, executes it and provides the necessary output.

In summary, the major concepts of the operating systems described in the paper syncs well with the idea of files and standard input and output (read and write), making it a fairly straightforward to understand yet high in functionality.

4. Evaluation:

There is not much data to evaluate or compare the implementation with other implementations. Most of the paper is about specific techniques used in the implementation of the file system, the shell and explains the 'interactive' component of the operating system. The authors provide usage statistics at the end of the paper, and the numbers tend to show that it has been fairly successful in adoption at the time.

5. Confusions:

The authors mention that locks are neither necessary nor sufficient and then provide a plausible reason in claiming so. It would be interesting to discuss on how this statement would change in the current scenario. Also, the concept of interlocks was mentioned briefly, albeit not a very detailed explanation on that is provided.

Summary :
This paper introduces the main features of the UNIX operating system and its implementation. The UNIX system is an interactive, inexpensive, flexible operating system. It at the first time integrate the hierarchical file system, process abstraction and the shell. Some insights behind the design, such as treat files and devices as same, are still useful now.

Problem :
UNIX is not designed to meet "any predefined objective". The intuition behind the UNIX operating system is it should be user-friendly: it should be interactive instead of batch, it should be runable without consuming too much hardware resources, it should be easy to add/remove memory/devices.

Contributions :
1. A hierarchical file system with uniform abstraction for files, directories and devices. It is very simple, clean abstraction. No extra effort on different implementation on different storage/devices.

2. use the i-nodes and i-lists. It package all relevant info about files in an clean way, which makes mount, file discriptors, I/O calls, redirecting I/O streams and linking simple.

3. The introduction of shell environment. It support multiple tasking by '&' operator, system calls like pipe(), fork() helps the interaction between hardware and software and provide an easy environment for programmers to use the file system.

Evaluation :
No quantitative evaluation on the system efficiency is presented. However, the paper does provide the ongoing adoption of UNIX systems to show that they can run on inexpensive computers and supports multiple users.

Confusing :
Why the paper claims that the locks are unnecessary and insufficient. When they maintain logical consistency of the file system, they use internal interlocks, how do they achieve that?

Summary:

This paper describes new features in 4th Version of Unix time-sharing system. It details motivation behind its development, its key features and its simplicity. Author discusses implementation of file system and user command line interface in detail.

Problem:

Major problem developers of 4th version of Unix want to solve was to develop cheap, general purpose and interactive operating system. Earlier versions were written in assembly and it was difficult for new developers to understand it. Also, as paper describes file system in detail, either file system was not implemented in previous versions or it was not so flexible and simple.

Solution:

I think major contribution of Unix was it was rewritten in C. This helped many developers to understand code easily and contribute to develop a powerful operating system. Unlike other operating system at that time, Unix was cheap, easy to use and was general purpose. Many key features like file system, CLI, protection were implemented and even included in today's operating system. Unix added support to major programming languages that were used in 1970's. Notion of “everything is file” was introduced and it made managing files, directories and devices easy. A new hierarchical structure of file system was introduced and mounting different file system made it extensible.

Evaluation:

Most of the paper doesn't describe whether features were introduced for first time or borrowed from another file system. There is no comparison in terms of performance under different workloads with either its previous versions or with other major operating system at that time. Tough it describes various features and its implementation, it fails to describe why certain design decisions were made. In statistics section it shows user database at that time.

Confusion:

1. In section 3.6 I/O calls, I don't understand why locks were unnecessary.

Summary :
This paper attempts to demonstrate the different features present in the UNIX operating system viz. the file system, IO, processes, shell as well as functioning of its various components. It tries to highlight UNIX’s simplicity and design principles. It also provides a brief history of its development and functioning of few salient features like mount, system requests, protection, initialization and traps.

Problem:
The creators of UNIX wanted to develop an operating system which was powerful, interactive, simple, inexpensive and didn’t consume a lot of effort in its development. They also made sure that the OS was able to perform in low grade hardware configurations. Users should be able to understand the OS and also be able to modify it to incorporate functional improvements.

Contributions:
One of the main contribution was providing the file system with a hierarchical directory structure, ordinary files which required no predefined structures from the OS’s perspective and special files associated with IO devices. File systems could also be mounted to the already existing hierarchy. It implemented access control machinery for files with the help of protection bits.
The paper also discusses the efficient way of using the information stored in i-node to do IO operations with ordinary files as well as to communicate with various devices (special files). The same read and write system calls can also be used for inter process communication through pipes. It also talks on how the running time is reduced by asynchronously pre-reading the next blocks during sequential block access. The i-list feature of UNIX enables to organize and also check the consistency of the filesystem reliably.
UNIX also provides the functionality of creating child processes, interfaces to communicate between the processes, synchronize as well as terminate processes. The UNIX shell can run multiple processes in background - enabling multitasking and also implement filters which can process the output of one process and sent it as input to another process. This prevents the wastage of idle CPU cycles.

Evaluation:
The author provides statistical data about the acceptance and usage of UNIX as an operating system. Though these numbers are very old it was indicative of a rising popular OS. The paper does not provide any comparative study with other OS to give an idea about the advantages of UNIX over others. Though the paper with its facts showcases UNIX to be powerful, simple and interactive OS with many impressive feature. It confirms that UNIX is fully functional on a very low configuration hardware.

Confusions:
I was unable understand the concept of fees to be charged to an user for using the file storage. What is meant by “Fees” ? How does an OS charge an user for using the space for a file that it is using.
I am unable to understand the line which mentions that the shell can ignore quit to prevent logging out an user. I was unable to relate this statement to the example which states that this feature is useful to stop long printouts without losing any work in progress.
Also I was unable to find a discussion about the MOO accounting problem.

Summary:
This paper discusses the implementation of the file system and of the user command interface in the Unix operating system.

Problem:
It was not designed to meet any predefined objectives. But 3 problems influenced the Unix system. (1) Interactive system can make it easy to write, test, and run programs. (2) There have always been fairly severe size constraints on the system and its software. (3) The system should be able to maintain itself.

Contribution:
(1) File system. There are 3 kinds of files: ordinary disk files, directories and special files. In Unix, the directory entry for a file consists merely of its name and a pointer to the information actually describing the file. Each I/O device is associated at least one special file and special files are read and written just like ordinary files. There is also a mount system which can replace a leaf of the hierarchy tree by a whole new subtree (the hierarchy stored on the removable volume). Each file is marked with the user ID of the owner and has 10 protection bits, but super user is exempted from the usual constraints on file access. The system I/O calls are designed to hide the difference between various devices and style of access. I/O call open and create can be used to get the file descriptor and read/write/lseek can be used to do sequential-read/ sequential-write/random-access. In the implementation, the file pointer in directory entry is an integer called the i-number, which will be used as an index in a system table to get description for the file. Once a file is open, its device, i-number, and read/write pointer are stored in a system table indexed by the file descriptor. I-node has corresponding link-count and resources (disk blocks and inode) will be freed when link-cout drops to 0. Space on disks are devided into 512-byte blocks logically. For non-special files, the storage of inode is designed to be hierarchical to trade off between disk access numbers and the size of largest file. For special files, the last 12 device address words are immaterial, and the first specifies an internal device name. System uses buffers as a cache for disk to reduce disk I/Os. Pre-reads are used for sequential access.
(2) Process. The commands related to process include: fork-create a new process; pipe-create an inter-process channel; execute-execute program; wait-synchronize between processes; exit-terminate program.
(3) User interface (shell). The implementation of shell is basically: shell waiting for user command-> read call returns -> analyze the command line -> fork a child process to perform an execute with the appropriate arguments -> wait for the child process to die -> type prompt and wait for next command.

Evaluation:
The author gives some numbers to suggest the scale of Unix operation but doesn't give more evaluation. We need to have evaluation for different sub-systems. For example, the performance, throughput and concurrency for the file system; the communication performance for the pipe and the robustness for the shell.

Confusion:
(1) What's the relationship with time-sharing? (2) In the implementation of file system, some numbers are fixed. For example, 512 bytes, 128 blocks, first 10, etc. But I think these numbers should be dynamically changed according to the demand? For example, as we the file size gets larger and disk capacity gets larger, we can switch to larger disk block size and deeper hierarchy?

Summary:
This paper is a primer on the Unix operating system. The authors give an overview of the design and implementation of the major components of the system and highlight the concerns that had an impact on their design choices.

Motivation:
The Unix system was envisioned by its developers as a simple and elegant operating system that catered to the needs of programmers in particular (eg: the focus on interactivity over batch processing), in contrast, in their opinion, to the then existing systems( most of which, the original developers of Unix felt, were 'inhospitable').

Contributions/Solution:
An important contribution to note in their new system was a hierarchical file system (with metadata lists called i-lists) which allowed other file system hierarchies to plug-in(mount) and where, in addition to normal files and directories, there were special files which served as proxies for devices. The same interface used to access the file system is also wrapped around the inter process communication channels, thus allowing programs to access these varied entities in a similar fashion. The other major component of the system is the process management module with a host of system calls ( such as fork, exec etc.) which provided a powerful interface to applications. The authors also explain in-depth the features and implementation of their command-line interpreter , the shell. The shell provided various innovative features of note such as redirection of I/O, chaining of multiple commands etc. and the authors explain how the flexibility and simplicity of the file system and process management system facilitated the development of such a powerful piece of software. The authors then conclude the discussion about the various subsystems with an overview of interrupt and error handling in the system, mentioning features such as a core-dump which enabled tracing out errors after a program crashed. But the most important contribution from this paper ( and the unix system ) might well be the design philosophy , with its focus on modularity , abstraction and extensibility.

Evaluation:
The paper does not provide any performance metrics for the system. But that is understandable since that was not the focus of the developers of the unix system in the first place. The authors do provide some details, such as the number of users/files that their system has, but these are of interest mainly from a historical perspective.

Confusion:
The authors talk (in section 3.5) about 'system entries' (separately from system calls) ,which are invoked by commands/executables, and mention that access to these could be controlled at user level ( eg: only the super user can invoke the system entry to make a new directory).But they never define them precisely. What exactly are these system entries? If they are just a type of executable, can't we just bypass their access control by calling the system calls that they use directly? Do they implement features that are not exposed through system calls? Also, the authors just mention and then gloss over the workings of the internal interlocks used to ensure consistency during simultaneous file updates, which is slightly confusing.

Summary:
The paper discusses the unix time-sharing system in terms of design and implementation of its two important components file system and shell(command line interface).

Problem:
To design an operating system that was easy to write, test and run programs, was adapt for interactive use, good portability, and easily adaptable to non-interactive use as well. Had lesser size constraints in terms of system and software. And, can be run on less expensive hardware.

Solution:
The key solutions provided in the paper as part of the file system design are the special files, directory linking, and removable file system handled using mount. The i-list feature for file system organization introduces the easy to scan directory structure logic. Process and image section describes the memory space handling for a process. A few novel ideas in this paper are introduced as part of shell design and implementation. Simple shell features like filters, redirection and default standard I/O stream greatly simplifies the implementation and usage of these features. The paper also goes on to describe the illegal access, or incorrect routine execution handling in unix by using the trap calls.

Evaluation:
There is practically no comparison studies to show the improvements done in unix. The statistics section of the paper is ineffective at capturing the impact authors intend to show by putting those numbers.

Learning/Confusions:
The paper uses "better-is-worse" principle in most of the cases, specially when handling cases like user space lock for file consistency. No evaluation proof to show that user space file inconsistency is in fact an occasional problem. Neither the paper discusses to what extent these trade-offs are done and how much they simplified the unix design and implementation.
There is a disconnection in going from file system to shell topic, where the authors describe the Processes and Images for unix enviornment. This breaks the tone of the paper as set in the introduction.
Paper also mentions that it uses the idea of forking a new process for each command executed in shell from Multics, but at the same time says that in Multics the idea was dropped due to efficienty reasons, but does not address the point of why it was still kept as a design option in unix.

1. Summary
An overview of the Unix operating system is given to the reader. The paper describes some early features of the OS, how the file system works, how users interact with the OS and some features the OS provides to users that other operating systems at the time did not.

2. Problem
The motivation behind writing Unix may not be anything more than to produce an arguably better operating system for the time. They seem to have aimed only to improve certain aspects of existing operating systems. Perhaps secondary motivations are to provide the simplest, yet most flexible system capable of running on the limited hardware of the time.

3. Contributions
The authors mention that Unix is entirely self contained, meaning that Unix is can be developed using Unix text editors and compiled and assembled using Unix as well. More notably Unix contributes this paradigm where seemingly everything is a file. Making this clever abstraction allows programs to be much simpler and more concise. It makes the interface to interprocess communication the same as interacting with a user or an attached device. This reduces the complexity of programs and the operating system overall. In addition to this paradigm, Unix offers a file system which is simple and convenient. Once again they abstract away the complexities of dealing with a disk or multiple disks, and distill it down to a simple yet powerful interface. They also add several features dealing with multiple processes and multiple users including the shell and fork.

4. Evaluation
Even though the authors had no clear goal, they do present some data on how their OS is used. Although it is unrelated it’s probably about as good as the authors could do. There may be no good way to compare Unix to other operating systems at the time. It is difficult to argue that choices like the “everything is a file” paradigm is better or worse than alternatives. Where some parts of an OS may be more intuitive and easier to work with, others may be more efficient by some objective metric like execution time or storage consumption.

5. Confusion
The authors mention that the 7th bit of file protection bits can allow a program to allows be able to access files owned by the owner of the program. It seems to have some obvious security concerns with malicious users modifying otherwise protected files that they do not own. I also find it strange that “..” at the root of a mounted disk, even though it may have a parent, points to that same directory. I understand that directories may not contain links to other disks, but isn’t “..” just some construct of the operating system and not a real link?

1. summary
This paper provides a high level overview of the Unix Operating System. The file system, process structure (and mechanisms), and shell interface employed by the OS are introduced conceptually. These items are subsequently delved into further via implementation details. The paper closes by introducing three significant considerations that controlled the evolution of the Unix OS as currently seen in 1974.
2. Problem
The Unix OS was created specifically because the authors were not pleased with “available computer facilities.” Previous operating systems only ran on expensive machines and were complicated pieces of software. An operating system that provided a simple, interactive interface allowing for programmable access to hardware did not exist.
3. Contributions
The main contribution of the paper was that of the file system- particularly the abstraction into special, ordinary, and directory files. Special files allowed for device and file I/O to be very similar. As a result, the ability to easily mount external file systems was gained. As a programmer, unbuffered, synchronous reading/writing via the buffering mechanism was a significant contribution. This was a true example of an OS handling low level hardware details that are often cumbersome and time-consuming for a programmer. Finally, default file descriptors added to the simplicity in usage. Output via the shell is easily managed via “standard out”, and the ability for fork and exec to keep open files allows for the creation of powerful commands like filtering between multiple processes.
4. Evaluation
The authors provide very little in terms of statistics to evaluate the Unix OS. However, they state the initial goal is to create an elegant, easy to use system. The concepts throughout the paper show that they have been successful - each feature is conceptually simple, powerful and easy to explain. Usage statistics are also presented, conveying that the OS has active users working on a variety of problems. I believe that the authors have been successful in their endeavour; these concepts presented in 1974 are still very much in use today (many calls and structures are even identical).
5. Confusion
The portion about the set-user-ID feature was slightly confusing to me. I understand why this feature could be useful to allow for restricted access, but am having trouble visualizing the mechanics of this user switch and where else this would be useful.

The UNIX Timesharing System:

Paper: The UNIX Time-Sharing System
Author: D.M Ritchie and K. Thompson

1. Summary:
This paper mainly talks about features of general-purpose, interactive operating System - UNIX and discusses two key concepts in detail: file system implementation and the user command shell interface. The author also explains the reason behind some design considerations, particularly to have simple, programmer convenient, interactive and self-supported OS. It shows how “Worse is better” approach contributed to success of UNIX OS at that time.

2. Problem:
Previous OS built were complex, not programmer friendly, and were expensive in terms of equipment or human-effort. The motivation of the author was to build a simple comfortable environment, elegant, easy to use (e.g. abstractions) interactive, powerful OS which is economical in terms of equipment, effort and can be self-supported.

3. Contributions:
The success of the UNIX system is largely due to the fact that it was designed to be simple and easy to use. The software was re-written in C language to make it easier for programmers to understand including multiprogramming and ability to share reentrant code among several user programs. Some other notable contributions done were:
- Device-independent file abstraction; treating everything as files (regular files, directories and special files) and concept of i-list (method of organizing the file system) also permits simple and rapid algorithm for checking file-system consistency.
- Provides SHELL - user friendly interactive interface which, can be used by programmers to interact with kernel. Framework useful for implementing IO redirection (, - Access control through protection bits also helped in solving MOO accounting problem.

Evaluation:
Although paper mentions statistic in section IX but in my opinion it lacks in explaining the below points:
In section 3.6 - the author fails to explain about why the locks are not necessary or sufficient in UNIX environment.
Comparison with other system or previous system in terms of performance, correctness, consistency was not reported.

Confusion:
I didn’t get the part where authors have mentioned the exception to rule of identical treatment of files on different devices: no link may exist between one file system hierarchy and another. Also, I didn’t get the part where the absence of control blocks is mentioned convenient.

1. summary
This paper introduced the UNIX operating system, and discussed the design of different aspects such as processes and traps. It also illustrated the characteristics and implementation of the UNIX file system and the user interface shell program in detail. The designers’ perspectives are presented to explain the original requirements that lead to such design.

2. Problem
Designers of the UNIX operating system considered the following problems that influenced the overall design:
The old “batch” system is not able to provide interactive functionalities for programming convenience. The ideal operating system should make it easy for programmers to write and debug programs.
The system design is encouraged to be economic and elegant under the severe size constraints of the system and its software.
The system is supposed to be able to maintain itself, so that the designers could use the system while working, to discover its defects and make improvements.

3. Contributions
This paper presented some innovative ideas for operating system design, to create convenience for writing, debugging and running programs, such as:
The file system that supports reading and writing files from a certain location with specified offset.
File protection mechanism that specifies each user’s read, write and execute permission of a certain file, with a tenth bit for temporary change of user id.
I/O devices are treated as special files, making file and device I/O quite similar, and may use the same protection mechanism.
The file system is devided into a lot of blocks. Each nonspecial file has 13 blocks, with 11th-13th blocks used as indirect fetch blocks, allowing the file to grow to much larger size.
The notion of i-node and i-list helps managing and updating opened/created files efficiently.
The command-line interpreter: shell program, with many useful operators that allows for easy I/O destination specification, output redirection to another program’s input, multitasking and executing shell program itself.

4. Evaluation
This paper presented some statistics in the ninth section introducing the scale of the research, but it hardly counts as evaluation. There is no “control group” that compares the performance of UNIX with other existing operating systems.

4. Confusions
In section 6.6, is it the to-be-shell process that checks user name and password, or is it the mainstream path? In other words, when init is called, does the mainstream path create a new process first, or verify the user identity first?
What does section “IX Statistics” imply? The paper simply presented the statistics without any comment on the numbers. There is no comparison with other systems either.

1. Summary
The paper presents the design of UNIX time-sharing system, a multi-user interactive operating system. It gives an high-level overview of the design abstractions chosen by the developers that made UNIX highly successful.

2. Problem
Although the development of UNIX did not start with specific design goals in mind, in hind-sight, the aim of UNIX can be thought of as designing an inexpensive (man-hours to develop) interactive multi-user operating system that is self-supporting.

3. Contributions
One of the main contributions of UNIX is the simple file abstraction, where ordinary files and devices are files in the system, and the programs can interact with them using simplified I/O system calls. This combined with simple yet powerful permission model implemented at the kernel was essential in realizing the multi-user aspect of the OS. The file model shifts the device dependent aspects into the operating system providing a device-agnostic view of system to applications. Being implemented in an high-level programming language C, UNIX served as a proof-of-concept that a fully functional operating system need not be implemented in low-level assembly language, which in turn provided portability at the expense of code size. Other contributions of UNIX include design of hierarchical file system with ability to mount secondary storage volumes, process execution model with inter-process I/O via pipe call, and shell (user interface), which is a command-line interpreter that can be used to execute commands that are programs residing in the system.

4. Evaluation
The authors do not evaluate the system. They allude to the success of the operating system by providing usage statistics of an existing deployment of the system. The authors could have evaluated the subsystems of UNIX in a controlled setting comparing their design choices with the competing options. For example, the file system design of using i-list was novel compared to other systems at that time, which they failed to evaluate.

5. Confusion
The authors concede that the success of UNIX was primarily due to “full exploitation of carefully selected set of fertile ideas.” They, however, fail to mention which of the ideas in the paper were their own or influenced by others (except for a paragraph in the end which discusses it very briefly.)

1. Summary
In "The UNIX Timesharing System" paper, the authors explain in detail about the main features of Unix operating system such as the hierarchical file system, its implementation and the command line interface.

2. Problem
According to the paper, the authors had no predefined objectives when they started to design the system. However, in retrospect, their choices were influenced by the following:
- an interactive system which makes writing, testing and running programs easier than the batch systems.
- a system that conformed to small size constraints and yet was reasonably efficient.
- a self-supporting and self-manageable system that allowed the users to correct the functional and superficial deficiencies as and when they were encountered.

3. Contributions
- Structure of files is controlled by the programs that use them, not by the system.
- A file exists independently of any directory hence linking permits all links to a file have equal status. No link between one file system hierarchy and another indicates how the New Jersey approach has been used.
- File and device I/O are treated in the same way (since devices are considered as special files)
- Mounting of different file hierarchies under a single root directory to give a single unified view to the end user
- I-number provides a short, unambiguous name makes file access and protection easier. I-list enables easier free space management and verifying disk portions containing useful information faster.
- Defines process, image and describes the various system calls to create, communicate, terminate and exit processes.
- Provides implementation details of shell - command line interpreter and briefly explains its features such as input/output indirection, filters etc.

4. Evaluation
From the statistics provided in the paper, the reader can conclude that Unix did indeed support multiple users and was scalable. However, there are no metrics to evaluate the performance against its previous versions or other operating systems at that time. Design and implementation decisions taken behind the rationale that the OS needs to be powerful and interactive, without compromising on simplicity in implementation, is hard to accept.

5. Confusions
I found the line "System command language selectable on a per-user basis" listed as one of the features of Unix, confusing. Is the choice to allow any user to set the set-user-ID bit on one of his own files without administrative intervention a safe approach? Also, the details of how internal interlocks work when two users are saving or deleting the same file is not very clear to me.

Summary
The paper talks about the design and implementation of file system and Shell (command user interface) in Unix operating system. File system implementation is through i-nodes and i-lists. Unix treats everything (directories and devices) in terms of files making it simple yet powerful. The paper also explains various system calls.

Problem
Existing operating systems were costly, hardware dependent, complex, difficult to maintain/modify. Unix aims to be a powerful operating system which is simple, easy to use, inexpensive (in terms of cost & human effort) and self supporting.

Contributions
1. Simple in Design. As it is implemented in C, it is easier to understand, modify and maintain.
2. File System: Everything is treated as file. special files corresponding to each supported I/O devices. Hence same protection scheme and implementation mechanisms can be used for ordinary files and special files.
4. Ability to mount independent file systems.
3. Protection scheme: Protection bits for access control and setuid to allows users to execute programs at ownership level.
4. Buffering of next block for faster access, a similar concept is used in modern database management systems.
5. Shell as a command line interpreter and various traps for hardware-fault, interrupts and quit signal.

Evaluation
The paper mentions describes the advantages of the design decisions in developing Unix OS but does not provide any performance statistics for the various mechanisms implemented or any comparison statistics with respect to exisitng operating systems at that time.

Confusion
1. The title of paper includes 'time-sharing', however I felt a little has been discussed in this context.
2. Later versions of Multics dropped the idea of creating separate process for each command executed on shell for effiency reasons. What design considerations led to its success in Unix?
3. I could not fully understand one of the arguments, 'avoid separation of portions of hierarchy' for a rooted tree structure in directory.

1. Summary
This paper presents the Unix operating system as a simple, easy to use and interactive operating system. It discusses the design and implementation of the Unix file system and user command interface in details.

2. Problem
The paper does not explicitly mention a specific problem that the authors are trying to solve. The authors are building an interactive operating system that can be used by multiple users simultaneously.

3. Contributions
The authors introduce the Unix operating system in this paper. In particular, they provide details about the design and implementation of the Unix file system and the shell. The authors added many simplifications to the Unix file system. Everything in Unix is treated as a file where a file is just related data. This means that simple files, directories and even interaction with I/O devices happens via files. They introduced ‘mount’ing a file system to provide a single and consistent file system tree image to the user. Files are indexed by numbers in the system but are mapped to human readable names for convenience. Information protection is available on a per file and directory basis with the use of few protection bits. Unix also provides an easy to use interface for creating, reading and writing files. Unix provides the abstraction of ‘process’ which is a running program. It also provides system calls to create child process, exit processes and communicating between processes. Unix comes with a shell which is a program that helps the users communicate with the system. The shell takes input from the standard input and prints to the standard output. It can also be directed to take input from or put output to files or even piping the output of one program to input of another. The shell can take multiple input commands from the standard input or from a file.

4. Evaluation
The paper does not have any evaluation of the Unix operating system. The authors do not talk about the performance of Unix as compared to the other existing operating systems. They do provide some statistics to show usage and scale of Unix. However, even this information is presented as standalone and not compared against any other operating system.

5. Confusions
The authors mention that the absence of ‘control blocks’ is a programming convenience. However they do not explain what these ‘control blocks’ are and how their absence makes a difference.

Summary
The paper outlines the major features of the Unix OS and also briefly explains the implementation details. It describes the structure of the file system and the way files are stored,accessed and protected. It then talks about the various features/ abilities and implementation details of the shell, the command-line interpreter. In the end the author recalls that the success of the Unix is due to its simple design and interface, that makes it extremely convenient to program or interact as a user.

Problem
According to the author, the developers had 'no predefined objectives' when they started off, except that they want to design a system that was easy to program and interact with, as they were dissatisfied with the existing 'batch' operating systems. They believed that a properly designed interactive system is much more productive and satisfying to use.

Solution
Unix made the system interactive by providing shell. The users can just type in the command in the simplest form,execute it and see the output.Some major programs like C compiler, Text editor etc were also provided by Unix. Through 'mount' system request files on the removable disks can be accessed just like any other file on the permanent file system. The system calls to the I/O are designed to eliminate the difference between ordinary files and I/O devices; and also the style of access. Through this abstraction and simple system calls like read,write,seek etc, Unix provided an easy environment for programmers to use the file system.

Evaluation
Most of the Unix system calls are the same even today after thirty years, that shows its sturdy design and implementation. The paper didn't quote any performance numbers to evaluate it or compare it with other operating systems of that time.

Confusion
The author quoted that 'the idea to create a process for each command executed on the shell ' was dropped by Multics for efficiency reasons, but
the same was implemented in Unix. The paper neither described the problem of efficiency nor the way they overcame it. I did not completely understand how the file system uses 'internal interlocks' to maintain the logical consistency when the same cannot be achieved by locks.

Summary:
The paper provides an overview of the fourth version of the UNIX operating system. It covers the features and implementation of the FS, I/O, processes and the shell, providing considerations that shaped the design.

Problem:
The authors were trying to provide an environment which was not only simple and easy to use, but was also self-supporting, interactive and reasonable in size. Apart from the operating system proper, the aim was to provide a convenient programming environment and include features such as the editor, multiple programming languages support etc.

Contributions:
Firstly, the choice of C for writing the system provided the authors the ability to make the system interactive and easy to maintain, which compensated for the code size overhead. The authors assumed that the programs that handled the files would control the structure and the OS need not take care of it, which in my opinion was a reasonable decision since structures would be program specific. The idea of special files helped to have a shared syntax and protection mechanism for handling files and devices and the ‘mount’ system feature, made adding and using a device to the computer much easier. I believe all these features succeeded in providing a convenient environment for programmers. The decision to not include user visible locks, was a good design decision as it took into account the type of workload. The concept of i-nodes to encapsulate the details, such as size and protection, not only enabled an elegant method to access, edit and delete files but also a method to check the consistency of the FS, although the authors failed to consider the speed of such an implementation, where files were placed apart from the i-nodes. The fork, execute, wait and exit system calls provided a unique way of running multiple programs concurrently with synchronization. The shell included features like redirection, filters and separators which provide the user an easy interface to realize complex functions. The inclusion of quit signal as a debugging tool and I/O dependent routines shows the programmer oriented design.

Evaluation:
Although the authors do not provide any data, such as the time to access files etc, to show the effectiveness or performance of the system, they still provide statistics that show that the system was able to handle a reasonable number of simultaneous users, run concurrent programs and also provide environment for different user applications.

Confusions:
Under section 3.5, the use of the tenth bit protection bit to change the user ID of the current user to that of the creator is vague. Why is this required? If this is a privileged operation, why is it available without administrative intervention?

Summary

Ritchie and Thompson present Unix: a general-purpose, multi-user and interactive operating system. This paper presents some of the novel features provided by their new system, and shows how it makes interacting with a computer easier for users and programmers alike.

Problem

At the time of writing, operating systems were typically complicated, expensive and non-portable. There was a lack of simple and intuitive abstractions for users to interact with their computers, and for programmers to write software that interacted efficiently with hardware. Moreover, compute power in the 1970s was expensive and programmers were scarce, so there was a strong need for an operating system that was lightweight and easily maintainable.

Contributions

This paper presents several novel contributions which paved the way for modern operating systems. First was the Unix File System and the abstractions of files, directories and special files, as well as the system calls to support disk hardware. Secondly, the general purpose shell which gives the user a flexible and easy interface for interacting with the system. Finally, coding the operating system in the C programming language (instead of Assembly) provided easier readability and maintenance, which contributed greatly to its widespread use.

Another contribution that I found particularly interesting was the concept of a community-developed operating system. This approach was very novel for its time, and was a precedent for the open source movement which continues today, most notably for the Linux operating system.

Evaluation

The authors do not spend much time evaluating their operating system; most of the paper is spent describing it. The only real quantitative measure happens in the conclusion where they describe their user base.

This is probably the greatest drawback of this paper: the authors do not spend any time describing existing operating systems, explaining their shortcomings, or showing how their new Unix systems offers improvements. To be fair, some of their novel contributions such as the Unix File System and shell had no suitable equivalents; but some measures of performance and efficiency of this new system would have been beneficial.

Confusions

Most of the paper was well written and easy to understand. I was confused however by the implementation (or lack thereof) of locking in the file system. I don't understand why locks were considered unnecessary and insufficient, or how the internal interlocks maintain logical consistency of the file system.

1. Summary:
This paper discusses a high level design of Unix Operating System and some of its salient features such as File system, Processes and images, user command interface i.e, Shell, and their implementation.

2. Problem:
Rather than solving any major problem, this paper describes the file system of Unix system, how it evolved from its earlier versions. As mentioned in the paper, thee difference of the current system running on PDP-11/70 from its earlier versions is rather small and has mainly to do with the details of file system implementation.

3. Contributions:
The paper has briefly touched upon several important contributions of the current Unix version. The way it treats normal files, directories and special files in the same manner leads to a very neat abstraction. For further ease and better reliability, it provides mechanism to mount/unmount different file systems and access control with various protection bits respectively. With very simple and intuitive system calls, a user can easily create, open, read and write a file both sequentially and randomly, which is a very elegant coding technique in my opinion. The low level implementation of file system consists of file's inode which contains all the information of the file including its data pointers. By pre-reading nearest blocks, the Unix file system greatly improves the sequential read performance. It also provides various ways of inter-process communication by means of exec command, pipes, and output redirection using '>' and '

4. Evaluation:
Although the authors do not provide any evaluation criteria to judge the current OS on different grounds like performance, correctness, security etc, but they do provide statistics mentioning the number of users currently using their OS, number of maximum simultaneous users, commands supported etc to justify the Unix OS.

5. Confusion:
While describing i-list, the authors pose a question on who is to be held responsible for the space used up by a file. Though they say its easier to either charge everyone equally or do not charge anyone at all, but what could be the best strategy?

1. Summary
The paper presents descriptions of the many features implemented in the UNIX Time-Sharing System. It provides a clear explanation of how the system interfaces with the hardware to provide ease-of-access to the users using high-level system calls. Implementations of a file system, multiprocessing system and a shell are explained.

2. Problem
The main motivation then was to have a easy to use software system to access the hardware rather than to remember and use the details of the hardware system meticulously in case of file operations and running processes. In doing so, the possibilities to provide organisation and security to files, interprocess communication, process synchronisation and development of the shell interface arose.

3. Contributions
a) File System: The file system provides organisation of files by directories and filenames. Special files from other I/O devices are integrated and displayed as a part of the existing file system. Protection to the data in the file is enabled along with executable permissions. I/O calls to files are done using simple system calls thus abstracting the user from the underlying complicated details of access to the hardware.
b) Process: The system uses the idea of having many images in memory at the same time while running one process and moving in between processes, thus appearing as a multiprocess system to the user. Process are created and executed while also being able to pass arguments to the child processes.
c) Shell: The interactive shell was an improvement compared to the previous batch mode of running commands. The shell had options to redirect input/output and also multitask several commands at once.

4. Evaluation
Since the UNIX system was one of the initial attempts to an operating system, the authors do not have a benchmark to compare the system against. However, its functionality is compared against the previous versions to show improvement in its ease of use.

5. Confusions
The implementation of the file system for I/O devices was a bit ambiguous as to what gets written in the i-node and how it is accessed using that data.

Summary :

The paper gives us an overview of the major components of the UNIX operating system such as the filesystem structure, process execution and the shell interface along with their implementation details. They also talk about the various advantages of their design considerations in the implementation.

Problem :

The problem in question was to design an operating system that was interactive, multi-user and having a file system structure and an interface that was fairly easy to use as a programmer.

Main Contributions :

1. The files are stored independent of the directories which they fall under. A file can be linked to from any number of directories by using just the name and the i-node number as a directory entry.
2. Devices are treated as files and therefore, no specific code is required for accessing devices as compared to accessing files.
3. The ability to mount or attach a removable file system to the already existing file system.
4. Access control mechanisms are in place for restrictions on access to files and directories by setting the protection bits appropriately. The functionality of the set-user-ID bit which allows a user running a program to inherit the access control permissions of the owner of the program to access files during the program execution.
5. System calls to access files both in a sequential and random manner.
6. The flexibility of the inode structure to have multiple levels of indirection for larger files. The inode stores the required file information to check for access permission information. It also tracks the number of links which when reaches zero frees the corresponding disk blocks.
7. Disk blocks are buffered in memory for faster access. The sequential access pattern of blocks also pre-fetches blocks into memory.
8. The fork() system call which was taken from Multics is the basis for process creation. The concept of background processes, filters and I/O redirection are other main features.

Evaluation :

The paper provides certain overall statistics about the number of concurrent users and the number of files/directories to give us an idea about the scale of the system then. They had focused also on keeping the size of the core OS small. We do not have any specific evaluation measures on the performance of the file system routines or the process system calls.

Confusions :

The concept of creating a new process for a command was taken from Multics. What was the reason that this method was later discontinued in Multics for lack of efficiency? The paper mentions that the file system maintains no locks when multiple users access the same file but interlock mechanisms are used to maintain logical consistency. How do the interlock mechanisms work?

Summary :
The authors present a detailed overview of a hierarchical file system, UNIX, and present the low level implantation details of how files and directories are organized and accessed. The paper also presents the implementation details of some system calls and the motivation behind developing this system.

Problem :
1. The authors wanted to develop an interactive system which would be more productive and satisfying to use when compared to a “batch” system.
2. The system that is being developed has to conform to the severe size constraints on it and also the desire for the reasonable efficiency and expressive power, simultaneously ensuring elegance of design.
3. The system needs to be able to easily adapt to new changes suggested by the users when they observe functional and superficial deficiencies and want to revise and rewrite the corresponding fixes.

Contributions :
1. The authors designed and implemented a hierarchical file system which supported mounting and demounting external devices and volumes.
2. An important contribution of the UNIX file system was the introduction of organizing files and directories using i-nodes and i-lists. This made file system storage very elegant and easier to manage.
3. The authors state the concept of treating I/O devices as special files where they are just treated as any other ordinary files and reside in /dev directory. This is because the file and the device names have the same syntax and meaning and they have the same ACL needs as the file.
4. Design and implementation of different system calls and functionalities like pipe(), fork() etc to help with easy interaction between hardware and software and also provide an easy environment for programmers to use the file system.

Evaluation :
The paper does not provide any details on the performance of the functionalities implemented. It does, however, state that the system supports multiple user operation and is comparatively inexpensive and efficient when compared to other systems.

What I found confusing :
I did not completely understand the concept of mount. If a user had to mount multiple copies of a single device/file and links between hierarchical file system is not allowed, how would this be done?

Summary :
The authors present a detailed overview of a hierarchical file system, UNIX, and present the low level implantation details of how files and directories are organized and accessed. The paper also presents the implementation details of some system calls and the motivation behind developing this system.

Problem :
1. The authors wanted to develop an interactive system which would be more productive and satisfying to use when compared to a “batch” system.
2. The system that is being developed has to conform to the severe size constraints on it and also the desire for the reasonable efficiency and expressive power, simultaneously ensuring elegance of design.
3. The system needs to be able to easily adapt to new changes suggested by the users when they observe functional and superficial deficiencies and want to revise and rewrite the corresponding fixes.

Contributions :
1. The authors designed and implemented a hierarchical file system which supported mounting and demounting external devices and volumes.
2. An important contribution of the UNIX file system was the introduction of organizing files and directories using i-nodes and i-lists. This made file system storage very elegant and easier to manage.
3. The authors state the concept of treating I/O devices as special files where they are just treated as any other ordinary files and reside in /dev directory. This is because the file and the device names have the same syntax and meaning and they have the same ACL needs as the file.
4. Design and implementation of different system calls and functionalities like pipe(), fork() etc to help with easy interaction between hardware and software and also provide an easy environment for programmers to use the file system.

Evaluation :
The paper does not provide any details on the performance of the functionalities implemented. It does, however, state that the system supports multiple user operation and is comparatively inexpensive and efficient when compared to other systems.

What I found confusing :
I did not completely understand the concept of mount. If a user had to mount multiple copies of a single device/file and links between hierarchical file system is not allowed, how would this be done?

Summary:
The paper aims to show why UNIX was a simplistic, powerful and interactive operating system at its time by discussing the design features and implementation of core components like the shell and the file system. In the end the authors explain factors like ease of use that drove their design decisions.
Problem:
With no clear objectives the initial motivation was to build a more user friendly system for writing and testing programs in because older systems were expensive, complicated and hard to maintain. By incorporating good design philosophies from the older systems the long term goal turned out to be developing a simple yet powerful operating system that was more economical in terms of memory and hardware usage.
Contributions:
Some notable design features that are still at the core of of UNIX based systems today.
1. An Organized File System: Treating files and devices the same made it easier to from a usability perspective and allows for a general API for read/writes which is simpler to implement. The mount feature made the file system more flexible as the file tree could easily be extended and still be consistent with the hierarchical structure. A simple 10 bit protection mechanism same for all the file structures, allowed users temporary rights to modify protected files legitimately. Inode tables helped with ease of use by providing organization between filenames and metadata.
2. The Shell as a User Interface: Spawning child processes from the shell made it more responsive and capable of multi-tasking. I/O redirection and inter process communication(IPC) via filters allowed the shell to execute a sequence of commands together.
3. Other improvements: Rewriting the OS in a higher level language not only made it portable but also easier for programmers to fix bugs and further develop the system on itself, making it more sustainable. The OS also allowed for code sharing among processes which helped towards a smaller memory footprint.
Evaluation:
The authors made a lot of claims about convenience but did not fully justify them by comparing their features with existing solutions from older systems. A lack of performance metrics apart from usage statistics makes it harder to gauge the effect of their design choices objectively because issues like user friendliness can be subjective.
Confusions:
It is unclear how they would charge all the links to a file with the space for it. Will the charges keep changing with the number of links?
How is programming convenience that there are no “control blocks” maintained by the and depended on by the file system or other system calls?

Summary
In the paper, “The UNIX Time-Sharing System”, the authors describe the basic structure of how UNIX implements a hierarchical file system, executes processes, describes the role of an image, and the implementation of the Shell along with how the Shell interacts with the lower levels of the operating system to present an interactive environment to the user. Towards the end of the paper, it describes how processes can communicate to each other through signals, some of the influences of the design of UNIX, and some basic statistics about the usage of UNIX.

Problem
While the paper actually asserts that “it was not designed to meet any predefined objectives”, the UNIX operating system did solve a number of problems in retrospect. One problem that UNIX was trying to solve was to run on inexpensive hardware and reduce the amount of effort it took to create programs. Before UNIX, hardware in computers was generally expensive and the software was bulky and took a long time to develop.

Solution
UNIX did a number of these to make the future development of programs (and future development of UNIX) easier. It provided an interactive environment in the Shell to create, compile, and execute programs against. This was convenient for programmers because they could create their code and execute it, and then go back and tweak the code much quicker than writing programs on punch cards. In addition to this, it provided an easy way to interact with output, files, and the disk that were conceptually easier than working with the actual hardware. The operating system was also very light-weight, which meant it could run on inexpensive hardware. The entire system kernel only requires 96K of core.

Evaluation
Most of the paper isn’t concerned with the evaluation of the system, it is most concerned with describing the structure of the system. It doesn’t really state why or how the file system or Shell is better than previous systems. However, at the end of the paper the authors do provide some usage statistics on UNIX which include user population, number of directories, and number of log-ins. These statistics were probably useful and interesting at the time of the publication of this paper, but seem to have little use in the present.

Confusions
When reading the paper, I was the most confused by the hardware terms that were being used, simply because I am not familiar with the terms. Additionally, while I understood most of the implementation of the file system, the actual implementation of the mount function confused me. I understand the overall use and goal of mount, but the implementation with how the system keeps track of external file systems was a bit confusing to me. One thing that I learned after reading this paper was that other programs, other than the shell, can be specified to run when a specific user logs in. I had always assumed that the Shell was run and was controlled by the OS and it could not be changed even with a privileged user.

1. Summary

This paper describes the major features of the UNIX operating system, and gives a bird’s-eye view into its implementation. The paper explains the rationale behind major design decisions, particularly the desire to create a simple, interactive OS for programming. UNIX’s design & implementation is a good reflection of the ‘Worse is Better’ school of SW design.

2. Problem

Surprisingly, UNIX was not designed to solve a single problem, instead it sprung from a general desire for a more conducive environment for program development & testing. Secondary considerations included frugal memory needs, ease of portability and modular design.

3. Contributions

In my opinion, the greatest contribution of UNIX is its philosophy that places simplicity & convenience at the forefront of SW design. This allowed the wide adoption of UNIX, which in-turn led to massive interest in refining & improving the system. UNIX introduced intuitive & powerful abstractions around native hardware, that continue to be in use today. The Unix File System presented the logical notion of files and directories for hierarchical storage of user data. Unification of files, directories & devices, is made feasible by a layer of indirection called i-node, which contains relevant file information. Mounting of new file-systems, creating links and access controls are easily achieved through the i-node. The abstraction of the process, coupled with APIs such as fork/exec & file descriptors, enables powerful multiprocessing environments such as the shell. Through conveniences such as transparent redirection of input/outputs, unified file & device IO etc., UNIX engendered the development of simple, but rigorously tested, programs, which can be coupled to achieve complex functions!

4. Evaluation

A few statistics are presented to demonstrate the scalability of the system, but otherwise no empirical evaluation is presented for any major design decision. Convenience, and often common sense, has driven most aspects of UNIX. While this has mostly worked fine, sometimes this has backfired. A case in point will be the UNIX file system, which treats memory & disk similarly, incurring heavy seek costs even for common file operations.

5. Confusions

Limited main memory was a major influence on UNIX design. Nowadays, this consideration is almost non-existent. I wonder what aspects of UNIX design ought to be re-evaluated under this paradigm and what is the scope for improvements? Also, one of the features given is ‘System command language selectable on a per-user basis’, what does this mean?

1.Summary
The paper provides both a high-level picture as well as the low-level implementation details of certain salient features of the Unix OS such as the file system, process abstraction and the shell (the user command interface). More importantly, the authors discuss the rationale behind the key design decisions taken during the development of this OS, such as providing a similar abstraction for files and devices.

2. Problem
The initial motivation of the developers was to create a more convenient interface to computer hardware than existing operating systems. However, the intention can be better phrased (perhaps in retrospect) as the desire to create a simple, inexpensive, interactive OS, which would be highly conducive for programming scenarios.

3. Contributions
In my opinion, there are several important contributions of this early version of the UNIX OS. Having uniform abstractions in the file system for normal files, directories as well as devices provides a clean interface to interact with all of these. This also avoids the need for distinct implementations, which would merely bloat up the code size. It also helps each of these leverage the same basic implementations for facilitating protection and access control. The use of the i-nodes which packages all the relevant information about files in an elegant manner, allows for simple implementation of mount, file descriptors and linking. The use of file descriptors in turn enables a simple method for supporting I/O calls, inter-process communication and redirecting input and output streams. The shell or the command line interpreter itself possesses certain powerful abilities like filters and I/O redirection. It also supports multi-tasking through the ‘&’ operator which schedules processes in the background. The presence of a powerful command line interpreter also allows for simplified batch-processing on this primarily interactive system.

4. Evaluation
While the authors do not present any data to demonstrate the effectiveness or the performance of their OS, they do report statistics regarding the ongoing usage/adoption of their OS to showcase the capability of the machine to run reliably and support multiple users on a reasonable scale of operation.

5. Confusions
I have a doubt regarding the programming convenience provided by not having control blocks, an assertion made in Section VIII - Perspective. What are control blocks? How does this tie in with the statement that a program’s address space is its own property?