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