Introduction and Index

Introduction

This blog is dedicated to an exploration of a distributed computing concept called Project MAD.  The hope is that MAD is someday used as a blueprint for hardware and software systems more powerful and flexible than the ones we have today.

I am where I am today, creating this site, because I have a working model in my head, one that satisfies every major problem I've thought up to date.  It is what is generally referred to as having a vision.  I am not, however, the kind of person who assumes that just because I envision it, it will work.  I also write fantasy fiction in my spare time; I can envision impossible things quite easily.

MAD is not an attempt at a money grab, it is not me attempting to implement the various systems described here, myself, and it is not me attempting to recruit people to do the work for me.  I am no salesman or tech CEO eager to turn a few nice-sounding words into a private funding round.  If a billionaire dropped ten mil in my pocket on a whim, I genuinely wouldn't know what to do with it, not if I wanted the best possible chance of success.  That isn't my skillset.

MAD is theory.  When you read the blog, you will find that a lot of it is written to be very high-level, lacking details and disconnected from any implementation.  This is on purpose.  Many things that are now part of Project MAD would never have entered my mind if I had viewed the project through the lens of existing technology.  If nothing else, every failure to implement things would have been harder to take.

If I were ever going to see MAD implemented, I would want to gather experts, and have major architectural decisions made by the people who know those systems, not by me.  While in theory I could start an open-source project which may slowly evolve over time with input from experts, there are still a lot of ground-level choices that would impact the future of the project, and I'd still hope to get input from experts before I made those choices.

Above that, though, I am the wrong person to try to implement these systems.  I have programmed occasionally since high school, and have a bachelor's in Computer Science, but I have never those things professionally.  Many of the core systems, such as OS concepts and programming language parsers, are beyond anything I was ever taught.  When I try to write code for them, my brain locks up.  Romantic dreams aside, I will not be the one who creates these systems.

In that context, it is important to me that I find a way to get all the concepts out.  I will never create Project MAD, and I may never be a part of any group that works on it.  But, I'd like people to at least see the same vision that I do.  If they see it and disagree, that's fine.  But I don't imagine I'd rest if the vision disappeared without ever being understood.

Suggested Reading Order

Project MAD is a complex topic, and many of my posts will go into details that make no sense without a greater context.  In this section, I will break up the blog into three general categories: Overview, Subproject-specific, and Extras.  A lot of the more specific posts and Extras will assume you've read enough of the Overview to have a general understanding of the project, in order to not go off on tangents explaining why things are important and how they relate.  (Believe me, I have a long history of going off on tangents.)

Overviews

Project MAD, in Theory - The canonical overview and first post in the blog.
The Problem with Modern Computing - In which I try to justify calling MAD the future of computing.
Why MAD? - A new overview that justifies the search for distributed applications, in general.

Extras

What's in a Name? - In which I talk about the original project name, MOS/DCA.
History of the MOS-ADA Model - Some background explaining how I got to the ADA model.
IP: The Worst RPC Stack - In which I make the argument that the internet protocol should not be used in place of a proper remote procedure mechanism.

OS-Specific

The MOS Unified System API - A high level overview of the MOS directory, in particular its use in standardizing APIs across a distributed system.
Plan 9: On Resource Distribution - In which I talk about the difference between making resources publicly available and expecting applications to "pull" them in, and taking the initiative to "push" an agent out to deal with those resources on their own hardware.
Beyond Unix: Application Folders - Describing a technique for deploying, configuring, and communicating with applications via the filesystem.
Beyond Unix: The System Directory - Explaining the role that the filesystem has in Unix, and starting to talk about how that will be modified.
Beyond Unix: Typed Data - In which I make the point that data in storage and in transit should be abstracted away as much as possible.

App-Specific

Remote Procedure Calls under MOS/ADA - A set of observations and requirements for remote procedure call mechanisms.
Programming MAD - In which I suggest that the ADA mechanism will be powerful while also not being too difficult for beginners to grasp.

Hardware-Specific