Thanks for the link - that looks really interesting! I will have to give it a try to make some informed statement, but I think it's definitely worth looking at.

Thanks for the link - that looks really interesting! I will have to give it a try to make some informed statement, but I think it's definitely worth looking at. Some parts of Ruby also seem to be inspired by Smalltalk, so that might be a good fit. There's also a Smalltalk-80 VM by Rochus Keller based on the Lua JIT compiler [8] (and a very nice Qt-based Smalltalk browser), that might also go in the same direction. In general, I think there are two major interesting aspects in systems like the Ruby system browser and Smalltalk. On the one hand one can discover the system - you can dig into the implementation without using a disassembler or reverse engineering - and on the other hand it is possible to change the system behavior at runtime (though this is, of course, dangerous). I would love to see at least the discoverability aspect to be more pervasive in standard operating systems. There are already partial approaches to this, such as DTrace/systemtap and the proc filesystem, but having discoverability as a first class concept - which might fit well to Plan 9's (and to some extent Unix's) "everything is a file" approach - would be nice. The ability to change the system at runtime is also fascinating. I already mentioned the research of Stephen Kell in another comment [1] and there's a great video of one of his talks [2] in which he shows his approach to dynamically alter a program's behavior on Unix using shared library mechanisms (you can find the code on github [3]). I worked on related ideas in my PhD thesis 15 years ago, maybe it's time to dig these out again ;-). However, these dynamic modifications should also be safe and accessible. I'm thinking of something related to AppleScript here, which allows to automate/scripts an amazingly large number of functions on OS X. Combining this with a browser that enables a user to discover the accessible OS functionality seems to be a good idea. The persistent image ideas might also be useful again in the context of persistent main memory systems, which are becoming available now, e.g. with Intel Crosspoint [6]. There's so much prior work in persistent object systems also on the OS side that is almost forgotten nowadays, such as the Eumel/L3 system by Jochen Liedtke [4] (the inventor of the L4 microkernel) and the BirliX OS [5]. Sounds like a good time to re-evaluate these 1980's-era approaches. I see some more recent work, such as Ksplice [7], as interesting related technology. What is really missing is an integration of many of these ideas into a consistent system. [1] https://www.cs.kent.ac.uk/people/staff/srk21/ [2] https://www.youtube.com/watch?v=LwicN2u6Dro [3] https://github.com/stephenrkell/liballocs [4] Jochen Liedtke, A Persistent System in Real Use - Experiences of the First 13 Years, Third International Workshop on Object Orientation in Operating Systems 1993 - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7112 [5] W. E. Kühnhauser, H. Härtig, O. C. Kowalski, W. Lux, Mechanisms for Persistence and Security in BirliX, International Workshop on Computer Architectures to Support Security and Persistence of Information 1990, https://link.springer.com/chapter/10.1007/978-1-4471-3178-6_22 [6] https://en.wikipedia.org/wiki/3D_XPoint [7] Arnold, Jeff and Kaashoek, M. Frans, Ksplice: Automatic Rebootless Kernel Updates, EuroSys 2009 - https://ksplice.oracle.com/doc/ksplice.pdf