DOCSLIB.ORG

Introduction to Operating Systems Abstractions Using Plan 9 from Bell

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction to Operating Systems Abstractions Using Plan 9 from Bell Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs (Draft ߞ 9/18/2006) Francisco J Ballesteros Copyright © 2006 Francisco J Ballesteros Plan 9 is Copyright © 2002 Lucent Technologies Inc. All Rights Reserved. Preface Using effectively the operating system is very important for anyone working with computers. It can be the difference between performing most tasks by hand, and asking the computer to perform them. Traditionally, Operating Systems courses used UNIX to do this. However, today there is no such thing as UNIX. Linux is a huge system, full of inconsistencies, with programs that do multiple tasks and do not perform them well. Linux manual pages just cannot be read. These lecture notes use Plan 9 from Bell Labs to teach a first (practical!) course on operating sys- tems. The system is easy to use for programmers, and is an excellent example of high-quality system design and software development. Studying its code reveals how simplicity can be more effective than contortions made by other systems. The first Operating Systems course at Rey Juan Carlos University is focused on practice. Because in theory, theory is like practice, but in practice it is not. What is important is for you to use the system, and to learn to solve problems. Theory will come later to fill the gaps and try to give more insight about what a system does and how can it be used. The whole text assumes that you have been already exposed to computer, and used at least a com- puter running Windows. This is so common that it makes no sense to drop this assumption. Furthermore, we assume that you already know how to write programs. This is indeed the case for the lecture this text is written for. One last assumption is that you attended a basic computer architecture course, and you know at least basic concepts. There is a quick review appendix in case you need to refresh your memory. Through the text, the boldface font is used when a new concept is introduced. This will help you to make quick reviews and to double check that you know the concepts. All important concepts are listed in the index, at the end of the book. The constant width teletype font is used to refer to machine data, including functions, programs, and symbol names. In many cases, text in constant width font reproduces a session with the system (e.g., typing some commands and showing their output). The text written by the user (and not by the computer) is slightly slanted, but still in constant width. Note the difference with respect to the font used for text written by a program, which is not slanted. Italics are used to emphasize things and to refer to the system manual, like in intro(1). Regarding numeric values, we use the C notation to represent hexadecimal and octal numeric bases. Unlike in most other textbooks for operating systems courses, bibliographic references are kept to the bare minimum. We cite a particular text when we think that it may be worth reading to continue learning about something said in this book. So, do not quickly dismiss references. We encourage you to read them, to learn more. There are not so many ones. If you want to get a thorough set of references for something discussed in the test, we suggest looking at a more classical operating systems textbook, like for example [1]. It is important to note that this book is not a reference for using an operating system nor a reference for Plan 9 from Bell Labs. The user’s manual that comes installed within the system is the proper reference to use. These lecture notes just shows you how things work, by using them. Once you have gone through the course, you are expected to search and use the user’s manual as a reference. One final note of caution. This text is to be read with a computer side by side. The only way to learn to use a system is by actually using it. Reading this without doing so is meaningless. I am grateful go to other colleagues who suffered or helped in one way or another to write this book. First, authors of Plan 9 from Bell Labs made an awesome system, worth describing for an Operating Sys- tems Course. It cannot be overemphasized how much help the authors of Plan 9 provide to anyone asking - 2 - questions in the 9fans list. For what is worth, I have to say that I am deeply grateful to people like Rob Pike, Dave Presotto, Jim McKie, Russ Cox, and many others. In particular, Russ Cox seems to be a pro- gram listening for questions at 9fans, at least his response time suggests that. I have learned a lot from you all (or I tried). Other colleagues from Rey Juan Carlos University helped me as well. Pedro de las Heras was eager to get new drafts for this manuscript. Sergio Arévalo was an unlimited supply of useful comments and fixes for improving this book, specially for using it as a textbook. José Centeno was scared to hell after reading our initial description of computer networks, and helped to reach a much better descrip- tion. Francisco J. Ballesteros Laboratorio de Sistemas, Rey Juan Carlos University of Madrid Madrid, Spain 2006 Table of Contents 1. Getting started 1 1.1. What is an Operating System? 1 1.2. Entering the system 3 1.3. Leaving the system 6 1.4. Editing and running commands 6 1.5. Obtaining help 8 1.6. Using files 10 1.7. Directories 12 1.8. Files and data 15 1.9. Permissions 18 1.10. Writing a C program in Plan 9 20 1.11. The Operating System and your programs 22 1.12. Where are the files? 23 1.13. The Shell, commands, binaries, and system calls 25 1.14. The Operating System and the hardware 25 2. Programs and Processes 27 2.1. Processes 27 2.2. Loaded programs 29 2.3. Process birth and death 32 2.4. System call errors 37 2.5. Environment 39 2.6. Process names and states 42 2.7. Debugging 44 2.8. Everything is a file! 46 3. Files 51 3.1. Input/Output 51 3.2. Write games 56 3.3. Read games 60 3.4. Creating and removing files 61 3.5. Directory entries 63 3.6. Listing files in the shell 68 3.7. Buffered Input/Output 71 4. Parent and Child 79 4.1. Running a new program 79 4.2. Process creation 80 4.3. Shared or not? 84 4.4. Race conditions 87 4.5. Executing another program 87 4.6. Using both calls 89 4.7. Waiting for children 90 4.8. Interpreted programs 93 5. Communicating Processes 97 5.1. Input/Output redirection 97 5.2. Conventions 102 5.3. Other redirections 102 5.4. Pipes 103 5.5. Using pipes 108 5.6. Notes and process groups 113 - 2 - 5.7. Reading, notes, and alarms 116 5.8. The file descriptor bulletin board 119 5.9. Delivering messages 121 6. Network communication 131 6.1. Network connections 131 6.2. Names 135 6.3. Making calls 137 6.4. Providing services 140 6.5. System services 146 6.6. Distributed computing 147 7. Resources, Files, and Names 149 7.1. Resource fork 149 7.2. Protecting from notes 151 7.3. Environment in shell scripts 153 7.4. Independent children 154 7.5. Name spaces 155 7.6. Local name space tricks 160 7.7. Device files 162 7.8. Unions 163 7.9. Changing the name space 165 7.10. Using names 166 7.11. Sand-boxing 168 7.12. Distributed computing revisited 170 8. Using the Shell 175 8.1. Programs are tools 175 8.2. Lists 176 8.3. Simple things 179 8.4. Real programs 182 8.5. Conditions 186 8.6. Editing text 189 8.7. Moving files around 194 9. More tools 197 9.1. Regular expressions 197 9.2. Sorting and searching 201 9.3. Searching for changes 206 9.4. AWK 210 9.5. Processing data 215 9.6. File systems 220 10. Concurrent programming 225 10.1. Synchronization 225 10.2. Locks 228 10.3. Queueing locks 235 10.4. Rendezvous 242 10.5. Sleep and wakeup 244 10.6. Shared buffers 248 10.7. Other tools 251 11. Threads and Channels 257 11.1. Threads 257 - 3 - 11.2. Thread names 260 11.3. Channels 265 11.4. I/O in threaded programs 270 11.5. Many to one communication 273 11.6. Other calls 281 12. User Input/Output 285 12.1. Console input 285 12.2. Characters and runes 288 12.3. Mouse input 291 12.4. Devices for graphics 294 12.5. Graphics 296 12.6. A graphic slider 299 12.7. Keyboard input 305 12.8. Drawing text 308 12.9. The window system 309 13. Building a File Server 317 13.1. Disk storage 317 13.2. The file system protocol 321 13.3. Semaphores for Plan 9 327 13.4. Speaking 9P 328 13.5. 9P requests 332 13.6. Semaphores 334 13.7. Semaphores as files 337 13.8. A program to make things 345 13.9. Debugging and testing 350 14. Security 353 14.1. Secure systems 353 14.2. The local machine 354 14.3. Distributed security and authentication 355 14.4. Authentication agents 358 14.5. Secure servers 364 14.6. Identity changes 367 14.7.
Load more

Recommended publications
  • Java Implementation of the Graphical User Interface of the Octopus Distributed Operating System
    Java implementation of the graphical user interface of the Octopus distributed operating system Submitted by Aram Sadogidis Advisor Prof. Spyros Lalis University of Thessaly Volos, Greece October 2012 Acknowledgements I am sincerely grateful for all the people that supported me during my Uni- versity studies. Special thanks to professor Spyros Lalis, my mentor, who had decisive influence in shaping my character as an engineer. Also many thanks to my family and friends, whose support all these years, encouraged me to keep moving forward. 1 Contents 1 Introduction 4 2 System software technologies 6 2.1 Inferno OS . 6 2.2 JavaSE and Android framework . 8 2.3 Synthetic file systems . 10 2.3.1 Styx . 10 2.3.2 Op . 12 3 Octopus OS 14 3.1 UpperWare architecture . 14 3.2 Omero, a filesystem based window system . 16 3.3 Olive, the Omero viewer . 19 3.4 Ox, the Octopus shell . 21 4 Java Octopus Terminal 23 4.1 JOlive . 24 4.2 Desktop version . 25 4.2.1 Omero package . 26 4.2.2 ui package . 27 4.3 Android version . 28 4.3.1 com.jolive.Omero . 28 4.3.2 com.jolive.ui . 29 4.3.3 Pull application's UI . 30 5 Future perspective 33 5.1 GPS resources . 33 5.2 JOp . 34 5.3 Authentication device . 34 5.4 Remote Voice commander . 34 5.5 Conclusion . 35 6 Thesis preview in Greek 38 2 List of Figures 2.1 An application operates on a synthetic file as if it is a disk file, effectively communicating with a synthetic file system server.
    [Show full text]
  • CSE 220: Systems Programming Input and Output
    CSE 220: Systems Programming Input and Output Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Unix I/O Standard I/O Buffering Summary References I/O Kernel Services We have seen some text I/O using the C Standard Library. printf() fgetc() … However, all I/O is built on kernel system calls. In this lecture, we’ll look at those services vs. standard I/O. © 2020 Ethan Blanton / CSE 220: Systems Programming Introduction Unix I/O Standard I/O Buffering Summary References Everything is a File These services are particularly important on Unix systems. On Unix, “everything is a file”. Many devices and services are accessed by opening device nodes. Device nodes behave like (but are not) files. Examples: /dev/null: Always readable, contains no data. Always writable, discards anything written to it. /dev/urandom: Always readable, reads a cryptographically secure stream of random data. © 2020 Ethan Blanton / CSE 220: Systems Programming Introduction Unix I/O Standard I/O Buffering Summary References File Descriptors All access to files is through file descriptors. A file descriptor is a small integer representing an open file in a particular process. There are three “standard” file descriptors: 0: standard input 1: standard output 2: standard error …sound familiar? (stdin, stdout, stderr) © 2020 Ethan Blanton / CSE 220: Systems Programming Introduction Unix I/O Standard I/O Buffering Summary References System Call Failures Kernel I/O (and most other) system calls return -1 on failure. When this happens, the global variable errno is set to a reason. Include errno.h to define errno in your code.
    [Show full text]
  • Persistent 9P Sessions for Plan 9
    Persistent 9P Sessions for Plan 9 Gorka Guardiola, [email protected] Russ Cox, [email protected] Eric Van Hensbergen, [email protected] ABSTRACT Traditionally, Plan 9 [5] runs mainly on local networks, where lost connections are rare. As a result, most programs, including the kernel, do not bother to plan for their file server connections to fail. These programs must be restarted when a connection does fail. If the kernel’s connection to the root file server fails, the machine must be rebooted. This approach suffices only because lost connections are rare. Across long distance networks, where connection failures are more common, it becomes woefully inadequate. To address this problem, we wrote a program called recover, which proxies a 9P session on behalf of a client and takes care of redialing the remote server and reestablishing con- nection state as necessary, hiding network failures from the client. This paper presents the design and implementation of recover, along with performance benchmarks on Plan 9 and on Linux. 1. Introduction Plan 9 is a distributed system developed at Bell Labs [5]. Resources in Plan 9 are presented as synthetic file systems served to clients via 9P, a simple file protocol. Unlike file protocols such as NFS, 9P is stateful: per-connection state such as which files are opened by which clients is maintained by servers. Maintaining per-connection state allows 9P to be used for resources with sophisticated access control poli- cies, such as exclusive-use lock files and chat session multiplexers. It also makes servers easier to imple- ment, since they can forget about file ids once a connection is lost.
    [Show full text]
  • Bell Labs, the Innovation Engine of Lucent
    INTERNSHIPS FOR RESEARCH ENGINEERS/COMPUTER SCIENTISTS BELL LABS DUBLIN (IRELAND) – BELL LABS STUTTGART (GERMANY) Background Candidates are expected to have some experience related to the following topics: Bell Laboratories is a leading end-to-end systems and • Operating systems, virtualisation and computer solutions research lab working in the areas of cloud architectures. and distributed computing, platforms for real-time • big-data streaming and analytics, wireless networks, Software development skills (C/C++, Python). • semantic data access, services-centric operations and Computer networks and distributed systems. thermal management. The lab is embedded in the • Optimisation techniques and algorithms. great traditions of the Bell Labs systems research, in- • Probabilistic modelling of systems performance. ternationally renowned as the birthplace of modern The following skills or interests are also desirable: information theory, UNIX, the C/C++ programming • languages, Awk, Plan 9 from Bell Labs, Inferno, the Experience with OpenStack or OpenNebula or Spin formal verification tool, and many other sys- other cloud infrastructure management software. • tems, languages, and tools. Kernel-level programming (drivers, scheduler,...). • Xen, KVM and Linux scripting/administration. We offer summer internships in our Cloud • Parallel and distributed systems programming Computing team, spread across the facilities in Dublin (Ireland) and Stuttgart (Germany), focusing (MPI, OpenMP, CUDA, MapReduce, StarSs, …). • on research enabling future cloud
    [Show full text]
  • Tutorials Point, Simply Easy Learning
    Tutorials Point, Simply Easy Learning UML Tutorial Tutorialspoint.com UNIX is a computer Operating System which is capable of handling activities from multiple users at the same time. Unix was originated around in 1969 at AT&T Bell Labs by Ken Thompson and Dennis Ritchie. This tutorial gives an initial push to start you with UNIX. For more detail kindly check tutorialspoint.com/unix What is Unix ? The UNIX operating system is a set of programs that act as a link between the computer and the user. The computer programs that allocate the system resources and coordinate all the details of the computer's internals is called the operating system or kernel. Users communicate with the kernel through a program known as the shell. The shell is a command line interpreter; it translates commands entered by the user and converts them into a language that is understood by the kernel. Unix was originally developed in 1969 by a group of AT&T employees at Bell Labs, including Ken Thompson, Dennis Ritchie, Douglas McIlroy, and Joe Ossanna. There are various Unix variants available in the market. Solaris Unix, AIX, UP Unix and BSD are few examples. Linux is also a flavour of Unix which is freely available. Several people can use a UNIX computer at the same time; hence UNIX is called a multiuser system. A user can also run multiple programs at the same time; hence UNIX is called multitasking. Unix Architecture: Here is a basic block diagram of a UNIX system: 1 | P a g e Tutorials Point, Simply Easy Learning The main concept that unites all versions of UNIX is the following four basics: Kernel: The kernel is the heart of the operating system.
    [Show full text]
  • Introduction to Unix
    Introduction to Unix Rob Funk <[email protected]> University Technology Services Workstation Support http://wks.uts.ohio-state.edu/ University Technology Services Course Objectives • basic background in Unix structure • knowledge of getting started • directory navigation and control • file maintenance and display commands • shells • Unix features • text processing University Technology Services Course Objectives Useful commands • working with files • system resources • printing • vi editor University Technology Services In the Introduction to UNIX document 3 • shell programming • Unix command summary tables • short Unix bibliography (also see web site) We will not, however, be covering these topics in the lecture. Numbers on slides indicate page number in book. University Technology Services History of Unix 7–8 1960s multics project (MIT, GE, AT&T) 1970s AT&T Bell Labs 1970s/80s UC Berkeley 1980s DOS imitated many Unix ideas Commercial Unix fragmentation GNU Project 1990s Linux now Unix is widespread and available from many sources, both free and commercial University Technology Services Unix Systems 7–8 SunOS/Solaris Sun Microsystems Digital Unix (Tru64) Digital/Compaq HP-UX Hewlett Packard Irix SGI UNICOS Cray NetBSD, FreeBSD UC Berkeley / the Net Linux Linus Torvalds / the Net University Technology Services Unix Philosophy • Multiuser / Multitasking • Toolbox approach • Flexibility / Freedom • Conciseness • Everything is a file • File system has places, processes have life • Designed by programmers for programmers University Technology Services
    [Show full text]
  • Storage Devices, Basic File System Design
    CS162 Operating Systems and Systems Programming Lecture 17 Data Storage to File Systems October 29, 2019 Prof. David Culler http://cs162.eecs.Berkeley.edu Read: A&D Ch 12, 13.1-3.2 Recall: OS Storage abstractions Key Unix I/O Design Concepts • Uniformity – everything is a file – file operations, device I/O, and interprocess communication through open, read/write, close – Allows simple composition of programs • find | grep | wc … • Open before use – Provides opportunity for access control and arbitration – Sets up the underlying machinery, i.e., data structures • Byte-oriented – Even if blocks are transferred, addressing is in bytes What’s below the surface ?? • Kernel buffered reads – Streaming and block devices looks the same, read blocks yielding processor to other task • Kernel buffered writes Application / Service – Completion of out-going transfer decoupled from the application, File descriptor number allowing it to continue - an int High Level I/O streams • Explicit close Low Level I/O handles 9/12/19 The cs162file fa19 L5system abstraction 53 Syscall registers • File File System descriptors File Descriptors – Named collection of data in a file system • a struct with all the info I/O Driver Commands and Data Transfers – POSIX File data: sequence of bytes • about the files Disks, Flash, Controllers, DMA Could be text, binary, serialized objects, … – File Metadata: information about the file • Size, Modification Time, Owner, Security info • Basis for access control • Directory – “Folder” containing files & Directories – Hierachical
    [Show full text]
  • Linux Kernel and Driver Development Training Slides
    Linux Kernel and Driver Development Training Linux Kernel and Driver Development Training © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Latest update: October 9, 2021. Document updates and sources: https://bootlin.com/doc/training/linux-kernel Corrections, suggestions, contributions and translations are welcome! embedded Linux and kernel engineering Send them to [email protected] - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/470 Rights to copy © Copyright 2004-2021, Bootlin License: Creative Commons Attribution - Share Alike 3.0 https://creativecommons.org/licenses/by-sa/3.0/legalcode You are free: I to copy, distribute, display, and perform the work I to make derivative works I to make commercial use of the work Under the following conditions: I Attribution. You must give the original author credit. I Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. I For any reuse or distribution, you must make clear to others the license terms of this work. I Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Document sources: https://github.com/bootlin/training-materials/ - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/470 Hyperlinks in the document There are many hyperlinks in the document I Regular hyperlinks: https://kernel.org/ I Kernel documentation links: dev-tools/kasan I Links to kernel source files and directories: drivers/input/ include/linux/fb.h I Links to the declarations, definitions and instances of kernel symbols (functions, types, data, structures): platform_get_irq() GFP_KERNEL struct file_operations - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/470 Company at a glance I Engineering company created in 2004, named ”Free Electrons” until Feb.
    [Show full text]
  • File and Console I/O
    File and Console I/O CS449 Spring 2016 What is a Unix(or Linux) File? • File: “a resource for storing information [sic] based on some kind of durable storage” (Wikipedia) • Wider sense: “In Unix, everything is a file.” (a.k.a “In Unix, everything is a stream of bytes.”) – Traditional files, directories, links – Inter-process communication (pipes, shared memory, sockets) – Devices (interactive terminals, hard drives, printers, graphic card) • Usually mounted under /dev/ directory – Process Links (for getting process information) • Usually mounted under /proc/ directory Stream of Bytes Abstraction • A file, in abstract, is a stream of bytes • Can be manipulated using five system calls: – open: opens a file for reading/writing and returns a file descriptor • File descriptor: index into an OS array called open file table – read: reads current offset through file descriptor – write: writes current offset through file descriptor – lseek: changes current offset in file – close: closes file descriptor • Some files do not support certain operations (e.g. a terminal device does not support lseek) C Standard Library Wrappers • C Standard Library wraps file system calls in library functions – For portability across multiple systems – To provide additional features (buffering, formatting) • All C wrappers buffered by default – Buffering can be controlled using “setbuf” or “setlinebuf” calls (remember those?) • Works on FILE * instead of file descriptor – FILE is a library data structure that abstracts a file – Contains file descriptor, current offset, buffering mode etc. Wrappers for the Five System Calls Function Prototype Description FILE *fopen(const char *path, const Opens the file whose name is the string pointed to char *mode); by path and associates a stream with it.
    [Show full text]
  • 307-151 Issue 1 N N~Nnwtsystem V ~ U~ U~ Release 2.0 DOCUMENTER's WORKBENCH™ Software 'Text Formatters Reference
    December 1983 307-151 Issue 1 n n~nnWTsystem V ~ U~ U~ Release 2.0 DOCUMENTER'S WORKBENCH™ Software 'Text Formatters Reference © 1983 Western Electric All Rights Reserved Printed in USA Western Electric ..... UNIX is a trademark of Bell Laboratories DOCUMENTER'S WORKBENCH is a trademark of Western Electric CONTENTS Chapter 1 INTRODUCTION Chapter 2 NROFF/TROFF TUTORIAL Chapter 3 NROFF AND TROFF USER MANUAL Chapter 4 DEVICE-INDEPENDENT TROFF Chapter 5 SROFF TUTORIAL GUIDE Chapter 6 SROFF REFERENCE MANUAL - I - Chapter 1 INTRODUCTION PAGE TEXT FORMATTERS ........................................... 1-1 Chapter 1 INTRODUCTION This book is a guide and reference manual for the text formatters that are provided with the UNIX* system DOCUMENTER'S WORKBENCHt software. This software provides an integrated set of text processing tools for easy, flexible, and professional documentation production. Books that describe other aspects of the DOCUMENTER'S WORKBENCH software are: • Introduction and Reference Manual-Select Code 307-150 • Macro Packages Reference-Select Code 307-152 • Preprocessors Reference-Select Code 307-153. The beginning user should refer to the DOCUMENTER'S WORKBENCH software Introduction and Reference Manual for a better overall description of the text processing tools available on the UNIX system. TEXT FORMATTERS On the DOCUMENTER'S WORKBENCH software, the text formatting programs provide control of text format by the use of requests (sometimes called formatter primitives) that are mixed in with the text to be formatted. These requests normally consist of two lowercase letters preceded by a period, on a line by themselves in the text file. The request may be followed on the same line by numbers or letters that provide the formatter with more information about the function of the request.
    [Show full text]
  • Knowledge Management Enviroments for High Throughput Biology
    Knowledge Management Enviroments for High Throughput Biology Abhey Shah A Thesis submitted for the degree of MPhil Biology Department University of York September 2007 Abstract With the growing complexity and scale of data sets in computational biology and chemoin- formatics, there is a need for novel knowledge processing tools and platforms. This thesis describes a newly developed knowledge processing platform that is different in its emphasis on architecture, flexibility, builtin facilities for datamining and easy cross platform usage. There exist thousands of bioinformatics and chemoinformatics databases, that are stored in many different forms with different access methods, this is a reflection of the range of data structures that make up complex biological and chemical data. Starting from a theoretical ba- sis, FCA (Formal Concept Analysis) an applied branch of lattice theory, is used in this thesis to develop a file system that automatically structures itself by it’s contents. The procedure of extracting concepts from data sets is examined. The system also finds appropriate labels for the discovered concepts by extracting data from ontological databases. A novel method for scaling non-binary data for use with the system is developed. Finally the future of integrative systems biology is discussed in the context of efficiently closed causal systems. Contents 1 Motivations and goals of the thesis 11 1.1 Conceptual frameworks . 11 1.2 Biological foundations . 12 1.2.1 Gene expression data . 13 1.2.2 Ontology . 14 1.3 Knowledge based computational environments . 15 1.3.1 Interfaces . 16 1.3.2 Databases and the character of biological data .
    [Show full text]
  • Plan 9 from Bell Labs
    Plan 9 from Bell Labs “UNIX++ Anyone?” Anant Narayanan Malaviya National Institute of Technology FOSS.IN 2007 What is it? Advanced technology transferred via mind-control from aliens in outer space Humans are not expected to understand it (Due apologies to lisperati.com) Yeah Right • More realistically, a distributed operating system • Designed by the creators of C, UNIX, AWK, UTF-8, TROFF etc. etc. • Widely acknowledged as UNIX’s true successor • Distributed under terms of the Lucent Public License, which appears on the OSI’s list of approved licenses, also considered free software by the FSF What For? “Not only is UNIX dead, it’s starting to smell really bad.” -- Rob Pike (circa 1991) • UNIX was a fantastic idea... • ...in it’s time - 1970’s • Designed primarily as a “time-sharing” system, before the PC era A closer look at Unix TODAY It Works! But that doesn’t mean we don’t develop superior alternates GNU/Linux • GNU’s not UNIX, but it is! • Linux was inspired by Minix, which was in turn inspired by UNIX • GNU/Linux (mostly) conforms to ANSI and POSIX requirements • GNU/Linux, on the desktop, is playing “catch-up” with Windows or Mac OS X, offering little in terms of technological innovation Ok, and... • Most of the “modern ideas” we use today were “bolted” on an ancient underlying system • Don’t believe me? A “modern” UNIX Terminal Where did it go wrong? • Early UNIX, “everything is a file” • Brilliant! • Only until people started adding “features” to the system... Why you shouldn’t be working with GNU/Linux • The Socket API • POSIX • X11 • The Bindings “rat-race” • 300 system calls and counting..
    [Show full text]