OnexOS is a proof-of-concept of an operating system without apps! That's quite a dramatic
change, so why do that?
As we will demonstrate here, there are correspondingly dramatic benefits to building
this. It can deliver freedom from the "traps" of apps, online services and Big Tech, and
deliver unprecedented empowerment over the devices and data that we're actually supposed
to own ourselves.
In fact, dropping the apps in our radical operating system leads us down a path where we
discover the power of the link, which is central to re-structuring,
re-decentralising and re-activating our shared data...
No apps, just files
Let's go through with a thought experiment: imagine a PC or mobile without apps, what
would be left; how would you do anything? You'd still have all those widgets for clocks,
WiFi and battery status and so-on. You'd presumably still have access to all the other
system and machine settings and status.
But, more importantly, you've still got a filesystem full of files. Just no apps to
animate or activate them.
On a PC you'd have a desktop covered in files. On mobile you'd just have an empty
wallpaper where the apps should be, but that could easily be replaced by a file manager,
too, showing all your files instead. You could argue that a file manager or desktop is
itself an app, but files are fundamental to any operating system, and they always ship
with a file manager that's closely integrated.
So, what then? Well, you can actually do quite a lot around just the
Firstly, there are the preview options. You've seen how photos can be shown in a file
manager as small versions of themselves, and you may have seen that feature where if you
hover over a video file, it shows a small window playing it.
Do you really need a separate gallery app, if the file manager could be used instead?
You would probably use the file manager's time-ordering to view the photos in the order
they were taken.
Secondly, you can move, rename and delete files, and create folders to organise them.
Every app seems to have its own move, rename, delete, group and organise functions.
Without apps, you could have just one integrated, universal and frictionless way of
doing these functions for all file types.
You just need a way to create and edit these files in the first place!
Let's dig deeper and see how far we can take this, and see what the advantages of this
approach may be...
Creating and editing text and media
A common data or file type we want to create and then edit is text, along with images or
videos. This is what we do in notes and documents apps, as well as when we use the
Instead of having separate notes and document creation and editing apps with their own
ways of doing things, we could benefit from having a single uniform way of typing and
editing text. This would be similar to the file preview function: if you see a note or
document file, you can simply go in and edit it directly via the file manager without
waiting for the file's associated app to fire up.
If you're on a mobile device and want to take a picture, you can imagine your photos
folder or "gallery" having a big plus "+" button at the top to allow a new photo to be
added right there.
So, you go to your notes folder and see the time-ordered collection and quick preview of
each. You want to create a new note, so you hit this folder's big plus "+" button and
get typing. Now it needs the picture that you just took, that's over in the gallery
folder. As you expect, you simply also use the file manager to select the photo to drop in.
But what happened there? What does "drop in" mean? Does the note file now balloon in size
because it has a complete copy of the photo? In most apps that's exactly what happens,
because each app thinks it should control everything about the data or files it is
But we don't have apps any more, so don't need to waste this amount of disk space with
redundant copying. We could simply have a link in the note file to the photo file. To
see how this would work, we first need to explore the concept of the link...
Normally, when we say "link" we mean a web URL, pointing at a page on an online server.
But it can also point to a local file; in Windows you may say "shortcut". And it can
also point to a file on a local file share server.
You should be familiar with the concept of a file's path: it has both a file name and a
containing folder, so you may have a photo who's file path is something like these:
You may also be familiar with file shares, at work or at home: remote files
that look and behave just the same as local ones, on servers or even on another person's
PC. Now our links can point to files and folders on other devices, as network share
paths - links across machines like
You may also have noticed that the Web's URLs often work the same way as file paths, so
you could fetch a photo on the URL:
In all cases these "links" are just a short piece of text pointing to a file. This can be
used to refer to it and fetch it when needed.
Now, in fact, if you take off the file name, you're left with the containing folder name:
These are also a valid "links" - but now they are links to a folder, a sequence or
collection of files.
Using ids for links
But hold on: this is quite a limited approach! We can do better in our operating system.
Doing things this way means we are forced into a "tree" structure where you only have
a hierarchy of folder-folders-folders-files, branching deeper.
But what if we see a folder as itself simply a collection of links, to either more
folders or to files? Consider a folder with this link:
Containing two photos with these links:
Why don't we break these photos free of their single containing folder, by giving them
unique IDs instead:
C:\Photos\img-143143.jpg => unique-id-photo-143143
C:\Photos\img-629319.jpg => unique-id-photo-629319
So now their folder is just a collection of those IDs:
C:\Photos\ = (unique-id-photo-143143 unique-id-photo-629319)
This allows us to have another folder that also links to some of the same photos, or
C:\Photos-Barbados\ = (unique-id-photo-143143 unique-id-photo-002188)
We can go further, and assign a unique ID to folders as well as files:
C:\Photos\ => unique-id-c-photos-3323
C:\Photos-Barbados\ => unique-id-c-photos-barbados-6210
So now we have:
unique-id-c-photos-3323 = (unique-id-photo-143143 unique-id-photo-629319)
unique-id-c-photos-barbados-6210 = (unique-id-photo-143143 unique-id-photo-002188)
Now instead of tree-like filesystem structures, we could create arbitrary webs with
circular loops, where folders can end up linking around to themselves:
unique-id-c-photos-3323 = (unique-id-photo-143143
unique-id-c-photos-barbados-6210 = (unique-id-c-photos-3323
Which is much more powerful and freeing. Our gallery above that was a rigid collection of
photo files can now share photos with other galleries and we can have galleries that
link to and from each other arbitrarily.
In fact, the link is a fundamental, pervasive and powerful concept that emerges from the
elimination of apps. There are three pillars building the power into our links:
Structure, Sharing and Semantic, allowing us to respectively re-structure,
re-decentralise and re-activate our shared data.
So, back to the situation where we were editing a new note and needed to drop in the photo
we just took: we simply drop one of these links to that photo into our note. It grows in
size a little, but there's no redundant copy of the entire image. Another benefit is
that this can be done many times, in many notes and documents, at near zero cost.
Now, let's take this further: if we look inside the note, how is it structured? It's
basically a sequence of text paragraphs, then the link to the photo, then more paragraphs.
So, why shouldn't those paragraphs also be linked to, in the same way as the photo? That
way, you could share both photos and paragraphs between two notes or documents by
simply dropping their links in. You'd have a single paragraph text file in some folder,
and notes and documents that link to it. Now, if you change the paragraph, it
updates everywhere it's used!
In the old days of apps, where some apps so jealously guarded their data that their
files were in a closed, proprietary format, you wouldn't be able to even think of doing
this. But now we've thrown the apps out, we can start to dig in to their files and think
about how their structure can be re-structured to suit us.
Notes are also like galleries
So, thinking a bit further here, we have two ways of doing the same thing: we have
folders that are just sequences or collections of links, and we have notes or documents
which are also sequences of links to paragraph and photo files. Perhaps folders and
notes or documents can be made the same - in the same way that we re-purposed folders
for our photo gallery. Couldn't we simply use folders for documents too, and drop the
idea that a document is a "file"?
A note or document is then just a folder containing a sequence of links to paragraph and
photo files. Our operating system or file manager has to spot that a folder is set up
like that, and present it to us as a document or note instead of just a simple folder,
in the same way it gave special treatment to gallery folders.
Of course you can now drop another note folder link into a note, alongside the paragraphs
and photos, to nest them and have notes linking to and from each other. The operating
system can show a nested note in a way that it can be either expanded in-place, or
In fact, since we're freeing our minds here - why not just drop into your note the link
to a whole photo gallery? Again, the operating system rendering your note to the screen
would show it in reduced form in-place, and allow you to scroll it or jump into it.
So, without any apps, and indeed because we dumped apps, we have now built a personal
web of notes and documents made up of shared images and videos, all pointing to and from
each other in collections and sequences.
We've actually arrived at a model for data that's becoming popular in apps such as
etc. These allow you to wire notes and media into personal planning, thinking and
mind-mapping spaces. But we're making a whole operating system like that, not just a
So we have a personal web - why not just use the existing Web? The primary difference at
this point (there's more to come!) is that the stuff at the ends of our links isn't
complete web pages or documents, because we've deconstructed documents down to their
basic elements: paragraphs and media. Unlike the Web, we can embed not just images in
our pages, shared with other pages, but individual paragraphs or other text chunks, too.
But there's more. Once we start digging deeper into the files that used to be created
and used by apps and breaking them up into smaller chunks we can find all sorts of
nuggets we can use in our personal webs of data, simply by pointing at them with links,
and taking us even further away from the big-document Web into a web of data chunks.
Diversity of types
For example, a list of notes from a notes app could also be a list of to-dos, if there
were a dash before each item, or could be encoded into a special to-do format from that
same app. There are calendar events or addresses and phone numbers either casually
written into a note, or encoded into
vcf files. Every
photo has "metadata" giving information about the location the photo was taken and about
the camera that took it.
If each of these types of data were extracted into little chunks that we can link to,
then we can re-structure everything to suit ourselves. Why not have a calendar event
pointing at a single relevant to-do? When you check the to-do off in the to-do list,
it's also shown "done" in the calendar event.
Of course, a folder full of calendar events is rendered as a calendar, without needing
a separate calendar app. A folder of contacts is your "contacts app"! A folder of to-dos
could render with a count of jobs still left to do.
Without apps, we are free to play with this data in new ways, to combine it all in ways
that no app would previously allow, by simply dropping links between them and collections
of them. We can create a collection of and between one to-do, three notes, five photos
and two calendar events, and no app developer can stop us!
Data is no longer jealously guarded by individual apps and in inscrutable formats. All
our data is out in the open, in open standard formats that all devices running this
operating system can understand on sight. We've broken free of the "app trap" and can
use the power of links to organise our digital lives freely the way we like in our own
personal web of data.
So, we've thrown out apps and their control over local data. But what about apps that
work online, and their control over our remote, online data? What happens to us when
using an operating system without those apps when we follow the links, files and
collections model through?
You'll recall that we mentioned fileshare and URL links above, because files needn't
just be on our local machine - links can point directly at files and folders on other
devices on the network. A file or photo can be local or remote, it looks the same. Now,
without any special app, we get file sharing, including direct, peer-to-peer file sharing.
We can directly share notes, events, media, etc, between our PCs and mobiles and those
of our friends, as long as the links allow us. Thus we can extend our personal web to
link up with the personal webs of our friends and family and co-workers. Obviously, this
needs a permissions system.
Again, we are sailing close to the existing Web here. But there's another crucial
difference with this approach: we're not using any central servers, just using links
that point directly between our personal machines, peer-to-peer.
At this point, our operating system is actually our "browser", so that's another app we
no longer need. Our links are the unique IDs described above. We never actually need to
see what these IDs look like, in a way similar to the way current browsers are hiding
URLs. Others have thought about the merge of operating system, file manager and browser,
so this is not a radical concept.
Chat without apps
What about WhatsApp, Facebook and Twitter? (presumably if you're reading this you're not
young enough for that list to include Snapchat and TikTok ... oh, how this page will
age!!). We don't just use text and media for our personal organising, but also for text
messaging, email, WhatsApp, and so on. These apps exchange text and media with other
people. WhatsApp also lets you make live video calls using the camera, and we've got a
phone app, too, also using the microphone and camera. How can we implement all of this
messaging and video calling functionality without separate apps?
As for live video calling: what if our cameras had links, too? If you viewed any camera
via its link, your own or someone else's, you'd see what it sees. Taking a photo file is
now basically grabbing a copy of the camera "file" at a point in time. Making a video
file is saving a series of copies between a start and end point in time.
For messaging or chat, let's review what we do have: an operating system that doesn't
need any apps to allow us to directly create, view, edit and delete files of various
types like text, media, to-dos, events, etc; organise them in collections including
galleries, documents and calendars and manage them by their links and share everything
across machines, across the network.
So in fact, we already have the pieces in place to implement chat: a chat room or group
is a folder, containing text and media messages as files, in the same way that we made
our gallery and document examples. We just need to view the folder in time order, with
latest at the bottom. Both email and chat apps can work this way: a chat app has a
sequence of messages in time order; an email app has a sequence of emails in the
opposite time order. Why do everything multiple times over, for each app, when the
concepts are basically the same? In the same way as galleries and documents, this would
clearly require a slick user interface aware of the chat or email folder type, to allow
the viewing and new message creation to be as smooth as WhatsApp and email clients.
Of course, there's something else to add: how do we post a new message?
For galleries, folders, documents, to-do lists and calendars, we have a big plus "+"
button to add a new photo, file, paragraph, to-do or event. So it would work the same
here, except, who owns the folder representing the chat group or room?
The solution delivers one of the key freedoms and empowerments of this app- and
service-free approach using links: sovereignty over our own data.
The way it works is that you create a folder representing the new chat room, then share
its link with some friends, setting appropriate read permissions. You can obviously post
a welcome message there, too. Both of these, the room folder and the welcome message,
are hosted on your own PC or mobile, and the links to them that you shared allow your
friends to fetch them both directly over the network from you, peer-to-peer.
Now, one of your friends wants to reply, so hits the plus "+" button. She types in her
message. This message is hosted locally to, and will always be owned by, her. We
now just need to get a link to her message into the chat folder. The operating system
takes care of this for us by shipping her message directly to your device and to the
chat folder, which has some internal logic that fires off, allowing the folder to add
the link to the incoming message. We'll talk more about this internal logic in the
Data is no longer jealously guarded within separate service apps - the "walled gardens"
of Big Tech, in their remote and private databases. All our data is safe on our own
devices running this operating system sharing directly. We've broken free of the
"service trap" and can use the power of links across our devices to co-create webs of
data without fear of censorship or surveillance.
It's time we started to use a more appropriate terminology than "file", "data chunk" and
"folder". We've come so far from an actual filesystem at this point, especially now that
we've got documents actually being "folders", folders being collections of unique IDs
and file paths replaced by those IDs, that it's stretching these terms too far.
From now on, we'll refer to both files, or data chunks, and folders as "objects". A
folder is just an object with its own ID that's a list of IDs to other objects. All
objects link together into a single global web called "The Object Network".
Semantic ("Spreadsheet") Links
We've come a very long way with just the most simple of building materials: the link
and the collection of links, to files of data, or objects. But it's still not quite
enough. The final use of links is the one that gives objects more complex behaviours
than these, but still without them being encoded into inscrutable apps.
Earlier, we alluded to the behaviour of a to-do list, keeping a count of jobs still
un-done. We also just described a simple behaviour of a chat room folder object reacting
to an incoming message object from someone permitted to read and post there, adding a
link to that message at the end of its sequence of links to previous messages.
Where does all this behaviour get built and run, without apps? Also, what about the
"presence" of a person using a chat app? How do we implement that? We've also described
the camera "file" or camera object, that is always letting us see what it's pointing at,
which seems a little more "behaviourie" than a simple, usually static, file.
Also we've so far not got around to talking about how we'd implement other more complex
functionality in our app-free operating system, like a calculator app.
All our objects in this app-free world are going to have to be "internally animated". An
app normally wraps and traps our data, so any behaviour can only come from the app, and
any data we could have access to is inert until animated by its owning app.
But without apps, we need to turn everything inside-out: instead of seeing the app first
and the data being largely hidden by it, we see our data first and it's the behaviour
that is hidden. Our data, our objects, are internally animated.
Further, without apps to manage the dynamics of our digital lives, we going to have to
see stuff as soon as it changes! This is the third and final difference to the Web. On
the Web, and indeed when fetching files from a file server over the local network or
internet, you have to hit the refresh button to see if there have been any updates. In
this app-free operating system, that isn't good enough. If some object changes, those
changes have to be pushed out straight away to everyone that's watching.
Input and output objects
But who or what is watching? In a world of objects and no apps, everything ends
up being an object, including the operating system's connections to and from the real
In a similar way that the camera we described before is an object that is "live" and can
be viewed as it changes, there's another object we've not yet introduced you to: YOU!
Yes, your "presence" actually has to be another object itself. So, if I have the
link to your "you" object, I can watch you just like I could watch your camera. A person
object, if you had permission to watch it, would simply be an avatar-like thing.
So, of course, this is starting to look a lot like a 3D virtual world. Just like in a
virtual world, the person/avatar is able to go around changing stuff. So as you type a
new message in the chat group, that new message and all its edits - all its internal
animation - is being driven by you.
But the camera isn't something you're driving. In this operating system there's also
going to be a clock object, which just ticks away, setting the current time without you
going in to edit it.
Things like this are representing inputs. In the same way that the user, person or avatar
object represents the actions coming in to the virtual world from the user, a camera or
clock inputs the camera's real-world view and the real-world current time, respectively,
into the virtual world.
There are also outputs. The avatar-like person object representing you can itself watch
other objects, as they animate. The person object is viewing or present somewhere and
sees the changes of the part of the world it's watching. That's an output, from the
virtual world to the real world. Similarly, there is a vibration motor and an indicator
light on your mobile device that are outputs - there would be a corresponding motor and
light object in the operating system's virtual world driving them.
Like a spreadsheet
So, back to those other internal behaviours outlined above, like the to-do list counter
or the chat group new message function. A calculator exists to save you doing the work,
so its behaviour has to be programmed! When the clock's alarm goes off, or when a
calendar event is due, that object has to trigger some kind of notification. These aren't
driven by input or output, they have to have internal logic to drive their internal
We could just go back to the app-like way of doing things and let some techie write
these behaviours, and that's a genuine option that will be used for common behaviours.
But this operating system is all about empowering the person using it, not the far-away
techie! And the most common way non-techies do programming is the spreadsheet.
You may be familiar with how a spreadsheet has cells whose value can be programmed
with simple formulae to depend on the values of neighbouring cells. In this operating
system, we can do something very similar: we can say that an object's whole state depends
on the state of neighbouring objects. By "neighbouring", we mean "linked to", of course,
since that's how we do things here. So an object links to another object that it depends
on. When that object changes, this one does, too, according to some formula.
To go over all the examples:
The to-do list object links to each to-do it contains. But it can also depend on them so
that it counts up those to-dos still not in a done state, and sets its counter accordingly.
The chat group list also depends on the state of any messages that claim to or want to
be in the chat history, so will add the incoming message link as soon as it becomes
aware of that message's state, pushed to it by the peer operating system.
If you are viewing a calculator object, the operating system can let you create or input
an "expression" object that you want calculated. The operating system then notifies that
calculator of this object. Now the calculator object's state depends on that expression,
triggering its internal logic to in turn set its "result" to the answer, rendered back to
the user. If the user edits the expression, then, as in a spreadsheet, the calculator
object instantly updates its result.
Finally, an alarm object and a calendar event object are basically the same thing,
except the alarm needs a more persistent notification perhaps. These objects clearly
depend on the clock object so have a link to it, and watch it ticking away. Then when
their time is due, set their state to, well, "due", perhaps. Because the user, through
their "avatar" object, has been viewing them before, their object sees the "due" state
and alerts the actual, physical user on the other side of the input-output interface
that the time is up.
Of course, one great thing about our approach is the way that, unlike in spreadsheets
where everything is local to the current worksheet, we can set up dependencies across
machines anywhere on the Object Network, between distant and disparate parts of our
shared personal object webs.
The details of the programming language are for a more in-depth article than this one,
as a whole new revolutionary programming language for our whole new revolutionary
operating system is quite an undertaking!
Data is no longer jealously wrapped and animated like a puppet by apps written in
obscure programming languages. Like in a spreadsheet, it's out in the open and it's the
internally-animating formulae that are hiding in the back. We've broken free of the
"techie trap" and can use the power of links to set up inter-dependencies between data
in our web of objects.
Some loose ends
So, nearly at the end of this article, and there are some loose ends we should tie up in
thinking about how this operating-system-without-apps would be used.
Firstly, we've hinted above that we're pretty much creating a virtual world with this
approach, and so there's no reason not to experiment with 3D as the default user
interface to our radical operating system. This expands the "thinking space" concept
into quite a novel direction. You could at least imagine 2D panels in a 3D world
rendering many of the above object types as a starting point. Then implementing a game
without isolated game apps becomes interesting: do you have a space over here reserved
for that game? Can items from one game be taken into another?
The Network of Objects is a good match to the "Internet of Things", where each Thing is
of course an object. Imagine a light output object with a link to a switch input object,
and an internal behaviour that turns it on or off depending on the state of the switch.
What about media apps like Spotify, Netflix and YouTube? Like all apps, we don't have an
alternative for their offering unless they feel like joining us, one day. But if we want
to produce and publish our own music and videos, then of course we get to ship them out,
peer-to-peer, without the pervasive censorship and narrative alignment enforced by these
Big Tech offerings. It's a subject for another article to discuss people-centric
alternatives to "Intellectual Property", but clearly peer-to-peer networks are generally
able to be light on compliance there.
What about maps and navigation? Say you have a folder or collection object of objects
with GPS coordinates. Just like all other special folder types, the operating system
would render that in a special way: in this case as a map with pins on it for each
object in the collection. The map tile layer objects would have to be fetched from
somewhere, of course, for the area being shown. Now, if you had a "route" object with
start and end coordinates, this could be rendered as two pins on the map, then the
internal logic of the route object kicks in with the route details, and the operating
system renders the lines of that route.
In the old app-based approach, you'd have a separate map for every app that wanted one.
Now, we can throw a map together from objects from any source. We could have a collection
of objects including some photos, the current location of the family, and a pub you
were all meeting at. We could watch everyone converge in real time on the pub.
Similarly, we've freed calendars from apps: instead of a calendar locked away in each
app that needs it, we can throw objects with start and optionally end times into a
folder or collection object and view that. The operating system will show this object
as a calendar. So we can make new calendars any way we like for any purpose.
One thing we may throw into a random calendar is the weather: weather forecast objects
could be imported into the Object Network as input objects from an existing internet
Talking of importing, where-ever there's an internet protocol (or "API") available,
that data can be imported into or exported out of our Object Network. So, the web,
email, news feeds, chat systems, and so-on. Even without apps, we can still get the
week's weather and catch up on the news, while communicating with everyone in the
Land of Apps.
One of the top things folk do in the Land of Apps is search. The Object Network can
easily support people building indexes of "crawled" content just like a search
engine does, only now the things being crawled, scanned, indexed and returned to
search queries are objects, not web pages. Of course, since everything is a live object,
your search queries and search results lists are also objects, so you can save them or
watch their results change.
One objection that could be easily be made to this operating system is that it takes
over everything: takes away the owner's choice to install alternative apps that work
better for them. You can't just install another map, calendar, gallery, todo or notes
app that you prefer, or another camera, clock, calculator or phone, you seemingly just
get the render and interaction provided by the operating system.
There are two answers to that. Firstly, few people in reality actually replace the
supplied calendar, map, gallery, camera or phone apps, most use the default stock app
for 90% of their needs. Secondly, the operating system just provides a vanilla
interaction for known object types. But you can extend everything, because one of the
vanilla types is a general purpose user interface builder, by analogy to HTML forms.
Again, that's a topic for another article.
Starting with the radical premise of "an operating system without apps", we've gone on a
journey where we've discovered the power of the humble link to free us from the three
traps of Big Tech: the app trap, the service trap and the techie trap. We've seen how
the pervasive link can empower us to re-structure, re-decentralise and re-animate our
shared data and enable us to create a global data fabric - owned by everyone, and by
no-one. Such an operating system can restore true ownership of our devices and our
precious data right back to us.
These concepts are being explored in the OnexOS operating system. OnexOS is a
proof-of-concept of this revolutionary way of rebuilding the tech stack from the ground
or from the "metal" up. OnexOS runs on every kind of computer from
and home automation devices up
to internet servers, via our mobiles, tablets, PCs, TVs and games consoles. The initial
primary target is the Raspberry Pi 4 and CM4, as these are very popular, well supported
and flexible devices that can behave like, well, tablets, PCs, TV boxes, gaming machines
and internet servers...
This reimagining of our internet experience created by OnexOS is called The Object
To read on, go
for an expanded view of this approach with examples,
to read about the smartwatch version.
There's also a list
of many more, broader and deeper, articles and presentations about the Object Network.
OnexOS is still under
development. If you want to get involved as an early adopter and tester, get in touch!
Duncan Cragg, 2023. Contact me