1 Network Operating System (NOS)

A Network operating system provides an environment in which users, who are aware of the multiplicity of machines, can access remote resources by either logging in to the appropriate remote machine or transferring data from the remote machine to their own machines.

1.1 Remote Login

An important function of a network operating system is to allow users to log in remotely. The Internet provides the telnet facility for this purpose. To illustrate this facility, lets suppose that a user at Westminster College wishes to compute on "cs.yale.edu," a computer that is located at Yale University. To do so, the user must have a valid account on that machine. To log in remotely, the user issues the command

telnet cs.yale.edu

This command results in the formation of a socket connection between the local machine at Westminster College and the "cs.yale.edu" computer. After this connection has been established, the networking software creates a transparent, bidirectional link so that all characters entered by the user are sent to a process on "cs.yale.edu" and all the output from that process is sent back to the user. The process on the remote machine asks the user for a login name and a password. Once the correct information has been received, the process acts as a proxy for the user who can compute on the remote machine just as any local user can.

1.2 Peripheral Sharing Service

Peripherals connected to one computer are often shared by other computers, by the use of peripheral sharing services. These services go by many names, such as remote device access, printer sharing, shared disks and so on. A computer having a peripheral device makes it available by exporting it. Other computers can connect to the exported peripheral. After a connection is made, to a user on the machine connected to a shared peripheral, that peripheral appears to be local (that is, connected to the users machine). The sharing service is the most basic service provided by a network operating system.

1.3 Remote File Transfer Service

The most common service that a network operating system provides is file service. File services allow user of a set of computers to access files and other persistent storage object from any computer connected to the network. The files are stored in one or more machines called the file server(s). The machines that use these files, often called workstations have transparent access to these files. Note only is the file service a common service, but it is also the most important service in the network operating system. Consequently, it is the most heavily studied and optimized service.

The Internet provides a mechanism for such a transfer with the file transfer protocol (FTP) program. Suppose that a user on "cs.uvm.edu" wants to copy a Java program Server. java that resides on "cs.yale.edu." The user must first invoke the FTP program by executing ftp cs.yale.edu The program then asks the user for a login name and a password. Once the correct information has been received, the user must connect to the subdirectory where the file Server. java resides and then copy the file by executing get Server. java

1.4 RPC service

A particular mechanism for implementing the services in a network operating system is called RemoteProcedure Calls or RPC. The RPC mechanism is discussed later in the section entitled Mechanisms for Network Operating Systems. The RPC mechanism needs the availability of an RPC server accessible by an RPC client. However, a particular system may contain tens if not hundreds or even thousands of RPC servers. In order to avoid conflicts and divergent communication protocols the network operating system provides support for building and managing and accessing RPC servers. Each RPC service is an application-defined service. However, the operating system also provides an RPC service, which is a meta-service, which allows the application specific RPC services to be used in uniform manner. This service provides several features:

1. Management of unique identifiers (or addresses) for each RPC server.

2. Tools for building client and server stubs for packing and unpacking (also known as marshalling and unmarshalling) of arguments between clients and servers.

3. A per-machine RPC listening service.

2 Distributed Operating System(DOS)

In a distributed operating system, users access remote resources in the same way they access local resources.Data and process migration from one site to another is under the control of the distributed operating system. The processors in a distributed system may vary in size and function. They may include small microprocessors,workstations,minicomputers,and large general-purpose cornputer systems. These processors are referred to by a number of names, such as sites, nodes, computers, machines, and hosts, depending on the context in which they are mentioned. We mainly use site to indicate the location of a machine and host to refer to a specific system at a site. Generally, one host at one site, the server, has a resource that another host at another site, the client (or user), would like to use. A general structure of a distributed system is shown in Figure 1.3.2

Fig. 1.3.2A distributed system

There are four major reasons for building distributed systems: resource sharing, computation speedup, reliability, and communication. In this section, we briefly discuss each of them.

Resource Sharing

If a number of different sites (with different capabilities) are connected to one another, then a user at one site may be able to use the resources available at another. For example, a user at site A may be using a laser printer located at site B. Meanwhile, a user at B may access a file that resides at A.

Computation Speedup

If a particular computation can be partitioned into subcomputations that can run concurrently, then a distributed system allows us to distribute the subcomputations among the various sites; the subcomputations can be run concurrently and thus provide computation speedup.

Reliability

If one site fails in a distributed system, the remammg sites can continue operating, giving the system better reliability. If the system is composed of multiple large autonomous installations (that is, general-purpose computers), the failure of one of them should not affect the rest. If, however, the system is composed of sncall machines, each of which is responsible for some crucial system function (such as tenninal character I/0 or the file system), then a single failure may halt the operation of the whole system. In general, with enough redundancy (in both hardware and data), the system can continue operation, even if some of its sites have failed.

Communication

When several sites are connected to one another by a communication network, users at the various sites have the opportunity to exchange information. At a low level messages, are passed between systems, much as messages are passed between processes in the single-computer message.Given message passing, all the higher-level functionality found in standalone systems can be expanded to encompass the distributed system. Such functions include file transfer, login, mail, and remote procedure calls (RPCs).

3 Real Time Operating Sytsem(RTOS)

A real-time system is a computer system that requires not only that the computing results be "correct" but also that the results be produced within a specified deadline period. Results produced after the deadline has passed-even if correct-may be of no real value. Real-time systems executing on traditional computer hardware are used in a wide range of applications. In addition, many real-time systems are embedded in "specialized devices," such as ordinary home appliances (for example, microwave ovens and dishwashers), consumer digital devices (for exarnple, cameras and MP3 players), and communication devices (for example,cellular telephones and Blackberry handheld devices). They are also present in larger entities, such as automobiles and airplanes. An embedded system is a computing device that is part of a larger system in which the presence of a computing device is often not obvious to the user.

Real-time computing is of two types: hard and soft. A hard real-time system has the most stringent requirements, guaranteeing that critical real-time tasks be completed within their deadlines. Safety-critical systems are typically hard real-time systems. A soft real-time system is less restrictive, simply providing that a critical real-time task will receive priority over other tasks and that it will retain that priority until it completes.

The following characteristics are typical of many real-time systems:

Single purpose

Small size

Inexpensively mass-produced

Specific timing requirements

Main goal of an RTOS scheduler:

 meeting timing constraints e.g. deadlines

 If you have five homework assignments and only one is due in an hour, you work on that one

 Fairness does not help you meet deadlines

Requirements of RTOS

Determinism

 Responsiveness (quoted by vendors)

 Fast process/thread switch

 Fast interrupt response

 User control over OS policies

 Mainly scheduling, many priority levels

 Memory support (especially embedded)

 Reliability

Typical RTOS Task Model

Each task a triplet: (execution time, period, deadline)

 Usually, deadline = period

 Can be initiated any time during the period

Features of RTOS

A variety of peripheral devices, such as graphical displays, CD drives, and DVD drives Protection and security mechanisms Multiple users

4 Mobile OS(MOS)

The operating system operates on a mobile device and is called mobile op-erating system. An overview about different mobile operating systems, that are currently available on the market is shown in Fig. 1.3.4

Fig 1.3.4 MOS Overview

In total it shows up 16 different mobile operation systems,whereof twelve are actual on the market or will be released in an expected time. An exception is the operation system MeeGoo of the companies Nokia and IBM, which future is unknown after Nokia announced that they will use theoperating system Windows Phone for their new devices.

Mobile OS: Android

Android is an open source operating system for mobile devices developed by Google and the Open Handset Alliance. With 22,7% it is the second most used operating system for mobile devices worldwide behind Symbian.

The system architecture consists of :

• A modified Linux Kernel

• open source Libraries coded in C and C++

• The Android Runtime,which considers core libraries that disposals the most core functions of Java. As virtual machine it uses Dalvin, which enables to execute Java applications.

• An Application Framework , which disposals services and libraries coded in Java for the application develop-ment

• The Applications, which operate on it

Fig. 1.3.5 Android OS

Like previously mentioned in the Android system architecture overview, is Android mainly based up on a Linux kernel and Java. This combination brings up some secure features, like efficient shared memory management, preemptive multi-tasking, Unix user identifiers (UIDs) and file permissions with the type safe concept of Java. Every Android application runs in a separate process under a unique UID with distinct permissions, which means that applications can typically not read or write each other’s data or code.

5 Cloud Operating System(COS)

A Cloud is a logical entity composed of managed computing resources deployed in private facilities and interconnected over a public network, such as the Internet. Cloud machines (also called nodes) are comprised of inexpensive, off-the-shelf consumer-grade hardware. Clouds are comprised of a large number of clusters (i.e. sets of nodes contained in a same facility) whose size may range from a few machines to entire datacenters.

We formulate a new metaphor, the Cloud operating system, that may be adequate to support the transition from individual computers as the atomic “computational units” to large-scale, seamless, distributed computer systems. The Cloud OS aims to provide a familiar interface for developing and deploying massively scalable distributed applications on behalf of a large number of users, exploiting the seemingly infinite CPU, storage, and bandwidth provided by the Cloud infrastructure. The features of the Cloud OS aim to be an extension to those of modern operating systems, such as UNIX and its successors: in addition to simple programming abstractions and strong isolation techniques between users and applications, we emphasize the need to provide a much stronger level of integration with network resources.

Cloud OS requirements

a) The Cloud OS must permit autonomous management of its resources on behalf of its users and applications:

Our main purpose is providing an abstraction of the Cloud as a coherent system beyond the individual pieces of hardware from which it is built. The Cloud OS should therefore expose a consistent and unified interface that conceals whenever possible the fact that individual nodes are involved in its operations, and what those low-level operations are.

b) Cloud OS operation must continue despite loss of nodes, entire clusters, and network partitioning:

Conforming to our assumptions, we expect that every system component, including networks, may unexpectedly fail, either temporar-ily or permanently. Guaranteeing continued operation of the Cloud management processes in these conditions involves mechanisms for quickly detecting the failures and enacting appropriate measures.

c) The Cloud must support multiple types of applications, including legacy:

In the assumptions above, we purposefully did not specify a target set of applications that the Cloud is supposed to host. Rather than optimizing the system for a specific mode of operation (e.g. high performance computing, high data availability, high network throughput, etc.), we aim to address the much broader requirements of a general-purpose scenario: applications of every type should ideally coexist and obtain from the system the resources that best match the application requirements.

d) The Cloud OS management system must be decentral-ized, scalable, have little overhead per user and per machine,and be cost effective:

The use of such a soft-state approach takes inspiration from recent peer-to-peer techniques: these systems are capable of withstanding failures and churn at the price of a reasonable amount of network overhead, and provide enough scalability to meet and surpass the magnitudes of today’s datacenters and large-scale testbeds. Architechure Of Cloud OS

Figure 1 represents a logical model of Cloud OS. We define the Cloud object as a set of local OS processes running on an single node, which are wrapped together and assigned locally a random identifier of suitable length to minimize the risk of system-wide ID collisions. A Cloud process (CP) is a collection of Cloud objects that implement the same (usually distributed) application. We refer to the small number of CPs that regulate physical allocation, access control, accounting, and measurements of resources as the Cloud kernel space. Those CPs that do not belong to kernel space pertain to the Cloud user space . User space CPs that are executed directly by users are called User Applications , while Cloud Libraries are CPs typically called upon by Applications and other Libraries. Applications can in-terface with Libraries and kernel CPs over the network through a set of standard interfaces called Cloud System Calls 2 . The assumptions stated above pose very few constraints about the features that the underlying Cloud hardware is expected to provide. Basically, the ability to execute the Cloud kernel processes, together with the availability of appropriate trust credentials, is a sufficient condition for a node to be part of the Cloud 3 . A limited access to Cloud abstractions and interfaces is thus also achievable from machines that belong to administrative domains other than that of the Cloud provider, with possible restrictions due to the extent of the management rights available there. All objects in the Cloud user space expose a Cloud system call handler to catch signals from the Cloud OS, i.e. they can be accessed via a network-based interface for manage-ment purposes. The association between object names and their network address and port is maintained by the process management and virtual machine management kernel CPs, and the resulting information is made available throughout the Cloud via the naming Library. The naming library also keeps track of the link between User Application CPs and the objects they are composed of. The access rights necessary for all management operations are granted and verified by the authentication kernel CP. Measurement kernel CPs are always active in the Cloud and operate in both on-demand and background modes.

6 Multiprocessor Operating System

A computer system in which two or more CPUs share full access to a common RAM called multiprocessor OS.

Key design challenges:

• Correctness of (shared) data structures

• Scalability