8 ms·

Phantom OS, a Russian OS where “everything is an object”

72 points by traverseda 8y ago

twotwotwo 8y ago
One thing it took me a while to realize is that a lot of what's provided by "OSes", the way users think of them, is standards: ABIs, protocols, formats, etc. And you can play with those in userspace. I am not saying kernels don't matter or anything, just that the kernel is not the only place one can play with radically different ways to organize stuff. So: if you want code to communicate and share capabilities through objects in a memory-safe environment, you can do that. (Browsers without strict site isolation often do this with cross-site iframes.) If you want to serialize state so you can stop and restore across reboots, you can do that. (CRIU does something like this, for apps not written for it even.) Sufficiently advanced language environments and runtimes often end up redeveloping OS-y bits (schedulers, binary formats, standard ways to exchange data). A big problem, as with completely new OSes with their own kernels and syscall interfaces, is getting people to develop to your interfaces. But it would be (is!) interesting to see folks build alternate universes in userspace that are much easier to dip into.
- roryrjb 8y ago
  So I believe I'm correct in saying that this is what Microsoft effectively does with WSL and Joyent does with Triton, i.e. faking a Linux kernel syscall table on top of a Windows NT kernel and Illumos kernel respectively.
  - twotwotwo 8y ago
    WSL does some interesting stuff, including some new code running in kernel mode (there's more here: https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/ https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-c...). No idea about Triton. gVisor is a user-space process providing a restricted Linux interface on top of regular-old Linux via syscall interception provided by ptrace. They all certainly demonstrate decoupling the "personality" presented to app code from the original interface of the kernel. I'm trying to say something a little different, which is that lots of things conventionally thought of as OS design issues are not inherently about syscalls and ring 0, and can be (and are) worked on in userspace. Like, you can have capability-based interaction between mutually untrusted bits of memory-safe code (the model of this OS) inside a Unix or Windows process, and you can do a lot of other exploration of how to organize/format/communicate in userland. The kernel interface provides necessary tools but it's not all there is. Of course kernel-side improvement is still important; foundations matter. Just, thinking big does not only have to mean replacing or even tweaking the kernel.
traverseda 8y ago
I thought this was interesting, it's not often I'm exposed to significant projects where the primary language isn't english. With all this new webassembly stuff it will be interesting to see if an approach like this takes off.
- slezyr 8y ago
  webassembly will make no difference at all. You still need to know english to learn how to program and read docs for libraries. It takes ages for translated books to appear, but even then most of them will be obsolete, especially for new tech like webassembly.
  - traverseda 8y ago
    When I say "maybe an approach like this will take off" I'm not saying "maybe we'll all be doing our programming in russian using phantom os". I'm saying that webassembly might ultimately evolve into something that look a bit like this, since it has almost-free IPC.
guicho271828 8y ago
Sounds like Lisp Machine Lisp reborn.
- jtr_47 8y ago
  Smalltak too
- agumonkey 8y ago
  лисп мачине
  - chupasaurus 8y ago
    A random class of russian language. Transliteration of latin-based word from English to Russian works differently. Word "machine" creeped into russian noble class through latin texts, so it was "махина" (х to this day transliterates to "kh"), but later on the french influence altered the word to "машина" (ш is pronounced as french "ch" or "sh" in english. The first word is still in the lexicon with the meaning of "a giant/huge object".
- monocasa 8y ago
  Reminds me more of the capability based OSs, like KeyKOS, EROS, and Coyotos.
- altmind 8y ago
  Reminds me of old 80ies Smalltalk environments. * everything is an object * image-based persistence I believe you cannot much traction in 2019 by merely claiming benefits of being object-oriented. These times are long gone. The basic ideas of OO(extension by inheritance, coupling data and code=poor concurrency, wrong abstractions = expensive rewrites, wrong incapsulation = impossibility to change behavior) turned out problematic in use. I'm still waiting for OS that positions itself to be "100% async" - every operation/event is a future/promise/callback, everything can be hooked, is progress-trackable and cancellable. That what I can stand behind.
  - pjmlp 8y ago
als0 8y ago
Persistent virtual memory is the future.
- theamk 8y ago
  I hope not, I like having readable file formats. When my SymbianOS phone started dying, I found out that there is no way to bulk-export all of my notes -- only way was exporting them one-by-one via laggy user interface. I subsequently spent lots of time analyzing backup file format, and then analyzing notes file format, and then finally extracting the text portions of the notes. Modern apps often use standard libraries for serialization [0], so it is much easier to get to your data back. But persistent virtual memory? We will be back to Symbian world again, but this time, you won't have to reverse engineer unknown on-disk format -- you will have to reverse engineer unknown object model, and chase the pointers to reassemble the data from the tiny pieces. [0] https://jvns.ca/blog/2018/03/31/reverse-engineering-notability-format/ https://jvns.ca/blog/2018/03/31/reverse-engineering-notabili... https://news.ycombinator.com/item?id=16726189 https://news.ycombinator.com/item?id=16726189
  - traverseda 8y ago
    Something like capnproto defining interfaces and memory structures in a cross-language way could be one way to mitigate that.
    - theamk 8y ago
      One of the big selling point of "persistent virtual memory" is that you do not need to serialize things to file at all: [0] > Phantom doesn't have files. Well, there are no files in the sense that a developer opens a file handle, writes to it, and closes the file handle. From the user's perspective, things still look familiar – a desktop, directories, and file icons. But a file in Phantom is simply an object whose state is persisted. You don't have to explicitly open it. As long as your program has some kind of reference to that object, all you need to do is call methods on it, and the data is there as you would expect. So in today's OSes, your editor may store data in the complex structure (ropes? ArrayList of Strings? b-tree?), but when saving, it serializes data to the nice format, using capnproto, json, xml, RIFF or something similar. In Phantom, there is no "save" step. If your editor stores text as a list of extents pointing into set of global buffers which contain strings in UCS-4 representation, this is whats gets written to disk, with pointers, vtables and all. Phantom OS magic ensures that pointers and vtables can be restored later. This is nice for application developer (less code), but very bad for third party trying to extract the data -- you either have to run the program and ask it nicely; or reverse engineer the class structure of the program. [0] https://www.theregister.co.uk/2009/02/03/phantom_russian_os/ https://www.theregister.co.uk/2009/02/03/phantom_russian_os/
_bxg1 8y ago
Looks like the last GitHub commit in the linked repo was 2 years ago; does anyone know if the greater project is still alive?

72 points by traverseda 8y ago

One thing it took me a while to realize is that a lot of what's provided by "OSes", the way users think of them, is standards: ABIs, protocols, formats, etc. And you can play with those in userspace. I am not saying kernels don't matter or anything, just that the kernel is not the only place one can play with radically different ways to organize stuff. So: if you want code to communicate and share capabilities through objects in a memory-safe environment, you can do that. (Browsers without strict site isolation often do this with cross-site iframes.) If you want to serialize state so you can stop and restore across reboots, you can do that. (CRIU does something like this, for apps not written for it even.) Sufficiently advanced language environments and runtimes often end up redeveloping OS-y bits (schedulers, binary formats, standard ways to exchange data). A big problem, as with completely new OSes with their own kernels and syscall interfaces, is getting people to develop to your interfaces. But it would be (is!) interesting to see folks build alternate universes in userspace that are much easier to dip into.

roryrjb 8y ago
So I believe I'm correct in saying that this is what Microsoft effectively does with WSL and Joyent does with Triton, i.e. faking a Linux kernel syscall table on top of a Windows NT kernel and Illumos kernel respectively.
- twotwotwo 8y ago
  WSL does some interesting stuff, including some new code running in kernel mode (there's more here: https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/ https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-c...). No idea about Triton. gVisor is a user-space process providing a restricted Linux interface on top of regular-old Linux via syscall interception provided by ptrace. They all certainly demonstrate decoupling the "personality" presented to app code from the original interface of the kernel. I'm trying to say something a little different, which is that lots of things conventionally thought of as OS design issues are not inherently about syscalls and ring 0, and can be (and are) worked on in userspace. Like, you can have capability-based interaction between mutually untrusted bits of memory-safe code (the model of this OS) inside a Unix or Windows process, and you can do a lot of other exploration of how to organize/format/communicate in userland. The kernel interface provides necessary tools but it's not all there is. Of course kernel-side improvement is still important; foundations matter. Just, thinking big does not only have to mean replacing or even tweaking the kernel.

traverseda 8y ago

I thought this was interesting, it's not often I'm exposed to significant projects where the primary language isn't english. With all this new webassembly stuff it will be interesting to see if an approach like this takes off.

slezyr 8y ago
webassembly will make no difference at all. You still need to know english to learn how to program and read docs for libraries. It takes ages for translated books to appear, but even then most of them will be obsolete, especially for new tech like webassembly.
- traverseda 8y ago
  When I say "maybe an approach like this will take off" I'm not saying "maybe we'll all be doing our programming in russian using phantom os". I'm saying that webassembly might ultimately evolve into something that look a bit like this, since it has almost-free IPC.

guicho271828 8y ago

Sounds like Lisp Machine Lisp reborn.

jtr_47 8y ago
Smalltak too
agumonkey 8y ago
лисп мачине
- chupasaurus 8y ago
  A random class of russian language. Transliteration of latin-based word from English to Russian works differently. Word "machine" creeped into russian noble class through latin texts, so it was "махина" (х to this day transliterates to "kh"), but later on the french influence altered the word to "машина" (ш is pronounced as french "ch" or "sh" in english. The first word is still in the lexicon with the meaning of "a giant/huge object".
monocasa 8y ago
Reminds me more of the capability based OSs, like KeyKOS, EROS, and Coyotos.
altmind 8y ago
Reminds me of old 80ies Smalltalk environments. * everything is an object * image-based persistence I believe you cannot much traction in 2019 by merely claiming benefits of being object-oriented. These times are long gone. The basic ideas of OO(extension by inheritance, coupling data and code=poor concurrency, wrong abstractions = expensive rewrites, wrong incapsulation = impossibility to change behavior) turned out problematic in use. I'm still waiting for OS that positions itself to be "100% async" - every operation/event is a future/promise/callback, everything can be hooked, is progress-trackable and cancellable. That what I can stand behind.
- pjmlp 8y ago

als0 8y ago

Persistent virtual memory is the future.

theamk 8y ago
I hope not, I like having readable file formats. When my SymbianOS phone started dying, I found out that there is no way to bulk-export all of my notes -- only way was exporting them one-by-one via laggy user interface. I subsequently spent lots of time analyzing backup file format, and then analyzing notes file format, and then finally extracting the text portions of the notes. Modern apps often use standard libraries for serialization [0], so it is much easier to get to your data back. But persistent virtual memory? We will be back to Symbian world again, but this time, you won't have to reverse engineer unknown on-disk format -- you will have to reverse engineer unknown object model, and chase the pointers to reassemble the data from the tiny pieces. [0] https://jvns.ca/blog/2018/03/31/reverse-engineering-notability-format/ https://jvns.ca/blog/2018/03/31/reverse-engineering-notabili... https://news.ycombinator.com/item?id=16726189 https://news.ycombinator.com/item?id=16726189
- traverseda 8y ago
  Something like capnproto defining interfaces and memory structures in a cross-language way could be one way to mitigate that.
  - theamk 8y ago
    One of the big selling point of "persistent virtual memory" is that you do not need to serialize things to file at all: [0] > Phantom doesn't have files. Well, there are no files in the sense that a developer opens a file handle, writes to it, and closes the file handle. From the user's perspective, things still look familiar – a desktop, directories, and file icons. But a file in Phantom is simply an object whose state is persisted. You don't have to explicitly open it. As long as your program has some kind of reference to that object, all you need to do is call methods on it, and the data is there as you would expect. So in today's OSes, your editor may store data in the complex structure (ropes? ArrayList of Strings? b-tree?), but when saving, it serializes data to the nice format, using capnproto, json, xml, RIFF or something similar. In Phantom, there is no "save" step. If your editor stores text as a list of extents pointing into set of global buffers which contain strings in UCS-4 representation, this is whats gets written to disk, with pointers, vtables and all. Phantom OS magic ensures that pointers and vtables can be restored later. This is nice for application developer (less code), but very bad for third party trying to extract the data -- you either have to run the program and ask it nicely; or reverse engineer the class structure of the program. [0] https://www.theregister.co.uk/2009/02/03/phantom_russian_os/ https://www.theregister.co.uk/2009/02/03/phantom_russian_os/

_bxg1 8y ago

Looks like the last GitHub commit in the linked repo was 2 years ago; does anyone know if the greater project is still alive?