Dinghy index concept papers System Niches . Explore a range of niches that computer systems fit into. Niche/0: Dinosaurs Mainframes, Minis. Defined the era when computing was expensive. Buy-in cost more than the average annual wage, with further ongoing costs, and the installation dominates a room. Niche/1: Real-time systems Platforms that must work well. Many have life-and-death stakes. Key qualities Device should never cease working correctly. Common use of timing guarantees, which must be met. Examples, Computers driving manufacturing equipment Drive systems in motor vehicles Niche/2: Early home system Console driven system with no network. Typically: 8-bit word-size, 16-bit address size, small ROM kernel offering a BASIC repl. Modern take on this genre, Maximite Makerlisp Niche/3: Racing dinghy Responsive, single user systems. Key qualities Developer interacts with the system bedrock. Sound and graphics Small kernel with support for multitasking Lightweight desktop, if any. User is all-powerful System ships with tools for interacting with the bedrock. Historic systems tended to be weak on the last point. Examples Amiga. Well-architected platform. Bundled dev tools were weak, but sufficient for a skilled user to bootstrap. Strong third-party tools available. Atari ST. Well-architected platform. Did it ship with dev tools? Strong third party tools available. Other systems that fall short, Apple IIGS. Bundled dev tools were weak, but sufficient for a skilled user to bootstrap. Better after market tools were available. Limited by legacy constraints of being an Apple II system. Strong audio. MacOS Classic. System came with no dev tools. Original arch was 68k, similar to Amiga/Atari. After System 7, you could install python to break out of the sandbox and do as you liked. Tutorial for creating a dev env in emulation, http://beyondloom.com/blog/thinkc.html VGA PC era. DOS, OS/2, Win95 and Win98 shipped with a quirky machine code monitor. Even by the birth of the 386, the PC platform was awash with legacy complications (e.g. a20, gdt, 640k barrier), increasing the barrier to entry. Batch and REXX could be used for scripting. Strong third-party tools available, some at low cost (Turbo Pascal). Sound blaster became a defacto standard late in this platform's life. The game Transport Tycoon illustrates the power and flexibility that were possible on this platform. Example of a no-tools bootstarp on DOS: https://github.com/mniip/BOOTSTRA. JVM, CLR. You can build a universe within these systems. A challenge: they tend to live on top of yachts. With a lot of effort, you can create a stripped linux foundation and achieve a high level of mechanical sympathy. Examples: LMAX, INET. MikeOS TempleOS Past systems of this form were vulnerable to malware. This is not an inherent flaw of this niche. Consider if we created a multiprocessor system, with limited memory maps. You could sandbox a process to a specific core with a limited memory map. There have not been any strong examples of this category since ubiquitous internet. Introducing networking to a dinghy presents several special challenge: Finding a balance between synchronous and asynchronous concerns, For responsiveness IO, a dinghy will tend to bring a synchronous attitude to IO. For example, polling to see whether the down arrow key is currently depressed. But networking is most effective when it is asynchronous. Example: requesting a call-back when a new message arrives. Security, Once you are on the network, security becomes a high priority, because it is so easy to get owned. The successful Windows 95/98 line of computers were killed off essentially over this issue in favour of Microsoft's yacht platform, Windows NT. Perhaps the ideal racing dinghy will have no network ambitions. if it has powerful enough local tools, does it need to live on a network? In the eighties and nineties, RAM was expensive. In 2020, RAM is cheap. It should be possible to do clever things with plentiful RAM. Niche/4: Yachts Mainstream workstation/server bracket. Key qualities CRUD filesystem. Multi-user design aimed at an academic or enterprise setting. Heavy emphasis on permissions. Users are treated as guests. There is clear separation between kernel and userland. Userland interacts with the kernel via a synchronous API. Variety of local-IPC mechanisms. An emphasis on some mix of cheap-processes and multi-threading. These mechanisms allow the system to achieve multicomputing despite the design weight of everything above. As a result of everything above, a large kernel written in C. Complex software installation arrangements. Examples Modern Unix. BSD, System-V descendants, Minix, OSX, Linux, etc. Windows NT. BeOS/Haiku, although is not multi-user. Note that Minix does appear in the Unix group above. As a microkernel, it moves some code out of the kernel. But as a platform, it pays the same design taxes. Gravity towards C/C++ C for the kernel. Allows developers who to reason about and debug large kernels. C++ for userland, particularly flagship applications. Office, photoshop, browsers, cad systems, video production tools. Yacht filesystems are quirky. On some levels, they look sophisticated. We have NFS and CIFS. We can partition then in neat ways, and mirror, and there are clever mechanisms to defend against corruption. Yet, our interactions with them are awkwardly synchronous. Consider the hassles involved in closing a file that might be on a remote system without jamming the application. Imagine a world where TCP had happened before hard disks. Perhaps we would say "everything is a stream" rather than "everything is a file", and would engage with our kernels using messages rather than synchronous API calls. The historic cost of RAM may also be a factor in the synchronous habit. Niche/5: Personal Device Phones and tablets have their own niche, the Personal Device. Key qualities Feel matters. Sound and graphics. Developers cannot directly interact with the underlying machine. User is sandboxed in a simple process model. May not have a filesystem. Weak IPC Examples Teenage Engineering OP-1. Pure example. This is a synthesiser built from first principles. It runs some kind of minimal operating system on custom hardware. Low-enough latency software system, beautiful small display, responsive controls let users craft waveforms. Apple iOS. Apple control the whole stack and have created a platform that is able to run commercial quality audio tools. Android. Android is a less pure example. It is a Java shell on top of a linux derived OS. It is not well-suited to low-latency audio work. OTTO. This is an attempt to build a device similar to the Teenage Engineering OP-1, on top of a Raspberry Pi running Linux. Given the difficulties that Android has had, it will be interesting to see whether they can make this work. Might Arduino be a better foundation? Games consoles from Atari 2600 to Nintendo Switch. Niche/6: Single System Image Distributed computer built from commodity hardware, and operated by a single party. Key qualities Single interface to a system composed of multiple computing nodes. Examples Amoeba Inferno Cthulix Niche/7: Consensus network Distributed computer operated by multiple parties. Key qualities Strong emphasis on achieving consensus between nodes. Examples Ethereum Other Word-processors of the 80s. Canon cat, Brother devices. Plan 9. Seems half way between a Yacht and a Single System Image. Oberon. Where does it fit? Yacht ambitions? kOS. Where does it fit? (As of 2020, seems to have been abandoned?) BaremetalOS. Aimed at the HPC domain. Strong mechanical sympathy goals. Does not contain its own dev tools, no sound or graphics. RMoX. This is an OS platform written in an obscure asynchronous systems programming language called Occam. It may have strong potential as a dinghy foundation. Links to the source code are broken at the time of writing. https://www.cs.kent.ac.uk/projects/ofa/kroc/rmox-cpa.pdf