Web site: (not active)
Origin: USA
Category: Workstation
Desktop environment: CLI
Architecture: Sun, DEC, MicroVAX
Based on: Thoth
Wikipedia: V (operating system)
Media: Install
The last version | Released: 1988
V (or V-System) – a microkernel distributed operating system developed by faculty and students in the Distributed Systems Group (DSG) at Stanford University from 1981 to 1988, led by Professors David Cheriton and Keith A. Lantz. The V distributed System was developed at Stanford University as part of a research project to explore issues in distributed systems.
The original DSG work focused on the V distributed system, which was developed in the 1981 to 1988 time frame (see CACM, March 1988 for an overview article). That work led to network protocol design including IP multicast ( RFC 1112), VMTP ( RFC 1045), Sirpent (SIGCOMM’89), and network interfacing VMP NAB (SIGCOMM’88). The work on V also led to computer architecture work on multiprocessor memory systems that are well-structured for operating systems. This work include the VMP (ISCA’86 and 88) and more recently the ParaDiGM multiprocessor (IEEE Computer Feb.’91 – also available on gregorio.Stanford.EDU).
The V distributed system is an operating system designed for a cluster of computer workstations connected by a high-performance network. The system is structured as a relatively small “distributed” kernel, a set of service modules, various run-time libraries and a set of commands, as shown in Figure 1. The kernel is distributed in that a separate copy of the kernel executes on each participating network node yet the separate copies cooperate to provide a single system abstraction of processes in address spaces communicating using a base set of communication primitives. The existence of multiple machines and network interconnection is largely transparent at the process level. The service modules implement value-added services using the basic access to hardware resources provided by the kernel. For instance, the V file server implements a UNIX-like file system using the raw disk access supported by the kernel. The various run-time libraries implement conventional language or application-to-operating system interfaces such as Pascal I/O and C stdio. Most V applications and commands are written in terms of these conventional interfaces and are oblivious to the distributed nature of the underlying system. In fact, many programs originated in non-distributed systems and were ported with little or no modification the original source was simply linked against the V run-time libraries.
The development of V was motivated by the growing availability and functionality of relatively low-cost high-performance computer workstations and local networks. Our basic hypothesis was that an operating system could be developed that managed a cluster of these workstations and server machines, providing the resource and information sharing facilities of a conventional single-machine system but running on this new, more powerful and more economical hardware base. This hypothesis contrasts with the conventional single mainframe approach to supporting a user community. It also contrasts with the personal computer approach in which the focus is on individual use; the sharing of information and hardware resources between computers may be difficult, if not impossible. The mainframe solution is less extensible, less reliable and less cost effective than appears possible with good use of a workstation cluster. However, the conventional personal computer approach fragments the hardware and software base, wastes hardware resources and makes system management difficult. As an extreme example, an engineering firm might require a simulation package be available to each of its personnel. Each of its personal computers would require the disk space, memory capability and processing power to run the simulation (as well as possibly the license to do so). Yet, the utilization of hardware and software would be much lower than for a conventional timesharing solution, possibly resulting in a higher cost. Moreover, the personal computer solution would be slower for the cases in which the full power of the mainframe would have been available, such as running the simulation at night.