I see instructions to install it in a VM, but is it possible to run it on bare metal?
I'm also interested in that, but I'm having difficulties in finding the bootstrap code since I'm not proficient in Lisp. Did anybody manage to find it?
Mezzano – An operating system written in Common Lisp
41–50 of 65 posts
Re: Mezzano – An operating system written in Common Lisp
#42One of my favorite things to learn when I come across any experimental OS is: "why?" Redox wants to do microkernel architecture The Right Way, and wants to use a guaranteed memory-and-type safe language (Rust). ReactOS wants to create a drop-in replacement for Windows that not only supports older Windows programs, but also Windows-compatible device drivers. MenuetOS wants to build something approximating the OS exper…
> microkernel architecture The Right Way
Re: Mezzano – An operating system written in Common Lisp
#43Wouldn't it be easier to port emacs to common lisp? Hmm... Actually, probably not.
Depends what you call 'port' and 'emacs'.
Common Lisp already has some native variants of Emacs. Though not GNU Emacs.
The first one was called Hemlock and was developed in the early 80s.
Re: Mezzano – An operating system written in Common Lisp
#44One of my favorite things to learn when I come across any experimental OS is: "why?" Redox wants to do microkernel architecture The Right Way, and wants to use a guaranteed memory-and-type safe language (Rust). ReactOS wants to create a drop-in replacement for Windows that not only supports older Windows programs, but also Windows-compatible device drivers. MenuetOS wants to build something approximating the OS exper…
Mezzano would be an OS on top of a language/runtime for a programming language which allows flexible development from low-level up to high-level (CLOS/MOP). One could experiment with different OS models, which would be integrating interactive programming. I grew up with a machine which booted into a BASIC interpreter. It was relatively primitive, but fun. How would it look & feel with a more powerful programming lang…
> I grew up with a machine which booted into a BASIC interpreter.
same here (bbc b). i still miss that experience sometimes; a bash prompt is not quite the same thing.
Re: Mezzano – An operating system written in Common Lisp
#45Earlier quoted context omitted.
> Instead, if your system is written in Lisp, then you can directly pass lisp objects from one lisp application to another lisp application, and there's no need to serialize/deserialize, to parse or otherwise mangle the data: you just have lisp objects and you can use them directly. You can pass closures (which enclose the lisp object data along with the lisp functions needed to process them). So, if I understand cor…
Well, if you're running on a typical processor than any process can use pointer arithmetic to access memory, so you still need some sort of low-level memory protection mechanism. On some hypothetical Lisp/high-level-language processor, that needn't be the case, of course, but I honestly don't think we'll ever see something like that again.
> I honestly don't think we'll ever see something like that again.
Why?
Re: Mezzano – An operating system written in Common Lisp
#46Very impressive. Since the demise Lisp machines, there have been several attempts at developing a Lisp-based operating system which didn't deliver anything: LispOS, Tunes, and Loper; and one successful attempt at getting Lisp to run on the bare metal: Movitz. Lisp was its own operating system on the original Lisp machines developed at MIT, and this evolved into Genera at Symbolics. Is this the case here? I notice tha…
I think files have proven themselves to be a useful abstraction in enough use cases across enough device form-factors to be worth backporting into whatever your idea of an ideal lisp machine might be.
You could, with a non-trivial amount of effort, replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image. You could, also with a non-trivial amount of effort, work out the schemes for permissions, etc. so that objects with all those file-like conveniences can be shared, like files, on multi-user systems or between machines or over networks.
It's not clear to me that the above would offer any tangible benefit over files. So if you're going to put a non-trivial amount of effort into a lisp machine, why not just teach it what a file is?
Re: Mezzano – An operating system written in Common Lisp
#47Earlier quoted context omitted.
> It's also terrible for security. The security angle is interesting. The thing about independent processes is that we're relying on the OS to provide a wall around each process to limit it's impact by default . Maybe a better approach would to be include something like chroot/containerization for execution of closures within the language ? Ie, if program 'A' receives data from program 'B', it can evaluate that data…
No runtime analysis can simultaneously allow all intended sharing and prevent all unintended sharing. Best you can hope for is a static analysis that rejects programs that would share objects in unintended ways.
I'm not talking about automated runtime analysis per se. The type of permission setting I had in mind would be specified by the programmer and enforced by the runtime/OS.
Re: Mezzano – An operating system written in Common Lisp
#48Very impressive. Since the demise Lisp machines, there have been several attempts at developing a Lisp-based operating system which didn't deliver anything: LispOS, Tunes, and Loper; and one successful attempt at getting Lisp to run on the bare metal: Movitz. Lisp was its own operating system on the original Lisp machines developed at MIT, and this evolved into Genera at Symbolics. Is this the case here? I notice tha…
Being file based is very much in MIT Lisp DNA, certainly MACLISP and the CADR MIT Lisp Machine. (Re-)Building from scratch from files and saving out an image for faster loading times (or resaving an image with your project's stable files), vs. the Smalltalk working on an image once you get one going.
The single address space OS was well known from Multics, but I think would have been too much additional work for the developers, and running such a system with the much less reliable hardware of those days required a lot of tape backup, e.g. MIT-Multics would back up any dirty segment (file) after ~1/2 an hour, which of course required 24x7 operator staffing, that sort of Information Utility thing wasn't really in this group's DNA.
The Incompatiable Time Shareing System (ITS) was in fact named in humorous opposition to the Multics predecessor, the Compatible Time Sharing System (CTSS), the latter was xompatible with batch, those jobs would soak up any spare cycles if possible, which was a big deal back then. ITS instead had features where you could pretty much take over the machine for a robotics experiment or demo, that sort of resource allocation was handled socially, and such features were hidden by obscurity and a sort of apprenticeship system, instead of being enforced by the OS.
Re: Mezzano – An operating system written in Common Lisp
#49Earlier quoted context omitted.
No runtime analysis can simultaneously allow all intended sharing and prevent all unintended sharing. Best you can hope for is a static analysis that rejects programs that would share objects in unintended ways.
I'm not talking about automated runtime analysis per se. The type of permission setting I had in mind would be specified by the programmer and enforced by the runtime/OS.
Ah, okay, makes sense.
Re: Mezzano – An operating system written in Common Lisp
#50Very impressive. Since the demise Lisp machines, there have been several attempts at developing a Lisp-based operating system which didn't deliver anything: LispOS, Tunes, and Loper; and one successful attempt at getting Lisp to run on the bare metal: Movitz. Lisp was its own operating system on the original Lisp machines developed at MIT, and this evolved into Genera at Symbolics. Is this the case here? I notice tha…
I think files have proven themselves to be a useful abstraction in enough use cases across enough device form-factors to be worth backporting into whatever your idea of an ideal lisp machine might be. You could, with a non-trivial amount of effort, replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image. You could, also with a non-trivial amount of effort, wo…
> I think files have proven themselves
You will need to store data which doesn't fit into RAM in secondary storage. But that doesn't mean you need a file system or even files.
> to be a useful abstraction
Files are a necessary evil in non-image based systems because you need to store data somewhere when the programs using them aren't running. As the different objects they contain, such as plain text, hypertext, photographs, sound recordings, executables, etc. have nothing in common, they seem an unnecessary abstraction. They require that programs which use them parse/serialize their contents. This is unnecessary if the contents are already in memory, already in the format the program needs.
> replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image
Why remember a file name and where it is in the directory tree when you could use a search engine to search for it based on content? Or simply chain through objects, going to the field you want and following the link? Programs, of course, will just directly link to the object.
> work out the schemes for permissions
I'd go for capabilities, rather than access control.
> why not just teach it what a file is?
Building a file system is a major undertaking. If it can be avoided, and to the extent it can be avoided, it should be. You would only need to know about files when you interact with systems which are based around files.