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.
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.
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".
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.
I'm not sure it is a good idea, performance wise. A database application can use differently optimised strategies (data structures, etc.) for memory or disk access. It can't if it doesn't know what's in memory, or on disk.
So, build default data structures as if everything is swapped out, and add structures designed for use in memory for caching that data.
Alternatively, only use structures optimized for in memory use, and trust your OS to keep the active set paged in (easier, but can harm performance if you have much more data than RAM)
> It can't if it doesn't know what's in memory, or on disk.
For maximum performance the application can still be aware of the different memory types. You may still have to copy memory around (from volatile to persistent state) but it's possible to avoid the cost of serialisation.
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.
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.
Yeah the other classic problem with "Orthogonal Persistence" is that it becomes nearly impossible to upgrade your software. All your existing data is locked to the old version forever (or until some sort of "migration" can be performed -- which requires a way to dump the data, which you may or may not have).
From CS perspective, it's an impressive feat of engineering. They used persistent data structures to optimize in-memory operations, and essentially a write-ahead log of these same structures to optimize commits to disk.
They also created "OLE" technology in the OS+libraries to support embedding live documents one in another - remarkably not unlike Phantom's goals.
The trouble is, they did these in document interchange formats! Office succeeded, and the insane complexity of reverse-engineering its formats actually became a great business "moat".
A lot has been written assuming malice in OOXML, but you can also argue it'd require unbelievable competence to evolve their codebase to anything other than this!
If you never needed pervasive dump/load abstractions, your formats map to 1:1 to your semantics, and the only way to evolve is keeping old semantics around, forever...
EDIT: I can't help copy pasting more from the last link:
- lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text)
- mwSmallCaps (Emulate Word 5.x for Macintosh Small Caps Formatting)
- shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
- truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation)
- useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules)
- useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking)
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.
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.
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-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.
24 comments
[ 4.9 ms ] story [ 52.6 ms ] threadI'm saying that webassembly might ultimately evolve into something that look a bit like this, since it has almost-free IPC.
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".
* 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.
So, build default data structures as if everything is swapped out, and add structures designed for use in memory for caching that data.
Alternatively, only use structures optimized for in memory use, and trust your OS to keep the active set paged in (easier, but can harm performance if you have much more data than RAM)
For maximum performance the application can still be aware of the different memory types. You may still have to copy memory around (from volatile to persistent state) but it's possible to avoid the cost of serialisation.
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-notabili... https://news.ycombinator.com/item?id=16726189
> 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/
From CS perspective, it's an impressive feat of engineering. They used persistent data structures to optimize in-memory operations, and essentially a write-ahead log of these same structures to optimize commits to disk. They also created "OLE" technology in the OS+libraries to support embedding live documents one in another - remarkably not unlike Phantom's goals. The trouble is, they did these in document interchange formats! Office succeeded, and the insane complexity of reverse-engineering its formats actually became a great business "moat".
But decades later, after switching the surface structure from binary insanity to XML, it still contains attributes like `autoSpaceLikeWord95` and `footnoteLayoutLikeWW8` :-( http://www.robweir.com/blog/2007/01/how-to-hire-guillaume-po...
A lot has been written assuming malice in OOXML, but you can also argue it'd require unbelievable competence to evolve their codebase to anything other than this! If you never needed pervasive dump/load abstractions, your formats map to 1:1 to your semantics, and the only way to evolve is keeping old semantics around, forever...
EDIT: I can't help copy pasting more from the last link:
- lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text)
- mwSmallCaps (Emulate Word 5.x for Macintosh Small Caps Formatting)
- shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
- truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation)
- useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules)
- useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking)
- wpJustification (Emulate WordPerfect 6.x Paragraph Justification)
- shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
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.
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.