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.

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.

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