Inferno Programming with Limbo 1st Edition Phillip Stanley-Marbell 2024 Scribd Download
Inferno Programming with Limbo 1st Edition Phillip Stanley-Marbell 2024 Scribd Download
Inferno Programming with Limbo 1st Edition Phillip Stanley-Marbell 2024 Scribd Download
https://ebookultra.com/download/earth-inferno-austin-osman-spare/
ebookultra.com
https://ebookultra.com/download/graphics-programming-with-perl-1st-
edition-martien-verbruggen/
ebookultra.com
https://ebookultra.com/download/maya-programming-with-python-
cookbook-1st-edition-herbez/
ebookultra.com
PHP Programming with PEAR 1st Edition Schmidt Stephan
https://ebookultra.com/download/php-programming-with-pear-1st-edition-
schmidt-stephan/
ebookultra.com
https://ebookultra.com/download/programming-with-c-zambak-1st-edition-
osman-ay/
ebookultra.com
https://ebookultra.com/download/inferno-special-illustrated-edition-
featuring-robert-langdon-dan-brown/
ebookultra.com
https://ebookultra.com/download/excel-programming-with-vba-
starter-1st-edition-robert-martin/
ebookultra.com
Inferno Programming with Limbo 1st Edition Phillip
Stanley-Marbell Digital Instant Download
Author(s): Phillip Stanley-Marbell
ISBN(s): 9780470843529, 0470843527
Edition: 1
File Details: PDF, 28.67 MB
Year: 2003
Language: english
Inferno Programming
with Limbo
This page intentionally left blank
Inferno Programming
with
Limbo
Phillip Stanley-Marbell
Carnegie Mellon University
Copyright © 2003 John Wiley & Sons, Ltd
The Atrium, Southern Gate, Chichester,
West Sussex PO19 8SQ, England
National 01243 779777
International (+44) 1243 779777
Email (for orders and customer service enquiries): cs-books@wiley.co.uk
Visit our Home Page on http://www.wileyeurope.com or http://www.wiley.com
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, scanning or
otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a
licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London WIT 4LP, UK,
without the permission in writing of the Publisher, with the exception of any material supplied specifically
for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser
of the publication. Requests to the Publisher should be addressed to the Permissions Department, John
Wiley & Sons, Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to
permreq@wiley.co.uk, or faxed to (+44) 1243 770620.
Neither the authors nor John Wiley & Sons, Ltd accept any responsibility or liability for loss or damage
occasioned to any person or property through using the material, instructions, methods or ideas contained
herein, or acting or refraining from acting as a result of such use. The authors and publisher expressly
disclaim all implied warranties, including merchantability or fitness for any particular purpose. There will
be no duty on the authors or publisher to correct any errors or defects in the software.
Designations used by companies to distinguish their products are often claimed as trademarks. In all
instances where John Wiley & Sons, Ltd is aware of a claim, the product names appear in capital or all
capital letters. Readers, however, should contact the appropriate companies for more complete information
regarding trademarks and registration.
This publication is designed to provide accurate and authoritative information in regard to the subject
matter covered. It is sold on the understanding that the Publisher is not engaged in rendering profes-
sional services. If professional advice or other expert assistance is required, the services of a competent
professional should be sought.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may
not be available in electronic books.
Preface xiii
1 Introduction 1
1.1 What is Inferno? 1
1.2 History and Overview of Inferno 2
1.3 Limbo 3
1.4 Resources as Filesystems and Per-Process Name Spaces 4
1.5 Networks 4
1.6 Installing the Inferno Emulator 5
1.7 Getting Started with Inferno 6
1.8 Name Spaces and Basic Name Space Configurations 12
1.9 The Inferno Application Development Environment 13
1.10 Summary 21
2 An Overview of Limbo 25
2.1 Introduction to Limbo 25
2.2 Hello World 26
2.3 Discourse on include and load 28
2.4 Some Details 29
2.5 Reserved Identifiers, Operators and Associativity 30
vii
vlii Contents
2.6 Scope 30
2.7 Import Statements 33
2.8 Flow Control 33
2.9 Summary 38
2.10 Chapter Examples 40
Problems 43
3 Data Types 45
3.1 Primitive Data Types 45
3.2 The string Data Type 47
3.3 Reference Versus Value Types 48
3.4 Lists 49
3.5 Arrays 52
3.6 Tuples 57
3.7 ADTs 58
3.8 Type Definitions 71
3.9 Summary 71
3.10 Chapter Examples 73
Problems 74
4 Using Modules 77
4.1 Review 77
4.2 Taking Advantage of Dynamic Module Loading 83
4.3 Module Resource Consumption and Built-in Modules 84
4.4 Self-Referential Modules 84
4.5 Summary 86
4.6 Chapter Example: Xsniff 88
Problems 92
Appendix: Developing Built-in Modules 93
A.I Defining the Module Interface 93
A.2 Generating C Stubs with the Limbo Compiler 94
A.3 Module Function Signatures 95
7 Channels 153
7.1 Introduction 153
7.2 Multi-Way Selection on Channels with alt and Arrays of Channels 156
7.3 Pipelining Computation with Channels 159
7.4 User-Level Filesystems: Files Connected to Channels 161
7.5 Example: A Simple File Server 165
7.6 Summary 169
7.7 Chapter Example: Multiplexing Readers in Simple File Server 170
Problems 172
Appendix: Modeling and Verification of Concurrent Applications
with SPIN 173
x Contents
9 Networking 215
9.1 The /net/ Filesystem 215
9.2 Configuring the Network on the Inferno Emulator 216
9.3 Configuring the Network in Native Inferno 217
9.4 Networking Through Sys Module Calls 220
9.5 Dealing with HTML: The Webgrab, Url and HTML Modules 224
9.6 Summary 231
9.7 Chapter Example: Tunneling Styx Traffic over HTTP 233
Problems 240
11 Graphics 253
11.1 Introduction 253
11.2 Point 256
11.3 Rect 258
11.4 Context 259
11.5 Display and/dev/draw 261
Contents xi
Bibliography 339
Index 345
This page intentionally left blank
Preface
The subject matter of the text is the development of software for the Inferno operating
system, using the Limbo programming language.
Inferno is an operating system for building distributed applications in networked
environments. It is targeted at resource-constrained computing systems such as set-
top boxes, PDAs and point-of-sale terminals, which usually have limited computing
resources, are networked and often need to handle multimedia such as streaming
audio or video. It was designed from the ground up to address these issues.
Inferno derives its heritage from the creators of the Unix and Plan 9 operating
systems and the C and C++ programming languages, Lucent Technologies' Bell Labs.
Inferno has recently been made freely available to the general public in binary form,
and source code is available for a small fee under an open-source-like licence. Limbo
is the programming language in which applications for Inferno are written.
Purpose
This book is intended as a comprehensive guide for programmers who wish to develop
applications for the Inferno operating system, with an emphasis on taking advantage
of its unique capabilities. The text provides a brief introduction to the installation and
use of Inferno, and an in-depth exposition and solid reference for developing Inferno
applications in Limbo.
xiii
xiv Preface
Target Audience
The text is targeted primarily at professionals who will be developing applications
in the Limbo language for Inferno and is therefore structured as a self-study text. It
is also suitable for use as a college-level text, providing end-of-chapter exercises to
further develop the concepts introduced in each chapter. For both the professional
audience and the college student, a familiarity with programming languages such as
Pascal, C/C++ or Java is assumed. It is not meant to be an introductory programming
text.
Every attempt has been made to keep the book as self-contained as possible, mak-
ing it an ideal introduction as well as a handy reference. Readers will appreciate the
practical approach of the text. Each chapter concludes with an analysis of a complete
representative application that uses concepts introduced in the chapter, which may
be used as a starting point for developing the reader's own applications. The exam-
ple discussion further serves to point out common pitfalls when programming with
concepts introduced in that chapter. The tone of the book is intended to be refreshing,
and every attempt is made to keep the presentation and discussions lively.
Material Covered
1 Introduction
An introduction to the Inferno Operating System, its origin, design and use.
A description of the heritage of the Limbo language, its origins and how it
compares to other contemporary programming languages. Resources as files
and per-process name spaces. Installing Inferno and setting up user accounts.
The Inferno application development environment.
2 An Overview of Limbo
An introduction to Limbo programming. The basic structure of Limbo pro-
grams. Operators. Flow control.
3 Data Types
An overview of the basic data types in Limbo.
4 Using Modules
Using modules to structure applications. Developing Inferno built-in modules.
5 System Input and Output
Performing program input and output in Limbo. The Inferno built-in system
module.
Preface xv
Conventions
Throughout the text, a handful of conventions are used to distinguish between differ-
ent types of material.
Path names are listed relative to the root of the Inferno distribution and are dis-
played in a teletype font, in-line in the text. For example, /appl/cmd/sort.b. IP
addresses and host names are also displayed in a tel etype font.
Code fragments and command shell transcripts are listed in shaded boxes such as
the following:
xvi Preface
Variable names and Limbo module names appear in tel etype font when they are
being discussed; for example, one may refer to a variable vari abl ename.
Inferno command-line utilities and other services are displayed in italics, with the
section number of their respective manual pages in parenthesis. For example, the
manual page for the application for displaying manual pages is referred to as manCL),
as its page is in Section 1 of the Inferno manual. Other applications, such as those
developed in this text, are referred to by their name in italics.
Acknowledgments
Thanks to all those who provided encouragement at various stages of this work,
spread over almost five years. I could not possibly mention by name all those who,
either by their encouraging remarks or outright derision, have helped keep me mo-
tivated. Truman Boyes, Russ Cox, Vasilios Daskalopoulos, Ben Lui, Nebahat Noyan,
Matthew Riben, Seth Rubenstein and Simon Wong all read early versions of the
manuscript and provided valuable feedback. Truman Boyes, Ben Brewer, Jon Ober-
ton, Andrew Sylvia and the collective energies of suspicious.org helped refine the
final versions of the manuscript.
Bengt Kleberg, Vasilios Daskalopoulos and Vincent Matossian deserve special men-
tion for their detailed reviews of many of the chapters of this book. Their feedback
was invaluable. The artwork preceding each chapter was created (all in one night!)
by Nebahat Noyan.
Last, but most importantly, I would like to thank the fine folk at Wiley and elsewhere
who helped make this happen: Karen Mosman and Gaynor Redvers-Mutton (my
editors in succession at Wiley), Jill Jeffries, Robert Hambrook (my production editor
at Wiley), Jonathan Wainwright (my copy-editor at T&T Productions), whom I drove
crazy with PDF sticky notes (almost 400 in one revision!)—Thanks Jon!—and countless
others whom I will probably never know.
This document was typeset using free software. The typesetting was done in KTgX,
primarily on computers running derivatives of the 4.4BSD operating system.
Phillip Stanley-Marbell
Pittsburgh, PA
This page intentionally left blank
1
Introduction
This chapter provides an introduction to Inferno, its history, underlying concepts and
construction. Also described in this chapter are the procedures for installing and
configuring an Inferno system, and the basic tools provided for editing, compiling
and debugging Limbo programs.
applications from the details of the underlying hardware. Having versions of Inferno
that run both on bare hardware and in emulated environments lends a degree of
flexibility in application development that is rare among operating systems. A devel-
oper, in order to develop applications for Inferno, therefore need not have access to
hardware that will run Inferno natively.
Figure 1.1 Organization of components in Inferno running directly over hardware (i.e. native Inferno).
Figures 1.1 and 1.2 illustrate the organization of components in the native and
emulated versions of Inferno, respectively. The emulated and native environments are
identical above the Dis virtual machine (Dis VM). Native Inferno, which runs over bare
hardware, provides the necessary OS support to the Dis VM, whereas the emulated
version of Inferno relies on the facilities of the host operating system. The facilities
required of the host operating system include performing I/O and scheduling Dis
VM threads. These Dis VM threads are threads (or processes, depending on the host
platform) of the Dis VM itself. The Dis VM contains an internal scheduler for scheduling
Limbo threads running over the VM. This is separate from the host platform's thread
or process scheduling in the emulator, and from the process scheduling in native
Inferno (which schedules Dis VM processes and the like, not Limbo threads).
decidedly commercial project that would later on be named Inferno' (after The Inferno,
vol. I of Dante Alighieri's Divine Comedy) 1 .
Several of the features of Plan 9 saw their way into Inferno. Unlike Plan 9, however,
Inferno comes with a virtual machine, the Dis VM, to enable portability of Inferno ap-
plications across different hardware platforms. Dis has a memory-to-memory archi-
tecture as opposed to a stack architecture as in the Java virtual machine. A memory-to-
memory architecture is essentially an infinite-register machine, with as many registers
as there are words of memory. This simplifies on-the-fly compilation on most mod-
ern target architectures. At the time of the development of Inferno, the developers
realized they needed a secure, type-safe, garbage-collected language. The developers
considered using Java, but Java was in a state of flux and they decided they would
rather deal with their own language that would be changing as it evolved rather than
someone else's moving target [64]. Unlike Java, Limbo is not object oriented; however,
it does support code reuse via modular programming.
1.3 Limbo
Limbo was designed by Sean Dorward, Rob Pike and Phil Winterbottom. It has cer-
tain features of other programming languages like Pascal (declarations), Alef (chan-
nels, ADTs), Occam (channels), Hoare's Communicating Sequential Processes (CSP)
(channels, alternating on channels), Newsqueak, ML (module system, compile-time
1This naming decision was made because a member of the team (Rob Pike) had been reading the Divine
Comedy at the time and noted that it would provide a rich source of names.
4 Introduction
type checking, garbage collection), and introduces ideas of its own. Limbo employs
strong type checking both at compile- and runtime, automatic garbage collection, and
inter-thread communication over typed channels. Limbo was designed for the devel-
opment of distributed applications. Its implementation makes it suitable for use on
machines that do not have memory protection hardware such as a hardware memory
management unit (MMU). There are no pointers in Limbo, and the language pre-
vents direct access to machine memory—the virtual machine and the Limbo compiler
cooperate to provide the functionality of memory protection. Limbo is compiled to
machine-independent byte-code for execution on the Dis VM.
1.5 Networks
Inferno (and to a lesser extent the Inferno emulator) supports a wide variety of inter-
networking protocols, such as IP, TCP/IP, UDP/IP, ICMP, GRE and ESP to name a
few. Communication between Inferno devices is typically in the form of messages
in a protocol called Styx, usually running over TCP/IP. Styx is a remote procedure
call protocol similar to the NFS RPC protocol [69] (though significantly simpler in
both design and implementation). Unlike NFS RPC, Styx is stateful, and a Styx server
maintains information on connected clients.
Installing the Inferno Emulator 5
The - r flag specifies the location of the Inferno root. Be careful that there is no
whitespace between the - r flag and the path name. Further options accepted by the
emulator command are detailed in the manual page for the emulator, which can be
viewed by typing man emu from within the emulator. The manual page for emu (and
other useful ones) are included in the appendices to this book.
There is nothing more in the setup that is specific to Windows platforms, and
everything else is a matter of configuring your Inferno system correctly, from within
the emulator.
host system, or whatever name you want the administrative user within Inferno to be
called.
1.6.3 Plan 9
The default installation location of Inferno on Plan 9 is in /usr/inferno. You can
override the root directory that the emulator knows of by using the - r/<path>/ flag
when starting up the emulator. To be able to cleanly run Inferno services, you need
to add the contents of the file /services/cs/services from your Inferno root to
/lib/ndb/1oca!. You will also need to create a user called 'inferno' on the host
system, or whatever name you want the administrative user within Inferno to be
called.
Figure 1.3 The initial console login prompt after starting the emulator.
1.7.1 Overview
After launching the emulator executable, you will be presented with the Inferno con-
sole, shown in Figure 1.3.
The Inferno graphical environment can be started by launching either the login
window manager interface shown in Figure 1.4, by typing wm/logon at the initial
Getting Started with Inferno 7
Inferno console, or launching directly into the window manager by typing wm/wm.
Once logged in, command consoles or shells can be opened via the button on the
lower left of the screen, as illustrated in Figure 1.5.
For those familiar with operating systems such as Unix and its derivatives, a few
of the familiar commands are also available in Inferno; ls(l) provides a listing of files
in the current directory, and accepts many of the command-line flags available in
Unix-like systems: cd(i) changes the current working directory; ps(1) provides a list
of launched threads; du(1) provides a listing of disk usage statistics, etc. There are
some new commands and variants of old commands: lc(l) provides a columnized
output of the contents of the current working directory. These commands and a few
more are illustrated below. Each line of the output of the ps command shows the
thread ID, thread group ID, user executing the thread, state of the thread, memory
size and module name, respectively:
8 Introduction
The command kill(l) takes as argument a thread ID or Limbo module name, and
terminates the corresponding thread or the threads executing the specified module,
respectively. More information is available from the Inferno command line or shell
by typing 'man' followed by a command, utility or application name.
the Inferno emulator, this user must have an account on the host system, i.e. on Unix
platforms there must be a user 'inferno' if your administrative user within Inferno is
going to be 'inferno'. This is because the Inferno emulator exports the file ownership
and permissions from the host system to the emulator level. Thus, for each user that
has an account to login to the emulator, there should be a corresponding user with
the same name on the host system (hopefully the same user!), but not necessarily the
same password.
Users are added to the system by creating home directories with their user names
under the /usr/ directory of the Inferno root. The directory 1ib/ in a user's home
directory conventionally contains per-user configuration files, such as rule sets for
the plumber(8) inter-application message router. The directory keyring/ is used for
holding certificates obtained from a certifying authority. The directory charon/ is
used to hold user configuration information and bookmarks for the Charon Web
browser. These directories have to be created for each user added to the system with
the mkdir(1) command. The creation of these directories is a separate process from
the creation of user passwords, to be described next. Figure 1.6 shows the top-level
hierarchy of a typical Inferno filesystem.
Figure 1.7 Adding a new user with the change login command.
User passwords are set on an authentication server via the changelogin(8) utility.
Passwords are stored in the file /keydb/password. The change login command
changes the password of a user with a current password entry or creates a new entry
in the /keydb/password file for a new user. To run change login, you need to have
write permission on /keydb/password, so this can only be done by the administrative
user. Figure 1.7 shows a typical session of the changelogin program.
Figure 1.8 Editing the connection server database in the Brutus editor. The connection server database
file has the name of the service in the first column and the name or IP address of the machine providing
that service in the second.
12 Introduction
The pctl system call is used to modify properties of a thread's name space, such as
detaching its name space from its parent's.
A default name space is constructed upon login, based on the contents of the
namespace file in the user's home directory. This is achieved through the nsbuild(l)
Inferno utility. In most scenarios, this is either invoked by the wm/logon login pro-
gram or wm/wm, the default window manager. The layout of the name space file is
described in detail in the manual page for namespace (6). In brief, it contains strings
which are interpreted as commands to perform operations on the name space through
bind, mount, unmount and pctl.
Figure 1.9 illustrates the operation of bind and mount system calls, using the equiv-
alent Inferno utilities from the command shell. In the figure, a host, nonetstack.
gemusehaken.org, has no network protocol stack implementation, but has an im-
plementation of Styx over a serial RS-232 line. It attaches the interface to the net-
work protocol stack of the host gw.gemusehaken.org into its local name space
through a mount operation, and subsequently positions it into the default network
protocol stack filesystem interface location through a bind operation. Subsequent to
these steps, the network protocol stack of gw. gemusehaken. org will appear local to
nonetstack.gemusehaken.org.
Applications which engage in network communication via TCP/IP will be using the
network protocol stack of the gw. gemusehaken .org host. Each network access will
cause the generation of Styx messages over the serial line to gw.gemusehaken.org,
where they will be received by the network protocol stack driver. Note that it is only
the interface to the protocol stack that is made local to nonetstack. gemusehaken .org.
All the network traffic to the outside world is being handled by gw. gemusehaken. org,
and nonetstack.gemusehaken.org only receives data that it explicitly requests,
through the protocol stack interface. Network communication and the structure of the
filesystem presented by the network protocol implementations is described further
in Chapter 9.
The Limbo compiler takes Limbo source files, ending with the extension '.b' by
convention, and produces executables for the Dis VM, with the conventional extension
'.dis'. The compiler will also generate a separate file containing symbolic debugging
information to be used by a debugger. In addition to its use in developing Limbo
programs, the Limbo compiler also provides facilities to ease the development of C
language modules that interact with Limbo applications, so-called built-in modules.
This use is discussed in detail in the appendix to Chapter 4. The following examples
illustrate some modes of use of the Limbo compiler.
Calling the Limbo compiler without any arguments prints a brief summary of its
usage. In the following example, the source file name is webdi ct. b and the resulting
executable is webdict. dis. The executable can then be run by either giving its full
file name or its file name without the '.dis' extension:
2The mechanism by which . sbl files are located by Stack and other debugging programs is described
in their respective manual pages.
The Inferno Application Development Environment 17
The Limbo compiler can generate warnings on potentially erroneous (but syn-
tactically correct) statements and expressions in Limbo programs with the -w flag.
Supplying more w's in the flag enables more verbosity:
18 Introduction
side shows a directory listing of the path /usr/pi p, and the window on the lower
right is a command shell. The top row of each text window is an editable menu bar,
often referred to as the tag of the window. In the case of the text window containing
all five text windows previously mentioned, the menu bar contains the text strings
Newcol K i l l Putall Dump Exit and the phrase limbo -g small, b.
Each of these items, which can be edited, can be executed by highlighting and
clicking with the middle mouse button (button-2). In the figure, the phrase 1 i mbo -g
smal 1, b has been highlighted, and clicking on it with the middle mouse button will
cause the compilation of the program (smal 1. b) being edited in the Acme window
on the left. For single-word commands, highlighting is not necessary. For example,
clicking on Exit with mouse button-2 will exit from Acme. Some of the more com-
monly used commands in Acme are listed in Table 1.1. Any new commands may be
typed into the menu bar and executed at convenience in this manner. More details
on Acme are provided in its manual pages, acme(l) and acme(4).
Acme is the environment of choice for writing and debugging Inferno applications.
A sample Acme session is shown in Figure 1.12, illustrating some of Acme's capabili-
ties. In the figure, a text file, /usr/pip/hel1o. b, is open for editing in the left half of
Acme. In the right half, there are four sections. The three uppermost window sections
show the contents of three directories, the last being the directory containing the file
hell o. b. The last section of the right-hand side is a window running the program
win, which is an interface to the shell.
20 Introduction
In the shell window at the lower right of Figure 1.12, an attempt has been made to
compile hel1o. b. It has resulted in an error message of the form hel1o. b: 6: syntax
error. Right clicking on this string automatically moves the mouse into the window
containing hel1o. b (or opens it in a new window for editing if it is currently not being
edited), and the faulting line (line 6) is highlighted. A more detailed description of
Acme can be found in its manual pages.
Figure 1.13 Attaching the debugger to an already existent thread—selecting the thread from the list
of running threads in the system.
Figure 1,14 The graphical debugger after attaching it to the SimpleHTTPD thread. The highlighted
source statement is the currently executing statement in the application.
selecting the SimpleHTTPD thread from the list of threads in the window that pops
up, as illustrated in Figure 1.13.
Once the debugger has been attached to a thread, the main debugger window
displays the source of the running application, with the currently running statement
highlighted, as illustrated in Figure 1.14.
The values of variables and other module information may now be probed from
the stack window of the debugger, as illustrated in Figure 1.15. The running program
may be stepped through, stopped, breakpoints inserted, etc., using the buttons on the
top row of the main debugger window.
1.10 Summary
This introductory section has provided a brief overview of Inferno and a walk-through
of how to perform an installation, and we have touched upon how to edit, compile and
debug Limbo applications. The next chapter provides an introduction to the Limbo
language.
22 Introduction
Bibliographic Notes
More detailed histories of Unix can be found in [34, 68]. The Plan 9 operating sys-
tem is described in [53, 54] and further in the accompanying system documentation
available from [55]. Overviews of the Inferno operating system and Limbo language
are provided in [15, 61, 75]. Brian Kernighan's A Descent into Limbo [27] was the ear-
liest tutorial on programming Inferno in Limbo. The use of Inferno for developing
distributed applications is discussed in [72]. Developing and debugging under In-
ferno are also described in [60]. Inferno's Styx protocol is described in [65]. The Dis
virtual machine is described further in [31,82], and its garbage collection mechanism
in [26]. Execution of Java programs under Inferno, by translating Java byte-code to
Dis instructions is described in [85]. The installation process for Inferno is described
further in the Inferno system manuals [80]. The Acme programming environment,
which originally appeared in the Plan 9 operating system is described in [51], and
borrows some ideas from Wirth's Oberon system [84]. Commercial products which
have employed Inferno to date include the Philips Consumer Communications /S2630
Screen Phone, Lucent Technologies' PathStar Access Server, which is described in [18],
and Lucent Technologies' VPN Fireivall Brick [19, 20,43].
This page intentionally left blank
2
An Overview of Limbo
25
26 An Overview of Limbo
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
ebookultra.com