Admiring Cybernetics in Software

A deep dive into the wonderful land of windows and widgets has led me through the architectures of Oberon, Plan9, NeWS, Arcan, Fresco, Genode, etc.. Without going deep into the specifics of each one, not in this post at least, I wanted to talk abstractly about what all these systems have in common.

Let’s briefly talk about each one and we can begin with the most well known system out of the lot, Plan9, and of course the most well known part being the “everything is a file” concept. The concept gives the system and all its parts a common language to act upon. Information in this concept can be categorized and addressed discreetly. All the while being observable to other parts of the system. Being a file system it has a really clean concept for hiding information in said system or overriding parts depending on the context in which it’s being accessed. Leaving Plan9 for now.

Next let’s look at Arcan. Arcan is a self-described Display Server, Multimedia Framework, and Game Engine. At the surface it’s apples and oranges to a whole operating system, right? Well, Arcan is built on top of shmif (shared memory interface) which is a lightweight data model capable of serializing audio, input, video, etc… data across applications in a really fast and secure manner. Arcan uses shmif to great effect in Durden and in conjunction with A12 shows what a modern desktop environment should look like (not biased at all.)

Rapid fire time:

  • Genode is another gem. An OS framework focused on capability-based security. With an extremely robust and recursive delegation system. Really underrated, even by me, and really deserves more attention (including mine own.)
  • Oberon is famous for its extensibility and dynamism. Oberon, the language, It’s often likened to Smalltalk and its style of object oriented programming. Oberon, the OS, has a really distinctly powerful gadget system that makes heavy use of record messages.
  • Fresco a exciting windowing system built on top of COBRA.
  • NeWS a extremely powerful display server using PostScript.

At this stage you might get where I’m going. I’m talking about IPC/RPC, right? Some form of shared remote or interprocess communication underpins the design of all these projects but what I’m trying to address here is actually larger than a single form of IPC/RPC. In fact a single form of IPC isn’t specifically necessary.

Communication in all of these projects really just boils down to that information is being shared. Messages are, in some form, being serialized and sent across to various different components. Funny computer programs do input/output, right? Sure, but it’s the way in which these projects engage with communication as a core component and how that’s done in relation to the overall system. Communication is key but it’s not the whole story.

We typically attribute using message passing, or RPC, and IPC as part of various design patterns. A method control in client/server, microkernel, and pure OOP architectures (among many others.) If you spend time with these various different projects they feel different. There is a way in which they are somehow much more integrated and composable than the design patterns we use to describe them usually.

I’ll quit beating around the bush. These projects are different than their design patterns and the feeling of how they are different is quantifiable. Be it by design or completely accidentally, each of these projects end up being quality examples of embracing cybernetics.

Regardless of the specifics, languages, or patterns they all end up solving:

  • A mechanism in which encapsules recursion
  • A method of communication with N+1, N, and N-1 recursive levels and sync state when appropirate
  • Some way to handle failure and understand when failure occurs
  • Some way to be addressable from the outside and handle incoming messages/data/information/failure
  • A sense of what component is and what it does

Once the above is solved in their given project they then go on to tie every component together with said solution. Every architecture, not just these projects, have to solve these problems in some way or another (even via absentia.) They are rarely solved at a project or system level. Much less specifically sought out and addressed.

The details of how each one of these projects solves these particular issues, then melds them into their specific design patterns, and then how deeply integrated their solutions end up being in the resulting system is the subject of a different post.