What's in a Name?

I suppose I can expect that most people who find their way to this blog post will expect me to give a rationalization for the project name, "MAD," because it seems to be exactly the kind of unsexy name that any reasonable person wouldn't attach to their life's work.  Or, if I may sum up, I'd have to be mad to call my project MAD, especially if it isn't mad, because consumers and therefore industry partners would get mad about being associated with a mad project, even in principle.  As mad as those people would have to be to take things at face value and trust that the name of a project means exactly what it seems to, that certainly is exactly the sort of mad world we live in.

Anyway, no, that's not what this blog post is about.  Don't worry, it's a relatively short one.

In writing my previous blog post introducing the ADA model and Project MAD in general, I said the following two things:

To this day, I still use the same name for [the hardware subproject]: the Distributed Computing Architecture, which is the D in Project MAD.

To this day, I still use the same name for [the operating systems subproject]: The Modular Operating System, which is the M in Project MAD.

It has been on my mind since then, that these two names deserve to be swapped.

In truth, "Modular" is exactly the right descriptor for the kind of distributed hardware that differentiates the hardware design of the DCA from normal computers;  it's all about taking a small payload, attaching it directly to a network bus, and then simply slotting that small, independent module into its place in a larger system.  So pervasive is my belief that these hardware chunks deserve the term that I am constantly trying not to refer to hardware nodes in a distributed system, in general, as modules, even in cases where I cannot assume I am talking about DCA-specific hardware.

According to Wikipedia: 

Modularity is the degree to which a system's components may be separated and recombined, often with the benefit of flexibility and variety in use. The concept of modularity is used primarily to reduce complexity by breaking a system into varying degrees of interdependence and independence across and "hide the complexity of each part behind an abstraction and interface".

In truth, this definition of modularity fits better with the hardware design than it does the operating system.  While yes, the Modular OS concept enables a modular computing, it's less correct to say that the operating system, per se, is modular.  It's not wrong, exactly; we're still talking about reducing the complexity of the operating system by breaking it into pieces.  Ideally, the operating system of each hardware component will be aggressively minimal, as it will only encompass the processor and software ecosystem, the backbone, and a specific payload.  And... some parts of that are arguably less in the domain of the operating system, and more about bundled software.

But the implication of a modular operating system is that the operating system is built on top of modules, not that the modular operating system is used to create modules, which themselves will be part of a larger gestalt system.  Technically, it's both; the effective operating system of a given hardware component will be expanded by all other modules attached to the gestalt system, and therefore, each component is arguably made of all the other operating system nodes.  But that's really not the best possible word for the phenomenon.

Indeed, "Distributed operating system" is a more correct label.  It speaks of an operating system whose whole is divided into parts, and each of those parts is supported by a different piece of hardware.  Being distributed comes with the kind of benefits the word tends to imply, such as not having a single point of failure; the operating system will continue to function even if a piece of it fails, because the effective core of the operating system is held up by all of the operating system "fragments" together.  As long as a single chunk of the operating system remains, you could say that there is an operating system on a whole distributed system, even if every other component has crashed, been destroyed, or been removed.  And like the Ship of Theseus, if you have the system running while you slowly replace every single hardware component (assuming that it is hotpluggable, which I feel comfortable presuming), at no time will the system as a whole cease to be.

In contrast, "Distributed computing architecture" is... honestly not the best name for the hardware.  It describes the overall goal, but not the means, and so it is a poor description overall.  What is it about the architecture, specifically, that is distributed?  It is intended to be capable of creating a distributed system, but there is nothing, and will never be anything, in the actual definition of the DCA that prevents a single hardware component from being a completely independent computer, containing all of the hardware necessary to run a full operating system and user application stack.  A full computer that also had a DCA expansion port would be a computer that could be expanded and extended, but where that full computer has not been expanded or extended, there is nothing "distributed" about its architecture.

No, the right word for that hardware is a module, even when the module itself contains a full and independent computer.  A module can contain a full computer, or it can contain a mere extension; what's important is that the module can be separated from a system and recombined.  As I pointed out in the previous post, there is already a specific use case that proves this point: a theoretical cell phone that can be plugged into a DCA computer to make use of its processors, input, and output.  The phone itself remains a separate and independent computer, but it can also be understood as a module which can be integrated into a larger system.

So what's in a name?  Why do I still use the old and arguably inapt terms?

Well, being honest, at the current time the largest reason why is my own pride.  Not pride, as in "I am proud of my naming conventions," but pride as in, this is mine and I don't want to change it.  That's a little disingenuous; a better explanation is that I want to preserve the origin and legacy of the project, simply because I want the project's origin and legacy to somehow redeem me of my failures since then.  The times when I was depressed and struggling, when people could point to all my failures and say that I was unworthy, even at those times I could point to the ongoing legacy of the project and suggest that I was still, technically, working on it.  That my periods of isolation, loneliness, and despair were somehow necessary, rather than simply being failures.

There are other reasons, though.  One good one is that if you simply swap the first word in each name, "Distributed Operating System" becomes problematic: its acronym is DOS, which (in case anyone in the audience is not aware) is already an acronym in use, specifically in the operating systems space.  That use of DOS is arguably a legacy, as it refers mostly to pre-Windows command interpreters, but at the current time, an unfortunate number of people in the computing sphere would hear the term "DOS" and think of something else, and specifically something vastly inferior to the scope and scale of the project I'm talking about.  DOS was, in its own era, ubiquitous and inescapable, something that academics, business professionals, and home users all came to know very well indeed.  The acronym MOS, while not 100% unique, does not suffer from this problem.  Likewise but less damning, MCA has a few more existing uses as an acronym than DCA, though not any that strike me as being that kind of immediate problem.

Plus, I feel that MOS/DCA rolls off the tongue better than DOS/MCA.  Not that I'm using that acronym pair alone, anymore.  As I am moving towards "Project MAD" as a shorthand for the overarching project, it definitely does not matter whether you switch around the M and the D.  But it's hard to just dismiss twenty years of the acronyms rolling around in my head.  It's not just something that was in my head once or twice, but something I've come back to, something I've invested time and sanity into.

Most likely, if this ever becomes a real project, I'll cheerfully swap the acronyms and never look back.  Where things currently are, with me just trying to explain to the universe that I have something here worth talking about, I'd rather not shake up all of my existing notes for no reason.  I'm not even sure that I'm going to shift most of my private notes from MOS/DCA to MAD, even though I agree that acronym better suits the project.  In my head, the original two projects are still just... what the project as a whole is.

Perhaps that will change as Project MAD develops more.