Theseus is a new OS written from scratch in Rust to experiment with novel OS structure, better state management, and how to shift OS responsibilities like resource management into the compiler.
We are continually working to improve the OS, including its fault recovery abilities for higher system availability without redundancy, as well as easier and more arbitrary live evolution and runtime flexbility. Though still an incomplete prototype, we envision that Theseus will be useful for high-end embedded systems or edge datacenter environments. See our published papers for more information about Theseus’s design principles and implementation philosophy, as well as our goal to avoid the phenomenon of state spill or mitigate its effects as much as possible. Also, see Theseus’s documentation for more.
Definitely an experimental operating system, and it joins the many other Rust-based operating systems projects out there.
[quote]
Theseus: experimental PS written from scratch in Rust
[/quote]
Should it be ‘experimental OS’ or what is a PS ?
Now Thom also has to register psnews.com 😉
The idea that avoiding so-called “state spill” might have benefits intrigued me, so I spent some time reading the papers to try to understand it. My conclusion is that it is way oversold, at least based on the work described in the papers so far. It’s true that with clients owning state objects that are opaque to them, the Rust runtime automates much of the cleanup process when a client crashes; this is indeed valuable. However, it seems the headline feature is supposed to be hot upgrading of OS components, which in general requires “transfer functions” to convert the component’s state from the old format to the new. Historically, such code has been very tricky to write. The continued need for transfer functions is acknowledged only briefly at the end of section 6.1 of “Theseus: an Experiment in OS Structure and State Management”, with a suggestion that it may be possible to partially automate their generation. I’ll believe that when I see it. Also, a quick read of the second-last paragraph of section 8 suggests that avoiding state spill may not be a helpful design principle for filesystems (as we understand them today: I will believe a fundamentally different approach is possible when I see it), which leads me to question how general that design principle is in the first place. But I haven’t thought about this part carefully.
I wholeheartedly encourage exploration of bold new ideas; at the same time, I don’t like them being oversold. If my skepticism is misplaced, please let me know what I am missing!