DOCSLIB.ORG

Introduction to Operating System Prepared By

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

MCA Part II Paper-XIII Topic: Introduction to Operating System Prepared by: Dr. Kiran Pandey (School of Computer Science) Email-id: [email protected] INTRODUCTION An Operating System (OS) is an interface between a computer user and computer hardware. An operating system is a software which performs all the basic tasks like file management, memory management, process management, handling input and output, and controlling peripheral devices such as disk drives and printers. The purpose of an operating system is to provide an environment in which a user may execute the programs. Operating Systems are viewed as resource managers. The main resource is the computer hardware in the form of processors, storage, input/output devices, communication devices, and data. Some of the operating system functions are: implementing the user interface, sharing hardware among users, allowing users to share data among themselves, preventing users from interfering with one another, scheduling resources among users, facilitating input/output, recovering from errors, accounting for resource usage, facilitating parallel operations, organising data for secure and rapid access, and handling network communications. Operating system Concepts An operating system is a program that acts as an interface between the user and the computer hardware and controls the execution of all kinds of programs. Figure 1: Components of a computer system In a computer system as shown in figure 1, we find four main components: the hardware, the operating system, the application software and the users. In a computer system the hardware provides the basic computing resources. The applications programs define the way in which these resources are used to solve the computing problems of the users. The operating system controls and coordinates the use of the hardware among the various systems programs and application programs for the various users. We can view an operating system as a resource allocator. A computer system has many resources (hardware and software) that may be required to solve a problem: CPU time, memory space, files storage space, input/output devices etc. The operating system acts as the manager of these resources and allocates them to specific programs and users as necessary for their tasks. Since there may be many, possibly conflicting, requests for resources, the operating system must decide which requests are allocated resources to operate the computer system fairly and efficiently. An operating system is a control program. This program controls the execution of user programs to prevent errors and improper use of the computer. Operating systems exist because: they are a reasonable way to solve the problem of creating a usable computing system. The fundamental goal of a computer system is to execute user programs and solve user problems. While there is no universally agreed upon definition of the concept of an operating system, the following is a reasonable starting point: A computer’s operating system is a group of programs designed to serve two basic purposes: ❖ To control the allocation and use of the computing system’s resources among the various users and tasks, and ❖ To provide an interface between the computer hardware and the programmer that simplifies and makes feasible the creation, coding, debugging, and maintenance of application programs. An effective operating system should accomplish the following functions: ❖ Should act as a command interpreter by providing a user friendly environment. ❖ Should facilitate communication with other users. ❖ Facilitate the directory/file creation along with the security option. ❖ Provide routines that handle the intricate details of I/O programming. ❖ Provide access to compilers to translate programs from high-level languages to machine language ❖ Provide a loader program to move the compiled program code to the computer’s memory for execution. ❖ Assure that when there are several active processes in the computer, each will get fair and non-interfering access to the central processing unit for execution. ❖ Take care of storage and device allocation. ❖ Provide for long term storage of user information in the form of files. ❖ Permit system resources to be shared among users when appropriate, and be protected from unauthorized or mischievous intervention as necessary. Though systems programs such as editors and translators and the various utility programs (such as sort and file transfer program) are not usually considered part of the operating system, the operating system is responsible for providing access to these system resources. TYPES OF OPERATING SYSTEM Batch Operating System Batch processing is a technique in which an Operating System collects the programs and data together in a batch before processing starts. An operating system does the following activities related to batch processing − The OS defines a job which has predefined sequence of commands, programs and data as a single unit. Batch processing is the execution of a series of jobs in a program on a computer without manual intervention (non-interactive). Strictly speaking, it is a processing mode: the execution of a series of programs each on a set or "batch" of inputs, rather than a single input (which would instead be a custom job). The users of a batch operating system do not interact with the computer directly. Each user prepares his job on an off-line device like punch cards and submits it to the computer operator. To speed up processing, jobs with similar needs are batched together and run as a group. The problems with Batch Systems are as follows − • Lack of interaction between the user and the job. • CPU is often idle, because the speed of the mechanical I/O devices is slower than the CPU. • Difficult to provide the desired priority. An example of batch processing is the way that credit card companies process billing. The customer does not receive a bill for each separate credit card purchase but one monthly bill for all of that month s purchases. Time Sharing Operating System Time sharing operating system allows many users to share the computer resources simultaneously. In other words, time sharing refers to the allocation of computer resources in time slots to several programs simultaneously. For example a mainframe computer that has many users logged on to it. Each user uses the resources of the mainframe -i.e. memory, CPU etc. The users feel that they are exclusive user of the CPU, even though this is not possible with one CPU i.e. shared among different users. The time sharing systems were developed to provide an interactive use of the computer system. A time shared system uses CPU scheduling and multiprogramming to provide each user with a small portion of a time-shared computer. It allows many users to share the computer resources simultaneously. As the system switches rapidly from one user to the other, a short time slot is given to each user for their executions. The time sharing system provides the direct access to a large number of users where CPU time is divided among all the users on scheduled basis. The OS allocates a set of time to each user. When this time is expired, it passes control to the next user on the system. The time allowed is extremely small and the users are given the impression that they each have their own CPU and they are the sole owner of the CPU. This short period of time during that a user gets attention of the CPU; is known as a time slice or a quantum. The Multics & UNIX operating systems are time sharing Operating Systems. Advantages of Timesharing operating systems are as follows − • Provides the advantage of quick response. • Avoids duplication of software. • Reduces CPU idle time. Disadvantages of Time-sharing operating systems are as follows − • Problem of reliability. • Question of security and integrity of user programs and data. • Problem of data communication. Real Time Operating System A real-time system is defined as a data processing system in which the time interval required to process and respond to inputs is so small that it controls the environment. The time taken by the system to respond to an input and display of required updated information is termed as the response time. So in this method, the response time is very less as compared to online processing. Real-time systems are used when there are rigid time requirements on the operation of a processor or the flow of data and real-time systems can be used as a control device in a dedicated application. A real-time operating system must have well-defined, fixed time constraints, otherwise the system will fail. For example, scientific experiments, medical imaging systems, industrial control systems, weapon systems, robots, air traffic control systems, etc. There are two types of real-time operating systems. Hard real-time systems Hard real-time systems guarantee that critical tasks complete on time. In hard real- time systems, secondary storage is limited or missing and the data is stored in ROM. In these systems, virtual memory is almost never found. Soft real-time systems Soft real-time systems are less restrictive. A critical real-time task gets priority over other tasks and retains the priority until it completes. Soft real-time systems have limited utility than hard real-time systems. For example, multimedia, virtual reality, Advanced Scientific Projects like undersea exploration and planetary rovers, etc. Multiprogramming Operating System In a multiprogramming system there are one or more programs loaded in main memory which are ready to execute. Only one program at a time is able to get the CPU for executing its instructions (i.e., there is at most one process running on the system) while all the others are waiting their turn. The main idea of multiprogramming is to maximize the use of CPU time. Indeed, suppose the currently running process is performing an I/O task (which, by definition, does not need the CPU to be accomplished).
Recommended publications
  • OES 2 SP3: Novell CIFS for Linux Administration Guide 9.2.1 Mapping Drives from a Windows 2000 Or XP Client

    OES 2 SP3: Novell CIFS for Linux Administration Guide 9.2.1 Mapping Drives from a Windows 2000 Or XP Client

    www.novell.com/documentation Novell CIFS Administration Guide Open Enterprise Server 2 SP3 May 03, 2013 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Service Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software.
  • Shared Resource Matrix Methodology: an Approach to Identifying Storage and Timing Channels

    Shared Resource Matrix Methodology: an Approach to Identifying Storage and Timing Channels

    Shared Resource Matrix Methodology: An Approach to Identifying Storage and Timing Channels RICHARD A. KEMMERER University of California, Santa Barbara Recognizing and dealing with storage and timing channels when performing the security analysis of a computer system is an elusive task. Methods for discovering and dealing with these channels have mostly been informal, and formal methods have been restricted to a particular specification language. A methodology for discovering storage and timing channels that can be used through all phases of the software life cycle to increase confidence that all channels have been identified is presented. The methodology is presented and applied to an example system having three different descriptions: English, formal specification, and high-order language implementation. Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: General--se- curity and protection; D.4.6 ]Operating Systems]: Security and Protection--information flow controls General Terms: Security Additional Key Words and Phrases: Protection, confinement, flow analysis, covert channels, storage channels, timing channels, validation 1. INTRODUCTION When performing a security analysis of a system, both overt and covert channels of the system must be considered. Overt channels use the system's protected data objects to transfer information. That is, one subject writes into a data object and another subject reads from the object. Subjects in this context are not only active users, but are also processes and procedures acting on behalf of the user. The channels, such as buffers, files, and I/O devices, are overt because the entity used to hold the information is a data object; that is, it is an object that is normally viewed as a data container.
  • Shared Resource

    Shared Resource

    Shared resource In computing, a shared resource, or network share, is a computer resource made available from one host to other hosts on a computer network.[1][2] It is a device or piece of information on a computer that can be remotely accessed from another computer transparently as if it were a resource in the local machine. Network sharing is made possible by inter-process communication over the network.[2][3] Some examples of shareable resources are computer programs, data, storage devices, and printers. E.g. shared file access (also known as disk sharing and folder sharing), shared printer access, shared scanner access, etc. The shared resource is called a shared disk, shared folder or shared document The term file sharing traditionally means shared file access, especially in the context of operating systems and LAN and Intranet services, for example in Microsoft Windows documentation.[4] Though, as BitTorrent and similar applications became available in the early 2000s, the term file sharing increasingly has become associated with peer-to-peer file sharing over the Internet. Contents Common file systems and protocols Naming convention and mapping Security issues Workgroup topology or centralized server Comparison to file transfer Comparison to file synchronization See also References Common file systems and protocols Shared file and printer access require an operating system on the client that supports access to resources on a server, an operating system on the server that supports access to its resources from a client, and an application layer (in the four or five layer TCP/IP reference model) file sharing protocol and transport layer protocol to provide that shared access.
  • Resource Management in Multimedia Networked Systems

    Resource Management in Multimedia Networked Systems

    University of Pennsylvania ScholarlyCommons Technical Reports (CIS) Department of Computer & Information Science May 1994 Resource Management in Multimedia Networked Systems Klara Nahrstedt University of Pennsylvania Ralf Steinmetz University of Pennsylvania Follow this and additional works at: https://repository.upenn.edu/cis_reports Recommended Citation Klara Nahrstedt and Ralf Steinmetz, "Resource Management in Multimedia Networked Systems ", . May 1994. University of Pennsylvania Department of Computer and Information Science Technical Report No. MS-CIS-94-29. This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_reports/331 For more information, please contact [email protected]. Resource Management in Multimedia Networked Systems Abstract Error-free multimedia data processing and communication includes providing guaranteed services such as the colloquial telephone. A set of problems have to be solved and handled in the control-management level of the host and underlying network architectures. We discuss in this paper 'resource management' at the host and network level, and their cooperation to achieve global guaranteed transmission and presentation services, which means end-to-end guarantees. The emphasize is on 'network resources' (e.g., bandwidth, buffer space) and 'host resources' (e.g., CPU processing time) which need to be controlled in order to satisfy the Quality of Service (QoS) requirements set by the users of the multimedia networked system. The control of the specified esourr ces involves three actions: (1) properly allocate resources (end-to-end) during the multimedia call establishment, so that traffic can flow according to the QoS specification; (2) control resource allocation during the multimedia transmission; (3) adapt to changes when degradation of system components occurs.
  • Novell Cluster Services,. for Linux. and Netware

    Novell Cluster Services,. for Linux. and Netware

    Novell Cluster Services,. for Linux. and NetWare. ROB BASTIAANSEN SANDER VAN VUGT Novell PRESS. Novell. Published by Pearson Education, Inc. 800 East 96th Street, Indianapolis, Indiana 46240 USA Table of Contents Introduction 1 CHAPTER 1: Introduction to Clustering and High Availability 5 Novell Cluster Services Defined 5 Shared Disk Access 6 Secondary IP Addresses 7 Clustering Terminology 8 High-Availability Solutions Overview 12 Novell Cluster Services 12 Business Continuity Clustering 13 PolyServe Matrix Server 15 Heartbeat Subsystem for High-Availability Linux 16 When Not to Cluster Applications 16 Availability Defined 18 High Availability Defined 18 Calculating Average Downtime 21 Avoiding Downtime 22 Hardware 22 Environment 23 Software 23 Procedures 24 Novell Cluster Services Requirements 24 Hardware Requirements 24 Software Requirements 26 CHAPTER 2: Examining Novell Cluster Services Architecture 27 Novell Cluster Services Objects and Modules 27 Cluster eDirectory Objects 28 Cluster Modules 31 IH Novell Cluster Services for Linux and NetWare Heartbeats, Epoch Numbers, and the Split Brain Detector 35 Removing a Failing Slave Node 36 Removing a Failed Master Node 37 Summary 37 CHAPTER 3: Clustering Design 39 Cluster Design Guidelines 39 How Many Nodes to Choose 39 Using a Heartbeat LAN or Not 40 Use NIC Teaming 41 Choosing Storage Methods 42 Mirror the Split Brain Detector Partition 48 Selecting Applications to Run in a Cluster 48 eDirectory Cluster Guidelines 50 Creating a Failover Matrix 52 Application-Specific Design Guidelines
  • Novell® Platespin® Recon 3.7.4 User Guide 5.6.4 Printing and Exporting Reports

    Novell® Platespin® Recon 3.7.4 User Guide 5.6.4 Printing and Exporting Reports

    www.novell.com/documentation User Guide Novell® PlateSpin® Recon 3.7.4 September 2012 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software.
  • Introduction to MS-DOS

    Introduction to MS-DOS

    1.Introduction to MS-DOS : MS-DOS (Microsoft Disk Operating System) was the Microsoft-marketed version of the first widely-installed operating system in personal computers. It was essentially the same operating system that (Bill Gates's) young company developed for IBM as Personal Computer - Disk Operating System in 1981. Most users of either DOS system simply referred to their system as Disk Operating System. Like PC-DOS, MS-DOS was (and still is) a non-graphical line-oriented command- driven operating system, with a relatively simple interface but not overly "friendly" user interface. Its prompt to enter a command looks like this: C:\> MS-DOS does not care about anything called an icon, wallpaper or screen saver. Rather than being considered as a Graphical User Interface (GUI) MS-DOS is what is known as a command-line interface. You type commands on what is called the command line. MS-DOS is a single-user, single-tasking computer operating system. In spite of its very small size and relative simplicity, it is one of the most successful operating systems that has been developed to date. In DOS, a file name consists of eight character followed by a 3 character file extension. The size of a file is restricted to a 4 byte file descriptor, which limits a file’s maximum size to approximately 4 billion characters. The first release of DOS could not read or write to disk drives so users could only read and write to a floppy disc. DOS was not a state of the art operating system, even for its time.
  • Chapter 1. Origins of Mac OS X

    Chapter 1. Origins of Mac OS X

    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
  • Characterizing Peer-Level Performance of Bittorrent

    Characterizing Peer-Level Performance of Bittorrent

    Characterizing Peer-level Performance of BitTorrent DRP Report Amir H. Rasti ABSTRACT 1. INTRODUCTION BitTorrent is one of the most popular Peer-to-Peer During the past few years, peer-to-peer appli- (P2P) content distribution applications over the cations have become very popular on the In- Internet that significantly contributes in network ternet. BitTorrent in one of the most popu- traffic. lar peer-to-peer applications providing scalable peer-to-peer content distribution over the In- In BitTorrent, a file is divided into segments ternet. Some recent studies [8] have shown that and participating peers contribute their outgoing BitTorrent is accountable for approximately bandwidth by providing their available segments 35% of the Internet traffic. BitTorrent is a to other peers while obtaining their missing peers scalable peer-to-peer content distribution sys- from others. Characterization of BitTorrent is use- tem that enables one-to-many distribution of ful in determining its performance bottlenecks as large files without requiring a large access link well as its impact on the network. bandwidth at the source. Similar to other peer- In this study, we try to address the following two to-peer systems, it uses resources of participat- key questions through measurement: (i) What are ing peers to increase the capacity of the system. the main factors that affect observed performance The main shared resource in BitTorrent is the by individual peers in BitTorrent?, and (ii) What up-link bandwidth of individual peers. The file are the contributions of these factors on the per- being distributed is divided into a large number formance of individual peers? To address these of segments.
  • Server I/O Networks Past, Present, and Future Renato John Recio Chief Architect, IBM Eserver I/O IBM Systems Group, Austin, Texas Recio@Us.Ibm.Com

    Server I/O Networks Past, Present, and Future Renato John Recio Chief Architect, IBM Eserver I/O IBM Systems Group, Austin, Texas [email protected]

    Server I/O Networks Past, Present, and Future Renato John Recio Chief Architect, IBM eServer I/O IBM Systems Group, Austin, Texas [email protected] Abstract • Low latency - the total time required to transfer the first bit of a message from the local application to the remote appli- Enterprise and technical customers place a diverse set of cation, including the transit times spent in intermediate requirements on server I/O networks. In the past, no single switches and I/O adapters. network type has been able to satisfy all of these requirements. As • High throughput - the number of small block transactions a result several fabric types evolved and several interconnects performed per second. The size and rate of small block I/O emerged to satisfy a subset of the requirements. Recently several depends on the workload and fabric type. A first level technologies have emerged that enable a single interconnect to be approximation of the I/O block size and I/O throughput rates required for various I/O workloads can be found in used as more than one fabric type. This paper will describe the “I/O Workload Characteristics of Modern Servers” [4]. requirements customers place on server I/O networks; the various • High bandwidth - the number of bytes per second sup- fabric types and interconnects that have been used to satisfy those ported by the network. Typically, used to gauge perfor- requirements; the technologies that are enabling network mance for large block data transfers. Peek bandwidth convergence; and how these new technologies are being deployed describes the bandwidth provided by a given link; whereas on various network families.
  • NFS Gateway for Netware 6 Administration Guide October 22, 2003

    NFS Gateway for Netware 6 Administration Guide October 22, 2003

    Novell Confidential Manual (99a) 11 September 2003 Novell * NFS Gateway for NetWare® 6 www.novell.com ADMINISTRATION GUIDE October 22, 2003 Novell Confidential Manual (99a) 11 September 2003 Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. You may not export or re-export this product in violation of any applicable laws or regulations including, without limitation, U.S. export regulations or the laws of the country in which you reside. Copyright © 2003 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher. U.S. Patent No. 5,157,663; 5,349,642; 5,455,932; 5,553,139; 5,553,143; 5,572,528; 5,594,863; 5,608,903;5,633,931; 5,652,859; 5,671,414;
  • Microsoft Plays Hardball: Use of Exclusionary Pricing and Technical

    Microsoft Plays Hardball: Use of Exclusionary Pricing and Technical

    Antitrust Bulletin, XL:2, Summer 1995, 265-315 MICROSOFT PLAYS HARDBALL: The Use of Exclusionary Pricing and Technical Incompatibility to Maintain Monopoly Power in Markets for Operating System Software† by KENNETH C. BASEMAN* FREDERICK R. WARREN-BOULTON* and GLENN A. WOROCH** May 1995 ___________________ * Principals, MiCRA: Microeconomic Consulting and Research Associates, Inc., Washington, DC. ** University of California, Berkeley. † Forthcoming, Antitrust Bulletin, June 1995. We would like to express our appreciation for helpful comments and other assistance to Sturge Sobin, Linnet Harlan, Paul Dennis and the participants at the Columbia Business School's Institute for Tele-Information's Seminar on Sustaining Competition in Network Industries through Regulating and Pricing Access, especially Janusz Ordover and Bobby Willig. TABLE OF CONTENTS I. INTRODUCTION AND SUMMARY ................................... 1 II. BACKGROUND .................................................... 3 A. THE MARKET FOR PERSONAL COMPUTER OPERATING SYSTEMS ............................................................ 3 TABLE: NEW SHIPMENTS OF PERSONAL COMPUTER OPERATING SYSTEMS .............................................. 8 B. MICROSOFT'S PRACTICES ..................................... 9 III. FIRST-DEGREE PRICE DISCRIMINATION vs. INEFFICIENT SUBSTITUTION ................................................... 15 A. FIRST-DEGREE PRICE DISCRIMINATION ........................ 16 B. INEFFICIENT SUBSTITUTION ................................. 20 IV. ANTIFRAUD AND ANTIPIRACY