1. 25
  1. 3

    For those who, like me, had a hard time finding a summary of what this is all about, here it is:

    What Phantom OS is

    To be short:

    Orthogonal persistence. Application does not feel OS shutdown and restart. Even abrupt restart. It is guaranteed that application will be restarted in consistent state, which is not too old. As long as you have reference to any variable, it’s state is the same between OS reboots. You don’t have (though you can) save program state to files. It is persistent. Managed code. Native Phantom applications are running in a bytecode machine. (But it is worth to mention that Phantom has simple Posix compatibility subsystem too.) Global address space. Phantom OS is an application server. All applications can communicate directly, by sharing objects.

    Phantom OS persistence is achieved not by serializing data to files, but by running all applications in a persistent RAM. You can (and it will be true) think of Phantom memory subsystem as of a persistent paging engine. All the memory is paged to disk in a way that lets OS to restore whole memory image on restart. Consistently.

    (From the developer’s guide, which might be a starting point for introducing something like this than the particular kind of README in this repo.)

    1. 1

      I like this idea. I don’t know if I would switch my main OS to this, but it could be useful for virtual machines, like setting up a dev environment that has a lot of watcher scripts.

      1. 4

        resetting application state by OS reboots – has been the ‘repair’ tool of our trade, for more than 2 decades. :-) Some technologies, eg (Erlang) made it into a feature.

        But yes, this is very interesting. Perhaps another area where this would be very helpful – is running ‘dually-verifiable-mode’ (my naming). Where similar apps (in functionality) are separately designed and run on even different hardware. Yet, they periodically-compare their state, to ensure that the results are not diverging. If they do diverge, the instance with ‘correct state’ should take over.

    2. 3

      I am a massive sucker for anything with single-level storage and/or persistent memory (since the two concepts go hand in hand), so seeing any implementations makes me curious.

      1. 1

        Conventional OSes have been doing a simpler version of this when they go into “hibernation” but the big difference here is that the OS updates that state constantly, essentially treating all of RAM as a cache for a virtual memory paging file. Perhaps even more intriguing is the cohesive simplicity of the programming language that accompanies this system: the demo app manages to load data from the Internet & render it graphically without needing to fiddle with a complex web of 3rd-party deps.

        1. 4

          Conventional OSes have been doing a simpler version of this when they go into “hibernation” but the big difference here is that the OS updates that state constantly, essentially treating all of RAM as a cache for a virtual memory paging file

          The difference is that you can update the kernel but not lose any application state. Hypervisors have done this for a little while, loading a new version underneath running guests. And, of course, hypervisors have been able to suspend processes^W VMs to disk and resume them later. There have been patches floating around for a few years for both FreeBSD and Linux to allow suspending a single process to disk and resuming it but it gets a bit exciting when the process has open file handles because you might not be able to restore state. For a disk it’s mostly fine (unless that disk has gone away) because the filesystem is a shared resource and programs need to be somewhat robust in the presence of concurrent modification (they aren’t, in general, but this just increases the concurrency window). It’s mostly fine for networks because networks are expected to go away periodically and so processes generally handle that gracefully. It’s far more complex for local IPC (if I suspend a process with a pipe to another process, what happens? What happens if I restore it later without restoring the target?).

          Perhaps even more intriguing is the cohesive simplicity of the programming language that accompanies this system

          This kind of thing is great for simple demos but all single level store systems eventually end up inventing some kind of filesystem because you discover the need to:

          • Update the code for the persistent process.
          • Modify the internal data structures of the persistent process.

          The first of these leads to the need for a clean separation between code and data and a model for stopping all threads and then starting them again. The second leads to a need for some data serialisation and deserialisation format.

          That’s not to say that a conventional filesystem is the right abstraction. It conflates persistence, namespacing, and communication in some quite unfortunate ways.

          1. 1

            you discover the need to:

            • Update the code for the persistent process.
            • Modify the internal data structures of the persistent process

            Common lisp provides in-band methods for achieving both of these; for the former, you can generally just redefine things; for the latter, you have tools like change-class and update-instance-for-redefined/different-class.

            (I also do not buy your implicit premise that something like the traditional process model could not function in such a system.)