Skip navigation.

exploreopera

| Help

Sign up | Help

Posts tagged with "plan9"

glenda blues

, ,

Eric Van Hensbergen, main developer of the 9p Linux kernel module, has been involved in porting Plan 9 to the Blue Gene/l architecture.

Initial attempts seemed to be quite successful: the kernel would boot, and the machine would sensibly reply to simple commands.

But then there was a funny turn - or should I rather say things went totally wild? It turned out that the apparently unexplainable crashers were not, as initially suspected, caused by some weird memory corruption -

The cores were executing in such precise synchronization (in the same memory space no less) that they even were writing the same characters to the console buffers and incrementing the console pointer to the same value.


When getting ethernet configured the two processors would start producing ddoouubbllee ccoonnssoollee oouuttppuutt, and then they would go back into sync! It is rare to read about such freaky stuff, totally and utterly broken, yet somehow functioning…

Latest reports however tell us that things got sorted out and it is now possible to cpu(1) into Blue Gene/l.

Progress seems to be fast…

fossil+venti - and a network!

I have been running Plan 9 on one of my machines for quite a while now. My first installation had been a clean, default fossil installation. Before starting to choose some extra features, it is best to get to know how the system actually works.

But then I decided to explore more, and discover the joys of venti. So I nuked my previous installation, formatted the partition, and made a default fossil+venti installation. And here my trouble started.

Venti

At reboot I started getting lots of error messages:

ventiSend vtWrite block 0xa failed: not connected to venti server
archWalk 0xa failed; ptr is in 0x7 offset 0
archWalk 0x7 failed; ptr is in 0x5 offset 0
archWalk 0xae71 failed; ptr is in 0xae70 offset 0
archWalk 0xae70 failed; ptr is in 0xae6f offset 0
archiveBlock 0xae6f: not connected to Venti server

Now what? I had accurately followed the installation instructions on the wiki and naively had been hoping it would work. Half a day of playing around with various solutions, and I realized that there was only one thing missing: telling the fossil file system where venti actually was - just one line was missing in the plan9.ini file.

When rebooting after installation, start 9fat: (yes, the colon is important) and edit /n/9fat/plan9.ini, adding one line:

venti=/dev/sdC1/arenas

Make sure this points to where you configured the arenas to be - and then reboot.

Network

That is the first step - and then I fell flat on the second one. I had a system now, with fossil+venti, so I quickly reconfigured my network settings - naively expecting them to work. Why shouldn't they, after all - that exact configuration was nicely working on my fossil system.

Well, at reboot I was now greated with a message:

ndb/dns: cannot read my ip address

and any networking that would require a name resolution was not working - so I wasn't even able to mount /n/sources. It took me quite a while to make sure that everything was configured as in the last known-to-work system. To no avail. Digging through the mailing list archives brought up other similar experiences - but no solution.

Some investigations later, here is what seems to happen: the kernel sets up a loopback device for venti to listen on. When termrc starts, the device is busy, and the machine fails to query the DHCP server for it's IP address, and anything else from there goes down the drain. The solution is simple: do not check if /net/ipifc/0/ctl exists before starting ip/ipconfig and ndb/dns - modify /rc/bin/termrc to simply run:

ip/ipconfig >/dev/null >[2=1]
ndb/dns -rf $NDBFILE

Voilà, a fossil+venti system - with a network!

trees and threads

, ,

…a beautiful UNIX history diagram [jpg, 2.4M] I recently found (and may I suggest, for the ease of inspection, to enable some fit-to-width feature your browser might offer for those occasions you find some too wide image)…

WIMP is dead

, , , ...

The WIMP paradigm is an antiquate paradigm. We are tired of WIMP interfaces. What is needed is some new approach to interacting with computers. There are few, but very interesting projects in the UNIX world trying to propose new approaches - namely two light-weight, easily configurable window managers.

ion3

ion3 deserves first mention. Not because it was first, or because it is *the best* - there is no such thing as *the best* solution fitting every user. Each user needs to discover her own most useful interaction. There is no dogma in what is right and what is wrong - but everyone has to *search* for his or her own "best" solution. Do not take anything for granted.

So ion3 is my favourite.

First off: what actually is ion3? Ion3 is a tailed and tabbed window manager, designed to be completely usable with keyboard only, and designed to put the window manager in charge of… well, managing windows - the user shouldn't have to waste time with arranging and resizing windows.

The tiled approach allows you to make best use of your screen estate. The traditional arrangement of windows on the desktop is everything but sensible: the tiled space will place all windows next to each other, not overlapping, according to a predefined "grid" you have set up: once. No more need to grab the mouse as a first thing after creating a new window and resizing it to what you like it to be, no more dragging the window into the position on the screen you want it to be - after telling the window manager once, it will do the job for you and place windows into the frames your grid defines.

Ion3's tabbed approach allows you to have several windows in one frame: the title bar will be divided into as many tabs as there are applications in that frame.

Keyboard!

One special plus point for ion3 is that it has been designed with keyboard users in mind: everything you can do in ion3 is possible to achieve without mouse. Of course this doesn't mean that you cannot use the mouse at all, but you can decide not to use it. Ion3 presents a minimal user interface, no icons, no buttons on title bars, no wasted space.

Most applications that have a GUI written in accordance with the ICCCM behave very well in ion3, some (few, to be honest) other applications that want to manage their own GUI fit a bit less well into ion's approach.

One of the things I like most about ion3 is its way of handling transient windows, i.e. temporary windows that belong to a main window, like e.g. dialog windows. Ion3 will not assign a frame on their own to these transients, but truely place them almost as "floating" *inside* the main window. This approach will guarantee that the transients always belong to their parent - preventing one of the major annoyances users complain about when using e.g. dual screen.

Why not?

Ion3 is certainly not a window manager for everybody, and its usability requires a certain learning curve. Furthermore, Ion3 is not what you are looking for if you belong to those that primarily are looking for a shiny GUI: it offers a very lean, simple interface, and development focus is on its functionality rather than its "look". There has been a start for a Cairo drawing engine to enhance the look of the tabs, and a ptach is provided in case you are looking for xft fonts for the GUI - but none of them are official, nor really maintained.

wmii

Another project moving away from the WIMP approach is the window manager wmii - a tiled, tagged, *dynamic* window manager. It is strongly influenced by Plan 9's acme, rearranging windows dynamically for the best usage of screen real estate. If you are not familiar with acme's window management you might wonder whether this actually can ever work - but you'll be surprised by how usable this approach actually is.

Tagging

wmii introduces tagging, a new approach aimed at replacing tabs: each window gets a tag, and windows can be grouped according to their tags. The idea of switching to a different workspace gets replaced by the principle of views: a view is a set of clients matching a specific tag.

As much as ion3, wmii is not the window manager you are looking for if you need shiny, polished 3D surfaces - both window managers grow out of the console culture and retain the primarily text-based approach.

wmii gets my sympathy note mainly because this was the project that made me discover Plan 9: an older version of this window manager was based on a version of Plan 9 from User Space tools, and that got me curious…

Make your choice

My main concern is not to promote one or the other solution - every user has different requirements and will find answers and solutions in different places. It is however important, in my personal view, to make a choice about how you want to interact with your computer and search for your best solution - don't take things for granted, don't assume the long-aged desktop paradigm is the only, let alone the best solution. Needless to say, this might require some experimenting and discovering: be open to it, explore different approaches - and what you will learn from it will certainly be rewarding.

how tux met glenda

, ,

I have been running Plan 9 on one of my machines since February - first on-and-off from the CD, later giving it a more permanent dwelling on one of the disks.

Obviously I want to access the machine from other machines on the network - and since Linux supports the 9p filesystem in the main-line kernel since 2.6.14, it was extremely easy to set up.

Glenda

The first step is to set up the Plan 9 machine to allow a connection to its filesystem - the easiest way of doing so is to tell the fossil filesystem itself to listen to incoming connections:

term% con /srv/fscons
prompt: listen -N tcp!*!564
prompt: listen -N il!*!17008
prompt:

The right-most argument to listen is in the form net!host!service: basically we told fossil to listen on port 564 to any host, speaking the tcp protocol, and on port 17008 speaking the il protocol. The -N option tells the filesystem that an un-authenticated user may connect at any time (else he would be only allowed to connect from a certain machine after an authenticated user has connected) - keep in mind that you should use this only in secure environments - obviously you can be more restrictive with the IP address allowed to connect, and remove the -N flag to require authentication. That's about everything we need to do on the Plan 9 machine.

Tux

Next we switch back to the Linux system. Make sure you are running with support for 9p - enable CONFIG_9P_FS=m in the kernel .config file. (Note: the former 9p2000 module goes now under the name of 9p). You will also need the plan9port tools installed.

Start the factotum and the network file service:

$ factotum
$ srv plan_9_machine_ip

and then mount the Plan 9 machine:

$ sudo mount -t 9p -o proto=tcp plan_9_machine_ip /mnt/9/

That's all. Enjoy!

Note for the curious:

…or the uninformed: Tux and Glenda are, respectively, the Linux and Plan 9 mascottes.

lost in outer space

, ,

I want more Plan 9 users. It's a great kernel, but it's going to continue to fall behind if we don't get more people on it.

Recently a long thread on the 9fans mailing list touched several important questions about Plan 9 and its use, and boiled down to: what does plan 9 do better that people actually care about?

I do not want to sum up the long and interesting thread, but a few points raised seem worth to be isolated.

Desktop environment

Plan 9 offers a very interesting desktop environment with an extremely innovative user interface, maybe best described by Ron in a post to the thread:

linux nowadays is all about building a windows desktop. BORING. Or a Mac OSX ripoff desktop. BORING. And just look at all that great vista stuff. oh boy, I can slant my windows or something. Who the F*** cares?

What if you had a window manager that could be recursive? that would set it up so you can name windows by a path name? that would let you treat the recursive desktops -- to any level -- as just another window? that would trivially allow you to connect mouse clicks in a window to control actions for one or more other windows (i.e. you could logically group windows and then control all of them via mouse clicks)? That would maybe let you easily connect output from a process in one window to another? that would let you build little widgets that could easily control other windows? That would let you display all window state in another window? That would let you set, say, all windows with a browser with the label abaco-### (### a number), with a simple text command; and let you find all windows with the label abaco.* with, in the limit, a grep? That would make it easy to group all windows with the label 'abaco.*' so that you could say 'hide all abaco' with a simple script?

Wouldn't that be neat? I mean, that's a real bitch in X, right?

Except ... you already have it.

The user input is not as clearly separated into mouse vs. keyboard, as it is in the UNIX world - but it presents a very interesting combination of both. Mouse and keyboard interaction are combined in a rather uncommon way, complementing each other. After an initial period necessary to getting used to it, I find it to be one of the most well-working UIs - I rarely came across moments when it wouldn't *do what I mean*.

Plan 9 is not UNIX. Plan 9 is spartan and lean, and also very effective, and "quieter" than Linux. A full Plan 9 desktop has less OS noise than a Linux box at the login prompt. This matters. It seems to have the basis for an interesting and appealing desktop operating system, but it lacks users - and killer applications to attract new users. The recent effort to get v9fs into the mainline Linux kernel, as well as a project to port gcc 4.1 to Plan 9 could be the first steps to convince some people that Plan9 (kernel) is a useful alternative to Linux without asking them to rewrite all their applications.

outer space is getting closer…

, ,

Since my first experiments with the 9P filesystem on linux, a number of things changed:

Several bugs got fixed both in the client and the server code, and things start looking brighter for use. The main hurdle for deployment is, at this very stage, (the lack of) security support - not a small one, though… Any serious deployment has to wait for this feature to be fully implemented, but experimenting in safe environments can already be done.

npfs

A special note is needed for npfs - there is no ready package yet, and you'll need to get it from the CVS repository:

$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/npfs login
$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/npfs co -P npfs

And now the trouble might start: the configuration script and the Makefile do not catch your environment well enough to allow for the simple and well-known `./configure` and `make`. I do not know how to solve problems on anything but Linux, and I do not know how to solve them for various environments.

First thing, if you are compiling on Linux: don't run `./configure`: it will only break stuff that else might have worked. Specifically, you might need to check in the Makefiles that libnpfs/mount-Linux.c gets compiled.

I myself did not have libaio installed: the feature is not protected well enough, so you manually need to make sure not to reference it:

In the file fs/ufs.c comment out the block:

//#if SYSNAME == Linux
//#define NPFS_USE_AIO
//#define NPFS_USE_AIO
//#endif

and then manually purge every Makefile of the string -laio. You are now ready to go, and `make` will provide you a npfs server.

Get it going!

The new npfs is much more flexible than the old u9fs and easily allows you to mount the 9P filesystem in userspace (replace the username me with your own username):

  1. `mkdir ~/mnt/9/`;
  2. `./npfs -s -p 5640&`;
  3. `sudo mount -t 9P 10.0.0.1 /home/me/mnt/9 -o port=5640,name=me&` - sudo here is only needed because of how mount is designed on Unix systems; I am confident that we'll soon see some fuse way of mounting in userspace;
  4. `ls ~/mnt/9/`.

Have fun!

from hell with love

Just a few notes to register my experiments, in order to remember, later, how I did stuff… and maybe useful for somebody who wants to go through the steps himself.

Got around to expriment a bit with Inferno, a Plan 9 based compact operating system designed for building distributed and networked systems.

Installation instructions are pretty straightforward. I did this on two machines of my local net (installing to userspace), then proceded to boot the systems up and get them to talk to each other. One of them functions as key and file server, the other one is the client. The online installation documentation [PDF] is very detailed.

Setting up the server

As a start, take care to edit the network setup file. I have installed Inferno in userspace to /home/csant/inferno - this file is the inferno_root. Open the file inferno_root/lib/ndb/local and in the section infernosite= edit SIGNER and FILESERVER to point to your local machine, say

SIGNER=10.0.0.5
FILESERVER=10.0.0.5

The file inferno_root/lib/ndb/inferno will also tell you which ports the system will need - if you run a firewall, it might be a good idea to make sure now that the other machine will be able to use these ports through your firewall, to avoid some grief later.

You'll now start the system that will function as server with the command line emu -r/home/csant/inferno, which tells it where to find its root. Next you are at the prompt.

;

I will not get into details on the shell, but lead you through the setup, providing commands you'll have to enter, and shell output.

First we set up the correct time:

; cp /locale/CET /locale/timezone

You can check out your initial namespace:

; ns
bind / /
bind -ac '#U' /
bind /dev /dev
bind -b '#c' /dev
bind '#p' /prog
bind '#d' /fd
bind /net /net
bind -a '#I' /net
bind -a /dev /dev
bind -a /net /net
bind /net.alt /net.alt
bind -a /net.alt /net.alt
bind -c '#e' /env
cd /

Now prepare a clean file of secrets:

; cp /dev/null /keydb/keys; chmod 600 /keydb/keys

and create a new entry for your network signer (either a fully qualified domain name, or an individual):

; auth/createsignerkey csant

Next start the authentication network services:

; svc/auth
Key: 
Confirm key:

The command ps should tell you if they are running:

; ps
       1        1      csant    0:00.0    release    73K Sh[$Sys]
      14       13      csant    0:00.0        alt    17K Cs
      18       17      csant    0:00.0       recv    25K Keyfs
      19       17      csant    0:00.0    release    47K Styx[$Sys]
      20       17      csant    0:00.0       recv    25K Keyfs
      22        1      csant    0:00.0        alt     9K Listen
      24        1      csant    0:00.0    release     9K Listen[$Sys]
      26        1      csant    0:00.0        alt     9K Listen
      28        1      csant    0:00.0    release     9K Listen[$Sys]
      30        1      csant    0:00.0        alt     9K Listen
      32        1      csant    0:00.0    release     9K Listen[$Sys]
      34        1      csant    0:00.0        alt     9K Listen
      36        1      csant    0:00.0    release     9K Listen[$Sys]
      37        1      csant    0:00.0      ready    73K Ps[$Sys]

Next create the users that will be allowed to authenticate with the signer:

; auth/changelogin csant
new account
secret: 
confirm: 
expires [DDMMYYYY/permanent, return = 21022007]: 
change written

and we need to generate a server key set - we'll obtain a certificate and save it in a file named default:

; getauthinfo default
use signer [$SIGNER]: localhost
remote user name [csant]: csant
password: 
listen: got connection on tcp!*!inflogin from 127.0.0.1!22226
save in file [yes]: yes

Our server is now up and running - time to get the client configured.

Setting up the client

The client is much less complicated to set up - he will get all information from the server. We'll edit the network setting file inferno_root/lib/ndb/local and enter the same values as for the server - yes, because the server will be 10.0.0.5. We assume the inferno_root is the same as above, just on another machine.

First start inferno on the client (in our case on 10.0.0.6) with the same command emu -r/home/csant/inferno.

Start your network and the connection server:

; ndb/cs

and get a certificate from the server:

; getauthinfo tcp!10.0.0.5
use signer [$SIGNER]: 10.0.0.5
remote user name [csant]: csant
password:
save in file [yes]: yes

We are authenticated - time to mount the remote machine and resources:

; mount 10.0.0.5 /n/remote

and you are ready for using your new distributed network operating system.

Disclaimer: did I ever say this was useful for something?

plan 9 from outer space…

, ,

…to your Linux box.

v9fs, the 9P file system support for Unix/Linux/*BSD, has entered the main Linux kernel tree as per version 2.6.13. 9P is the resource sharing protocol developed originally for Plan 9. It presents a unified distributed resource sharing protocol that will be able to distribute devices, file systems, system services, and application interfaces. It was revised for the 4th edition of Plan 9 under the name 9P2000.

The operating system Inferno is based on Plan 9, but both the original and the derivative product do not have a broad audience. Implementing the underlaying key concept on other UNIXes seems to be a very promising project, though, and likely to meet a much broader audience.

Setting it up on my Linux box was not too difficult. Here a little HowTo.

Setting it up

Step 1: enabling the client in the kernel

  1. Grab a recent kernel source - I myself used a vanilla 2.6.15.4;
  2. Enable CONFIG_9P_FS=m in the kernel .config file - unless you don't want it built as a module and need it directly in the kernel;
  3. make and install your kernel as usual;
  4. load your new module with `modprobe 9p2000`.

Step 2: installing the server

  1. Download the UNIX 9P server, aka u9fs - there is ongoing work to implement the server into the kernel module as well;
  2. make the server, and then
  3. copy the binary executable to /usr/sbin/u9fs; you might also want to copy the file u9fs.8 in your source code directory to /usr/share/man/man8/ and read `man u9fs`;
  4. one way to start the server is via xinetd - add the following to a new /etc/xinetd.d/u9fs file:
    service u9fs
    {
         disable         = no
         socket_type     = stream
         wait            = no
         user            = root
         group           = root
         protocol        = tcp
         port            = 564
         server          = /usr/sbin/u9fs
         server_args     = -m 65560
    }
  5. and the follwing to your /etc/services:
    u9fs     564/tcp       9fs  # Plan 9 fs
  6. there are three ways for authentication, none, the default rhosts and p9any; use rhosts only on very safe and controlled networks; none obviously turns off authentication altogether. Personally, I have not yet managed to get p9any working - so I have, for the time being (my network is safe), added the hosts of my internal network to /etc/hosts.equiv;
  7. now `/etc/init.d/xinetd restart`.

Step 3: get it going!

  1. `mkdir /mnt/9`
  2. `mount -t 9P 10.0.0.1 /mnt/9` - make sure you replace the IP address with your own address; a warning: do not use a hostname, but a numeric IP address, the DNS lookup has been biased to work with NFS, but not with other distributed filesystems.
  3. `ls /mnt/9/`

There are other ways to start the server and mount the filesystem in userspace only, but this is still new ground to me. At the moment the security model is still rudimentary - a safer alternative is to tunnel through ssh and call your own instance of the u9fs.

This is all not very exciting as long as the machine with the server is the same the client is running on - but becomes far more interesting when you mount remote machines. Currently I have only been able to access the filesystem, and this only in read mode, but as far as I have understood accessing devices and process resources shouldn't be too far off. And at that point 9P will be unleashed to its full potential.

What is the big deal about it?

Quoting from the main paper [PDF] :

9P2000 support provides a nice alternative to NFS for distributing static files. It can be configured in such a way that users can export and mount their own file system resources. Its synchronous mode of operation and optional caching make it ideal for situations where the cache models and delayed writes of other file systems cause problems. Many utilities, such as CVS and various e-mail servers, discourage the use of NFS repositories due to concerns with data corruption resulting from bad cache behavior and lack of transaction semantics.

However, as mentioned several times before - distributed file service is not the only benefit of 9P2000. It can be used to share networking stacks and block and character devices between members of a 9P2000 cluster. It can be used to manipulate Linux synthetic file systems, such as /proc and /sys providing distributed control and management. It also can be used as an infrastructure to implement distributed applications.

Userspace applications

Unfortunately there are not many applications in userspace yet - the main collection being Russ Cox's Plan 9 from User Space, aka plan9port or p9p, a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems. My somewhat biased perspective cannot but smile when reading the `man web` page - a sample quotation:

web, wmail - handle web page, mail message for plumber […] The supported browsers are Opera, Mozilla Firefox, Mozilla Firebird, and Mozilla.

wmii is a very interesting dynamic window manager based on 9P.

Plan 9 and 9P is a new universe to me; it might be worth exploring it more, and following development of the v9fs. Once we get so far as to really share resources on Linux as well, a huge step forward will be achieved. I am looking forward to it.

Oh, and did I mention that Glenda, the Plan 9 bunny, is really cute? :smile:

Update 1

Interestingly enough, as soon as I have started digging into this project, some significant changes get announced. The v9fs site moves to a new location and u9fs is going to be replaced by npfs, the Linux-based set of libraries and servers that soon will find distribution in various packages, to be pushed out to distros.

October 2008
SMTWTFS
September 2008November 2008
1234
567891011
12131415161718
19202122232425
262728293031