Principles & Methodologies

The Philosophy of AvalonOS

On Wednesday, I spoke about a few of the features and implementation deatils of AvalonUI.

While AvalonUI itself—that is, the visual manifestation of the "Avalon Philosophy"—is an important aspect to the project as a whole, it is, at the end of the day, just a component.

In other words, the so-called "characteristics" of AvalonUI aren't specific or linked in any way to the particular way I implemented it. Color, depth, adaptability and so on are all general, and many different UIs could fit the bill.

Because of this, I wanted to get the actual UI out of the way first, at least in part. Changes happen, people's preferences mutate over time—I am no stranger to indecisiveness. Therefore, it stands to reason that, as "adaptability" suggests, the UI should adapt to the needs of the user. This can include tiny changes, like modifying the background color of the dynamic panel, to much larger ones, like the redesign of all system components.

Therefore, the most important thing is what the UI ultimately accomplishes.

Another thing to mention is that many users (myself included) want to customize the UI to their preference. The UI, therefore, being adaptable and encountering potentially unpredictable scenarios, plays an important role only in generalization, not in specificity.

It stands to reason, then, that the ideal aim of the UI should be to implement the underlying philosophy that Avalon subscribes to, however that implementation may turn out to be. In other words, as long as it fulfills the necessary requirements, it can be constituted as being "Avalon-like."

Implementation of the UI

Now, one of the important things about AvalonUI is that it is designed specifically—though not by means of exclusion—for AvalonOS.

And, since AvalonUI inherits the principles of the Avalon Philosophy, AvalonOS does as well. Indeed, it is entirely the OS that I want to focus on with the philosophy. The tiny UI-focused implementation details like the floating backgrounds are, at the end of the day, subject to preference. I definitely love them, but you may not. In this case, it doesn't matter too much because the UI just needs to, like I mentioned before, fulfil the requirements of the underlying philosophy.

Therefore, as I go on to discuss this mysterious "Avalon Philosophy," note that it applies specifically to AvalonOS, from which the UI inherits its properties.

Without further ado, let's proceed.

Application of the Philosophy

There is an imperative distinction that needs to be made between the behavior the Philosophy describes and the default assumptions it makes.

For instance, AvalonOS assumes that "files" and "folders" are a very common way of dealing with data stored on disk, and therefore, they are present in the OS.

This is one of the first principles of the Avalon Philosophy (although, note that there is no sanity to the ordering): Be radical, but not unacceptably so.

Modern infrastructure and software play an undeniably critical role in the way we work. While fundamental changes are, in my opinion, acceptable and indeed should be researched, in general, the best practice lies in remaining as familiar as you can.

This is in contrast to projects like MercuryOS where the entire OS has been redesigned from the ground-up. MercuryOS was a partial inspiration for this project, but I've remained on the less radical side of the "new OS design spectrum."

In summary, the philosophy applies both to the behavior of the interface and the underlying structure of the operating system in general.


I'll go ahead and get the cliché item out of the way.

Simplicity is a widely over-used and over-misunderstood topic that I'm hesitant to speak on for that reason. Regardless, it is crucial to Avalon.

Lots of modern operating systems display contextually useless information at all times. For instance, I personally dislike—to a moderate degree—the MacOS menu bar icons. My VPN is blasting a constant green "CONNECTED" (at least, it feels this way) symbol.

From my perspective, I don't really need to know if it's working—I only need to know if something goes wrong.

And, of course, by extension, if I am not alerted of an issue, I shall implicitly assume it is working as expected. [1]

So, simplicity is a key factor. Many would argue that my disgust of the MacOS menu bar is partly a result of the whims of developers. To a certain degree, this is true. My VPN application chose to add that feature, and therefore it is there.

It is essentiall, therefore, that any OS which intends to be "radical" to any substantial degree should enact or enforce a certain level of restriction in regard to the underlying applications. Not to mention even more critical topics such as security (application sandboxing comes to mind), the OS ultimately controls the interface—and therefore it should decide what is shown when.

I intend for AvalonOS to be more applicable than, say, MercuryOS. In the latter, with the more radical changes to, for instance, the eradication of the file/folder structure, it would require a lot of work on behalf of application developers.

Therefore, it is imperative that the OS is intelligent about the opinions it enacts. If an app is requesting permission to display information to the user, it should be deemed as relevant by the OS.

It is much easier said than implemented, of course.

Now, the magnitude of the above implementation is largely decided by the underlying infrastructure of the OS and how it handles applications.

This brings me to an important topic.

Application management

This is undeniably a touchy subject when it comes to OS redesigns.

In many cases, you can't avoid, at least in theory, the requirement for application developers to modify their application to fit with your new design. Ideally, the software developer can simply ship a tarball of their code and the package manager will handle the installation.

This is a fantasy in modern software distribution—at least as far as I'm aware.

When you make a Linux application, for instance, you don't just make one "Linux Application" (in most cases). You make one for Fedora, one for Ubuntu, and so on.

There are a variety of new-ish projects that attempt to improve this, but not all of them are ideal.

Regardless, this ideally shouldn't be a problem at all. While I certainly don't intend to innovate the entire software distribution practices in all modern operating systems, I can at least control how AvalonOS works with applications.

One thing I think may be overlooked is the safety of first-party OS applications. In general, I'd say we can all trust the stock Settings app to not go against your best interests. That's not to say that first-party applications are entirely safe, of course. The vulnerabilities are introduced the second that an app allows your machine to talk with other machines.

Still, the idea that applications can be processed on-device (sandboxed, of course) without installation is very valuable for software distribution.

Indeed, this is precisely how the web works. Web developers can choose the way they want to distribute their software. But at the end of the day, it all ends up as some IP address with port listeners serving HTML, CSS, JavaScript, and more.

I think this is a powerful concept, and I believe it can be applied to operating systems to some degree.


Now, I have avoided touching on the distribution of "AvalonOS." That was quoted this time because my vision for Avalon doesn't really make it an "OS."

I've been using "OS" only because it is a familiar term which is very closely related to how most people will interpret Avalon.

Now, allow me to clarify that Avalon is still very experimental. It will likely change a lot as time goes on, but for right now, this is the general plan.

It is primarily a web-based OS, but slightly more integrated than just

I think Linus Torvalds had it right when he spoke of how adoption of Linux at large scale would only happen if installation wasn't required.

He also spoke of ChromeOS and its primarily browser-focused approach.

Now... you may be questioning how good a browser-based OS could really be. After all, it's sandboxed within sandboxed on top of an already demanding OS. Can Avalon really replace modern operating systems?

Well, I think, in some-to-many cases, it actually could.

Let's imagine the life of a hypothetical property manager. Day-to-day responsibilities include being on stand-by if a guest requires assistance, ensuring the properties remain stocked with supplies, ensuring properties are cleaned and ready on-time, and so on.

In the modern era, one would reasonably expect this person to utilize technologies such as phone calls, SMS, spreadsheets, email, web browsers, and so on.

The thing is, every one of those can and has been made available on the web—generally, with similar to identical performance.

Google Sheets, for instance, has seen wide use in corporate environments—and that's an understatement.

Indeed, over time, I've observed many companies and individuals shift to an increasingly web-only workflow. Many apps are just easier to access on the web (on desktop, at least).

Now, it's not necessarily the web itself that has this characteristic. Instead, it is just its modular nature.

Now, if we just assume that AvalonOS would just be another OS on top of your current one that also allows web browsing... there's very little point to that. For that reason, I think there's another key to its efficacy.


One of the unique things about web technology is that it is modular and integrated at the same time. How many sites out of the ones you've seen offer the ability to create an account with many different social media providers? 80%? 90%?

This is a small example, but if we enlarge it, we come to see how AvalonOS might actually be useful.

In the way that a website can accept and work with the authentication mechanisms of many different providers (usually via some standard), AvalonOS could hypothetically integrate with any other system.

Of course, this isn't exclusive to web technology. Nevertheless, what if you could have your desktop OS integrate seamlessly with your phone, regardless of what OS your phone uses?

Better still, what if your OS wasn't linked to any particular device?

What if your hard disk crashes and your work is lost? How often do you back it up?

If your OS was linked elsewhere, you could spin up and access your data from, hypothetically, anywhere.

Naturally, this highlights the concern of security. After all, do you really want all your data on some server?

Well, I'd argue that there are definitely secure ways to do this. Primarily, OS-level encryption on the server will be enabled by default. The second before data leaves the browser, it's rendered useless by means of encryption.

In addition to this, we could also introduce physical security keys which are less likely to be destroyed. Moreover, many of the same keys could be manufactured at a time, leaving the possibility for spare keys to be stored elsewhere.

This technology of web-based operating systems isn't completely new. I've observed a few enterprises make use of this technology in rare cases. Although, they are usually highly limited by their corporate environment and they must still be downloaded on-device.

Instead, I am proposing something so simple that I could walk into the lobby of my hotel, stick my physical key or passowrd into Avalon, and get right back to precisely what I was doing before I left my hotel room only minutes prior.


Much in the same way that the UI should adapt to its environment, certain underlying features of the OS should adapt to the whims of the user.

For instance, if the user would prefer all data to be kept local only, by strict restriction from the OS, then that is how it should work.

This brings up another point, in particular about the construction of such a system: Avalon should largely be a series of the Middleman pattern. Instead of working directly with cloud files, for instance, it should always create a local store to which a separate entity (read "microservice") will handle the submission of that data to a third-party.

Many systems already work in this way, but Avalon would make copious use of the pattern to enable highly precise integration with existing systems.

So far, I've only mentioned AvalonOS in the context of being a desktop OS. Avalon is not exclusive to a PC, however. In fact, I envision Avalon to be fully compatible out-of-the-box with any device. There's no sense of "sharing" things between your own devices—they simply are the same thing, and Avalon would recognize that they are separate, albeit identical (as much as possible), instances.

Having the same underlying OS for desktop and mobile purposes unlocks an incredible amount of untapped potential for sharing, collaboration, and so on.


When I think of futuristic technology, I think of highly integrated technology—I think of being able to walk into a conference room with nothing but a USB around your neck and being able to share that presentation you've been working on—in precisely the way you intended it to be seen.

In addition, I think of those split-seconds where your screen cracks or you drop your device; the ensuing stress about the data you've lost and all the recovery you'll need to do to get back to working order can be overwhelming.

Not to mention the cost of the device itself, the data within it is often priceless, just due to its unique (and, unfortunately, in many cases, singular) nature.


Again, one important aspect of Avalon is that it can integrate nicely with existing technologies. In practice, this would mean that switching between Avalon and more traditional operating systems wouldn't involve, for instance, reformatting your data from APFS to LUKS.

This means that both the complete adoption of Avalon as well as the integration with your existing OS would generally be seamless. In this way, Avalon is not lock-in, not downloadable (in the layman sense of the word), not restrictive.


Back when my hardware was nice to me (or when Linux distros contained code that my hardware liked), I made excellent use of Linux.

Not unlike many of my colleagues, I was inclined to the notorious distro-hopping—the practice of switching the operating system you use at a frequent pace in an effort to learn and/or qualify/disqualify any particular distribution from becoming your daily driver.

At my "peak" (of stupidity, it often seems) I was changing distros every day.

As I work in design, I have particular tastes in interfaces. I often wanted to change it up and get a feel for some new ways of doing things.

This brings me to something very important: AvalonOS is actually a low-level abstraction of a real OS. It itself does not contain any UI whatsoever. This means that the UI can, in theory, literally be downloaded on-demand from anywhere.

Of course, in practice, this would not be ideal in almost any scenario, but it highlights the capability that "distro-hopping" is no longer a thing; just swap out the UI for something completely different and continue your work.

This is in complete constrast to something like the custom themes of GNOME. When you download a theme from, you're downloading a hack, so to speak.

In reality, you're downloading a set of files that reset or alter the design of GNOME itself. Although, this is largely limited.

If you want one theme for your menu bar (the top one), the dock, the windows, and the icons, you've got to download, at minimum, 2 different theme packages as well as manually set the theme for each of those components...

Umm... what?

Exactly. It's a pain in the ass to get even a little bit of customization. Not to mention, most of the themes are complete shit and made with sub-par code.

What if, when you're in the mood for a little refreshment, you open a snappy window with a curated selection of complete UI redesigns—all of which are completely integrated and not a refactor, readjustment, or reset of any existing styles. They instead exist as entire UI modules themselves—able to be switched out at whim with no distruption to your underlying data or apps.

When I talk about "the UI" here I mean literally the entire interface that sits atop AvalonOS, I'm not talking just about the design of Menus and Inputs.

To go into more detail, one could imagine that one UI module would contain a full i3-like window manager, or another containing a mix like the one we see in COSMIC.

Closing remarks

I could go on, really. There is a lot to say about the highly modular nature of Avalon and how it can work closely with the workflows we already have today.

There are also a lot of areas to explore, particularly in implementation, performance, efficacy, and more.

This was only part 2 of a still multi-part series. There is more to come.

Next up, we'll visit specific UI implementations of the principles outlined here. More specifically, we'll be taking a closer look at what AvalonOS looks like, how it works, and more on the trajectory of the project as a whole.

If you've made it this far, then {props} to you.

Thanks for reading.


  • [1]: Of course, this also assumes that I've set up my OS to establish a VPN connection automatically.

Copyright © 2022


Made with

in SLC