tomo platform

comrade sketch

the base system provides a runtime environment for distributed applications. this document provides a high-level overview of the available programming interfaces and links to more specific documentation.

x-platform via source-level/self virtualization

inferno can 'self-host' on various ARM, PowerPC, SPARC and x86 platforms but also 'hosted', under an existing operating system (including AIX, FreeBSD, IRIX, Linux, MacOS X, Plan 9, and Solaris), again on various processor types.

we define a virtual system target, which is provided by port-specific constructs which guarantee the system contract. this approach has been done in multiple ways either as part of the build system (inferno) or as parameterized modules (ocaml functors in mirage OS).

language kernel

register vm with jit capability. trying to optimize the power to weight ratio.
prescheme vm for AOT optimized DSLs.
stack vm designed to facilitate instruction set development especially for array programming.

notation

If [you take] a look at how APLers communicate when they have ideas, you see code all the time, all day long. The APL community is the only one I've seen that regularly can write complete code and talk about it fluently on a whiteboard between humans without hand waving. Even my beloved Scheme programming language cannot boast this. When working with humans on a programming task, almost no one uses their programming languages that primary communication method between themselves and other humans outside of the presence of a computer. That signals to me that they are not, in fact, natural, expedient tools for communicating ideas to other humans. The best practices utilized in most programming languages are, instead, attempts to ameliorate the situation to make the code as tractable and as manageable as possible, but they do not, primarily, represent a demonstration of the naturalness of those languages to human communication. — aaron hsu

limbo is the extant common language in tomo, but we'd like to make it easier to define interoperable DSLs and high performance programming languages on the kernel vm. prescheme has some interesting ideas in this direction that we ought to take inspiration from. interestingly, inferno ends up reproducing part of the lisp solution for a unified runtime. syntax construction is again left as an implementation concern, rather than a central feature, but inferno brings unix back to the language kernel ideas that make lisp machines (Symbolics) and oberon (Wirth, Gutknecht) so interesting.

beyond this technical requirement, we would like the end system to be flexible enough for anyone to "program in" the way people can "program in" excel and do a bunch of complicated work without "being a programmer". including very flexible input methods to facilitate the use of OG maya and nahua writing systems and many others without the need for decades of work retrofitting the limited unicode standard. we hope to extend this design to allow very easy and direct interaction with computer systems using natural tablet input methods and efficient table processing.

service oriented message passing

The essential problem that must be solved in making a fault-tolerant software system is therefore that of fault-isolation. Different programmers will write different modules, some modules will be correct, others will have errors. We do not want the errors in one module to adversely affect the behaviour of a module which does not have any errors.

— Joe Armstrong

In our approach, all data is private to some process, and processes can only communicate through communications channels. Security, as used in this paper, is the property which guarantees that processes in a system cannot affect each other except by explicit communication.

When security is absent, nothing which can be proven about a single module in isolation can be guaranteed to hold when that module is embedded in a system [...]

— Robert Strom and Shaula Yemini

Concurrent and applicative programming complement each other. The ability to send messages on channels provides I/O without side effects, while the avoidance of shared data helps keep concurrent processes from colliding.

— Rob Pike

inferno represents services and resources in a file-like name hierarchy. programs access them using only the file operations open, read/write, and close. 'files' are not just stored data, but represent devices, network and protocol interfaces, dynamic data sources, and services. the approach unifies and provides basic naming, structuring, and access control mechanisms for all system resources. a single file-service protocol (the same as Plan 9's 9P) makes all those resources available for import or export throughout the network in a uniform way, independent of location. an application simply attaches the resources it needs to its own per-process name hierarchy ('name space').

9p
krpc
http/cgi

venti ⥊ object storage

content-addressed storage that syncs!

OFFSystem

a major goal of the pikabu project is to roll out a distributed object cache based on information-centric networking principles that eventually can replace the s3 and disk-based object storage currently in use on the fediverse.

the pikabu design is trust-based, no benefit in providing object storage to unknown strangers, but open-ended so groups of users on independent OR shared infrastructure can cooperate to provide resilient online services. narrow scope for now, but in theory the architecture can be extended to provide any kind of network services including distributed and decentralized email and activitypub systems. in a word: communist☭ cloud storage☁ .

anonymized public shared storage, useful!

factotum ⥊ dark crystal

Dark Crystal is a protocol for distributed data persistence and threshold-based consensus. It is based on a secure implementation of Shamir’s Secret Sharing and has multiple possible applications in security-oriented tools.

Factotum is a user-level file system that acts as the authentication agent for a user. It does so by managing a set of keys. A key is a collection of information used to authenticate a particular action. Stored as a list of attribute=value pairs, a key typically contains a user, an authentication domain, a protocol, and some secret data.

adhoc grid computing

your computer is legally distinct building blocks

community oriented resource sharing. build collaborative networked grid systems using any available hardware or cloud resources.

optional software

TOMO DOES NOT HAVE A PACKAGE MANAGER, but we do provide a standard facility for manually building and installing shareware from the internet.