Please see the disclaimer.
These are listed in the order I plan to do them (right now).
I have already written an explanation of Yao’s name.
As part of Yao, I am going to build Rig, a new build system.
This is necessary because I want Yao’s bootstrap process to be dead simple, not like Rust’s, for example.
In addition, I want a build system that works with Yao to give it metaprogramming without ugly things like macros.
While I have not laid out very well how I plan to do that with Rig, I plan to soon. In the meantime, you can read the requirements list for Rig.
I named it Rig because it is short (less typing), memorable, and somewhat related to building, which is what a build system is about, of course.
There is also a name for software using Rig: kits. Like Rust’s Cargo, which has “crates,” Rig will have “kits.”
In addition, I may add a way to the build system for Rig to be invoked as
because the build system is invoked often.
That will not interfere with the R programming language because R uses a capital R. It may still interfere on Windows, however.
Yada is a next generation version control system, first mentioned here.
Yada is only its working name; I want it to be invoked with a plain
y, so I
might just call it the Y VCS.
Why Yada? This one is more nebulous; I was trying to think of words that began with Y and also had to do with version control, even indirectly. So far, the only one I’ve come up with is yada, as in “yada yada…”.
The reason I like it is because a version control system should be boring for users, in a way that git is not.
Next up, and last, is my idea for an operating system: KoOS.
Besides what I already linked, I want this OS to be about smoothing over the portability problem with other OS’s.
I will do this in several ways.
First, if someone writes software for KoOS, I plan to make it automatically run on every other major OS, including the mobile ones. I plan to do this with compatibility libraries for each major OS; the library will take the syscalls for my OS and make them work on other OS’s.
Second, I would like to write libraries for KoOS that will let it implement as much of other OS syscalls as possible, or at least appear to. What this will do is that, even though software written for other OS’s would have to be recompiled for KoOS, that software should need very little porting.
Third, I plan to write a compatibility library for drivers written for one major OS, probably Linux. This will (hopefully) allow Linux drivers to be used on my OS with very little porting, solving the chicken and egg problem.
KoOS comes from the Estonian word “koos” which Google Translate tells me means “together.” That makes sense to me for on OS that is meant to smooth over the portability problems with OS’s in general; it should bring software together with itself as the gathering place.