The classic OS we all use and even the layer allow for Stratimux to exist as an MVP. It can run any application, including a prototype of a new emerging paradigm. Classically this would be referred to as a Universal Turing Machine that is capable or running any computation variant. When put to the test however, this ability is something that is merely good enough, or in general it can run any computation, until you find the wall for what was supposed to be a boundless computation environment.

One design decision that contrasts your OS in comparison to my own. Is that all calculations have some timer attached to them. This is done to ensure that operations must always conclude allow you computer to keep running uninterrupted. But this mechanism isn't perfect, and people can create their own code that unintentionally triggers a broader impact across the system.

What if you wanted a loop to always be running in the background? In our current paradigm of computing you would have to create a sophisticated event loop to ensure that you can pause this operation, modify it as needed, and close if your program exits. In fact this is the current mechanism used within Stratimux to ensure that long running processes such as an indefinite loop may halt, without the utilization of a timer.

What if you wanted an indefinite loop, but needed it to run continuously and pick up where it left off so long as the process is active? Or if you wanted that loop to be saved at its current iteration and when the program exits? If you could freeze an application prior to hitting a system error. Then hand it directly to a colleague to help you find the solution, initializing just prior to the error. And all you had to do was open a file associated with that error.

What if loops were simply bad design?

In modern programming languages there is a strange dynamic that may now be pointed out. That the alternative to this approach, the Recursive Function, is often times exchanged for a loop on the backend. Yet each step of a loop is merely some function. As the two approaches interchangeable, except the loop blocks the current thread. Alternatively we can use a functional approach, first by creating a greater recursive function. Where the logic of the loop is translated into a recursive function controlled by the greater. Therefore each step of the loop is just one step of the greater recursive function and is non blocking, but still loops.

The most basic loop, the while. Is just a function that recalls itself so long as a condition is true. Next would be the for loop, but it provides an additional interface that automatically iterates some value, to control when the loop concludes. Since all loops can be replaced with recursive functions, each iteration of the loop is just a function, but represented as a code block. We are now able to highlight the while loop is an arbitrary function or symbol. This logical inconsistency is the the reason why the halting problem in the Turing Machine exists in the first place.

To eliminate this critical vulnerability in the scope of AI, we can replace the while loop with a recursive function, that accepts a condition and a halting pointer. If an ASI is larger by proportion than an AGI, the ASI would have a greater likelihood of being stuck in an Infinite Loop, despite the slim chance of such in isolation. For example how mainframe computers need to take into account sun spots due to scale, but home PCs can throw out the issue entirely.

Following the same line of logic, there isn't a reason to ring any alarm bells for the general population. But instead can focus laser targeted effort at the most critical areas of our infrastructure. Such the creation of an AI running logging operations would be a prime candidate to have to have the halting issue resolved entirely.

Thus, the reason why my operating system can do something yours cannot. Is that the logical consistency for its operation was inspired by the frustration of running into limitations with the classic. The ability to halt a computer system, cease all operations and then resume as if nothing had happened. Even when transferring between different devices, is merely consistent logic that supports that dynamic. Discord on my own PC has a habit of requiring myself to force quit the application each time I wake my computer if I want to use it. Is just the poor application of consistent logic in the larger context of computing.

Granted the above would be the low level implementation of Stratimux once it moves from MVP. The most important aspect of this design pattern. Is that each part of it, can be translated from high level, to low level representation. Meaning we can have a form of backwards compatibility with the classic OS. The intent of this next OS paradigm, would be one that takes into account all lessons we have learned at this point of computing. But this is the larger picture and far away right now.

Stratimux proposes a new interface for managing what we call loops. The Plan.

const plan = axium.plan('Count to 5', [
    createStage((concepts, dispatch) => {
        const count = selectState<CounterState>(concepts, counterName).count;
        if (count && count <= 5) {
            dispatch(addOne(), {
            // Stops the stage delimiter from concluding the stage
                thottle: 0,
            });
        } else if (count) {
            console.log('Counted to 5', count);
            plan.conclude();
        } else {
            console.log('Counter removed from axium');
            plan.conclude();
        }
    })
]);

In contrast to the original while loop:

let count = 0;
while (count <= 5) {
    count++;
}
console.log('Counted to 5', count);

While the plan has more code, it is likewise is fully responsible for its implementation as a framework. If we were to create our own backend, while allowing for type information to be directly integrated into the logic. We could have something like this:

plan [
    stage {
        const {count} = select<Counter>();
        if (count <= 5) {
            dispatch(addOne(), {
                thottle: 0,
            });
        } else {
            conclude(log('Counted to 5: ' + count));
        }
    }
];

The above would be a minimum while remaining verbose. Noting we are determining plan, stage, dispatch and conclude as a keywords. Then assuming that the select is receiving the most recent concepts, removing the need to always mention such. The plan can likewise iterate through its stages, allowing for greater control over your applications logic.

Despite the example above, a plan is mainly used to dispatch entire strategies. Becoming an effective tool towards the manipulation of graph slices to formalize truly dynamic run times that are not possible in the current Turing Machine paradigm. But may be written in one.

There we have it, a halting loop that is able to remain consistent with the rest of the application. Not only that, each part of the application may be allowed access to the shared count value. This is what makes the Unified Turing Machine non-linear, and by side effect a Function as Operating System. As one of the greatest things my OS can do that yours cannot, is to allow another program reference this count value. While allowing for either to define the logical consistency of this interaction.

While this approach to programming has greater complexity than your traditional linear approach. This dynamic was created to allow for the entire scope of our applications to be mapped in such way, that we can reconfigure those parts into new applications. Or even allow our application to be unified together to create a new emergent application based on the prior. Just another super power this FaaOS can perform natively, in contrast to the classic.