we are on a peaceful scientific mission. a full briefing is available here.
design and lineage
tomo is a rapidly evolving reserch project at this time, use at your own risk!
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').
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.
snapshot builds are published periodically. real stable versions of the base system are planned, but not likely in the near future. currently we are publishing only Linux-386 builds. we may eventually graduate to nightly builds.
tomo is based on inferno from vita nuova. the concepts behind tomo have been an on going research project of mine for at least a decade. i tend to analyze things from a top-down approach, so it has been a long road down to the metal. i have followed and sometimes particpiated in hobby os projects, but the most persistently inspiring system to me has always been plan9 and its variants. i do appreciate a lot of what haiku brings to the table, but i can't embrance C++ so deeply. there is a lot more to be said about my design goals and ideas, but i'll have to dig them out of backups and probably update them. don't hold your breath for speed, but i do hope i have something interesting to contribute ^^
i share some of the concerns that a collapse scenario is possible, but i choose to set a different bar. tomo does prioritize portability and simplicity, but also security. the crypto requirements alone set a minimum bar for supportable hardware. short- and medium-term salvage hardware should be sufficient for something like inferno and fits the solarpunk ethos. a collapse scenario would be catastrophic and something like collapeos may be the only realistic approach. for the time being, i think its important to reach for systems that can thrive in an increasingly chaotic world. simpler, more robust, and easier to learn.
APL was originally designed as a mathematical notation for describing algorithms (Iverson). a prophetic design, decades ahead of its time, now perfectly at home on modern data-parallel hardware, including GPUs. not because the designer imagined this is what machines would look like, but because the language was designed to enable humans to easily reason about computational problems in their heads and on paper. in the same spirit, tomo el fuego, cryptogen, and bbnet represent conceptual areas that eventually will be represented as a notational language of their own. focusing always on the HCI problem and creating useful and general thoughtforms, in pursuit of an informatics system that can stand for a century or longer.