Paper Discussion - Fall 2008 - CS 736

This Paper describes the fourth version of the Unix Time-Sharing System. It demonstrates that a powerful interactive system need not be expensive in equipment and human efforts, additionally this Operating system is simple in implementation and has great ease of use. The main discussion revolves around nature and implementation of the file system and of the use of command interface.

Features of Unix:
1. The FileSystem: Every accessible object like File, Directory, and Devices are treated as Files and they are stored in the File system hierarchy. Each file entry has a unique filename and an I-number that points to the i-node containing all the information about it. Each file has a set of protection bits, which defines its access over user, group or other id’s. This eases down the protection of all the files. It has ability to link files from different directories and mountable file system.
2. Processes and Images: Process is the execution of a user program and it maintains it own image that includes Memory Image, general register values, status of open files, current directory and like. Process has an ability to create another process. Processes are created using a fork() system call. This results in creation of child, where both parent and child have similar memory images.
3. Process Synchronization and Communication: Unix provides basic system calls for synchronization and process communication like pipe. The simplicity of unix makes the ease of using these features widely. Each system call has an associated error code to determine if the command succeeded or not.
4. Shell: For most of the users, it’s a mode of communication with the system. It’s a command line interpreter. Cascading of operators can be used to achieve bigger tasks done in a single command. File descriptors 0, 1, 2 are opened automatically for standard input, output and both but these can be overwritten to files by use of standard I/O operators.

The success of Unix was primarily due to the fact that it wasn’t designed to be perfect or to meet any predefined objectives. This Operating System was designed while keeping simplicity of design both in implementation and interface. It considered simplicity over correctness and completeness. The usage of C language favored its usage by huge users/programmers. As pointed out in the New Jersey approach the worse-is-better has better survival characteristics. The simple interface and implementation led to it spreading like a Virus.

One of the disadvantages is, the user is left with the effort of error checking in every system call. The system never assures that it’s going to succeed.

THE UNIX TIME-SHARING SYSTEM:

This paper describes the particularities of the file system and the user interface of the fourth version of the Unix system. It also shows how the use of the C programming language made the system much more easy to understand, develop and modify.

The intention is to design a large general purpose system that is portable, for multiple users and that can run in relatively inexpensive computers. Some of the primary considerations in the design were to create a simple and easy to use system, that is reduced in size and that could maintain itself.

This paper explains some simple concepts that are still used in nowadays Unix systems. The hierarchical file system with ordinary files, directories and special files (as an abstraction for I/O) is still the base for Unix file systems; the idea of the i-node containing the description of the file and the direct, double and triple indirect blocks that it occupies in memory is still used. The shell is still the main interface between the user and the system and it still maintains the same functioning method of creating a process for each introduced command and then executing it. The development of C was also an important step towards the design of operating systems.

The Unix system was designed with no particular constraints or demands. The fact that making this system simple and easy to use was the main priority may have left other important issues behind, such as security. Another aspect is that generalization and uniformity is always a preferred solution for the system than optimization, all the I/O devices are treated the same way and all the files in the system are assigned the same way no matter if they are really short or really long.

The presented file system gives an abstraction over the I/O devices, but it avoids accessing special characteristics of the different peripherals.

Summary: This paper describes the Unix environment consisting of OS and Shell+basic utilities. It shows basic OS interfaces and enough OS and Shell internals to understand how they interact and complement each other in offering a simple but powerful environment.

Problem: In those days hardware restrictions were stringent and there was no interactive, "hospitable environment" for research and quick experimentation.

Contributions: 2 kinds
1) OS Technical: Powerful, viable, interactive OS, yet for low budget. They put together many useful concepts mostly existing (see Organization), and a few new.
Although not named this way they use the concept of STREAMS (files, pipes or special files; mostly sequential, but also random). The concept of 'mounting'.

2) General Software engineering, besides overall simplicity and flexibility. Unix evolution shows the power of programmers as users. Unix also shows the evolutionary success of an interactive system, where quick experimentation is possible. Most OS or Shell primitives as well as a set of basic utilities are simple, and designed to do one thing well. This allows for easy testing and reuse.

Flaws: 1) It is not a generally "hospitable environment". It is only "hospitable" for fast typing, highly educated user, who can make sense out of something like "ls | pr -2 | opr".
2) Being written in C is both a plus, for efficiency, and a minus, C being bug friendly although in those days, probably one could have argued for the opposite).

Organization: This paper is about the environment, OS and the Shell, not just the OS. They describe a very well designed File System, with a unified treatment of regular files, as well as "special files". Internally, they are implemented using i-nodes. Unix has a flexible, uniform, process structure, designed to allow primitives like pipes and redirection. In general, the kernel is designed to facilitate the use of a Shell. IPC is done through pipes.

Issues:
The flexibility offered by mounting and linking comes with some semantic and implementation difficulties, all solved in favor of simplicity. Protection mechanism was OK in a mostly cooperating environment.

Summary

The paper presents UNIX as a general purpose, interactive and portable multi-user operating system. It explains the features that have been incorporated justifying the above claim. In particular, it discusses the design and implementation of the file-system, process management policies, I/O and the user interface program - shell

Problem attempted

The initial version of the system was designed in response to the inadequate computing facilities available at the Bell labs then. The primary goal was to build an interactive system that makes the use of underlying hardware much easier.

Contributions

1. This was the first time when the concept of a portable operating system was spoken about. The system has stood the test of time proving itself to be protable to almost any machine.

2. The operating system was written in C - a high level programming language instead of the assembly language. Though the size of the system has been 30 to 40 % larger,and probably slower, the advantages like easy readibility, debuggability and hence the ease of improvement far outweighs the disadvantages.

3. This was the first system that provided a consistent interface to all files and devices. This meant that, for programs expecting file names as parameter, we can pass a device name too. The operating system taking care of the idiosyncrasies of the device is a great relief to the programmers.

4. The system implements a hierarchical file system that permits easy maintenence and implementation. For example, when a directory is removed, it is just a removal of a subtree in the system tree. It also does not demand the entire hierarchy to be stored in a single device.

5. Access control is fine-grained i.e. it is implemented on a per-file basis.

6. The system provides a buffering mechanism that helps ensure that the number of I-O calls is minimized i.e. each time a block is searched for read, its availability in buffer is seen before trying to fetch it from disk and while writing back, it is first written only in buffer and the change is not immediately effected in device. This helps save an I/O call when teh same blcok is going to be changed very soon.

7. The way in which the i-node stores the device addresses of a file is clearly making the common case fast - it ensures that files below 5 KB in size can be read with a single disk access.

8. The shell is a very powerful user interface - a good command over its features helps accomplish many tasks in a much easier fashion - like the one mentioned in the paper.

Flaws

1.The paper does not seem to place any restriction on the number of processes any single user may own. This could mean that a fork bomb can make the system completely unresponsive , leaving reboot as the only option.

What it makes easier

1. The programmer's life is made easy because, the details of deveices are completely hidden from him now. Also, I/O calls are

2. There is no restriction on the structure of the file by the operating system. This helps all programs treat files as unformatted stream of bytes

3. The system gives primitives that help users in combining many small programs into a complex program - like the I/O redirection and pipe

What it makes harder

1. Difficulty exists in charging a user for disk space when multiple users have a link to a file, particularly when the owner deletes the file

2. Though it is difficult to implement locks for shared resources, it would have been better to have implemented a lock system that fails in the most infrequent situations rather than implementing no lock at all

In The UNIX Time-Sharing System, Dennis Ritchie and Ken Thompson presented an overview of a time-sharing operating system designed to address the concurrent needs of many users.

UNIX initially attempted to address the need for an interactive programming and document preparation environment. It was designed to with a small memory footprint and ease-of-maintenance in mind.

First and foremost, Ritchie and Thompson's paper contributed details about several system abstractions used within UNIX that simplified both the logic and implementation of their system.

For example, they detailed how all UNIX devices, files, and directories were exposed to userspace programs as files. This allowed them to implement one file-based permissions system that applied to all these objects, and make heavy use of the same core set of functions to perform I/O on these objects. Along these lines, they noted the system shell was just another “command” with standardized I/O linked to typewriter and printer “files”.

Second, Ritchie and Thompson offered a detailed description of how to interface with the system while using the abstractions above to one's advantage. Examples include “filtering” the output of a command with another command and “backgrounding” a process such that other tasks can be run in parallel with it. Impressively, the shell commands described are still present in modern UNIX and Linux distributions.

Third, a brief description of the file-system used (unnamed) was provided. Here they described hard links and mounting file-systems on top of directories. They also noted how writes took effect immediately (long before being flushed to disk) and claimed file-locking systems were not easy or worth implementing. It's worth noting that today many UNIX and Linux applications use lock files to manage a shared resource.

Finally, the paper suggested UNIX's popularity amid programmers was due to it being written in C (instead of assembler), making it easy to port to new systems.

The UNIX Timesharing System

Summary

This paper discusses the design & implementation of the significant components of the UNIX timesharing system namely:

1. the hierarchical file system with unmountable devices where all files ( ordinary files, directories, and devices as special files ) are oraganized in a tree structure.
2. the interative command interface called Shell which nicely integrates with the process subsystem features like the ability of a process to create asynchonous child processes and achieve synchrony between them when needed.

Description of the problem being solved

An attempt is made to develop a well-designed, portable, multi-user, interactive operating system that can provide a hospitable environment for general-purpose usages like text editing & formatting, photo-typesetting , programming, entertainment in the form of games like chess, black-jack etc.

Contributions of the paper and their relevance today

All the contributions below are very much relevant today and found in most of the UNIX based modern operating system.

1. A well designed file system and file organization that has the following significant features :

a) the tree like layout of files that makes file discovery and maintenance easy
b) treatment of devices as files makes programming easier because of same protection mechanism and I/O interface for files as well as devices.
c) a simple, programmer friendly I/O interface that can talk to all devices and do any kind of I/O ( sequential or random )
d) access control using set-user-ID feature that allows controlled execution of priviledged code by unpriviledged users
e) unmountable file systems
f) ability to creates links from different directories to the same file ( today's hard links )

2. A well designed process subsystem that provided the following features:

a) Ability of once process to create another asynchronous child process through fork system call and to achieve synchrony with the forked child process using wait system call when needed. This facilitates program development. For example, the shell interactive command interface uses this to execute child processes that perform the commands specified.
b) Organization of the user memory of a process image into text segment
c) Pipes for interprocess communication between processes under a common ancestor ( that sets up the pipe; common ancestor can be one of the communicating processes also )
d) The device drivers for the various devices are made part of the Operating system kernel rather than taking other approaches like having each program have its own copy of the driver OR using dynamic linking to share device driver code.

3. A powerfull interactive command interface with the following features:

a) Many small programs can be combined in several ways using pipes to achieve a bigger task easily and effectively. For example, ls | grep star displays all file names in the current directory that have "star" subsequence.
b) Standard file descriptors 0,1,2 for input , output and error message respectively are created for all commands executed by the Shell. The standard file descriptors can also be redirected easily when needed
c) Commands can be started in the backgroud so that the shell can immediately take another command from the user.

Flaws in the paper

1. Completeness and Correctness is sacrificed in favor of Simplicity.

For example, a) the choice of not implementing the feature for programs to lock files for read or write. This made the operating system development simple but the feature set was not complete. b) the choice of continuing forward a system with significant state when a interrupt occurs in the middle instead of going back on the system call to process the interrupt first. Here, Correctness is sacrificed in favor of simplicity. In short the "New Jersey style of development has been adopted" ( see http://en.wikipedia.org/wiki/Worse_is_Better )

Though the above was a conscious design decision of the designers , I think it is a flaw in the design.

What is made easier?

1. Programming to interact with the operating system and also to maintain the operating system is made easier because of several reasons like simple , consistent I/O interface to talk to all devices and availability of good process creation mechanisms.
2. The operating system being written in a high level programing language C rather than assembly language, motivated the developers to fix bugs and implement new features easily and therefore made the system self-maintainable.

What is made harder?

1. Writing complex programs like single-file databases maintained by multiple processes is impossible because of lack of availability of features like locking on files ( sacrifice of completeness in favor of simplicity ).

2. Since the design was not supposed to be Correct always unlike the MIT design approach, sometimes when interrupts happen during execution of system calls with significant state , the system call errors out. The responsibility of handling errors from System calls and retrying them whince the design was not supposed to be Correct always unlike the MIT design approach, sometimes when interrupts happen during execution of system calls with significant state , the system call errors out. The responsibility of handling errors from System calls and retrying them when needed falls on the programmer. This makes is slightly harder to write programs.en needed falls on the programmer. This makes is slightly harder to write programs.

In this paper, Unix, a general-purpose, interactive, multi-user operating system is described. Specifically, the authors present the features of the system (file system, process management, user interface) in detail as well as the philosophy behind its implementation.

By reading the paper (although it’s not mentioned), we understand that the authors intention is to create a simple but powerful interactive system that will be easy to use.

One of the most important contributions of the system is that it is written in C and not in assembly. As a result of the portability of the code, Unix could spread easily. Another significant contribution is that the I/O devices are treated as files. Programs can easily access devices, by just reading and writing disk files. Moreover, the shell which supports many features (redirection, multitasking e.t.c) allows the user to easily communicate with the system. Finally, the paper presents some very important features like the i-nodes which keep metadata for all files, protection bits and links among others. The fact that these features are used until today , proves that the system is very practical and efficient.

As mentioned in “The Rise of worse is better” Unix focuses more on the simplicity of implementation than the simplicity of interface. For example, the file system doesn’t maintain user-lever locks .Another example is the PC-loser-ing problem described in the “Rise of worse is better” where the users have to insert extra loops in order to check if everything is done correctly.

One of the main advantages of the proposed operating system is the abstractions for files and I/O devices, which make I/O very simple. Moreover, the shell and its features make easy the execution of multiple dependent commands. Finally the modification of the system is easier since it is written in C. One drawback of the system, as I mentioned above, is that it makes the users perform extra checks in their programs to ensure that everything functions well.

Summary:
This paper describes the implementation of the UNIX file system. The UNIX system has multiprogramming and the ability to share reentrant code among several user programs and has the most unusual feature by introducing special files in it. The paper also focuses on talking about the implementation of the user command interface called shell, which is considered as a command.
The problem the paper was trying to deal with:
The goal of the authors is to develop a file system and the command interface for a general-purpose, multi-user, interactive UNIX operating system. The new system is not only become much easier to understand and to modify but also include many functional improvements compared with the old system.
Contributions
1． The UNIX file system has a good feature introduced by special files and removable File System makes UNIX file system more scalable.
2． The UNIX file system used i-numbers as the pointer to the file itself, i-lists as the system table, and i-node as the entry which make the file be easily implemented.
3． The UNIX System is written in the high level language C, instead of assembly language, which makes it more portable.
4． The UNIX system includes a rather complicated buffering mechanism, which reduces greatly the number of I/O operations required to access a file.
5． All locks in the file system are invisible to the user, and there is no restriction on the number of users who open the file for reading and writing.
6． At some place this paper do exhibit 'new jersy approach or worst-is-better' in UNIX implementation.
Flaws:
There are no read and write lock for files, therefore the UNIX file system may have the trouble to deal with the issue when many users access the same files in the meantime. And the UNIX file system doesn’t handle the quota issues well.
What it makes easier:
The existing of shell in the system makes the communication among different users much easier.

The authors of the UNIX 4 system designed and implemented a system which itself was easy to program and which was acceptably easy to write programs for. In doing this, they used the system to develop itself, and so became their own customers. A system designed with no particular motivation thus found problems to address.

One of the key results of UNIX is an interactive system, or a system which is designed to be attractive to programmers rather than to the tasks they program (a batch system). The authors speak of, "satisfaction," which rises from the use of such a system, which seems to imply that such a satisfaction in one's product will motivate its success. The authors' satisfaction in what they produced, in fact, appears to preclude, in their mind, need for a more systematic evaluation of the product. They offer instead their own vouch, that it is "simple, elegant, and easy-to-use." To be fair, the system has shown in practice to be an effective design with many advantages. The file protection scheme, for example, has persisted 34 years now in almost the same form, as has the root directory structure, the system of links, and the names of system calls written to interact with the kernel. Being small and portable, too, has persisted as a primary goal of derivatives since then. Each of these features were developed to answer the needs of programmers working on the project. This alone probably secured the system's success.

The success of UNIX, coupled with the informal presentation of it in this paper, draws attention to the core methodology of the authors. This methodology has been called, "worse is better," by Richard Gabriel. The advantages are exactly as we have hereinbefore discussed: it tends to address the most immediate problems in such a way that makes the product attractive, if incomplete. There are flaws to the UNIX system, though they are not discussed here. An example given by Gabriel is the error value returned when a spurious system event makes handling of a system call too complex. In this case, apparently contrary to the goals of the system, the burden is placed on the programmer to check for the return value identifying this condition and handle it himself. Gabriel believes the attitudes of the authors was, "It's easy enough for the programmer to make this check," and as they fail to mention such trade-offs in their paper this may well have been their position. Time has told that while yes, it is easy to do, programmers don't do it because it's obnoxious and this has given rise to buggier software. If there is one core flaw in the system, it is the failure of the authors to address user programs as fragile.

Summary:
The paper discusses design and implementation aspects of the UNIX operating system.

Problem:
The development of an operating system suited for interactive use, as against contemporary batch operating systems. There is also great focus on portability.

The system organization:
Central to the unix system are two concepts: the filesystem, and processes.

The unix file-system is organized as a hierarchical tree of directories (non-leaf nodes) and files (leaf) nodes. It supports integration of file-systems resident on different devices through the mount facility. It also provides a uniform interface to I/O as files.

The processes in unix is a dynamic pool with system calls provided to create, terminate and syncronize processes (wait etc). The shell process provides the user interface through a command line interpreter.

What it makes easier:
- I/O is made very simple by pushing the device dependent aspects into the OS and providing a uniform interface as files.
- multi-processing is made easier through the shell, numerous process management system calls, and ipc facilites.
- the approach of providing a set of utility programs that can be chained together to accomplish tasks makes for ease of use.

What it makes harder:
- on the flip side of having device specific aspects hidden from the process, applications that need to access these aspects find a hard time.

Contributions:
- the filesystem is layout: because it introduces key concepts like mounting, uniform interfaces to devices, hard-links etc
- the advanced shell / command line interpreter: supports many features like i/o redirection etc..
- debugging capabilities: traps and core-dumps allowing easy debugging.
- building block utility programs (refer above)

Limitations:
- Apart from the limitation discussed in how to account for files that are linked to by multiple users, I do not see a logical inconsistensy of the proposed design against its purpose.

The UNIX Time-sharing system discusses an operating system designed for writing, executing, and testing programs that is convenient for software development and capable of interactive use. This system was designed by combining key features from earlier systems including a file system using virtualization with i-nodes and device files, file protection, more standardized process control, and a shell for interaction.

The problem that was trying to be solved by this paper was the ability to create a powerful operating system that can be ported across a broad spectrum of hardware while simplifying the task of programming applications through a simpler and abstracted programming interface.

This paper contributes a complete operating system that combines together previous ideas into a powerful and simplistic system. The abstraction of all devices as files allows developers to write software that interacts with hardware similar to that of a file. The piping and shell redirection allow applications to interact allowing for better reusability. The expansive applications and programming languages make the system more appealing for adoption.

The paper discusses the advantage of having a user community develop the software; however, it does not address the concerns of validating such a system. The challenges associated with a community of developers can lead to programming bugs that are difficult to track down and hard to make stable and robust. This simplistic OS design also leads to virtualization overhead caused by i-nodes and overly simplified devices abstractions as well as known limitations such as the ability to corrupt files when multiple writes occur simultaneously.

The operating system organization consists of a file structure in which all the devices are abstracted as files. Above this structure is a shell which can be used to launch additional processes. The simplicity in design makes the system easier to program and debug applications. However, the abstraction of all hardware as files reduces possible optimizations and complicates the hardware device drivers.

Summary: The authors present an updated (for Unix v. 4) description of the Unix System to elaborate on the new file system hierarchy they created to better serve a larger user community. They emphasize the simplicity of the new OS in C with regards to variety of languages that can be handled and command line shell.

Problem to Solve: The goal of the authors was to develop an abstracted file system and a variation on the command line interface for an OS written in a language other than assembly such that it was simple to write, modify and maintain the system.

Contributions: First of all the authors demonstrate that it was possible to create an OS in an language other an assembly language, namely C. It took a relatively short time to write (two man years), supported numerous languages, and lead to the portability of the operating system which increased reusability, efficiency, and the user community. Secondly, the authors create a fairly elaborate file system for implementation within the UNIX system, which was important because of the growing user community. Now users had their own directories and the privileges to maintain subdirectories within those directories with protection mechanisms in place to help ensure programs could only change certain files. This file system also introduced the notion of i-nodes, i-numbers, and i-lists, which allowed files to be named one thing but pointed to in memory by an integer number. This integer number could then be reference to create symbolic links, and reference all metadata and data for the file such that a user could easily manipulate the file.

Flaws: One of the largest flaws in the paper is the lack of evaluation behind the work presented. There is no supporting evidence as to why this particular file system design was chosen and if there were a maximum number of directories/users the tree structure could support. The authors also don’t necessarily explain the importance of the command line shell they describe. Many general commands are explained, but nothing regarding how this is an improvement or alternative to shells which already existed.

Advantages of Proposed OS: First, the file system allowed users to have their own directories and have control over those directories, and it allowed them to symbolically link to other files they were interested in. The file system structure also abstracted out I/O devices into “special files” creating the sense that files on these devices could be interrupted/used just as any files on a hard disk were. Also, with the block structure data is store in, the system is able to read a large number of bytes in very few read accesses leading to a faster system response time and improved performance. Secondly, the integration of the command-line shell gives users the power to run several processes at once through the fork operation and output results to files in a simple way.

Disadvantages: Although the file system had many advantages, the introduction of the i-node also introduced wasted space (when files are small) because of the static construction of 13 device addresses and blocks of 512 bytes.

Summary
In this paper, Ritchie and Thompson talk about the fourth version of the Unix operating system. They introduce various features such as an hierarchical file system, file-based device i/o, a simple user-interface (shell) with powerful tools such as filters/asynchronous jobs etc.

Problem
Though not explicitly stated, the problems that Unix seems to focus on are
1. Portability - OS's at that time didn't seem to work well with all devices and couldn't incorporate new i/o devices easily.
2. Usability - For any programmer to use/understand/re-use an OS at that time was very difficult.

Contributions
1. The entire OS was written in C, and was the first of its kind, which resulted in better understanding and more contributions to the UNIX system.
2. It had a hierarchical file system, where the structure of the files was controlled by the applications. It also had some novel features like hard links, mounted filesytems and files for device io. This simplified the design for programmers a lot as writing/reading from any device was the same.
3. The filesystem implementation uses an i-list for files that makes consistency checks simpler. Also it uses lazy writes and pre-fetching to reduce disc writes and latency.
4. Files, devices, processes use similar descriptors for read and write which makes using this system a lot easier. As a result adding new devices was also simpler.

Flaws
One of the flaws in the design is the inability to handle io which can’t be buffered such as when mouse was introduced.
It also doesn't seem to handle quota issues with hard links well. For e.g. if you share the quota with different people and they delete their hard links, you might exceed your quota without having any idea what caused it.
They have also cut down on features to maintain simplicity of code. For e.g., it provides no locking mechanism for files just because they don’t use any shared database system. Although this is more of a general Unix philosophy flaw (or feature)
There are no comparisons with any of the existing systems or for any of the features such as prefetching/block io etc.

OS Design
Easier
- to use/modify the system as it’s entirely in C
- to use their device io mechanism as it is similar to file io and uniform across devices.
- to perform complex operation because of pipes/filters along with simple modular tools.
Difficult
- to handle file access where they might be shared.
- to handle system calls, as they might fail if there is another system interrupt. Programmers need to handle these cases gracefully.

Summary
The paper discusses various implementation and usage details of Unix as well as several of the considerations involved in the design.

Problem
The authors insist that while several considerations were involved in the design, considerations in making a “hospitable environment” that may not have been previously considered in quite the depth they are in this system, there was no predefined, limiting, objective.

Proposed Organization
The system is presented as an interactive time-sharing system designed so as to be simple, efficient, portable, and easily modifiable. In particular, I/O devices are treated in the same way as files so as to make usage of files and devices uniform and interchangeable. To such ends, a file system is implemented with an access control scheme, and a small number of I/O calls are implemented for both random and sequential I/O. A call is outlined in which a new process may come into existence, and a method is provided for communication between processes (sharing a common ancestor). Methods for execution, process synchronization, and termination are introduced. Additionally, the shell is introduced which allows the user to easily communicate with the system. The system makes certain tasks easier such as interchanging devices and files and maintenance of the system. The system may make difficult communication with certain devices; although it may not have been the case then for all I know, it seems that certain devices are not easily amenable to treatment as a file.

Contributions
That Unix is programmed in C, being one of the first operating systems written in a higher level language, allows for easier portability as well as a system that is easier to understand and modify. A number of applications are provided, including the C compiler, so given source code, portions of the system may be modified and replaced on-line. This makes the system perhaps more easily adaptable to new ideas than most previous systems. The system was designed with an emphasis on simplicity and efficiency, especially in implementation.

Flaws (with regards to the proposed organization as well as the paper)
The question can be raised as to whether the provided framework really is as “simple” as it claims to be in certain cases. Indeed, ease of use may be defined with regards to various aspects, and in the Gabriel paper, ways are pointed out in which Unix does not provide the simplest or the “right” interface to programmers, even though the methods used by Unix may have an easier or more portable implementation. One may also question whether “missing” but known-about features, such as file locking, ought not to have been left out. With regards to the form of the paper, it is a bit dull and, of actual importance, a more extensive quantitative analysis of the extent to which the system met the authors’ considerations would have been appreciated.

Summary :
Paper talks about Implementation of Unix File System and User command Interface called Shell. Paper introduce to unique feature of UNIX File System like Devices as Special files , Removable File System (Mount) and 10 bit based Access Control Schema. Later paper talk about Shell features like filters,Pipes and Multitasking.

Work Summary/Contribution :
1. This is the one of first Operating System written in the high level language C as opposed to assembly language . The migration from assembly language to the higher-level language C resulted in much more portable software, requiring only a relatively small amount of machine-dependent code to be replaced when porting Unix to other computing platforms.
2. Unix makes command interpreter a user-level program, with additional commands provided as separate programs. New commands could be added without changing the shell itself. Shell can be modified/developed easily for user need.
3. Buffering mechanism in File System reduce the number of I/O operation to access a file . using this mechanism file block will not be written to device every time it is modified . If program need to access updated file block then buffered block will be delivered. This buffering mechanism is transparent to user .
4.Special File feature of UNIX file system abstract all storage device. program need not worry which device it is accessing . same read and write call can be used for all devices. Device dependent implementation has been implemented in the OS itself.
5. Removable File System (Mount ) makes UNIX file system scalable . different device with different file system can be mounted on Unix file system.
6. '3 level Data block' implementation let Unix file system handle file size upto 1 GB and maintain the i-node size very reasonable .
7 . At some place this paper do exhibit 'new jersy approach or worst-is-better' in UNIX implementation . for example Rule 'Identical treatment of files on different device '* is constrained by not allowing link between different file system to keep the implementation simple .

Flaws:
1. No read/Write lock for files . so this file system will not be able to handle case in which lot of processes might access same files .
2. Author do raise question about Quota management in case of link but doesn't explain how this is handled in UNIX.
3. Author do raise concern about dynamic device Driver loading or Loading all device driver at beginning. But then doesn't explain which approach is followed in UNIX .

Summary
“The UNIX Time-Sharing System” provides a description of the UNIX OS and is aimed at giving an overview of the system’s features for possible users.

Problem
Computer systems were generally underdeveloped in terms of being interactive and easily used by a number of users. Large systems were generally run in a batch mode which, due to the delay in feedback, made interaction with the system tedious and unpleasant. To combat this, Ritchie and Thompson describe an operating system that is constructed relatively cheaply and provides a command interface that allows users to access a file system and other I/O devices and to run programs.

Contributions
• As was self-proclaimed in the paper, Unix’s success really was bringing together a variety of “fertile ideas” and “exploiting” their potential in order to present a system which contained sufficient tools of sufficient quality to be adopted.
• Developing a system that was “easiest” (with a tradeoff between being easy to use and easy to develop). For example, by writing the system in C, the OS became easier to port and thus could spread more easily.

Flaws
• Allowing implementation simplicity to sometimes come before interface simplicity, correctness, consistency, or completeness. Granted, this is also part of the reason UNIX became used so widely (implementing in C instead of assembly made porting easier).

Organization
UNIX has an interactive shell in which the user may enter commands and execute them (whereby the shell launches the command as a process). The shell has a variety of features that allow the user to manipulate programs and to pipe data from program to program or from or to a file. Additionally, the shell facilitates access to a file system that can store and retrieve data from storage and also access a variety of devices.

Concentrating not only on the overall design of the system but also on the implementation allowed for a manageable implementation that in turn could be more easily understood and ported than other operating systems. However, this was a trade off; to ease implementation, some sacrifices were made, such as treating all files identically except for files on different devices, which were treated differently “so as to avoid the elaborate bookkeeping” that would otherwise be needed. By making tradeoffs such as this, the system became harder to use just so that it could be more easily written.

Introduction:
This paper introduces the philosophy and design behind, and implementation of,
the UNIX operating system. The paper particularly emphasizes the file system
design and the shell design.

What were they trying to solve: At the end of the paper, the authors
mention that the UNIX system succeeded because it had no pre-set goals. The
authors took ideas and approaches from various sources, and created a usable
,portable, versatile operating system. Ease of development and easy
programmability seem to be the primary driving force behind their decisions.

Contributions:
First major OS to be ported to multiple hardware systems.
Everything-is-a-file: This simple but powerful abstraction simplified
how various different devices could be accessed through the same interface,
and also to incorporate features like pipes without any special means.
Hierarchical file systems, with different parts of the hierarchy not
necessarily on the same device. Dynamic updation of the file tree via
mount/unmount.
One-file-many-paths: Separating the actual data on the disk with the
logical file entity, thus making links possible.
Separation of file data and metadata (stored as i-nodes).
The shell is just another program, which can be replaced by any other
program.
One command does one thing: The user can put together a sequence of
commands to achieve a complex task, since the shell provides pipes and
redirection operators.
Transparent usage of pipes/redirection makes writing of tools much
simpler, because the program doesn't ever know about them.

Flaws:
Most of the "flaws" in the paper are of those of approach. As the other
paper says, UNIX follows the "keep implementation simple" principle,
at the cost of making the usage of the system more complex. For example,
Unix provides no user-level file locking and allows multiple simultaneous
writers. The authors purposefully chose to ignore the practically rare
case of jumbled writes. Similarly more complex IPC mechanisms like
semaphores were not implemented for simplicity's sake.

OS Organization:
The OS is organized as a collection to small tools, with a user-changeable
shell providing features to integrate the tools to do more complex operations.
Advantages:
Each tool does one job, and doesn't know about the other process.
Disadvantages:
Some part of the complexity of combining different tools in the desired way
to get the result falls on the user.

Summary:
This paper presents the UNIX 4 multi-user operating system with a heirarchical file system and user interface. Notable features of this system are its portability (C language), simpler and uniform file system abstractions for files, devices and even IPC; and its ability to initiate asynchronous processes (write system calls).

Problem:
This paper does not focus on solving a single problem, rather presents a full system UNIX 4, which was shown to support 125 users with a filesystem comprising of 1630 directories, a lot more files and devices. The following are the major contributions/features of this system -

Contributions:
- FS abstractions for ordinary files, directories, devices and removable file systems.
- Simpler and uniform system call interfaces for all FS abstractions.
- Pipes and text editors such as roff \cite{wikipedia:unix}.
- Better UI with the implementation of shell (not novel, MULTICS had it earlier).
- Writing the whole system in C, and not assembly.

Flaws:
- Each inode for the proposed FS does a lot of bookeeping with different bits, like user and group-id, protection bits, etc. The overhead (~1%) is negligible for a normal heavy-tailed file size distribution. But for a hypothetical workload with only very small files, bookeeping overheads (metadata) may be large enough.
- Limit on the size of file ~ O(1GBytes), though files bigger than this were neither envisioned nor possible (due to disk constraints) at that time.
- With the advent of larger disk sizes, the Unix FS faced thrashing due to fragmentation. BSD proposed FFS to overcome this by localizing associated data blocks.

What it makes easier?
- The whole system was written in C, replacing assembly, thereby increasing portability.
- Functional improvements like multi-programming and the ability to share re-entrant code among several programs.
- Simple system call interfaces and abstractions for both file IO and device IO, though ideas for shell and other forms of system calls for IO have been borrowed from MULTICS.

What it makes harder?
- Because of uniform system call interface for all files and devices, device-dependent considerations have to be incorporated into the OS itself. Otherwise, dynamic loading and linking
could prove to a costly option in terms of overhead.

D. Ritchie and K. Thompson present UNIX, a portable multi-user operating system. They describe the basic design of the operating system, focusing on process management, the file system and the user interface.

An important aspect of the system design --although not a contribution of the paper per se-- is that the system is written in C and not in assembly language. This allows for code that is easier to read, faster to write and portable between different machines. A contribution of UNIX is the powerful file abstraction: every I/O device is represented by a file. Porting applications to use new devices is therefore a simple matter of pointing the application to the correct virtual file, as the API remains the same. Another contribution of UNIX is the shell redirection features which allow to combine small and simple programs into powerful workflows. Finally, the user interaction is extremely simple: each shell command spawns a new process (synchronously or asynchronously) and processes can be interrupted and restarted at any point in time, if applications carefully implement interrupt handling.

Some flaws are introduced by the simplicity of the design: Resources are underutilized as a result of virtual files, for which irrelevant bookkeeping data must be kept (such as size and modification date). Also, the user interaction involves creating and destroying processes all the time. Finally, in hindsight, the security model could have been better, offering alternatives between the ultimate power of the superuser and the protected environment of a single user.

The "every device is a file" abstraction makes it trivial for applications to talk to new devices. However not all devices can have meaningful open/read/write/seek/close operations. Retaining this abstraction even for devices that can't fit well has resulted in the explosion of custom parameters in ioctl() calls in modern Unix variants.