It’s been a while since I wrote about the brand new updates on Supernova, a complex web OS I have been working on for almost four years now (since 2021!). Supernova is a next-generation web OS designed for speed, flexibility, and innovation, pushing the boundaries of what a browser-based operating system can achieve.

In my last progress report, I explained that the biggest milestone achieved in the prior few months had been process sandboxing. This continues to be Supernova’s biggest feature, and I have since improved it greatly, specifically through the use of two main process-parent communication styles. Request-response based events (referred to as calls), as well as streamed events are now both available within Supernova.

communication

Both communication types are similar to certain network communication types. Calls are similar to the HTTP protocol. Similarly to the network protocol, calls require responses from the opposite side (the recipient, the medium that did not initiate the call). Unlike HTTP, however, where requests can only be started by the client, on Supernova, calls can be started from either side, both the parent process (typically the kernel) and the program.

Streamed events were added in October, and consist of WebSocket-like events. Similarly to WebSockets, streamed events are bi-directional duplex events. This means that either medium can send a streamed event, and that this medium does not necessarily expect a response from the recipient.

I have also updated Satellite to be compatible with these two messaging types. The documentation has been updated accordingly.

process manager

Additionally, after the addition of the 41worker code runtime, I found the need to add a process manager. The Supernova kernel initiates the process manager, which is essentially a higher-level wrapper of the code runtime.

The process manager can spawn processes, terminate processes, send messages to processes, all thanks to the process runtime, and it can also get a list of the running processes, the number of active processes, the number of terminated processes, and more.

build system

A lot of work has gone into making sure the build system is fast, but a lot more work needs to be done. As more system executables are created, I’m finding the build times get longer and longer. Full Supernova builds are taking ~15 seconds, which is a lot, especially when watch mode is on and the application is rebuilding on every file save. What makes the current build system inefficient is the filesystem builds. While I am mostly working on the kernel, every file save triggers a full rebuild, which then triggers each individual system executable to also be re-built. This is starting to slow down the build process, because there are >13 system executables now. More on this later.

faster filesystem

The Supernova installer filesystem is now entirely RAM-based. All files are cleared on reboot. With a RAM-based installer, system setups are incredibly fast and efficient, making testing and development smoother than ever. Obviously the plan for the complete OS is to have a persistent filesystem in place, using the IndexedDB API. Anyways, let me talk a bit about some of the other improvements happening in the future.

back to the future?

The future holds greatness! Here’s a few of the things on the roadmap for Supernova.

build overhaul

As mentioned before, I’m planning a complete overhaul of parts of the build system. I also plan on adding two separate watch modes, one for system executables and one for the kernel.

assembly runtime

Assembly Runtime, or AsmRuntime, will be a secondary runtime for programs that need to run in the main thread. Programs running within AsmRuntime will continue to be isolated mainly through the use of WebAssembly, which acts like a sandbox. By default, all programs will run under 41worker except for specific system executables that need to run under AsmRuntime. This does mean that a variety of executables will now be compiled, and not just plain readable JavaScript. The plan is to write these executables using AssemblyScript, and later on write a Go SDK, and possibly a Rust SDK. Currently this is be number one item on the agenda, and is being actively worked on. I have already refactored the majority of 41worker to not have to copy a ton of code for AsmRuntime, since the actual interfaces for both will be very similar.

display server

One of the aforementioned executables will be the Display Server. The display server will be in charge of handling all connections to the GUI, and will also be responsible to drawing to the screen. For the display server to have access to certain lower-level APIs, such as the DOM and the HTML Canvas APIs, it will need to run under AsmRuntime.

shell

After the Display Server is in place, a very rudimentary shell will be developed using xterm.js. This will be the interface the user interacts with until a proper GUI is implemented. As with all xterm.js applications, it will be a command-line oriented interface, capable of spawning processes, terminating them, and performing multiple complex operations at once. A scripting language is also planned, most likely based on CoffeeScript.

in conclusion

I’m hopeful and optimistic of a future with Supernova. Your feedback and ideas could shape Supernova’s journey—so don’t hesitate to reach out or get involved. Keep yourself update by subscribing to the mailing list. As always, contact me if you have any questions.