Why Nostr? What is Njump?
2024-02-16 18:12:25

How to Build a Small Operating system in Texas

This is a long form article, you can read it in https://habla.news/a/naddr1qqghxmtpd3kz6mmn945kutt5v4uxzuczyqxkequgmjcynwxaflyd8kxrhwfau0dfpw5z3e8snj9dpu6xfz9rxqcyqqq823cghcykk

One of my favorite essays of all time is WrathOfGnon's "How to Build a Small Town in Texas."

He takes something that sounds so foreign, complicated, and unbounded, and breaks it down into a process that sounds so straightforward and obvious that it's almost astonishing that it doesn't happen all the time!

I want there to exist a new operating system for mobile devices. I have very many "wishes" for this theoretical OS, and very few powers to grant those wishes. After hearing my thoughts on this subject you will in no way believe this is straightforward, obvious, or be surprised there is no such OS being built.

And yet, I wish such an essay would exist, so this is my weak first attempt at such a thing.

The tl;dr: we should build a "human scale" operating system. Less code, fewer bugs, more human agency, more human sympathy. That's how we win.

1. Size and borders: “You can’t have a garden without fences.”

This ideal OS needs sufficient hardware support, sufficient application support, done with minimal code.

What's the least amount of code required to run applications on a "modern" phone (5G, high-res touch display, GPU)? That's the operating system.

As a point of motivation, QNX fit a whole OS including a web browser on a floppy disk (1.44MB).

QNX

MenuetOS / KolibriOS is another more modern example of an OS that fits on a floppy.

Kolibri

2. Water, energy, food and connections: the needs hierarchy of towns.

An operating system needs to provide reliable, safe, and permissioned access to underlying hardware capabilities such as storage, memory, CPU, GPU, graphics, sound, and touch input.

Simultaneously, it needs to expose this access in a way that simplifies the work of the application developer, or at the very least does not complicate it.

problem

Casey Muratori in his "The Thirty Million Line Problem" video essay blames most of the complexity explosion of modern operating systems on the lack of standardization and over-reliance on software drivers in aspects of the system outside the well-defined CPU ISA (Instruction Set Architecture). He argues a well-defined ISA for using network and graphics hardware could simplify the OS back down to Linux's original 20k lines.

In the 80s and early 90s many "apps" shipped with their own operating systems because it provided the best performance and because the underlying system was simple enough to make this possible.

The great irony is that modern OS abstractions actually are often a source of additional complexity for the application dev, rather than simplification. The exact same GPU, when passed through an OS, can be exposed to the developer as DirectX 12, Vulkan, or Metal.

This unnecessary complexity and layering cries out for a protocol.

Casey points out that experiments in removing layers has shown dramatic performance improvements.

zoom go fast

I believe these performance improvements could perhaps make up for the lack of expensive, megacorp-driven optimizations, and bleeding-edge TSMC chips, that the complex operating systems currently enjoy.

3. Materials and harmony.

One of the greatest failings of "Linux on the desktop" is that there are so many flavors of everything, there's no cohesive, single vision that can give users a common UX across apps or distros. Freedom to choose results in many choices.

radix

That said, the modern web seems to have some trend toward a sort of cohesion and shared UI language. And many native apps are built with web views or non-"native" toolkits anyways. So it's not worth stressing too much about this.

I do believe, like React for the web, highly popular UI frameworks and toolkits will emerge (and have emerged) for popular efficient languages like Rust, Zig, C, and C++ that will allow developers to make apps out of common components so the wheel is not constantly reinvented.

4. The problem of undeveloped and vacant lots.

No matter how good a new operating system is, it's nothing without apps. This was the death of Windows Phone, which in my opinion limited the expressivity of app developers to its detriment. This was also the death of Palm's WebOS, which likely bet on web technologies too early.

webos

The modern web is easily powerful enough to serve as a stop-gap for many apps. But for the next operating system to be better than its overly complex predecessors it will require amazing native apps that aren't available on existing systems.

These better apps can potentially arise out of the operating system's simpler, more minimal abstractions. App developers will (hopefully) be attracted to a system where they can express their intent more directly, rather than fighting against the grain of highly opinionated frameworks like SwiftUI, JetPack Compose, and GTK.

5. Who will live there?

A new operating system needs users. Early on, this new operating system will be lacking in many features and many killer apps. Who would choose such suffering?

I can think of three primary candidates: 1. Cypherpunks. If you run GrapheneOS you experience a small subset of this suffering. If a new operating system offers one or two novel applications, you might be willing to adopt additional suffering to further live out your cypherpunk vision. 2. Developers. An operating system simple enough to "hack" on would be very exciting to a certain kind of developer. Think of the guy with a great Vim config or Emacs environment that he lovingly curates and codes for. 3. People who hate change. Ironically, modern devices, by economic necessity, continue to underserve a huge portion of the population that views a mobile device as a pragmatic tool and loathes the annual (often forced) churn to their user experience. A minimal OS can fight the sort of bitrot that makes unchange so hard for modern software. If it works, it can keep on working.

6. Build to the edge of the lot

With a much smaller set of built-in OS SDKs, app developers will need to discover new protocols and methods for inter-app communication and harmony. This will be challenging and is not guaranteed to succeed. But the dream is for non-dev users to finally have access to abstractions as powerful as Unix pipes for their normie workflows.

7. Alright, I'm done copying headers from the town-in-Texas piece

If you're curious and want some imagination fuel, the remaining headers are:

  1. Personality, neighborhoods, and character.
  2. The Story, the founding Myth.
  3. Build the least valuable lots first.
  4. Public space.
  5. A grand entrance.
  6. How to live without cars.
  7. To grid or not to grid.

8. The goals

Okay, so in summary here are some of the goals I believe a "next OS" should try to achieve, with some hints at methodology:

  • Freedom to use, freedom to change (through minimalism)
  • Performance (through minimalism, layer collapse)
  • Fight bitrot / change (through minimalism)
  • Good UX (hard. unlikely to emerge without good monetization)
  • All the apps (probably web tech / PWA / "enhanced" PWAs at the outset)

9. The hard parts

Naturally, this is a very challenging project. Possibly the hardest part will be Casey's proposal for a broader SoC ISA, which might turn out to be a required foundation for the whole system.

The other hard part is a browser, which would be necessary to get all these "free" web apps.

serenity os

It's likely that WebKit can be ported to a sufficiently advanced system, but I don't know how much underlying complexity that "bakes in" to the OS at the outset. Serenity OS, a "hobby" OS for the desktop that's gotten to a truly impressive state, has its own browser Ladybird that covers a surprising amount of web technologies, but is still far from rivaling Chrome, Firefox, or WebKit.

10. The good news

On a positive note, there are a ton of really cool projects that provide reasons to hope that a new mobile operating system is possible in our lifetime. Some of them might even be the building blocks that get us there. Others might serve as testing ground for these ideas before we can get the OS to bring them all together.

  • [x] A good money (Bitcoin)
  • [x] Decentralized protocols protocol (Nostr)
  • [x] Modern low-level languages (Rust, Zig)
  • [x] Binary portability / sandboxing (WASM)
  • [x] Portable modern graphics standard (WebGPU)
  • [x] Far-along complex desktop OS projects (Redox OS, Serenity OS)
  • [x] Cross-platform "native" GUI libraries (Iced, Egui, Dear Imgui)
  • [x] Cross-platform "web + native" frameworks (Tauri, Electron, Capacitor)
  • [x] Cross-platform windowing (Winit, SDL)
  • [x] Linux-based phones (Pinephone, Purism)
  • [x] Open source ISA (RISC-V)
  • [x] "Reinvent everything" communication device (Precursor / Betrusted / Xous OS)

11. One final optimism

Here's an FPGA running Quake 1. What's bonkers is that this guy define his own ISA (MRISC32), designed a soft CPU to run that ISA on an FPGA, modified a C compiler to target his ISA, and compiled Quake 1 with that compiler (running at 30fps).

quake on mrisc32

This is an obvious case of genius, but it's also inspirational to me that we have this many high-leverage tools at our disposal that a work of lone genius like this is even possible.

We shouldn't limit our dreams to match only the methods that have been employed in the past. The methods of the past got us iPhones and Linux on the desktop. Billions of man hours got us our current tech stack. We, by definition, have no way of knowing how much work is necessary to build our next tech stack. That will be a process of discovery.

Author Public Key
npub1p4kg8zxukpym3h20erfa3samj00rm2gt4q5wfuyu3tg0x3jg3gesvncxf8