I hasten to inform you that I have launched a project to return the UNIXtypewriter to Plan 9/9 front - Plan “Typewriter”¹. The project is focused on preparing an environment that ignores the mouse completely and allows you to work without removing your hands from the keyboard.

– We built, built, and finally built! Long live us, hooray!

So far, it is ready ** very basic** only the window manager - nwm. At this stage, this is a fork of rio from the 9front project, to which I added the rendering of the navigation bar and the processing of hotkeys. When developing the interface, I was inspired by dwm², a simple and concise window manager for the X server. Only working with windows and the file system will remain directly from rio. As development progresses, everything “superfluous” will be removed to reduce the amount of code.

I’ve been hatching the idea for about a year. The project seemed too complicated and unaffordable to me. But one day I decided to make a couple of sketches of the bar rendering. It just went on by itself…

On the way as well:

• st³/foot⁴-like terminal emulator. So far, I’ve only made small sketches and am diving into the technical details.
• Emacs⁵-like text editor, extensible (in the future) not just with its Lisp dialect, but with a full-fledged Scheme (I haven’t decided which one to use yet). As soon as everything is ready, it will be published on the project’s website.

Acme: OFF

Acme (as conceived by the developers) is a system interface. After all, if everything is a files and most of them are with text, then only a text editor is needed to work with the system. But what I can’t accept is the very limited keyboard support. The editor is too mouse-oriented. It also lacks syntax highlighting. The idea is not to write code so complex that syntax highlighting is needed. If you plan to limit writing code to “Hello, world!"’s applications, then its capabilities should be quite sufficient. But few people will be able to say that the code, for example, rio is simple.

So when developing, I used Emacs and immediately tested the code in 9front. And drawterm helped me in this. When connected to Plan 9 via drawterm, the machine’s local file system is mounted to the current environment. All files are available absolutely transparently. Just go to the right directory, compile and run.

Amazing C

In the process, I discovered something very interesting about Plan 9 dialect C - embedding structures. We are used to the fact that in C you can use one structure inside another in two ways.

1. As a variable:

struct A {
	int x;
};

struct B {
	struct A a;
};

After that, we can access the field from the structure A through b.a.x.

2. As an anonymous structure:

struct B {
    struct {
        int x;
    };
};

This is especially noticeable when there is a high level of nesting of structures in large projects and long field names.

But in Plan 9 dialect C, the developers didn’t look back. They will later transfer this behavior to Go:

struct A {
	int x;
};

struct B {
	A;
};

The field x is now available as native through b.x. And you know what, it’s very pleasant and convenient to work with it. Especially after Go. There is a small fleur of OOP (in the good sense).

What’s next?

I will certainly bring the application to 1.0 releases (not mean quickly). I will develop the project as much as I can. As always, I will not refuse advice and recommendations. At this stage, the most important help you can provide to the project is the dissemination of information and commits/patches. Yes, the project is currently at a very early stage. But I did not say that this is Production-ready software.

The main purpose of this publication is to attract the attention of an already narrow community. Maybe there are 3.5 people somewhere who wanted to see in Plan 9 what they were used to on their UNIX machines.

If you are there, please respond!

In no case do I pretend to be the truth. Maybe I’m completely mistaken somewhere. But I post it to share my thoughts and understand myself.

Lately, I’ve been thinking more and more about the essence of the Web as a reflection of a Man. By its very nature, a Man, like a Web, is decentralized. Both have both vertical (bosses, cities, node routers) and horizontal (close, neighbors, local area networks) connections. Is that why the original Web so easily overlapped with society and was accepted?

The original idea was simple - here are a handful of protocols that allow you to transfer information between nodes. From person to person, from terminal to mainframe, from worker to shop supervisor, from computer to computer, and so on. There are a lot of analogies here. But if vertical connections in human society have a rather indirect effect on horizontal ones (you won’t stop loving someone if you are ordered to), then horizontal connections in networks are extremely difficult to maintain. Technology is not perfect and does not reflect well how a person builds connections in the real world. We can get to know someone online, communicate, and belong to communities, but we depend on the site where this communication takes place. Whether it’s a game server, a forum, or a social network. Just think about how many of you know your friends’ email in case the WathsApp or Telegram are closed. At best, a cell phone number.

It is also important that a person is not inclined to perceive network connections as at least somewhat similar to real ones. You’re more likely to meet people at a concert than in the comments below a video or post. And this lower weight of connections in the Web is difficult to condemn, because humanity does not live with them for so long. Here you are communicating with people, strengthening your connection based on interests. But suddenly the person disappears, and you don’t have any other contacts. He might just get bored and stop going on the platform for a while. And without knowing it, you decided that he had left the resource forever, and you were leaving too. Perhaps that is why we are all drawn to large resources where “all friends are sitting”.

But back to the protocols. For example, RSS¹ and Atom² are extremely simple protocols that people know almost nothing about. Their essence is to convey the news to people in a simple way. You don’t need to visit your favorite website or blog to find out if there was any news. The RSS reader will receive all the updates on its own and inform you about them. But the ease of receiving this news in a decentralized manner has helped major news aggregators also receive this news, publish it, and thereby increase their already considerable audience. After all, a person is simple and unpretentious, he will not check the original source. This creates two excellent opportunities. First, publish half-truths or lies. Secondly, don’t publish anything at all. And we get censorship and the imposition of opinions based on the vector of editorial policy. That is, what was originally intended to bring independence to people was used against them, in favor of selfish interests at best.

And so we find ourselves in a situation where, with a seemingly abundance of information, we find ourselves in an information cocoon that we don’t even know we have. For balance, we have, for example, as many as three different opinions about the same event. The others before you were filtered, digested, and disguised. You won’t even know about it, because people learned to lie and manipulate long before the advent of the Web.

There have been other attempts besides RSS and Atom. The most successful of them, of course, is email. There are no options. It appeared much earlier than large companies realized how to take advantage of such technologies. And due to the steady growth of email, they are now in a situation where it is a very risky idea for them to lose backward compatibility. Perhaps this is one good example of a protocol that could not be subdued and squeezed under itself. But despite this, they do not stop trying to make a mail club “for their own” and continue to impose “new” and “secure” protocol extensions on us. Dancing with certification authorities and PTR records alone is worth a lot. I am already silent about the shadow blocking of the 25 TCP port by providers.

XMPP/Jabber³ was the least lucky. Does anyone even remember it? And it’s not surprising, because the whole Google has put a lot of effort into suppressing its use. Ban? Blocking? Be more cunning! The good old tactic: if you can’t win, take the lead. They have launched their large XMPP service. The same free cheese as the Gmail, but which was much easier to collapse. The fact is that it is quite difficult and expensive to keep an XMPP server. This requires a fairly large storage for chat histories, a stable connection, and round-the-clock server operation. Only geeks could keep it for themselves. Basically, people signed up at large nodes, which kept crashing, and people left for others. That was until Google came on the scene. And indeed, they will be able to provide user support. Large nodes began to close due to the outflow of users. And soon Google itself shut down support due to “low demand”. What can you do against Google? The funny thing about this is that XMPP/Jabber is still in use. But you don’t know about it. After all, you don’t care how WhatsApp works. The RSS story repeated itself, almost one-on-one. It was the same with personal websites and blogs: just switch to hosting or a platform. And as a result, we have to count on our fingers the companies whose resources are used by, if not 90%, then certainly 70% of the planet.

People on large platforms don’t belong to themselves. Their correspondence is being read, information is being leaked, and is being used in behavior analysis, targeted advertising, and neural network training without their consent. They can be automatically blocked at any moment for saying something that is “incorrect” from the platform’s point of view. And even despite the huge number of people on these platforms, they are all extremely lonely. After all, as I have already said, the value of virtual communication is much lower than the real one. Have a million followers or 100 friends, which one do you choose? Moreover, the more subscribers you have, the less you belong to yourself. Sincerity disappears, sponsors and advertisers appear. Step to the left and you’re an outcast without funding. A commissioned article, a few corrected facts - no one will remember you tomorrow. But even worse, you don’t communicate. It’s a surrogate. On the one hand, the content producer. On the other hand, the consumer. No love, no trust. Just production and consumption. Accurate calculation. Does this really happen in real life? No, of course, you can give examples of their category of “so calm, sociable, but it turned out to be a maniac”, but this is already a distortion. Most often, people who know you personally will either not believe in slandering you at all, or ask you for your position on the situation. Truth and sincerity are rarely truly alone.

But what is the purpose of separating us by false unity? I’m afraid I don’t know the answer to this question yet. All I know is that it all depends on us. Yes, it’s hard to keep your email server at least for your family. But this is already a huge step at a fairly low price. And I understand ordinary people who are far from information technology, and geeks who are not interested in this routine. After all, it’s so easier to go with the flow than to stand apart and even more so to go against.

In general my thought is very simple - protocols can only combine and cannot be evil in themselves. Only in evil hands. That’s what happened with XMPP. This is what happens with RSS. And the corporate Towers of Babel did not originate on their own. It’s all the fault of people’s idleness and vanity. “They give me free registration and chat, just a rare advertisement”. But the ads you see aren’t even half of what you got.

The externaly Web may have changed in a similar way to humanity - tribes, villages, cities - but in fact this path has not been passed. The analogy here is very simple - the revolution of 1917 in Russia. They have not been able to make a communist out of a man by force for 70 years. Even the socialists turned out to be so-so.

I repent, I have sinned. But I’m working on myself. Until recently I tried Fediverse, but I found all the same flaws in it as on major platforms. At the moment, the nostr⁴ protocol looks very promising to me. But I find the clearest reflection of myself on the web at the moment in returning to the original Web - the website, RSS, and Plan 9, which is very close to my spirit.

But I believe that Mankind will be able to find their true reflection on the Web and the Web will cease to be an alien and hostile place for a Man.

Preparation

– Don’t grab it right away. Don’t grab him right away, Urry. Find out how it’s operated first. Find out how it’s managed first.

– I didn’t understand, repeat.

– Find out where his button is!

Before you start, you have to answer a few questions:

• What configuration does your local network have?
• What hardware is installed in your machine and is it supported in the OS? [a list of supported hardware is available on the project’s website²]
• What name will the machine and your user have?

If you are having difficulties at this stage, then I advise you to stop and come back later. After you have received the answers to these questions, we can move on.

First, download the appropriate installation ISO system image from the project website³ and create a bootable USB flash drive. If you have chosen to install on a virtual machine for the first attempt [which I advise you], then simply mount the disk image to the VM and start booting. If everything was done correctly, you will see the boot process.

Also, during the first boot, you will be asked several questions. In most cases, you can leave the default values [usually indicated in square brackets], if they are available.

user

 user[glenda]:

The suggested default user is glenda. The system will be started on this machine under this user. Such a user in the context of Plan 9 is called host owner. The concept of a root user has been abolished due to security concerns. The host owner has high permissions on a specific machine, but is limited in access to other users files. For the first installation, it is better not to change it. Just hit Enter.

vgasize, monitor, mouseport

The following questions will ask for information about the display and mouse:

vgasize is (text, 640x480x8, 1024x768x16, ...) [1024x768x16]
monitor is (vesa, xga, lcd, ...) [vesa]
mouseport is (ps2, ps2intellimouse, 0, 1, 2) [ps2]

Based on the responses, the environment variables $vgasize, $monitor and $mouseport will be set. These values will also be written to the plan9.ini file, from which they will be used for follow bootings.

• monitor - any value other than vesa will skip VESA BIOS emulation and an attempt will be made to use the native VGA driver for the video card. The list of displays and video cards supported by the system can be found in the file /lib/vgadb. Additional information can be found on the help pages vga(3), vga(8) and vgadb(6).
• vgasize - used to store the resolution and bit depth of the display. Here you can specify any value supported by your display.
• mouseport - the default value ps2 should be suitable in most cases. When installing on a laptop or using a mouse with a scroll wheel, you may need to set it to `ps2intellimouse'.

After the booting is complete, you can change the set values in the plan9.ini file.

Example of the content of plan9.ini:

monitor=vesa
vgasize=1024x768x16
mouseport=ps2intellimouse

Startup

After answering the questions, the boot process will try to launch the standard graphics multiplexer rio, welcoming you with a gray desktop with a running load monitor stats and a window with a rc shell.

Keep in mind that if the user has been changed, then you will just see a gray screen. Initialization ready only for the glenda user. In all other cases, the system remains clean.

A little bit about control

A three-button mouse is used to control the multiplexer rio.

• Left Mouse Button - focus indication and highlighting, nothing special;
• Middle Mouse Button - context menu, which will vary for different applications;
• Right Mouse Button - rio menu, allows you to create, edit and delete windows.

Applications run in windows rio. But the most interesting thing is that in the rio window can be launched … rio. And more. And more.

When working with a flash drive, this may be enough for a first acquaintance. The system will save its state as a regular live image of any other OS. So you can move on to the next articles in the cycle.

If you have sufficiently explored the live image of Plan 9 and feel that you are ready to build a full-fledged computing network [in the context of Plan 9, the term grid is used], then we continue.

Installing the basic system

The installation is performed by the rc script /rc/bin/inst. To start the installation, run the inst/start command in the terminal.

term% inst/start

Follow the instructions to complete the installation, selecting the default values if necessary.

Each step can be repeated by entering its name in the prompt.

Now let’s move on to the installation steps.

configfs

The cwfs64x file system uses permanent and temporary storage on different partitions. The hjfs file system is more homogeneous, but works slower. If you are installing to a disk of less than 12 GiB, you should choose hjfs. In this example we will press Enter to accept cwfs64x as the default.

You can install the following types of systems:
    cwfs64x     the cached-worm file server
    hjfs        the new 9front file server (experimental!)
File system (cwfs64x, hjfs)[cwfs64x]:

partdisk

At this step, we need to create partitions. The installation script will tell you which disks it was able to detect.

Select the one that is not an optical disc emulation and press Enter.

The following disk devices were found.

sdC0 - QEMU DVD-ROM
    empty                  0 3916        (3916 cylinders, 29.99 GB)
  * p1

sdF0 -

Disk to partition (sdC0, sdD0)[no default]: sdF0
The disk you selected HAS NO master boot record on its first sector.
(Perhaps it is a completely blank disk.)
Shall we create a blank EFI partition table (GPT)
or install traditional DOS partition table (MBR)?

Our disk is empty, so let’s create a fresh MBR table.

Install mbr or gpt (mbr, gpt)[no default]: mbr

This is disk/fdisk; use it to create a Plan 9 partition.
If there is enough room, a Plan 9 partition will be
suggested; you can probably just type ’w’ and then ’q’.

cylinder = 8225280 bytes

For this example we will use the entire disk. Accept the defaults.

>>> w
>>> q

prepdisk

Due to the peculiarities of CWFS, we need to divide of the partition into subpartitions.

The following Plan 9 disk partitions were found.

/dev/sdF0/plan9
  empty                  0 62910477    (62910477 sectors, 29.99 GB)

Plan 9 partition to subdivide (/dev/sdC0/plan9)[no default]:
Use the Plan 9 partition created in the previous step. Type /dev/sdC0/plan9 and hit enter.
This is disk/prep; use it to subdivide the Plan 9 partition.
If it is not yet subdivided, a sensible layout will be suggested;
you can probably just type `w` and then `q`.

no plan9 partition table found
9fat 204800
nvram 1
other 8957953
fscache 8957953
fsworm 44789770
>>>

Again, accept the defaults.

>>> w
>>> q

mountfs

Now that the subpartitions are created, we specify how to mount them and format them. If the previous steps went without problems, then the installation script will detect the partitions we created on its own. Just press Enter on each of the questions.

The please choose your cwfs64x partitions

--rw-r----- S 0 glenda glenda 4586471936 Jul  4 13:28 /dev/sdC0/fscache

Cwfs cache partition (/dev/sdC0/fscache)[/dev/sdC0/fscache]:
--rw-r----- S 0 glenda glenda 22932362240 Jul  4 13:28 /dev/sdC0/fsworm

Cwfs worm partition (/dev/sdC0/fsworm)[/dev/sdC0/fsworm]:
--rw-r----- S 0 glenda glenda 4586471936 Jul  4 13:28 /dev/sdC0/other

Cwfs other partition (/dev/sdC0/other)[/dev/sdC0/other]:

Since this is a fresh install, we choose yes to ream (format) the file system:

Since this is a fresh install, we choose yes to ream (format) the file system:
Ream the file system? (yes, no)[no]: yes
Starting cwfs64x file server for /dev/sdC0/fscache
Reaming file system
bad nvram key
bad authentication id
bad authentication domain
nvrcheck: can’t read nvram
config: config: config: auth is now disabled
config: config: config: config: config: config: current fs is "main"
cmd_users: cannot access /adm/users
63-bit cwfs as of Wed Jul  4 00:59:30 2012
    last boot Tue Jul 17 13:34:57 2012
Configuering cwfs64x file server for /dev/sdC0/fscache
Mounting cwfs64x file server for /dev/sdC0/fscache
% mount -c /srv/cwfs /n/newfs
Mounting cwfs64x file server for /dev/sdC0/other
% mount -c /srv/cwfs /n/other other

confignet

We will configure the ethernet.

Please choose a method for configuring your ethernet connection.

    manual - specify IP address, network mask, gateway IP address
    automatic - use DHCP and SLAAC to automatically configure

Configuration method (manual, automatic)[automatic]:

automatic

In this example, I will focus on the automatic configuration, since I have DHCP configured. If you will also use DHCP, then do not forget to reserve the address on the server.

Hit Enter to move on to the next task.

manual

Manual configuration is not difficult. You just need to specify the IP address, network mask, gateway and DNS server.

Configuration method (manual, automatic)[automatic]: manual
ip address [no default]: 192.168.2.10
network mask [no default]: 255.255.255.0
gateway address [no default]: 192.168.2.1
dns server [192.168.2.1]:
starting ethernet manual config

mountdist

We will tell the installation script where to look for the files to install.

Please wait... Scanning storage devices...
    /dev/sdC0/9fat
    /dev/sdC0/data
    /dev/sdC0/fscache
    /dev/sdC0/fsworm
    /dev/sdC0/other
    /dev/sdD0/data

The following storage media were detected.
Choose the one containing the distribution.

    /dev/sdD0/data (iso9660 cdrom)

Distribution disk (/dev/sdD0/data, /dev/sdC0/fscache, /)[/]:

The CD-ROM is already mounted at /, so type / and hit Enter.

% mount /srv/boot /n/distmedia

Which directory contains the distribution?

Location of archives [/]:

And again, the root directory of the CD-ROM is already mounted at /, so hit Enter to choose the default.

copydist

At this step, the system distribution files will be copied from the install media to the hard disk. Currently, there is no progress meter. Disk activity may be verified by inspecting the stats(8) window. Task may exceed one hour in duration depending on the speed of your disk.

Eventually, you should see the following:

This indicates that the system files have completed copying to the install target.

ndbsetup

Let’s give our host a name. By default, cirno will be assigned.

Setup network configuration

sysname [cirno]: test-fs

tzsetup

Setup Time Zone

Time Zone (Argentina, Australia_ACT, Australia_Broken-Hill,
Australia_LHI, Australia_NSW, Australia_North, Australia_Queensland,
Australia_South, Australia_Sturt, Australia_Tasmania,
Australia_Victoria, Australia_West, Australia_Yancowinna, Brazil_Acre,
Brazil_DeNoronha, Brazil_East, Brazil_West, CET, Canada_Atlantic,
Canada_Central, Canada_East-Saskatchewan, Canada_Eastern,
Canada_Mountain, Canada_Newfoundland, Canada_Pacific, Canada_Yukon,
Chile_Continental, Chile_EasterIsland, Cuba, EET, Egypt, GB-Eire, GMT,
HST, Hongkong, Iceland, Iran, Israel, Jamaica, Japan, Libya,
Mexico_BajaNorte, Mexico_BajaSur, Mexico_General, NZ, NZ_CHAT, Navajo,
PRC, Poland, ROC, ROK, Singapore, Turkey, US_Alaska, US_Arizona,
US_Central, US_East-Indiana, US_Eastern, US_Hawaii, US_Michigan,
US_Mountain, US_Pacific, US_Yukon, W-SU, WET)[US_Eastern]: GMT

Type your chosen time zone and hit Enter.

bootsetup

Setup Plan 9 FAT boot partition (9fat)

Plan 9 FAT partition (/dev/sdC0/9fat)[/dev/sdC0/9fat]:

Hit enter to accept the default.

Any environment variables entered at the > prompt during boot, as well as settings configured during install will now be written to /n/9fat/plan9.ini and the kernel will be copied to the 9fat partition.

dossrv: serving /srv/dos
Initializing Plan 9 FAT partition.

% disk/format -r 2 -d -b /386/pbs /dev/sdC0/9fat
Initializing FAT file system
type hard, 12 tracks, 255 heads, 63 sectors/track, 512 bytes/sec
used 4096 bytes
% mount -c /srv/dos /n/9fat /dev/sdC0/9fat
% rm -f /n/9fat/9bootfat /n/9fat/plan9.ini /n/9fat/9pc
% cp /n/newfs/386/9bootfat /n/9fat/9bootfat
% chmod +al /n/9fat/9bootfat
% cp /tmp/plan9.ini /n/9fat/plan9.ini
% cp /n/newfs/386/9pc /n/9fat/9pc

If you use the Windows NT/2000/XP master boot record
or a master boot record from a Unix clone (e.g., LILO or
FreeBSD bootmgr), it is probably safe to continue using
that boot record rather than install the Plan 9 boot record.

Since we are not installing on a disk with a pre-existing Windows installation, we choose to install the Plan 9 master boot record and mark the partition active.

Install the Plan 9 master boot record (yes, no)[no default]: yes
Mark the Plan 9 partition active (yes, no)[no default]: yes

The Plan 9 partition is now marked as active.

finish

The last step will disable the CD image and shut down. We confirm by pressing the Enter key to restart the computer.

Your first installation of 9front is complete.

Congratulations!

Auth and File Server Setup

Based on follow example - youtube.

This step will be a little tricky to follow. But only need to be done once to get the File server officially running. There are a lot of moving parts and they need to be done correctly for everything to work. As this will be a combination of Authorization and File server we will need to set up both those systems.

Authorization will handle checking the passwords and the file system will make sure the users have access to the correct files. First thing that needs to be done is to set a host owner for the system. The Plan 9 developers did away with a root user because it was had obvious security issues. Instead each system has a designated host owner. The host owner has ultimate power over any processes runnung on the system it owns. So the host owner can kill processes and access pretty much all the hardware.

In the case of the file server the host owner does not have ultimate acceess to the files normally. Only in the special case where the host owner boots the console mode with authorization disabled.

Setup NVRAM

We’ve noted the NVRAM partition before this is a small piece of storage called Non-Volatile RAM for historical reasons and it holds a password token for the host owner. This allows the system to boot with authorization without needing to enter a password at the boot prompt. To be sure the system uses it i will add it to the plan9.ini. Some systems will do this automatically but i just want to be sure.

So lets mount the 9fat partition.

% 9fs 9fat
% sam /n/9fat/plan9.ini

Here we can specify exactly where to get the NVRAM partition from and this can also be set as a file.

bootfile=9pc64
nvram=/dev/sdF0/nvram
bootargs=local!/dev/sdF0/fscache
mouseport=ps2
monitor=vesa
vgasize=1024x768x16

tiltscreen=none

And now we’ll reboot the system so that takes effect.

% fshalt -r

Write to NVRAM

Now we have rebooted the system with the NVRAM partition specified and the next step is to write to it.

• authid - will be the host owner which will be glenda.
• authdom - in this case this asking for a domain name. If you use one just specify it. If not - put something as stub.
• secstore key is used for another authorization system and i’m just going to be skipping it for now. Hit Enter and leave it blank.
• password - password for glenda user.

% auth/wrkey
authid: glenda
authdom: testdom
secstore key:
password:

That it.

Add users to auth

The next step is to add glenda to the authorization system and we’ll also be adding a regular user to. So first we need to make sure we have access to the keys.

% auth/keyfs

So we’ll do one for glenda here:

• Password - enter the same password;
• Confirm password - and again;
• assign new Inferno/POP secret? [y/n]: n - nevermind for now, just set to no;
• Expiration date (YYYYMMDD or never)[never]: won’t bother with an expiration date, set to never;
• Post id:, User's full name:, Department #:, User's email address:, Sponsor's email address: - these are if you have like an actual office full of people.

% auth/changeuser glenda
Password:
Confirm password:
assign new Inferno/POP secret? [y/n]: n
Expiration date (YYYYMMDD or never)[never]:
Post id:
User's full name:
Department #:
User's email address:
Sponsor's email address:
user glenda installed for Plan 9

There we go. glenda is now added as a user. And i’ll add just a plain regular user testuser. Give them a password and basically the same options.

% auth/changeuser testuser
Password:
Confirm password:
assign new Inferno/POP secret? [y/n]: n
Expiration date (YYYYMMDD or never)[never]:
Post id:
User's full name:
Department #:
User's email address:
Sponsor's email address:
user testuser installed for Plan 9

Add users to file system

The next step is to add our new testuser to the file system. So glenda automatically gets entered as one of the users on the file system when you do the basic install. And now we need to add the testuser so that they can also own files. To do that we need send commands into the file system’s command server.

% echo newuser testuser >>/srv/cwfs.cmd

All right, so now the new user testuser has been added to the CWFS.

Set up network database

The next step is to edit the network database file to designate this system as the authentication and file server. This file located in /lib/ndb/local. Down near the bottom here we have an example that we can use.

# example: adjust to fit your network
#auth=cirno authdom=9front
#ipnet=9front ip=192.168.0.0 ipmask=255.255.255.0
#	ipgw=192.168.0.1
#	dns=192.168.0.1
#	auth=cirno
#	dnsdom=9front
#	cpu=cirno
#	smtp=cirno

So we just need to make own version of this:

auth=test-fs authdom=testdom
ipnet=testdom ip=192.168.2.0 ipmask=255.255.255.0
	ipgw=192.168.2.1
	dns=192.168.2.1
	auth=test-fs
	fs=test-fs
	dnsdom=testdom

Edit plan9.ini

Now we need add another edit to plan9.ini. Because of quircks with CWFS we need to do two edits.

• The first is to make copy of plan9.ini to boot the system up in configure mode to make sure that authorization to the file system is working;
• And we also need a final plan9.ini configuration so the server boots up normally without any need for interaction.

So let’s mount the 9fat again and make a copy of current plan9.ini and another one which we’ll use later.

9fs 9fat
cp /n/9fat/plan9.ini /n/9fat/plan9.bak.ini
cp /n/9fat/plan9.ini /n/9fat/plan9.new.ini

For existing one the first thing we need to do is change this from the default which is a terminal to a CPU server. And then to the boot arguments we’ll add a -c to drive option for the file system and this will put it into configure mode.

bootfile=9pc64
nvram=/dev/sdF0/nvram
service=cpu
bootargs=local!/dev/sdF0/fscache -c
mouseport=ps2
monitor=vesa
vgasize=1024x768x16

tiltscreen=none

For the new one we’ll add an option -a tcp!*!564 to drive options. This will tell the system to be listening on TCP port 564 for commands to mount to the file system. This will also be a service CPU and we will change the boot args to nobootprompt so it won’t ask for us to hit Enter.

bootfile=9pc64
nvram=/dev/sdF0/nvram
service=cpu
nobootprompt=local!/dev/sdF0/fscache -a tcp!*!564
mouseport=ps2
monitor=vesa
vgasize=1024x768x16

tiltscreen=none

So we writing both file now because once the system reboots the graphical system will be disabled so it won’t load rio and we can’t edit the files with acme or sam. You can use ed, but writing now and using just mv to rename them later is easier.

Boot as a server

So we’ve rebooted the system now and you can see it’s waiting me to enter the default which has the -c. Hit Enter.

And it has config prompt. At this point we need to type noauth. It says auth is disabled.

I’ll type noauth again and auth is now enabled. Than type end and continues booting the system.

bootargs is (tcp, tls, il, local!device)[local!/dev/sdF0/fscache -c]
config: noauth
auth disabled
config: noauth
auth enabled
config: end

As you can see there’s no rio now. It’s just a prompt.

We’ll mount 9fat partition and so we will move that plan9.ini file with the configuration option. And then move our final plan9.ini file and reboot the system again.

# 9fs 9fat
# cd /n/9fat/
# mv plan9.ini plan9.config.ini
# mv plan9.new.ini plan9.ini
# fshalt -r

Now you can shut the system down and then take out the monitor, keyboard and mouse and boot it back.

It will happily sit there and wait for file server requests.

Connecting

Now you need a drawterm⁴ on you main system to connect to file server.

drawterm -h 192.168.2.10 -u testuser -a 192.168.2.10

Enter user password and voila! Now you connected to FS server. You also can access you local machine files in /mnt/term. It’s a pretty usefull, you can write some software on your usual text editor and test it in Plan 9 environment without copying any file.

In subsequent articles, we will focus in more detail on the application of Plan 9, working in the environment and expanding our grid.

Background

By the mid-80s, there was a tendency to move away from large centralized computers operating in time-sharing mode to networks on top of small personal machines [usually UNIX workstations]. Users were eager to switch to small systems that they could support themselves despite the loss in computing power. Microcomputers became faster and cheaper, and these losses were compensated. This style of computing remains quite popular today.

When migrating UNIX to personal workstations, however, some of the existing shortcomings and problems were not taken into account. The UNIX operating system was old, monolithic, and operated in time-sharing mode. The possibilities of adapting it to new technologies that appeared later were very limited. Graphics and networking capabilities were added to UNIX back in its heyday and were poorly integrated architecturally and, as a result, difficult to manage.

And most importantly, the early focus on personal machines made it impossible for the trouble-free operation of networks typical of old monolithic time-sharing systems. Time-sharing and management centralization made it possible to amortize costs for large machines. But with the advent of personal computing, the problems of administration have escalated to the limit. Choosing an old time-sharing operating system to run on these personal machines would be unjustified.

Beginning

It was decided to create an OS more adapted to the challenges of the time. Plan 9 originated in the late 1980s as a new system designed to solve UNIX problems that the developers considered “too deep to fix”. At the same time, two goals were pursued:

• the system, built from cheap modern microcomputers, had to be centrally controlled;
• and at the same time be inexpensive.

The idea was to use more than just workstations when building a computing system. Computers should fit their role: small, cheap machines in offices could serve as terminals, providing access to large, central, shared resources such as computing and file servers. Recent multiprocessor systems appeared to be obvious candidates for the role of central machines.

The project was taken over by a specialized division of Bell Labs, known as “Computer Science Research Center” (CSRC). In fact, the development was led by the same team that originally worked on UNIX and the C programming language: Ken Thompson, Dennis Ritchie, Rob Pike, Dave Presotto and Phil Winterbottom. And it was decided to leave the concept the same, developing it as much as possible.

The name of the OS was inspired by the trash horror film “Plan 9 from Outer Space” directed by Edward Wood. Mascot of OS - hare Glenda - was named after the film “Glen or Glenda” by the same director. The same name was given to the default user in Plan 9.

By 1989, the system had become so stable that it was used as the only computing environment in the laboratory. This meant the need to migrate many services and applications that were previously used in UNIX. The researchers used this opportunity to review a lot of things in the OS architecture. Plan 9 had new compilers, languages, libraries, window systems and a variety of new applications. Many of the old utilities have been omitted, and those that have been left behind have been re-written or debugged.

Why was it necessary to review everything to the ground? The differences between the operating system, library, and application are important to operating system researchers, but uninteresting to users. For them, only functionality matters. By creating a completely new system, they were able to solve many problems that needed to be solved. For example, there is no tty driver in the kernel. It is the result of the operation of the window system in the user space. In the modern world, computing systems, by necessity, are multiarchitectural and made up of products from different suppliers. However, conventional compilers and utilities assume that the program must be built to run in a local environment. More importantly, however, the operating environment it provides serves as a certain test for the system. Ensuring greater efficiency when running old programs - the “workhorses” of UNIX - was only a matter of technique. The researchers were much more interested in the fact that the new ideas proposed by the architecture of the new system would contribute to improving work efficiency. Thus, although Plan 9 provides an emulation environment for executing POSIX commands, this is not the main thing in the system. Most of the system software is developed in the native Plan 9 environment.

The completely updated system had certain advantages. The laboratory had experience in developing controllers for experimental peripheral devices. In order to make it easier to write their drivers, they wanted to have a system that would be available as source code [which UNIX could no longer guarantee, even in the laboratory where it was born]. In addition, they wanted to redistribute the work. The software should have been created in a decentralized manner [let me remind you, git and etc. haven’t even thought about it yet, let alone CI/CD]. For example, they could use C compilers from some vendors for the system. But even if they had overcome the problems with cross-compilation, they would have had difficulty redistributing the result of this work.

Result

The basic concept of Plan 9 is that it is a distributed operating system, unlike UNIX. Network functionality is extended by mechanisms such as remote login and a network file system in it. In Plan 9 network support is built into the OS functionality. For example, all resources, theoretically, can be transparently distributed in the Plan 9 network. The system hides from the user that the resources are not local. Plan 9 supports not only file servers, but also authorization and computing servers, and this list can be expanded¹².

The system was built on three principles:

• Firstly, resources are named and can be accessed as files in a hierarchical file system;
• Secondly, there is a standard protocol called 9P for accessing these resources;
• Finally, the unrelated hierarchies provided by the various services are joined together into a single personal hierarchical file namespace.

The unusual properties of Plan 9 are due to the purposeful consistent application of these principles.

Plan 9 is based on the UNIX paradigm that “everything is a file”. Relying on a huge collection of add-ons, UNIX absorbed more and more changes that went against this original, fundamental principle. An example of this is the terrible socket mechanism used for the functions of reading and writing network resources, different than regular files. Plan 9 puts an end to this by providing a file-oriented system interface. For example, /net/tcp and /net/udp for network interfaces. Most system services also follow the server principle. In Plan 9, for example, there is no regular ftp program. Instead, ftpfs mounts the FTP server to the /n/ftp directory. The 9660fs server is responsible for mounting CD’s.

Although Plan 9 was originally intended to work with traditional files, its ideas have been extended to many other resources. File hierarchy export services include I/O devices, backups, window system, network interfaces, and more. The file system model is well understood by both system developers and ordinary users, so that services with file-like interfaces are easy to build, understand and use. The files come with familiar, unified rules for protection, naming, and access (both local and remote). Therefore, services built in this way are ready for use in distributed systems. This is the difference from object-oriented models, where these aspects have to be dealt with anew for each class of objects. The following articles will provide examples illustrating these ideas in practice.

One example would be the /proc file system command, which provides a clear way to explore and manage current processes. Plan 9 was the first OS to support the file-oriented process management system proc. Precursor systems are based on a similar idea³, but in Plan 9 the metaphor of files is developed much further⁴. Later, /proc was integrated into GNU/Linux.

In Plan 9, the main network functionality is provided by the 9P protocol, which includes about 30 control messages. The implementation of 9P in GNU/Linux has been added to the main kernel since version 2.6.14 This eliminated any obstacles in the interaction between GNU/Linux and Plan 9. The 9P protocol is structured as a set of transactions, each of which sends a request from the client process to a local or remote server and returns the result. 9P controls the file system, not just the files. It includes procedures for distinguishing file names and converting the hierarchy of file system names provided by the server. On the other hand, unlike systems such as Sprite⁵, the user namespace is supported only by the client system, and not on or with the server. In addition, file access occurs at the byte level, not at the block level, which distinguishes 9P from protocols such as NFS and RFS.

A typical Plan 9 installation consists of a number of computers connected to a network and each providing services of a certain class. Shared multiprocessor servers ensure the execution of computing cycles. Other large machines serve as file storages. These machines were located in an air-conditioned room and connected by a high-performance network. Networks with lower bandwidth, such as Ethernet, connect these servers to office or home workstations or PCs, called terminals in Plan 9 terminology.

The modern style of computing assumes that each user has a dedicated workstation or PC. Plan 9 uses a fundamentally different approach. Although it can function on a workstation with files stored on a local disk, this configuration is not canonical. Instead, machines with monitors, keyboards, and mice gain access to most computing resources and storage systems over the network, becoming terminals of the system, similar to the terminals of the old time-sharing system. The terminal is temporarily personalized by this user when using Plan 9.

The principle of building equipment for the user does not work here. Plan 9 offers the possibility to programmatically change how it is perceived by the user. This adjustment is accompanied by giving publicly visible resources on the network local personal names. Plan 9 provides a mechanism for organizing a personal representation of a shared space with local names of globally available resources. Since the most important network resources are files, the model of this representation is file-oriented.

Local namespaces provide a way to implement a network representation “for yourself”. All services available on the network export file hierarchies. Those of them that are important to the user are gathered together into a personal namespace. Currently of no interest are ignored [this approach is hard to understand, but it is one of the most important concepts implemented in the system]. This usage style differs from the homogeneous global namespace in UNIX. Plan 9 has well-known names for services and unified names for files exported by these services, but their representation is completely local. An example is the difference between the phrase “my home” and a clearly formulated exact address. The latter can be used by anyone, whereas the former is used only in colloquial speech: the meaning of a phrase varies depending on who says it and when, but it is considered understandable. Similarly, in Plan 9, the name /dev/mouse always refers to the mouse, and /bin/date is the date output command, but what files these names represent depends on circumstances, for example, on the architecture of the machine executing the date command. Plan 9 thus has local namespaces that obey global conventions. It is these conventions that guarantee reasonable behavior in the presence of local names.

Present day

Plan 9 carried several innovations that influenced many subsequent systems. But until recently, the source code was under a commercial license that bounded developers and users. Bell Labs and a small community of programmers continued to improve and develop Plan 9.

The license was softened from year to year, and in 2003 Plan 9 was finally released under the first free license. The commercial branch, known as Inferno, is now also available under a free license.

9front

This is a fork of Plan 9, which has been worked on by a team of developers from the NineTimes community since 2011. It consists of fans of the original OS from Bell Labs. One of the main problems of the original Plan 9, which slowed down the development of the system, was the lack of drivers and weak support for peripheral equipment. This was due to the uniformity of the equipment in the laboratory. This is exactly the problem that the developers of 9front tried to solve. They wrote OS drivers for USB, Wi-Fi, audio cards, game emulators [you can run DOOM]. The fork was distributed under the same open Lucent Public License as Plan 9. At the moment, distribution is conducted under the MIT license.

The creators of 9front have placed a package repository on the network, which greatly facilitates the installation of system components. The loader was completely rewritten in this fork. It is called 9boot and is distinguished by the use of rc scripts that allow you to access shell at any stage of loading [which may be useful if something went wrong].

Plan 9 supported several file systems: first, the native Fossil developed at Bell Labs specifically for this platform, as well as Kfs, Paq, cwfs and FAT ** [where without it]**. In 9front, the main FS is cwfs (cwfs64x) - this is also a file system from Plan 9, which supports encryption of disk partitions, and also allows you to securely store backups of OS components and user data.

The Go programming language compiler has been added to 9front. A simple text editor hold was also added to the package. The distributed version control system Git is used to update the OS. In order to provide more flexible hardware support, the message-triggered interrupts subsystem MSI (message signalled interrupts) was introduced.

The system is regularly updated, the latest up-to-date version was released on April 28, 2024⁶. You can try 9front on a virtual machine, either by installing it on a PC or a single-board computer.

System operational

Yes, it is certainly not suitable for everyday use. Like Plan 9, 9front is still an experimental, research OS. The main purpose of the creation was to bring to life some of the original ideas of UNIX and implement them on a more advanced and modern hardware platform. It was generally successful. In research laboratories Plan 9 was used quite effectively as a platform for distributed computing. At a minimum, Plan 9 and 9front have proven that the basic concept of UNIX - each system interface can be represented as a set of files - is quite successfully implemented in a modern OS.

Like other forks of Plan 9, among which it should be noted 9atom, Harvey OS and Jehanne OS, 9front is an OS for programmers and engineers. For those who prefer to dig into configs and write their own code rather than run someone else’s. 9front can be called the most active offshoot from the “classic” Plan 9. The creators of the fork are continuously working to improve hardware support and develop new drivers. Their efforts also have practical applications: for example, the ATA over Ethernet protocol, created for NAS clusters, works on principles similar to the Plan 9 architecture.

With the advent and development of the Internet of Things and single-board computers with limited performance, the demand for distributed operating systems that allow flexible redistribution of computing resources in the network and ensure their balancing is sure to grow.

This means that this project has a future.

Without a doubt, Plan 9 is one of the most interesting operating systems I’ve encountered along my way. The approaches that were used in its design are simple and universal. The OS itself turned out to be the same. UNIX’es “everything is a file” in Plan 9 is raised to the absolute.

No wonder, because it was designed by the same engineers as the original UNIX - Ken Thompson, Dennis Ritchie, Rob Pike, etc. It also developed approaches such as “text as an interface” and “homogeneous operating environment” - the ideas of Niklaus Wirth and his Oberon¹ environment. [just compare the screenshots, for the rest you need to go into the code]

ENTIRE OS architecture is built on file interaction:

• Do you want to create a file? Create a file.
• Do you want to create a TCP socket? … Create a file! [hello to Berkeley sockets² bolted sideways across with their special system calls]
• Do you want to raise the VPN? Well, let’s skip it for a while…

Any device in machine is represented to us as a hierarchical file system. Yes, this imposes some restrictions on driver developers, because they have to design this device file system. But the achieved uniformity of the entire system saves us a lot of time during operation.

Network transparency, which was incorporated into the 9P³ protocol from the very first stages of design, blurs the boundaries between machines. Therefore, it does not matter where the file/device is located - locally or remotely - the interaction will follow the same protocol. Access to mail? To the file storage? Chat? GPS data? Everything can be implemented using a single protocol.

Well, it’s just some kind of engineering utopia.

Problems

But if Plan 9 is so great, then why hasn’t everyone switched to it yet? I think it was influenced by several factors.

Status

Plan 9 was conceived as an experimental OS with closed source code and has not got rid of this halo until now. It was used to test the latest concepts that were developed in the Inferno⁴ OS. Initially there were almost no user programs in it. Only the most necessary things for work. And as a result …

Lost time

The Plan 9 source code was opened under the GPL-2.0-only license (and then under MIT) only in 2014. The attention of the community was missed. GNU/Linux was already growing and expanding, which “just good enough”⁵. Think about all the community efforts that have been spent on the development of GNU/Linux. Maybe with the same attention to Plan 9 we would live in a completely different world. But …

Architecture

The specificity of Plan 9 block easy migration of software written for UNIX to it. It turns out that a huge layer of programs that everyone is used to are nailed to the GNU/Linux and BSD system calls. A very limited number of people agree to sit and write the entire toolkit from scratch with the same zeal⁶.

Besides the fact that this is a laborious process, it is also slowed down by maintaining the ideological purity of the OS. “The best code is no code at all.” This idea is close to me, but not so literally. The ability to create almost any software in the form of shell scripts is interesting, but not all software can be implemented this way.

Graphics

(this is from me personally)

They removed from Plan 9 exactly why I left Windows for the UNIX family - a convenient typewriter machine. The standard Rio shell and the Acme editor/interface require you to have a 3-button mouse. If you manage to work using only the keyboard, it will be very uncomfortable and will require you to make changes to the code of the basic utilities.

And you know, I tried to work in this paradigm. But the longer I worked like this, the more I realized that although this is an interesting approach [you can add your command to Acme by simply writing it in the panel!], it does not allow me to work as fast as with a keyboard-oriented interface.

Standard CUA⁷? Forget it.

Syntax highlighting? Forget it. [“Don’t write such complex code that needs syntax highlighting.” Well, it’s just a great idea. How could I not have guessed it myself.]

What to do?

I have been hatching a plan for some time to return the typewriter to Plan 9 in the form of a small set of programs:

• tiling window manager (at the stage of experiments with input/output);
• simple terminal emulator (not started yet);
• emacs-like text editor (at the stage of the first sketches).

But here’s the dilemma.

Leave Plan 9 as an ideologically pure artwork and not let it reveal itself to the fullest?

OR

Get in with my dirty hands with software that destroys [maybe] the philosophy of the entire OS?

As you may have noticed, I’m leaning towards the second option. Maybe a lot of people won’t like what I’m going to do. Even with proper planning and careful work, I’m afraid to complicate what I shouldn’t. On the other hand, no one forces them to use this software. Well, I will not give up tips and commits.

But maybe I’m not as lonely as I think I am? Maybe there are more people who could not “switch” from UNIX to Plan 9 for similar reasons? And what happens if they all get, though not identical, but similar to the usual tool on top of a beautiful architecture that you can work with, forgetting about the boundaries of the machine? I will not rush into such formulations as “revolution” or “unprecedented progress”, but this will definitely be an interesting dynamic.

Plans

With this article, I want to start a series of publications, lyrical and technical, dedicated to 9front⁸ [Plan 9 fork].

Some of the articles will be sketches for my educational work on OS [“be” won’t mean often!]. Technical articles (installation, configuration) will be useful for people who are just starting their acquaintance with Plan 9. As it turned out, there are not so many of them even in English, not to mention Russian. This way, beginners and those interested will get a faster start than I had.

PS

Even if you read this article a year, two, five, ten years later and thought the same thing at the time - write to me in one of my resources [preferably by mail or in nostr]. It will be very interesting to know your opinion on this matter.

sarcasm

Indeed, I think this will be a great entry point for my resources. For a long time there was a simple stub that I used for local resources. But then I started one of the projects and started thinking, how can I communicate my contacts to people in a compact way? And here is my own page on the Internet. So anyone with a browser and without any account can go in and read if they are interested. Well, my inner graphomaniac will finally find an outlet for his letters.

I use a simple SSG Hugo¹. So a blog is a set of generated pages without any engine under the hood. It’s both simple and safe. I think dependence on technologies, even free ones, is an addiction. So following KISS² in everything is a good plan in my opinion. It should be possible to understand the technology within an acceptable period of time and not overcomplicate it ever. The tool should not be more complex than the job for which it is intended. This principle is preached by many: suckless.org³, Drew DeVault⁴, UNIX/Plan 9⁵⁶, etc. I won’t argue with them, because I mostly agree with them.

I also want to experience those good old days when people just kept their Internet pages for themselves and their friends. Before corporations lured everyone onto platforms they controlled. Everything I write here is entirely under my control. If I want, I’ll change it, if I want, I’ll delete it. Yes, someone can make a copy, but it will only be a copy. Of course, this does not mean that I will change everything that is written here every day. But the possibility of this warms the soul.

I will, of course, leave the rest of the resources for cross-posting for now. Over time, perhaps I will get rid of them. Or maybe they will be replaced by new popular resources and tools. At a minimum, this resource will also be available through Gemini⁷ (seriously, this is a very interesting protocol).

So for now:

make publish

His name is mice¹. For he is small!

I thought, what am I missing as a programmer? That’s right, my own Scheme dialect. Of course, the point is not that I just want to write an interpreter. The fact is that the new wonderful programming language Hare² lives without the ability to extend application logic with any scripting language. This can’t go on any longer! “How long!” I thought and sat down to work.

In fact, I expected that much would be unclear to me. But having some experience writing plugins for Emacs and a little experience in Hare itself, I had an idea where to approach it. I also found an excellent article³, which explains in a very basic but clear way what and how to do. I slightly reworked Hare lexer, wrote a small READ, tweaked EVAL. And before I could blink, my interpreter began accepting test code for calculating Fibonacci numbers for interpretation!

(define (fib n)
        (if (= n 2) 1
          (if (= n 1) 1
            (+ (fib (- n 1)) (fib (- n 2))))))

After that, I filed REPL itself and now it usable!

$ ./mice
mice-repl v0.0.0
λ => (define x 12)
12
λ => (+ x 25)
37
λ => (define y (+ x 25))
37
λ => (exit)
Bye!

Of course, there is still a lot of work ahead, but I can handle it. Initially I thought I would add one primitive per week. But implementing Scheme on Hare turned out to be so easy that in a short time I was able to add almost all the most basic primitives. I think I will have some difficulties with the garbage collector. Something tells me that no one has done this on Hare before me. All that remains is to read the documentation and code examples in good old C. Fortunately, Hare and C have comparable capabilities.

As an unexpected bonus, I received another piece of the “understanding technology” puzzle that I was putting together. Now I can say with confidence that I not only understand exactly how machines process commands and perform the operations described in them, but I have also implemented such a machine, albeit at a very basic level and not in hardware. But who knows, maybe someday I’ll get to a stack machine on FPGA.

In the meantime, wish me luck, because I have very big plans for this interpreter.

To be continued…