Note: Parts II and III are up now.

In the art world there is this idea of anti-art. The goal is to do all of the things backwards or wrong so that you can discover new rights. You have to tear down the world before you can build it again. I’m not entirely sure how it works, but they seem happy with it so I figured I’d give it a go with something that really needs shaking up: the *desktop operating system*.

Beforwarned. This post is an epic. Not epic in a"'that movie was awesome" sort of way. It's epic in a "3000 stanza poem you had to read in english class" way. Just FYI.

Since this is my blog I’ll start by getting rid of everything I personally hate about operating systems.

Fixed Font Sizes

I’m getting old. My eyes don’t work as well as they used to. I should be able to resize any window, or the entire OS, by hitting cmd-+. It works for the web, why not the desktop?

Filesystems

They crash. They have weird restrictions. They have a single hierarchy. They are slow to search. And the folder metaphor is sooo 1980s I feel like I need a Flock of Seagulls haircut (kids, ask your parents). Let’s just get rid of filesystems right away. In the bin.

Device Drivers

Device drivers are the crap software written by hardware companies. They fix just enough bugs to ship, then move on to the next project. Installing them is a pain. Updating them is a pain. Uninstalling them is nearly impossible. Device drivers need to just go. Seriously. Just go out the way you came in.

Backing up your computer

So annoying! Built in backup software sucks and 3rd party software sucks even more. Backups are slow, we forget to schedule them, and they magnify the real problem: the filesystem. First you’ve got a filesystem. Then you’ve got a backup of the filesystem. Now you’ve got two problems. Just go.

System utilities.

These are the redheaded step children of OS applications. Apple spends a lot of time polishing Mail. The system console? Not so much. Oh look, there’s a whole folder of these poor guys. Who knew?

Window managers

I sorta like Window Managers, but the existing ones kinda suck. I like application windows. It’s the management part I hate. All of that moving and resizing is annoying and error prone. If only I had some sort of automated tool to manage windows for me. We could call it a window manager. Nah, that’ll never work.

Inputs

I like the mouse and keyboard, but my computer has a camera and microphone too. Yet the OS itself doesn’t use it for interaction. No voice recognition. No visual gesture support. They should really just call the camera a Skype accessory since that’s all it gets used for. We should find a use for these or get rid of'em. The NSA wouldn’t be happy, but that’s life.

Applications:

This is the big one. I could learn to live with all of the other problems but applications are too big to skirt around. "Your application is so fat when it walks around the house it really walks around the house” (kids, ask your parents).

Supposedly we buy computers to run applications, but that’s just not true. We buy computers to get some work done. In theory applications help us do that but in practice they often get in the way.

Each application looks and works differently. Each has it’s own file format, or worse, unreliable internal database. They are supposed to work together but in reality they just share files on disk, and that only works half the time. Drag and drop would seem like a solution but it’s really just a short hand for sharing files.

Each application is it’s own silo. A world unto itself. In the age of the app store this isolation is just getting worse. Every year another brick in the wall. (kids, ask your parents). Applications definitely have to go.

What's Left?

So, after throwing away applications, filesystems, device drivers, system utilities, and everything else; what does that leave us with? Not much. Just the kernel for managing CPU and memory, an empty bitmapped screen, and, um.. some memory buffers I guess. Now what?

Well, if we were willing to add the filesystem back in we’d pretty much have Unix, or at least old Unix before X. A bunch of tiny tools, not applications, that connect together in different ways to get work done. Quite productive. The only problem is we have to time travel back to the 70s. Going with pure Unix means giving up graphics, typography, modern networking, cameras and microphones and mice. In other words, giving up all of the progress of the last 40 years.

Surely there is some sort of middle ground?

Yes! Yes, there is! We can rebuild the desktop computer. We have the technology. (kids, ask your... oh just Youtube it!).

The creators of Unix had the right idea: little tools that you combine to perform different tasks. The problem is the interchange. Unix tools share data through a single stream of bytes. Great for 1970 but not enough for today. And because that wasn’t enough to do everything you’d want to do, they continued to hack ioctrls and control characters on top. When that didn’t work they added X-windows, a horrible abomination against heaven and nature that somehow crawled out of the primordial slime and refused to die when evolution gave up on it. (Kids, read a book).

Simple Tools

What we need are simple tools that communicate using a stream of small objects. They could be events or records or something else. I’d go with JSON, but that’s just me. The important thing is they must be structured and human parseable; higher level than pure byte streams.

If object streams form the primary way our tools communicate, then how do they store things. We got rid of the filesystem, remember?

How about a document database? Databases have gotten really good in the 40 years since SQL was invented. They can store structured documents, byte streams, and metadata. They can give you live queries. They can do full text search. Let’s finally use a system that allows a file appear in more than one folder at a time. Hierarchical filesystems in 2014 are madness. It’s time for something better.

Now then. Armed with a database and streams of objects we can rebuild the world. Lets start with graphics.

# Graphics

We are more than a decade into the 21st century. We can assume a proper GPU will be available. That means our base graphics layer can be a real hardware accelerated OpenGL scenegraph, not bitmaps layered with software.

Which scenegraph? Who cares. There’s a ton to choose from or we can build a new one. The important thing is hardware acceleration is mandatory. *Mandatory*. Something with shaders. OpenGL ES 2.0 or higher. And I don't care about X-Windows network transparency. That's an idea that died along with Network Computers and SunRays.

So we have three things: a database to hold stuff, object streams to send data around, and a GPU to draw it. Now we can start to build some tools. But we can’t just start building applications. Applications are bad, remember. Let’s think about tasks we want to complete, then talk about how to build the tools to accomplish those tasks.

# Modular Email

Let’s start with something simple: checking your email. There are actually many pieces to this. First you have to set up your email. The computer needs to know the server where you receive email, any proxies or security layers (SSL,TLS, etc), and of course your username and password (assuming that is the authentication mechanism your email provide uses). Then the computer needs to speak the server’s protocol. Let’s keep it simple and assume we only support IMAP. Now the computer needs to download your email message and store local copies on disk (in our *real database*, not files) Then the computer must show the new messages to the user in some sort of sortable list. Finally, when the user selects an email message the computer must display it.

So far so good. We know how an email is viewed. The problem is that in a traditional desktop operating system this is all done by a single application called the "email client" even though many of these tasks have little to do with one another. In our new OS we can split these out.

a setup wizard for capturing email account information.

a service to check for new emails and download them into the database

an inbox view which is just a saved database query rendered in a particular way (namely, ‘from' and ‘subject' fields from messages displayed in a standard sortable list view)

and finally an message view which can display a single message.

By splitting up these functions into separate modules we make it a lot easier to write email support for our new OS. It also means we can change and add functionality in one part of the system without modifying others. Let’s consider a few additions:

A spam filter doesn’t need to know about how emails are viewed or downloaded into the system. It just needs a list of new messages. In other words: a saved database query. Whenever a new message comes the filter analyzes it and adds a `spam` tag if it’s spam. Then the inbox viewer can display spam messages in a different color, or under a spam folder, or not display them at all. Separating out functions makes everything easier.

Adding a new email service is simple. We need a new wizard to create the "account" document stored in the database. When the email checker runs it looks for all account documents then connects to each one looking for new message to download. If the new mail service uses a different API (say, GMail’s new API), then we add a new email checker implementation. The rest of the email modules don’t have to change at all. They don't care. Proper separation of concerns. Brooks was right.

Trigger rules: Want to control your music by email? Add a filter that looks for messages with a subject like: “play music, beatles random”. When it finds such an email it marks it as deleted then plays the music. Nothing else in the system changes.

By splitting the email task into separate modules the system becomes more flexible and hackable. A trigger rule can be written in any programming language. It can have an interface or be headless. As long as it can talk to the database it can do it’s thing. Modules with standard communication gives us flexibility and power.

The Other Apps

Imagine if we apply this modularity principle to everything else on your computer. The applications I use every day include iTunes, Evernote, Mail, Things (a todo list), Contacts, Calendar, Messages, iPhoto, Coda (a code editor), and Safari. Except for Safari, everything else is essentially an editable view into a custom database. They could all be broken up into modules that combine in different ways to replace the existing functions, and let us do so much more.

iTunes: becomes a few sortable list views of database queries, a music playback service which supports local and remote resources, and a visualizer. All separate and swappable. iTunes is pretty much a galaxy unto itself these days and is in danger of collapsing into a black hole. Time to split it out.

Evernote: a text editor and a db query, plus a background service to sync with Evernote’s servers.

Mail: As discussed before, many different modules.

Things: a tiny text editor (single line) and a DB query of tiny documents.

Contacts: a view into the database of address entries, plus a syncing service.

Calendar: a view into the database of event entries, plus a syncing service.

Message: background modules to connect to various chat services. Conversations become a view into the database for chat events.

iPhoto: again a view into the database, but this time with an image service to perform fast scaling and an view to edit photos. Syncing to iCloud, Facebook, and Flickr become more background services.

Coda: A fancy text editor. It would be the least changed under a new OS, but could benefit from file syncing (replaces SFTP client), and easily managing editor plugins for theming, syntax highlighting, and keybindings. Wouldn’t it be nice to define your keybindings once for the OS rather than in each application? Wouldn’t it be nice if all applications could use SFTP to edit remote files instead of duplicating this feature in each app?

Safari: The many parts of a web browser probably need to remain tightly coupled, but at least bookmarks and plugins could become modules in the system instead of tied directly to the browser. Even the renderer could be a module. In a modern Mac we already have these things (web views and bookmarks databases), but in the new OS the modularity would be explicit and usable from any language.

Only Data Matters

There is another, arguably more important trend here. By breaking up applications into pieces we shift the focus from the application to the data. The things the human wants to do with the data is the only important part.

Our computers can again become "machines to do work", not places to manipulate applications. They become workstations. We interact with our data. The applications are simply small tools that we rearrange as needed. It's more like a craftsman's workbench then the office desk of today.

Next Time

Sadly for you, this is just part one of my series. Time time I'll dig into the actual UI and window manger. How will people actually interact with the system? How will we handle the ever growing information deluge of the 21st century.

Until next time, keep tearing things down.