Process-Oriented Patterns for Concurrent Software Engineering

Total Page:16

File Type:pdf, Size:1020Kb

Process-Oriented Patterns for Concurrent Software Engineering PROCESS-ORIENTED PATTERNS FOR CONCURRENT SOFTWARE ENGINEERING A THESIS SUBMITTED TO THE UNIVERSITY OF KENT IN THE SUBJECT OF COMPUTER SCIENCE FOR THE DEGREE OF DOCTOR OF PHILOSOPHY. By Adam T. Sampson 2008 Abstract Concurrency is unavoidable in modern software development, owing to the increasing complexity of computer systems and the widespread use of parallel computer hard- ware. Conventional approaches to concurrency are fraught with danger: in particular, uncontrolled access to shared resources, poor scalability and the inability of the pro- grammer to reason about the correctness of a program. Process-oriented programming is a software design approach that offers solutions to many of these problems. A process-oriented program is constructed as a network of isolated, concurrent processes that interact only using synchronisation objects such as channels and barriers. Using techniques drawn from CSP and the p-calculus, de- sign rules can be constructed that enable the programmer to easily build systems with known safety properties. Since process-oriented programs expose by their nature a high degree of explicit concurrency, they can be efficiently distributed across multiple processors and clusters of machines. This thesis describes a pattern language for the engineering of process-oriented pro- grams. Design patterns describe reusable, adaptable solutions to common problems that may arise during the design and development of a system. A pattern language serves the dual purposes of documenting the proven design solutions developed by a community, and providing a common technical vocabulary. The patterns described in this thesis are drawn from a variety of existing process- oriented real-world applications, and have been used to construct new applications in fields such as embedded systems, multimedia processing, and complex systems simu- lation. While much of this work has been conducted using the occam-p programming language, the patterns—and the new language and library facilities they inform—are applicable to process-oriented systems built in any language. ii Acknowledgements I would like to thank the members of the Programming Languages and Systems group at the University of Kent, those involved in the TUNA and CoSMoS projects, and the Communicating Process Architectures community at large for the many interesting and fruitful discussions that we have had during the course of this work—and for their willingness to let me use their applications as case studies. This work was supported by EPSRC: both directly through a research studentship (EP/P50029X/1), and through case studies from the TUNA (EP/C516966/1), CoSMoS (EP/E049419/1) and RMoX (EP/D061822/1) projects. iii Contents Abstract ii Acknowledgements iii Contents iv List of Figures viii 1 Introduction 1 1.1 Roadmap . 2 1.2 Conventions . 3 2 Background 4 2.1 Process-Oriented Programming . 4 2.1.1 Concurrency . 4 2.1.2 Isolation . 5 2.1.3 Communication . 6 2.1.4 Composition . 6 2.1.5 Reasoning . 7 2.1.6 POP and Other Paradigms . 7 2.1.7 Problems with POP . 8 2.2 Basic Facilities . 8 2.2.1 Processes . 9 2.2.2 Channels . 12 2.2.3 Barriers . 16 2.2.4 Synchronisation Objects . 18 2.2.5 Mobility . 21 2.3 Process-Oriented Environments . 24 2.3.1 Implementing Processes . 24 2.3.2 occam . 27 2.3.3 From Newsqueak to Go . 29 2.3.4 Erlang . 31 2.3.5 Java . 32 2.3.6 C# . 33 2.3.7 Python . 34 2.3.8 Haskell . 36 2.4 Design Patterns . 39 2.4.1 “A Pattern Language” . 39 iv 2.4.2 “Design Patterns” . 40 2.4.3 Other Concurrent Patterns . 41 2.5 Process Diagrams . 42 2.5.1 The Syntax of Process Diagrams . 43 2.5.2 Drawing Process Diagrams . 44 2.5.3 Other Kinds of Diagrams . 45 3 Case Studies 47 3.1 Flightsim . 47 3.2 occam-X11 . 50 3.3 KRoC . 51 3.3.1 The Module System . 53 3.3.2 General Utilities . 53 3.3.3 Graphics . 54 3.3.4 Operating System Bindings . 54 3.3.5 Distributed Application Support . 55 3.4 RMoX . 56 3.4.1 Substrates . 57 3.4.2 Network Stack . 57 3.4.3 USB Stack . 60 3.5 TUNA . 61 3.5.1 Life . 61 3.5.2 Simulating Life . 63 3.5.3 Blood Clotting . 66 3.6 occvid . 68 3.7 LOVE . 70 3.8 Occade . 77 3.8.1 Implementation . 79 3.8.2 Sending Events . 80 3.8.3 Future Directions . 80 3.9 CoSMoS . 81 3.9.1 Occoids . 83 3.9.2 Distributed Simulations . 86 3.9.3 Generalised Space Model . 90 3.9.4 Ccoids . 91 3.10 Plumbing . 92 4 Process-Oriented Patterns 96 4.1 Process Patterns . 96 4.1.1 Producer and Consumer . 97 4.1.2 Black Hole . 97 4.1.3 Filter . 98 4.1.4 Buffer . 99 4.1.5 Glue . 102 4.1.6 Valve . 102 4.1.7 Grouper and Ungrouper . 104 4.1.8 Merge . 105 4.1.9 Collector . 106 v 4.1.10 Delta . 107 4.1.11 Distributor . 108 4.1.12 Factory . 108 4.1.13 Oracle . 109 4.2 Patterns of Structure . 110 4.2.1 Pipeline . 110 4.2.2 Fan-Out . 113 4.2.3 Location . 115 4.2.4 Ring . 116 4.2.5 Client-Server . 118 4.2.6 Farm . 121 4.2.7 Intermediary . 123 4.3 Patterns of Cooperation . 124 4.3.1 Acknowledgement . 124 4.3.2 I/O-SEQ and I/O-PAR . 125 4.3.3 Phases . 127 4.3.4 Clock . 128 4.3.5 Lazy Updates . 129 4.3.6 Just In Time . 130 4.3.7 Messenger . 133 4.4 Patterns of Mobility . ..
Recommended publications
  • Introduction to Concurrent Programming
    Introduction to Concurrent Programming Rob Pike Computing Sciences Research Center Bell Labs Lucent Technologies [email protected] February 2, 2000 1 Overview The world runs in parallel, but our usual model of software does not. Programming languages are sequential. This mismatch makes it hard to write systems software that provides the interface between a computer (or user) and the world. Solutions: processes, threads, concurrency, semaphores, spin locks, message-passing. But how do we use these things? Real problem: need an approach to writing concurrent software that guides our design and implementation. We will present our model for designing concurrent software. It’s been used in several languages for over a decade, producing everything from symbolic algebra packages to window systems. This course is not about parallel algorithms or using multiprocessors to run programs faster. It is about using the power of processes and communication to design elegant, responsive, reliable systems. 2 History (Biased towards Systems) Dijkstra: guarded commands, 1976. Hoare: Communicating Sequential Processes (CSP), (paper) 1978. Run multiple communicating guarded command sets in parallel. Hoare: CSP Book, 1985. Addition of channels to the model, rather than directly talking to processes. Cardelli and Pike: Squeak, 1983. Application of CSP model to user interfaces. Pike: Concurrent Window System, (paper) 1988. Application of Squeak approach to systems software. Pike: Newsqueak, 1989. Interpreted language; used to write toy window system. Winterbottom: Alef, 1994. True compiled concurrent language, used to write production systems software. Mullender: Thread library, 1999. Retrofit to C for general usability. 3 Other models exist Our approach is not the only way.
    [Show full text]
  • Short Range Object Detection and Avoidance
    Short Range Object Detection and Avoidance N.F. Jansen CST 2010.068 Traineeship report Coach(es): dr. E. García Canseco, TU/e dr. ing. S. Lichiardopol, TU/e ing. R. Niesten, Wingz BV Supervisor: prof.dr.ir. M. Steinbuch Eindhoven University of Technology Department of Mechanical Engineering Control Systems Technology Eindhoven, November, 2010 Abstract The scope of this internship is to investigate, model, simulate and experiment with a sensor for close range object detection for the purpose of the Tele-Service Robot (TSR) robot. The TSR robot will be implemented in care institutions for the care of elderly and/or disabled. The sensor system should have a supporting role in navigation and mapping of the environment of the robot. Several sensors are investigated, whereas the sonar system is the optimal solution for this application. It’s cost, wide field-of-view, sufficient minimal and maximal distance and networking capabilities of the Devantech SRF-08 sonar sensor is decisive to ultimately choose this sensor system. The positioning, orientation and tilting of the sonar devices is calculated and simulations are made to obtain knowledge about the behavior and characteristics of the sensors working in a ring. Issues surrounding the sensors are mainly erroneous ranging results due to specular reflection, cross-talk and incorrect mounting. Cross- talk can be suppressed by operating in groups, but induces the decrease of refresh rate of the entire robot’s surroundings. Experiments are carried out to investigate the accuracy and sensitivity to ranging errors and cross-talk. Eventually, due to the existing cross-talk, experiments should be carried out to decrease the range and timing to increase the refresh rate because the sensors cannot be fired more than only two at a time.
    [Show full text]
  • Architecture of 8051 & Their Pin Details
    SESHASAYEE INSTITUTE OF TECHNOLOGY ARIYAMANGALAM , TRICHY – 620 010 ARCHITECTURE OF 8051 & THEIR PIN DETAILS UNIT I WELCOME ARCHITECTURE OF 8051 & THEIR PIN DETAILS U1.1 : Introduction to microprocessor & microcontroller : Architecture of 8085 -Functions of each block. Comparison of Microprocessor & Microcontroller - Features of microcontroller -Advantages of microcontroller -Applications Of microcontroller -Manufactures of microcontroller. U1.2 : Architecture of 8051 : Block diagram of Microcontroller – Functions of each block. Pin details of 8051 -Oscillator and Clock -Clock Cycle -State - Machine Cycle -Instruction cycle –Reset - Power on Reset - Special function registers :Program Counter -PSW register -Stack - I/O Ports . U1.3 : Memory Organisation & I/O port configuration: ROM RAM - Memory Organization of 8051,Interfacing external memory to 8051 Microcontroller vs. Microprocessors 1. CPU for Computers 1. A smaller computer 2. No RAM, ROM, I/O on CPU chip 2. On-chip RAM, ROM, I/O itself ports... 3. Example:Intel’s x86, Motorola’s 3. Example:Motorola’s 6811, 680x0 Intel’s 8051, Zilog’s Z8 and PIC Microcontroller vs. Microprocessors Microprocessor Microcontroller 1. CPU is stand-alone, RAM, ROM, I/O, timer are separate 1. CPU, RAM, ROM, I/O and timer are all on a single 2. designer can decide on the chip amount of ROM, RAM and I/O ports. 2. fix amount of on-chip ROM, RAM, I/O ports 3. expansive 3. for applications in which 4. versatility cost, power and space are 5. general-purpose critical 4. single-purpose uP vs. uC – cont. Applications – uCs are suitable to control of I/O devices in designs requiring a minimum component – uPs are suitable to processing information in computer systems.
    [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]
  • SERVO MAGAZINE TEAM DARE’S ROBOT BAND • RADIO for ROBOTS • BUILDING MAXWELL June 2012 Full Page Full Page.Qxd 5/7/2012 6:41 PM Page 2
    0 0 06 . 7 4 $ A D A N A C 0 5 . 5 $ 71486 02422 . $5.50US $7.00CAN S . 0 U CoverNews_Layout 1 5/9/2012 3:21 PM Page 1 Vol. 10 No. 6 SERVO MAGAZINE TEAM DARE’S ROBOT BAND • RADIO FOR ROBOTS • BUILDING MAXWELL June 2012 Full Page_Full Page.qxd 5/7/2012 6:41 PM Page 2 HS-430BH HS-5585MH HS-5685MH HS-7245MH DELUXE BALL BEARING HV CORELESS METAL GEAR HIGH TORQUE HIGH TORQUE CORELESS MINI 6.0 Volts 7.4 Volts 6.0 Volts 7.4 Volts 6.0 Volts 7.4 Volts 6.0 Volts 7.4 Volts Torque: 57 oz-in 69 oz-in Torque: 194 oz-in 236 oz-in Torque: 157 oz-in 179 oz-in Torque: 72 oz-in 89 oz-in Speed: 0.16 sec/60° 0.14 sec/60° Speed: 0.17 sec/60° 0.14 sec/60° Speed: 0.20 sec/60° 0.17 sec/60° Speed: 0.13 sec/60° 0.11 sec/60° HS-7950THHS-7950TH HS-7955TG HS-M7990TH HS-5646WP ULTRA TORQUE CORELESS HIGH TORQUE CORELESS MEGA TORQUE HV MAGNETIC ENCODER WATERPROOF HIGH TORQUE 6.0 Volts 7.4 Volts 4.8 Volts 6.0 Volts 6.0 Volts 7.4 Volts 6.0 Volts 7.4 Volts Torque: 403 oz-in 486 oz-in Torque: 250 oz-in 333 oz-in Torque: 500 oz-in 611 oz-in Torque: 157 oz-in 179 oz-in Speed: 0.17 sec/60° 0.14 sec/60° Speed: 0.19 sec/60° 0.15 sec/60° Speed: 0.21 sec/60° 0.17 sec/60° Speed: 0.20 sec/60° 0.18 sec/60° DIY Projects: Programmable Controllers: Wild Thumper-Based Robot Wixel and Wixel Shield #1702: Premium Jumper #1336: Wixel programmable Wire Assortment M-M 6" microcontroller module with #1372: Pololu Simple Motor integrated USB and a 2.4 Controller 18v7 GHz radio.
    [Show full text]
  • Squinting at Power Series
    Squinting at Power Series M. Douglas McIlroy AT&T Bell Laboratories Murray Hill, New Jersey 07974 ABSTRACT Data streams are an ideal vehicle for handling power series. Stream implementations can be read off directly from simple recursive equations that de®ne operations such as multiplication, substitution, exponentiation, and reversion of series. The bookkeeping that bedevils these algorithms when they are expressed in traditional languages is completely hidden when they are expressed in stream terms. Communicating processes are the key to the simplicity of the algorithms. Working versions are presented in newsqueak, the language of Pike's ``squint'' system; their effectiveness depends critically on the stream protocol. Series and streams Power series are natural objects for stream processing. Pertinent computations are neatly describable by recursive equations. CSP (communicating sequential process) languages1, 2 are good vehicles for implementation. This paper develops the algorithmic ideas and reduces them to practice in a working CSP language,3 not coincidentally illustrating the utility of concurrent programming notions in untangling the logic of some intricate computations on sequences. This elegant approach to power series computation, ®rst demonstrated but never published by Kahn and MacQueen as an application of their data stream system, is still little known.4 Power series are represented as streams of coef®cients, the exponents being given implicitly by ordinal position. (This is an in®nite analogue of the familiar representation of a polynomial as an array of coef®cients.) Thus the power series for the exponential function ∞ 1 1 1 e x = Σ x n / n! = 1 + x + __ x 2 + __ x 3 + ___ x 4 + .
    [Show full text]
  • Programming and Customizing the Multicore Propeller
    PROGRAMMING AND CUSTOMIZING THE MULTICORE PROPELLERTM MICROCONTROLLER This page intentionally left blank PROGRAMMING AND CUSTOMIZING THE MULTICORE PROPELLERTM MICROCONTROLLER THE OFFICIAL GUIDE PARALLAX INC. Shane Avery Chip Gracey Vern Graner Martin Hebel Joshua Hintze André LaMothe Andy Lindsay Jeff Martin Hanno Sander New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore Sydney Toronto Copyright © 2010 by The McGraw-Hill Companies, Inc. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. ISBN: 978-0-07-166451-6 MHID: 0-07-166451-3 The material in this eBook also appears in the print version of this title: ISBN: 978-0-07-166450-9, MHID: 0-07-166450-5. All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps. McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. To contact a representative please e-mail us at [email protected]. Information contained in this work has been obtained by The McGraw-Hill Companies, Inc.
    [Show full text]
  • Go Web App Example
    Go Web App Example Titaniferous and nonacademic Marcio smoodges his thetas attuned directs decreasingly. Fustiest Lennie seethe, his Pan-Americanism ballasts flitted gramophonically. Flavourless Elwyn dematerializing her reprobates so forbiddingly that Fonsie witness very sartorially. Ide support for web applications possible through gvm is go app and psych and unlock new subcommand go library in one configuration with embedded interface, take in a similar Basic Role-Based HTTP Authorization in fare with Casbin. Tools and web framework for everything there is big goals. Fully managed environment is go app, i is a serverless: verifying user when i personally use the example, decentralized file called marshalling which are both of. Simple Web Application with light Medium. Go apps into go library for example of examples. Go-bootstrap Generates a gait and allowance Go web project. In go apps have a value of. As of December 1st 2019 Buffalo with all related packages require Go Modules and. Authentication in Golang In building web and mobile. Go web examples or go is made against threats to run the example applying the data from the set the search. Why should be restarted for go app. Worth the go because you know that endpoint is welcome page then we created in addition to get started right of. To go apps and examples with fmt library to ensure a very different cloud network algorithms and go such as simple. This example will set users to map support the apps should be capable of examples covers both directories from the performance and application a form and array using firestore implementation.
    [Show full text]
  • A Descent Into Limbo Brian W
    A Descent into Limbo Brian W. Kernighan [email protected] Revised April 2005 by Vita Nuova ABSTRACT ‘‘If, reader, you are slow now to believe What I shall tell, that is no cause for wonder, For I who saw it hardly can accept it.’’ Dante Alighieri, Inferno, Canto XXV. Limbo is a new programming language, designed by Sean Dorward, Phil Winter- bottom, and Rob Pike. Limbo borrows from, among other things, C (expression syntax and control flow), Pascal (declarations), Winterbottom’s Alef (abstract data types and channels), and Hoare’s CSP and Pike’s Newsqueak (processes). Limbo is strongly typed, provides automatic garbage collection, supports only very restricted pointers, and compiles into machine-independent byte code for execution on a virtual machine. This paper is a brief introduction to Limbo. Since Limbo is an integral part of the Inferno system, the examples here illustrate not only the language but also a cer- tain amount about how to write programs to run within Inferno. 1. Introduction This document is a quick look at the basics of Limbo; it is not a replacement for the reference manual. The first section is a short overview of concepts and constructs; subsequent sections illustrate the language with examples. Although Limbo is intended to be used in Inferno, which emphasizes networking and graphical interfaces, the discussion here begins with standard text- manipulation examples, since they require less background to understand. Modules: A Limbo program is a set of modules that cooperate to perform a task. In source form, a module consists of a module declaration that specifies the public interface ߝ the functions, abstract data types, and constants that the module makes visible to other modules ߝ and an implementation that provides the actual code.
    [Show full text]
  • A Native Transterpreter for the LEGO Mindstorms RCX
    Communicating Process Architectures 2007 339 Alistair A. McEwan, Steve Schneider, Wilson Ifill, and Peter Welch IOS Press, 2007 c 2007 The authors and IOS Press. All rights reserved. A Native Transterpreter for the LEGO Mindstorms RCX Jonathan SIMPSON, Christian L. JACOBSEN and Matthew C. JADUD Computing Laboratory, University of Kent, Canterbury, Kent, CT2 7NZ, England. {jon , christian , matt} @transterpreter.org Abstract. The LEGO Mindstorms RCX is a widely deployed educational robotics platform. This paper presents a concurrent operating environment for the Mindstorms RCX, implemented natively using occam-pi running on the Transterpreter virtual ma- chine. A concurrent hardware abstraction layer aids both the developer of the operat- ing system and facilitates the provision of process-oriented interfaces to the underly- ing hardware for students and hobbyists interested in small robotics platforms. Introduction At the University of Kent, we have access to over forty LEGO Mindstorms RCX robotics kits for use in teaching. Additionally, it is our experience through outreach to local secondary schools and competitions like the FIRST LEGO League[1] that the RCX is a widely available educational robotics platform. For this reason, we are interested in a fully-featured occam-π interface to the LEGO Mindstorms. The Transterpreter, a portable runtime for occam-π programs, was originally developed to support teaching concurrent software design in occam2.1 on the Mindstorms[2]. In its original implementation, the Transterpreter ran on top of BrickOS, a POSIX-compliant op- erating system for the RCX[3]. However, as the Transterpreter has grown to support all of occam-π, it has used up all of the available space on the RCX.
    [Show full text]
  • Design and Validation Computer Protocols
    DESIGN AND VALIDATION OF COMPUTER PROTOCOLS Gerard J. Holzmann -----------, PRE NTI CE HALL SOFTWARE SERI ES www.spinroot.com DESIGN AND VALIDATION OF COMPUTER PROTOCOLS Gerard J. Holzmann Bell Laboratories Murray Hill, New Jersey 07974 PRENTICE-HALL Englewood Cliffs, New Jersey 07632 www.spinroot.com Prentice Hall Software Series Brian W. Kernighan, Advisor Copyright 1991 by Lucent Technologies, Bell Laboratories, Incorporated. This book is typeset in Times Roman by the author, using an Linotronic 200P phototypesetter and a DEC VAX 8550 running the 10th Edition of the UNIX operating system. DEC and VAX are trademarks of Digital Equipment Corporation. UNIX is a registered trademark of AT&T. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 Prentice-Hall International (UK) Limited, London Prentice-Hall of Australia Pty. Limited, Sydney Prentice-Hall Canada Inc., Toronto Prentice-Hall Hispanoamericana, S.A., Mexico Prentice-Hall of India Private Limited, New Delhi Prentice-Hall of Japan, Inc., Tokyo Simon & Schuster Asia Pte. Ltd., Singapore Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro www.spinroot.com CONTENTS Foreword ix Preface xi Part I Ð Basics 1. Introduction 1.1 Early Beginnings 1 1.2 The First Networks 9 1.3 Protocols as Languages 12 1.4 Protocol Standardization 13 1.5 Summary 15 Exercises 16 Bibliographic Notes 16 2.
    [Show full text]
  • Dash1.Gz.Pdf
    6DEI >ook M=I JOFAIAJ troff -ms -mpictures|lp -dstdout|ps2pdf En LK?E@= 5=nI >O JDA =KJDoH, KIEnC = LAnoLo 6DEnk2=@ : ! 6=>lAJ HKnnEnC JDA 'BHonJ oFAH=JEnC IOI­ JAm. 4An@AHA@: %--$ '.4ON6 'BHonJ.oHC 6DEI EI = MoHk oB BE?JEon. N=mAI, ?D=H=?JAHI, Fl=?AI =n@ En?E@AnJI AEJDAH =HA JDA FHo@K?J oB JDA =KJDoHߣI Em=CEn=JEon oH =HA KIA@ BE?JEJEoKIlO, =n@ =nO HAIAm>l=n?A Jo =?JK=l FAH­ IonI,lELEnCoH@A=@,>KIEnAIIAI,?omF=nEAI,ALAnJIoHlo?=lAIEIAnJEHAlO?oEn?E@AnJ=l. M16/++/2K>lE?,om=En 9FRONT FREQUENTLY QUESTIONED ANSWERS Those who can do, those who can’t write and those who can’t write make ezines. ߞ 5=FAMKllAn@AH ACHTUNG! 6DEI @o?KmAnJߣI 5647+674- ߞ =n@ IomA oB EJI 6-:6 ߞ EI Fl=CE=HEzA@ ߞ BHomJDAO2-N*5,.)3 ACHTUNG! 601515NO6)52)+- ACHTUNG! 1nBoHm=JEon FHoLE@A@ >O JDEI @o?KmAnJ m=O >A oKJ@=JA@ oH jKIJ Fl=En MHonC.7IAOoKH>H=En.NO4-.7N,5. _sl’s info is incorrect. ߞ =nJD_N i really hate the openbsd content in the fqa ߞ =EjK 0 − Introduction to Plan 9 .-9D=JEI2l=n'? ..-2l=n'EInoJ7N1: ...-2l=n'EInoJFl=n'FoHJ ... -2l=n'EInoJ1nBAHno .. -2l=n'EInoJ=FHo@K?J ..!-2l=n'EInoJBoHOoK . -9DO2l=n'? . .-9D=J@oFAoFlAlEkA=>oKJ2l=n'? . ..-9D=J@oOoKKIA2l=n'BoH? . -9D=J@oFAoFlAD=JA=>oKJ2l=n'? . .-9D=JEInoJEn2l=n' . .!-9DO@E@2l=n'ߣI?HA=JoHICELAKFon2l=n'? . ."-9D=JEIJDA@A=lMEJD2l=n'ߣIMAEH@lE?AnIA? . .".-4E?D=H@5J=llm=nD=JAIJDA2l=nNEnAlE?AnIA?EH?= .
    [Show full text]