nfirvine.comwiki

Root

Filed in: Ideas.Root · Modified on : Sat, 11 Feb 12

Impetus

I really liked Digital: A Love Story and Uplink. But I wondered if it wouldn't be cooler to make a system that's a little more realistic. That's console-based. Hence root, the hacking simulatrix. Uncover dastardly government plots! Bring the world to its knees! Become God of the Internets!

Tech

Relation to Hash Shell

It might be kind of neat to use the ideas from Yamsh aka Hash Shell as a basis for a fake OS. I like the idea of having a stable data format to pass between programs, and I like a standardized command naming convention.

Over a year later and some more experience with JSON, I'm waffling again on the subject of JSON vs YAML vs XML. JSON has its drawbacks (namely lack of comments and general inflexibility make it difficult to write by hand), but so does YAML, like the weird-looking typing system and a smaller adoption. (XML is completely out -- one of the ugliest, most verbose, and cumbersome languages to write by hand IMO.)

Implementation

I want to avoid this becoming "Nick's complete OS from scratch". There should only be enough cool, new improvements to support the game aspect of it, and to make it feel like a complete OS. For example, it would be good if we could just avoid IPv4 entirely and only do IPv6.

The OS

I'm considering employing User-mode Linux in a VM with Yamsh replacing the usual GNU stuff. By using UML, I avoid having to recode e.g. an entire network stack or filesystem from scratch. However, running a game as a VM might be overkill.

The OS is tentatively named "ROS".

Window Manager

By default, terminals should run a textmode window manager, similar to GNU screen. No application that runs in screen should do window management (e.g., like how Vim can split, has tabs, etc.), since each application is embedded in a screen window.

Windows have real and virtual dimensions and are scrollable when the virtual dimensions are greater than the real ones.

Windows can be nested. For instance, the root window could be split into two vertical windows: the left is split into two horizontal windows each containing a shell, and the right is a set of tabbed windows, each containing a text editor. Only one window at a time may have focus. There is one key combination that "retreats" from the current window to the parent window to manipulate it; e.g., in tab 2 above, press Retreat to get to the tabs and change to tab 4, which could simply reveal it, or reveal and focus.

Terminal Capabilities

The terminal will be required to be Unicode capable and support 256 colors, like most Linux terminal emulators I've seen, There should also be mouse support. Keyboard layout should not be assumed, but a minimal reasonable subset may be.

Process

Each process shall have a few default pipes (with accessibility from process's POV):

  • data (r/w)
  • ui (r/w): read represents keyboard/mouse; write writes to the screen
  • ctl (r): receiving signals, like KILL, TERM, etc.
  • error (w)

All pipes except the ui pipe are only for well-formed data (YAML documents). In very few cases, data may be binary data (non-YAML) in a app-specific format; for example, cat would need to have non-YAML output.

Pipes may in fact point to the same destination, namely data and ui outputs.

Filesystem

The filesystem is based largely on the Plan 9 principal that everything (possible) is part of the filesystem. If you want to open TCP socket 5166, you'd socket = open('/net/tcp/5166', 'rw') and socket.write('somedata') to write to it.

Directories may be both a container for files and a file itself. For example, /bin/te might be executed to invoke the text editor, and /bin/te/doc/invoke might be a link to te's invocation documentation. To distinguish between the file and the directory (where it is not obvious by context), directories end with /.

Each process has its own view of the filesystem, more aptly called a "namespace" (in Plan 9 parlance). Processes can (and usually do) pass down their filesystem view (a mount table) to their spawned processes. However, there is also a kernel filesystem, from which all process filesystems are reachable.

Filesystem Tree

/proc/
Process information
n
Information about process number n
self
Information about the current process
init
Information about the initialization process (pid 0)
fs
The process's entire filesystem.

Each process directory contains:

fd/
Open file descriptors
mem
Memory
mnt/
Mounted filesystems
bin
Executable name
/dev/
Devices
disk/bus/location-on-bus/partition
e.g., /dev/disk/scsi/0/0 is equivalent to /dev/sda1 on Linux.
disk/uuid
Analogous to /dev/disk/by-uuid/uuid
/bin
Hierarchy of executables
net/
Network-related programs

Bundle

The filesystem will need to be distributed in an imagey format. I'm thinking compressed tar (TOC not at beginning, bad random access, no encoding support): or zip. Contents would be a number of file data objects, indexed by hash, and a pile of metadata, describing the tree structure, file types, etc.

Processes

In ROS, binaries are run in processes. There are no threads. When a process spawns a subprocess, the parent process controls what parts of itself are inherited by the child, like its filesystem view.

I think I'd like to implement Processes as Tasklets, using Stackless Python.

IPC

The only form of IPC is through pipes and sockets. Generally, they operate on YAML documents (messages). Pipes may be reconnected between messages to do live teeing or multiplexing. Complex pipes are implemented as processes themselves.

Virtual Network

The root game takes place on a virtual network running on the player's host computer. The network consists of many nodes, some/most/all? running ros.

The network is governed by a hypervisor that oversees all nodes. All nodes run a single ros kernel, and that kernel governs processes on that node.

On the host machine, this is all one process.

Networking

All networking is IPv6.

Code

All code is Python, except where it is ros shell. It might be neat to have virtual mounts on /bin, that, when dumped, yield python byte code.

Email

Email is an integral part of storytelling. Email gets mounted in /mail (filesystem is per-process, remember?).

rosh, the ros shell

Use prefix/postfix for different pipes; e.g., "code/compile something.c e|d file/write /tmp/log" compiles something.c and connects the error pipe to the data pipe of file/write, which writes to /tmp/log.

Art

Videogames are inevitably a union of technology and art, each supporting the other. While root will have some significantly cool technology, I think the emphasis should be on the art side, working under the theory that competition in the technology requires more money than inspiration and art the opposite.

Narrative

The player takes the role of the classic evil AI (Shodan, Skynet) that takes over the world, but not in an ironic Dungeon Keeper way, more of a giant misunderstanding. This AI is the first true digital lifeform, and like all lifeforms it seeks to live and thrive. Being young, it doesn't realize the consequences of its actions.


Powered by PmWiki