PLANB(1)                                                 PLANB(1)

          planb - introduction to Plan B 4th edition

          Plan B is an attempt to build a system designed for dynamic
          distributed environments and provide a convenient computing
          environment.  In a Plan B environment, a user has multiple
          machines and devices.  Machines are assumed to be volatile,
          they may come and go while the user is using the system.

          The environment is made of the set of available machines.
          For example, after starting a player at a machine nearby,
          the user requests to play songs would be serviced by that
          player.  Also, the keyboard and mouse at hand are used with
          any machine and not just with the one they are attached to.

          Resources are exported to the network as file trees. User
          programs and machines may import any resource from the
          network by either importing a particular file tree or asking
          the system to import a file tree with a given name and
          attributes. The system tries to satisfy the import requests
          made and maintains a name space that maps names to
          particular trees that match the given name and attributes.
          If one such trees becomes unavailable, the sytem picks up
          another (matching) one as a replacement.

          Most of the code of the system and most of the system
          applications and libraries are those of Plan 9. This edition
          of Plan B runs as a set of user programs on top of a Plan 9
          system. In this manual, only pages that  are specific for
          Plan B refer to the system by that name.  Pages that
          correspond to things unchanged, ie. taken verbatim from Plan
          9, still refer to the system as Plan 9. Plan 9 manual pages
          that describe elements that have a preferred alternative in
          Plan B, explicitly state this. After reading this page,
          intro(0) is a good thing to read.

        System Organization
          In Plan B, all the machines are considered peers and usually
          run the same system software. Any machine (running Plan B or
          otherwise) may export a resource to the Plan B network and
          behave as a resource server. In particular, we use services
          from Plan 9 authentication servers, Plan 9 file servers,
          Linux tools as voice synthesis device servers, etc.

          Users own multiple Plan B terminals. Most of them are quite
          capable of performing heavy computing and equipped with
          large grahical displays. Each one of the terminals is owned
          by a single user who customizes it to import the desired
          kind of resources from those available.

     PLANB(1)                                                 PLANB(1)

          The I/O devices available, e.g. mouses and keyboards, may be
          used to operate with any of the user machines. In the same
          way, file viewers and other programs may be started at dif-
          ferent machines and work together with the rest of the envi-
          ronment using their name space.

          Once users have shown their preferences by building a name
          space, the system is responsible for adapting to the changes
          of the environment. For most tasks, users can forget about
          where to run processes, where to start interfaces, which
          file trees should be mounted, when should services be
          mounted/unmounted, and so on.

        Name Spaces, Resources, and Volumes
          There are a number of Plan B services available, each of
          which is provided by one or more trees of files. Each file
          tree has a global name and a set of attributes to reflect
          properties of interest.  Each file tree is referred to as a
          volume. For example, audio playing is a service, which pro-
          vides a file tree to play audio.  Each file tree exported to
          the network to provide an interface for audio playing is a
          an audio player volume.

          Therefore, in Plan B, (like in Plan 9), almost all objects
          look like files.  The object retrieved by a given name is
          determined by a namespace that maps names to files.  See
          namespace(4) for the conventions used.  Each process can
          independently customize its namespace. This is done by
          binding or mounting volumes (or subtrees of volumes) to
          names in the name-space-so-far.  Typically, a user starts
          with a name space providing volumes for the conventional
          file tree for the system, and then binds volumes onto parts
          of it. Volumes can be bound explicitly, or by requesting to
          the system to bind them as they become available.

          Plan B has union directories: directories made of several
          directories all bound to the same name, as described in
          intro(1). Besides, there are volume unions where all volumes
          matching the mount request are imported into a single name,
          and not just one of them.

          Volumes mount points are serviced by bns(4), which serves
          file trees to the underlying system and hot-swaps them
          according to volume availability. See the mentioned manual
          page for details on how to mount and use volumes. Upon
          mounting a volume, any volume that matches the name and
          attributes given to mount will be mounted as it becomes
          reacheable. It will be unmounted when it is no longer
          reacheable. Only one of the volumes mounted at a mount point
          will be used at a given time. For example, it is usual to
          call mount so that any audio device volume would be bound to
          /devs/audio.  Although there might be multiple matching

     PLANB(1)                                                 PLANB(1)

          volumes, only one of them will be shown and used by the sys-
          tem. When the volume used becomes unreachable, another one
          will be picked for use.

          When mounting volumes, the user specifies a volume name and
          a set of attribute/value pairs. Only volumes that mach the
          given name and properties will be bound by the system to the
          mount point. An examle is:
          mount /srv/vol /n/audio '/devs/audio user=nemo loc=136'
          that imports into /n/audio any volume with name /devs/audio
          owned by nemo and located at

          Volumes are exported using 9P, described in section 5 of
          this manual, like any other Plan 9 file tree.  All Plan B
          servers read and respond to 9P requests to navigate through
          a file tree and to perform operations such as reading and
          writing files within the tree.

          The volume discovery protocol is implemented by bns(4) and
          adsrv(8) and is used to discover which volumes are available
          for use.

          When a terminal is powered on or reset, booting proceeds
          like in Plan 9, as said in booting(8). The process ends up
          loading into memory a Plan 9 kernel that uses bns(4) as the
          initial process. This process defines several environment
          variables, that guide the boot process, sets up a name space
          that mounts necessary volumes to run other programs, and
          then executes the system script brc(8) and the user's pro-
          file $home/lib/profile as a final step.

          The environment variable $planb is set to value yes on Plan
          B systems.

          The file /lib/namespace.planb determines how the namespace
          is built. This namespace is used to run the system start
          script and the user's profile.  The user's profile usually
          runs the omero(1) window system as the primary user inter-

        Using Plan B
          Using Plan B is very much like using Plan 9, although the
          user can now forget about how to set up a name space for a
          particular network setup.  Users should tell the system what
          kind of resource they want, and let the system choose a par-
          ticular one to satisfy the constraints given by the user.
          Otherwise, the system would not adapt to changes in resource

          The user commands of Plan B are those of Plan 9 in many
          cases. However, Graphical interfaces are provided by the

     PLANB(1)                                                 PLANB(1)

          omero(4) service, which provides portable widgets. Command
          execution is performed through the portfs(4) network messag-
          ing service, by sending requests to the exec port, which
          works for remote machines as well.

          The same happens to the programming interface documented in
          section 2. Most notably, readf(2) is the preferred way for
          file I/O, instead of the venerable read(2) interface. User
          interface programming should rely in omero(2) and not in
          control(2) or draw(2). There are other changes in the API
          that are important to easy adaptation to environment
          changes.  The system is just born and interfaces are still
          evolving quickly, beware of that.

        Physical Environment
          Context information is available at /what, /who, and /where.
          Services to operate and inspect the physical environment are
          available at several directories mounted under /devs.  The
          environment is handled by tools descrived in env(8) and
          other programs.

        User Input
          The character-delete character is backspace, and DEL is the
          interrupt character: typing it sends an interrupt to pro-
          cesses running in that window.  Control is usually the
          caps-lock key, and the left control, start, and alt buttons
          are usually equivalent to the three buttons found in the
          mouse. The menu key permits character composition.  See
          keyboard(6) for instructions.

          The standard editor is ox(1), which works in omero(1) panels
          and integrates well with the rest of the Plan B system.

        Devices and Volumes
          The devices in Plan B are those of Plan 9, described in sec-
          tion 3.  But beware that for some devices, most notably
          graphics, text and mouse I/O, audio, and command execution,
          there are other (preferred) servers documented in section 4
          of this manual. Such servers provide a high-level interface
          designed for applications, and are more portable and adapta-
          tive than the ones described in section 3 of the manual.

          It is advisable to check first section 4 when looking for a
          service, before resorting to the low level interface pro-
          vided by native devices. Note that devices in section 3 com-
          pletelly circunvent the name space and lead to name spaces
          that do not adapt to changes in resouce volumes availabil-

          A Plan 9 file server provides a file tree to processes.  A
          Plan B file server is similar, but is usually implemented to
          provide a volume that can be used with the volume mounting

     PLANB(1)                                                 PLANB(1)

          facility.  This means that the server has options to start
          servicing network requests, announce the volume, and has
          authentication implemented. Authentication is only requested
          for connections from remote machines, because the volume
          owner is the terminal owner in a Plan B installation. See
          planb(4) for a description of Plan B volume file servers and
          other conventions regarding the name space. Conventions
          regarding attributes for volumes are described in cnstr(6).

          intro(1) for a description of the underlying Plan 9 system.
          planb (4) for a description of Plan B conventions regarding
          volume servers and name spaces.
          /sys/doc/9 for white papers on Plan 9 (which of course can
          still apply to Plan B), and /sys/doc/papers for copies of
          Plan B papers that might be of help.

          The system is just born. Bugs are found now and then, but
          the system is stable enough to let us use it as our develop-
          ment platform and to perform our daily work.  Most good
          things come from Plan 9, most bugs are ours instead.