I think that the best way to get a similar experience would be to grab SBCL and write a high-level virtual machine on top of it that serves as a common GUI, application framework, editor, database, and provides other OS-related functions to make the developer experience 100% within Lisp. No Emacs or anything else from the outside, everything from audio over the graphics and the monitor sizes to networking needs to be abstracted away from the real machine. For example, every GUI and graphics feature needs to be freely scalable and resolution-invariant, based on virtual screens with their own coordinate systems. Aspect ratio is a problem, though, it probably needs to be taken from the real machine.
Anyone who wants to develop such a thing would have to take care to also abstract away from common mechanisms that are not very useful. For example, there seems to be absolutely no need to speak about files in such a system except for legacy support with the outside world. Likewise, standard network access should be on a self-configuring virtual p2p network whereas normal networking is a legacy system to the outside world.
Well, that's just my idea of a good Lisp machine. I don't mind if it runs on Linux as long as it doesn't feel like it. On the contrary, having such a large ecosystem underneath would allow the VM developers to integrate existing technologies freely into the VM. All it takes is to write a Lisp abstraction layer that deliberately prohibits any direct access to the underlying non-Lispy implementation. (If you grant too much access to the outside from the VM, then you destroy the VM's purpose - guaranteed interoperability, full reflection, and interactivity.)
However, I don't see such a truly interactive environment to happen because it's a lot of work.
Yes, I know these but my suggestion was pretty much the opposite, to use Linux as a basis and abstract away from it entirely. The result is better and much more usable. That's just my opinion, of course, and ymmv.
McCLIM runs on Linux, but it has tools like debugger, editor, listener and others written on top of it. Applications are possible. The UI is similar to that what a Symbolics had. It can serve as the UI part of a larger solution like you mentioned, where some services are provided by Linux, or tools on top of Unix (database, etc).
Anyone who wants to develop such a thing would have to take care to also abstract away from common mechanisms that are not very useful. For example, there seems to be absolutely no need to speak about files in such a system except for legacy support with the outside world. Likewise, standard network access should be on a self-configuring virtual p2p network whereas normal networking is a legacy system to the outside world.
Well, that's just my idea of a good Lisp machine. I don't mind if it runs on Linux as long as it doesn't feel like it. On the contrary, having such a large ecosystem underneath would allow the VM developers to integrate existing technologies freely into the VM. All it takes is to write a Lisp abstraction layer that deliberately prohibits any direct access to the underlying non-Lispy implementation. (If you grant too much access to the outside from the VM, then you destroy the VM's purpose - guaranteed interoperability, full reflection, and interactivity.)
However, I don't see such a truly interactive environment to happen because it's a lot of work.