Technology Strategy
I tend to struggle with selecting the right work at the right time. When I want to work on one thing, I see the flaws in a lower-level dependency and feel the need to fix those first. Sometimes this isn’t necessary, but many times this will result in a more pleasant higher-level implementation. Because of this, I need to properly plan my work so that I finally stop bouncing between different projects and levels of abstraction. Some concessions will need to be made, but for the most part this plan orders things from lowest to highest level of abstraction.
Aux Tidepool
Tidepool needs to be the first project completed. It is a from-scratch Nix package set with no other expectations than Nix itself being available. Because of this, the Nix implementation can be replaced later if desired and all future work can be built on top of secure, easily-configured packages.
Nilla
Once Tidepool is functioning completely as a modern package set, we will need a way to handle Nix projects that incorporate the module set. This will be done with Nilla. As such, Nilla needs to grow into a more comfortable, usable solution than its current form. It should replace Flakes entirely, without requiring any opt-in Nix features. Note that this version of Nilla’s CLIs will still be written in Rust. The CLI can be replaced later with another implementation.
Aux OS
Now that Nilla has been completed and multiple kinds of Nix integrations can exist together in a project, we can begin work on Aux OS. This is a Linux-based operating system, functioning very similarly to NixOS. The point is to finally have a full replacement for the Nixpkgs ecosystem – package set, operating system, library. When this project is complete, all future work can be done on Aux OS itself rather than still needing NixOS as a workstation.
Juice
With a workable operating system not based on a problematic community, now we can get to the rest of the projects. The first is Juice, a programming language that offers comparable performance to C, an improved memory model over Rust, and significantly less syntax than alternatives. Juice will take a while, but it will be worth it. The only focus right now should be native CPU targets. Specifically x86_64 as the first platform officially supported. The language should be careful to not tie itself to a specific platform or operating system.
Leyline
With a modern programming language capable of direct machine control as well as higher level abstractions, now we can move on to the OS. Leyline is a novel take on operating system design, going several steps beyond what typical microkernels do and instead utilizing the kernel for only scheduling and single-time resource mappings. All other support is implemented in user space and granted ownership of required hardware, capabilities, and memory by the kernel once rather than requiring constant roundtrips.
Thicket
With an operating system functioning, work can begin on a proper solution for multi-machine computing. Thicket is a resilient mesh network capable of dynamic connection capabilities, toggling between direct p2p connection and multi-hop obfuscation for privacy. Being the primary solution for connectivity on Leyline means that typical networked services become decentralized, but also that any application on the machine can easily take advantaged of a full p2p network without any extra work.
This post was initially intended to be a note in my notes app, but in the effort of trying to write more publicly I have decided to share it here. Hopefully you find some of these ideas interesting or give you something to think about.