5 ms·

Closos: Specification of a Lisp operating system (2013) [pdf]

90 points by ska80 6y ago

heisig 6y ago
There is an active and growing group of hackers trying to make CLOSOS a reality. The current progress can be viewed at https://github.com/robert-strandh/sicl https://github.com/robert-strandh/sicl (SICL is the Common Lisp implementation that will be used for CLOSOS) I am one of the contributors, so please don't hesitate to ask questions or discuss ideas.
- smabie 6y ago
  If you're starting from scratch, why not design a new Lisp? CL has never struck me as a particularly inspired language, and neither has the kind of code people write with it. Or, if the idea is to leverage existing CL code, I'm sure with a little bit of effort SBCL could run as a unikernel and provide a good base for the system. Awhile ago there was a standalone Lisp implementation called Movitz. What are your thoughts on that?
  - pjmlp 6y ago
    Not the OP, but I would also use CL, it is an industry standard and there are endless libraries around. Anything else is just yet another risk for the project ever reach any kind of long term adoption. Clojure got this far only because it could ping back into the host libraries.
  - rjsw 6y ago
    There is at least one bug in the Movitz compiler, It won't correctly compile a simple loop expression, I spent a fair bit of time trying to fix it. I think it would be fairly easy to make SBCL run as a unikernel. There is also Mezzano [1], it is a Lisp OS. [1] https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano
  - heisig 6y ago
    > why not design a new Lisp? Hell no. Here is why: 1. The Common Lisp standard is brilliant. If your new Lisp is designed by anything less than a committee with people like Kent Pitman, Guy Steele, and Richard P. Gabriel, chances are that you will end up with something worse. 2. Common Lisp has one feature that people often forget about, but that is crucial for an operating system - you can rely on the fact that the semantics doesn't change. Lisp programs written in 1960 can usually be run on today's Common Lisp without modification, so there is hope that programs written today will still run properly even in centuries. 3. Common Lisp has the most powerful object system and the most powerful condition handling system. Both these features are invaluable for an operating system. This is actually my main motivation for contributing to this project. I want my programs to communicate via objects, and I want a system-wide mechanism for recovering from errors without crashing or unwinding the stack. 4. By relying on a very good existing language instead of reinventing this wheel, there is a chance that CLOSOS will actually get finished. > I'm sure with a little bit of effort SBCL could run as a unikernel and provide a good base for the system. Probably. But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments. And bolting that on top of SBCL without breaking existing things is about as painful as a full rewrite. The other big point is that SBCL values performance more than safety. But for CLOSOS, safety is crucial. > Movitz We intend to borrow some ideas from Movitz. But since we managed to bootstrap Common Lisp directly from Common Lisp, we hope that some things can be done more elegantly. The other project that should be mentioned here is Mezzano (https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano). We even borrow some code from Mezzano and are actively collaborating with its author.
    - rjsw 6y ago
      > But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments. This seems fine as a research concept but it wouldn't tempt me to use it. IBM got on fine with CMS just being a single-user operating system.
      - heisig 6y ago
        First class global environments are not about having multiple users on the same machine. Their main purpose is isolation, sandboxing, and reproducibility. Not every program should be able to modify the compiler, the kernel, or the garbage collector :)
  - alexisread 6y ago
    If we're talking about Lisp OSs, there's also LOSAK https://news.ycombinator.com/item?id=16980640 https://news.ycombinator.com/item?id=16980640 Interim OS http://interim.mntmn.com/ http://interim.mntmn.com/ Personally I'd be interested in a deterministic Lisp OS ie. Managed memory but no GC. Unfortunately that precludes CLOS but I'd imagine that many modules could ported over, depending on how far the language drifts.
  - dpc_pw 6y ago
    > why not design a new Lisp? Urbit.
lachlan-sneff 6y ago
I love thinking about ideas like this. A few years back, I wrote a kernel that ran wasm similar to how Closos would run lisp. Webassembly is perhaps a bit uninspired compared to lisp, but there are many advantages, although the system cannot be dynamic in the same way that this would be. I'd love to see these kinds of ideas revisited.
skulk 6y ago
Interestingly enough, the four-step process that is presented in section 1.4 seems very similar to how Urbit is being built right now.

90 points by ska80 6y ago

There is an active and growing group of hackers trying to make CLOSOS a reality. The current progress can be viewed at https://github.com/robert-strandh/sicl https://github.com/robert-strandh/sicl (SICL is the Common Lisp implementation that will be used for CLOSOS) I am one of the contributors, so please don't hesitate to ask questions or discuss ideas.

smabie 6y ago
If you're starting from scratch, why not design a new Lisp? CL has never struck me as a particularly inspired language, and neither has the kind of code people write with it. Or, if the idea is to leverage existing CL code, I'm sure with a little bit of effort SBCL could run as a unikernel and provide a good base for the system. Awhile ago there was a standalone Lisp implementation called Movitz. What are your thoughts on that?
- pjmlp 6y ago
  Not the OP, but I would also use CL, it is an industry standard and there are endless libraries around. Anything else is just yet another risk for the project ever reach any kind of long term adoption. Clojure got this far only because it could ping back into the host libraries.
- rjsw 6y ago
  There is at least one bug in the Movitz compiler, It won't correctly compile a simple loop expression, I spent a fair bit of time trying to fix it. I think it would be fairly easy to make SBCL run as a unikernel. There is also Mezzano [1], it is a Lisp OS. [1] https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano
- heisig 6y ago
  > why not design a new Lisp? Hell no. Here is why: 1. The Common Lisp standard is brilliant. If your new Lisp is designed by anything less than a committee with people like Kent Pitman, Guy Steele, and Richard P. Gabriel, chances are that you will end up with something worse. 2. Common Lisp has one feature that people often forget about, but that is crucial for an operating system - you can rely on the fact that the semantics doesn't change. Lisp programs written in 1960 can usually be run on today's Common Lisp without modification, so there is hope that programs written today will still run properly even in centuries. 3. Common Lisp has the most powerful object system and the most powerful condition handling system. Both these features are invaluable for an operating system. This is actually my main motivation for contributing to this project. I want my programs to communicate via objects, and I want a system-wide mechanism for recovering from errors without crashing or unwinding the stack. 4. By relying on a very good existing language instead of reinventing this wheel, there is a chance that CLOSOS will actually get finished. > I'm sure with a little bit of effort SBCL could run as a unikernel and provide a good base for the system. Probably. But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments. And bolting that on top of SBCL without breaking existing things is about as painful as a full rewrite. The other big point is that SBCL values performance more than safety. But for CLOSOS, safety is crucial. > Movitz We intend to borrow some ideas from Movitz. But since we managed to bootstrap Common Lisp directly from Common Lisp, we hope that some things can be done more elegantly. The other project that should be mentioned here is Mezzano (https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano). We even borrow some code from Mezzano and are actively collaborating with its author.
  - rjsw 6y ago
    > But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments. This seems fine as a research concept but it wouldn't tempt me to use it. IBM got on fine with CMS just being a single-user operating system.
    - heisig 6y ago
      First class global environments are not about having multiple users on the same machine. Their main purpose is isolation, sandboxing, and reproducibility. Not every program should be able to modify the compiler, the kernel, or the garbage collector :)
- alexisread 6y ago
  If we're talking about Lisp OSs, there's also LOSAK https://news.ycombinator.com/item?id=16980640 https://news.ycombinator.com/item?id=16980640 Interim OS http://interim.mntmn.com/ http://interim.mntmn.com/ Personally I'd be interested in a deterministic Lisp OS ie. Managed memory but no GC. Unfortunately that precludes CLOS but I'd imagine that many modules could ported over, depending on how far the language drifts.
- dpc_pw 6y ago
  > why not design a new Lisp? Urbit.

lachlan-sneff 6y ago

I love thinking about ideas like this. A few years back, I wrote a kernel that ran wasm similar to how Closos would run lisp. Webassembly is perhaps a bit uninspired compared to lisp, but there are many advantages, although the system cannot be dynamic in the same way that this would be. I'd love to see these kinds of ideas revisited.

skulk 6y ago

Interestingly enough, the four-step process that is presented in section 1.4 seems very similar to how Urbit is being built right now.