An operating system, or OS, is a program that runs programs. An operating system traditionally runs "on the metal" without being hosted by another layer of software, but virtual operating systems and avant-garde projects such as Urbit challenge this standard.
In lay terms, an operating system is the thing on your computer. This clueless definition is workable: the hardware does who-knows-what, and the OS does whatever it takes to show you a cat video. An OS puts your computer in a dark box so programs can run on it.
This is probably more than you need to know, but what a modern personal computer does is this:
On startup, the CPU receives a BIOS program from the ROM chip, then locates a storage device and master boot record to load a program from. This program, the bootloader, loads the OS into memory and launches it with full CPU privileges. The OS uses a laborious checklist to establish communication between the CPU and other hardware devices.
At last the OS can run something the user can interact with: a graphical shell, usually presenting a login screen. Itself a separate program, the shell needs to run in tandem with the OS. When the user presses a key or moves the mouse, a hardware signal causes the CPU to stop running the shell and start running OS code to properly translate and direct the user input. The OS switches back to the shell with information about the user input, and the shell proceeds accordingly, switching back to the OS whenever it needs to change pixels on the screen. The task of a graphical shell is to launch user applications which will switch back and forth with the OS in a similar way.
Besides managing input and output, a typical operating sytem also simulates a memory bank for each program (virtual memory) and runs them sequentially in short bursts (time slicing). It also facilitates communication with other devices such as a hard drive or graphics card, giving developers a convenient and reliable interface to write their applications for.
It sounds like a lot, doesn't it? An OS is the thing that deals with this mess so you don't have to.
A program is a specification for transforming data. A computer is a machine that transforms data. An OS is a program for the computer that transforms a program for the OS into a program for the computer. In Urbit as of 2024, the program is a Gall agent or thread, the operating system is Arvo, and the computer is the full combination of your machine, your host OS, and your runtime.
The 2016 whitepaper says in section 3.5, "A practical SSI [solid-state interpreter], though in a philosophical sense an OS, actually runs as a Unix process. (At some point a move down to the hypervisor might be advisable.)" The best time to make this change was eight years ago. The second best time is now.
The sole purpose of an OS is to convey data between programs and devices. There should be as few steps as possible. In the current state of things, Vere translates Nock into bytecode and runs that in a Unix process, storing nouns in virtual memory and snapshotting said memory to disk through the abstract file system. Messages pass only through Unix sockets and communicating with hardware devices requires a sidecar.
This is obviously too many layers for a proper OS running intensive applications. We should like for applications to make full use of the hardware. Bottlenecks must be eliminated, and every single component is a potential bottleneck. Arvo is such a bottleneck. Linux is also such a bottleneck. Urbit should run directly on the hardware, with maximum privileges, contiguous nouns, no protected memory, and as few layers as possible between a noun product and its effect. When a video game on your Urbit laptop uploads a texture to the GPU, that atom should be available to the memory bus as-is.
From your stereo to your thermostat, any thing in an internet of things should be running Urbit. Or at least, our job is to make that statement become true. Axiomatically, Urbit shall be a good fit for embedded systems. It must have a tiny footprint and miniscule overhead, and it must be capable of communicating nouns.
An embedded Urbit system can constrain its input to any format and simply ignore other inputs. From the outside, this is identical to a crash. By the same principle, this system need not fully implement Nock; any interpreter has the option of crashing on any formula at any time. Therefore, as long as an embedded system can receive and transmit at least some kind of noun, it can ignore the general case and run strictly native code, or an FPGA, or whatever it wants in order to interact with its cluster over Urbit.
This is already possible on Urbit, since Urbit is a protocol, not a program. But in order for Urbit to gain enough market share to attract meaningful development, the default way of doing things should be suitable for doing the things people want to do on their computers. It's a little more than sending DMs in a web browser.