Mezzano – An operating system written in Common Lisp
11–20 of 65 posts
Re: Mezzano – An operating system written in Common Lisp
#12One 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…
>Redox wants to do microkernel architecture The Right Way, and wants to use a guaranteed memory-and-type safe language (Rust) Just curious, how much of the Redox code is wrapped around unsafe?
Re: Mezzano – An operating system written in Common Lisp
#13One 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…
Basically, the point of lisp OSes, is that they allow you to seamlessly write code at all layers, from down into the darkest bowels of the system, thru and up to the highest level application scripting, all in a single integrated language and libraries and frameworks. You don't have to reboot a machine just because you make a patch to the kernel, and at the same time, you can patch the system using the same high leve…
So, if I understand correctly, the memory block in which a particular object is stored doesn't belong a priori to this or that process, but rather you can simply hand down objects to other processes? This is very cool! I've been thinking for quite a while that the very idea of memory protection is just a lame workaround to deal with the fact C is memory-unsafe.
Re: Mezzano – An operating system written in Common Lisp
#14I see instructions to install it in a VM, but is it possible to run it on bare metal?
Re: Mezzano – An operating system written in Common Lisp
#15Re: Mezzano – An operating system written in Common Lisp
#16One 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…
http://www.symbolics-dks.com/Genera-why-1.htm
...still aren't available in mainstream OS's despite being totally awesome. I particularly like how they came with integrated editor and source so an OS-related problem in app makes editor show you the problem (data or whatever), the source code involved, and a REPL letting you live-update it. Academics keep building prototypes that approximate any one of these steps to some degree for Linux or BSD. Not the whole thing, consistency, and production grade. :)
Re: Mezzano – An operating system written in Common Lisp
#17As our forefathers did program upon the metal in Zetalisp, now thou shalt program upon the metal in Common Lisp.
:D
Re: Mezzano – An operating system written in Common Lisp
#18One 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…
>Redox wants to do microkernel architecture The Right Way, and wants to use a guaranteed memory-and-type safe language (Rust) Just curious, how much of the Redox code is wrapped around unsafe?
Rust is built around wrapping unsafe things safely - i.e. it's possible in nearly every case to develop a performant API that doesn't let you do anything to break Rust's invariant of memory safety. Usually, these are small, meaning they're testable, which is likely good enough for almost everyone.
The next step up in safety is proving a program against a model of a system, which is a heck of a lot of hard work - you have to create a formal model of every single piece of hardware you might ever want to use. The next step after that would be proving a system actually matches the model.
Re: Mezzano – An operating system written in Common Lisp
#19I see instructions to install it in a VM, but is it possible to run it on bare metal?
I assume so: The only real issue would be BIOS compatability, so it might take some work, but it should be possible.
Re: Mezzano – An operating system written in Common Lisp
#20Earlier quoted context omitted.
Basically, the point of lisp OSes, is that they allow you to seamlessly write code at all layers, from down into the darkest bowels of the system, thru and up to the highest level application scripting, all in a single integrated language and libraries and frameworks. You don't have to reboot a machine just because you make a patch to the kernel, and at the same time, you can patch the system using the same high leve…
> 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…
Whilst convenient, it isn't an unqualified good. Bugs in any part of the system have the potential to catastrophically break everything. It's also terrible for security. |Without the notion of a distinct kernel - or "unsafe" code that only privileged users can compile or load - there's nothing to stop user code reading or writing directly to/from IO ports or arbitrary memory locations.
Being able to pass closures isn't something that's particular to Lisp, nor does it require a lack of memory protection. It just requires that the calling convention can denote a closure as such, and can arrange for it to be invoked in the right security context - i.e. the one in which it was created.
Another issue with having a single global environment backing everything is that you can't easily experiment with changing built-in Lisp functionality without immediately crashing the system.
This sort of thing is probably perfectly fine for embedded systems, and "micro-service" VMs, though. The benefits may well outweigh the risks then. And of course it's great as a starting point for experimentation.