8 ms·
Mezzano – An operating system written in Common Lisp
- spaceheeder 10y agoOne 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 experience most users are used to, but on bare metal in assembly. So: why Mezzano?
- rjsw 10y ago> So: why Mezzano? One way to think of it is as a Lisp Machine [1] using an x86 CPU. [1] https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
- ComodoHacker 10y agoThank you for the link! Turns out I completely missed these pages of computing history.
- vertex-four 10y agoI'd assume because a Lisp OS for modern-ish machines is interesting if you're into Lisp and its history.
- ohyes 10y agoBecause it can be done!
- spaceheeder 10y agoOne of the best reasons to write any software!
- lispm 10y agoMezzano 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 language? This may all have its limits, but it looks like an interesting experiment. At some point in time it might even useful...
- hooya 10y ago> I grew up with a machine which booted into a BASIC interpreter ZX Spectrum by any chance?
- DonaldFisk 10y agoThat's one possible machine. Most Z80 and 6502 machines booted straight into BASIC in the early 1980s.
- lispm 10y agoApple IIe and IIc. A friend's father had an IIe and I got a IIc for myself, later.
- eggy 10y agoMy first computer in 1977 that booted up into BASIC - Commodore PET (Personal Electronic Transactor). It had 8k of memory, and I paid a whopping $400 for the 32k memory expansion module. The original PET cost me $800 used. My first game was a horse racing / betting game, reflecting my Mom and Dad's penchant for the ponies (OTB, you owe me big time ;) IIRC, I could only use graphics characters if all the letters were uppercase. My game had 3 horses to a race that ran from left to right based on a random number of which horse and how many spaces it moved. I generated a random number of 0 to 3 for each of the horses with: 100 FOR R = 1 TO 3 110 X = INT(4 * RND(1)) 120 NEXT R 130 SPC(A) You could bet based on fixed odds, and the payoff would show at the end of the race (bet * odds). My memorable joy was watching my Mom and Dad rooting at the 9 inch monochrome green screen! I was hooked on coding, but only at home. I rarely worked coding for a living. It booted up into PET BASIC, and aside from some PEEK/POKE limitations, you could access all of it. People hooked up joysticks later to the user port, and hacked speakers or buzzers for sound. I loved the Datasette (cassette tape drive) for storage! You had to put the tape in the drive, instruct BASIC to LOAD "PROG", and then it would prompt you to hit 'PLAY' on the Datasette. I think you then typed RUN "PROG" when if finished loading. I would go to the store where I bought it in NYC, and they had like 4 or 6 plastic bags with cassette tapes in them and a one sheet or a few sheets of instructions. I wanted FORTRAN or APL, but APL was not available on my PET. I would love a real LISP Machine, even an historical one for the pleasure of it really being 'turtles all the way down'! I love Lisp more than BASIC, but PET BASIC will always have a special place in my heart, and in the cobwebs of my mind. [Edit] It would boot up in about 4 seconds or so!
- informatimago 10y agoBasically, 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 level development tools as you would use to develop an application. The thing is that there's what we call an impedence mismatch between a unix kernel and applications running on it, in that the data types processed by applications which are of higher level, don't match the data types processed by the unix kernels. For example, a Ruby Integer is actually a bignum, and you cannot pass a bignum to the unix kernel: you have to provide a bit field with 32-bit or 64-bit. This is work, and this is pain. It is already pain when you write your applications in C or C++ where assumedly you already have bit field types, because your application could be compiled to run on kernels and processors using different word width! Imagine the pain it is when you write your applications in Common Lisp with very high level data types (ratios, closures, pathnames!), and when you have to map those data objects onto the lame bits accepted by unix syscalls. Consider all the literature written about logging, the byte vector logging provided by unix syslog vs. high level object logging provided by higher level libraries or other systems. And of course, this is not limited to the interface between applications and systems, but goes beyond to the interface between applications. When the system provides a pipe abstraction where all you can pass between applications are streams of byte, this leads to a lot of suffering. You have to serialize and deserialize your data, you have to consider formats (a java float doesn't have the same syntax as a Common Lisp float!), encoding (utf-8? iso-8859-1, -15?). Have you ever been advised to never parse the output of /bin/ls? For good reasons! 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).
- spaceheeder 10y agoThis does a very good job of explaining the value-add of lisp as a whole OS! And it does make the prospect of a working lisp OS on modern hardware seem quite exciting.
- bitmapbrother 10y ago>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?
- spaceheeder 10y agoAs of about a year ago [1] it looks like there were quite a few, although the Redox devs were aware and intended to cut down on them. Apparently it's something you can't do completely without, but the goal seems to be to have as few of them as possible, and none in userspace. [1]: https://news.ycombinator.com/item?id=10295187 https://news.ycombinator.com/item?id=10295187
- vertex-four 10y agoBy definition, all of it. The Rust language doesn't and can't encode the semantics of, say, a DMA chip, or some other piece of hardware at some arbitrary point in memory which can do arbitrary things. 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.
- nickpsecurity 10y agoYou'll find that a few on this list of benefits... http://www.symbolics-dks.com/Genera-why-1.htm 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. :)
- abecedarius 10y ago> Redox wants to do microkernel architecture The Right Way What is the Right Way? I couldn't find their take on that in 5 minutes on their website; this seems closest: https://doc.redox-os.org/book/introduction/why_redox.html https://doc.redox-os.org/book/introduction/why_redox.html
- Iispm 10y agoWhy? The question is never 'Why?', but 'How?'. The answer is the hacker "Hands on Imperative".
- snaky 10y ago> microkernel architecture The Right Way http://yarchive.net/comp/microkernels.html http://yarchive.net/comp/microkernels.html
- blue1 10y agoI see instructions to install it in a VM, but is it possible to run it on bare metal?
- qwertyuiop924 10y agoI assume so: The only real issue would be BIOS compatability, so it might take some work, but it should be possible.
- vertex-four 10y agoWell, the main issue would be it requires a specific network card to talk to its file server.
- qwertyuiop924 10y agoAh, missed that. Yep. I think USB, etc. are standard enough, so that should be it. With Intel motherboard, and Intel integrated networking, it could probably run in my machine. Wait. Graphics. %$&#!.
- khedoros 10y agoDepends on how graphics are implemented, right? Even a modern graphics card has some kind of support for older standards like plain VGA and VESA video modes, it seems like.
- qwertyuiop924 10y agoYeah, but I don't even know if Mezzano queries for a GPU or graphics card. It might just decide to use onboard no matter what.
- carlesfe 10y agoI'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?
- rcarmo 10y agoNeat. I rather like the idea, although these days any OS that doesn't target embedded systems and doesn't sport a web browser is instantly filed as a tech demo...
- qwertyuiop924 10y agoThis is a fun toy. As our forefathers did program upon the metal in Zetalisp, now thou shalt program upon the metal in Common Lisp. :D
- zeveb 10y agoWhat'll be really awesome is once it's possible to run SBCL on Mezzano (or would it be Mezzano in SBCL?), to take advantage of all the optimisations SBCL offers.
- johnhattan 10y agoI hope there'll be a driver for the Symbolics keyboard. I cannot be productive without a "meta", "super", and "hyper" key.
- dpc_pw 10y agoWouldn't it be easier to port emacs to common lisp? Hmm... Actually, probably not.
- lispm 10y agoDepends 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. https://en.wikipedia.org/wiki/Hemlock_(editor) https://en.wikipedia.org/wiki/Hemlock_(editor)
- erikj 10y agoWow, this is pretty impressive. The last time I checked its progress, it was very basic. Now it even has a working GUI with transparency! I should find some time to tinker with it.
- sigzero 10y agoThat's pretty nifty. I will have to fire up a VM and try it out.
- DonaldFisk 10y agoVery 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 that Mezzano has files. Files are inherited from operating systems running non image-based languages. They're alien to Smalltalk, where everything is just stored in the image (or world, in Lisp parlance). This could also be done in Lisp. Text files could be replaced by long strings contained in the world. Hypertext, provided tags are balanced, could be stored as lists. When the system is shut down, and periodically beforehand, the world is written to disk. You can go further, by using a single address space. Particularly large blocks of text which don't fit into RAM, and so have to be stored on disk, can be addressed by treating the disk as an extension of RAM. You can even go further on 64 bit machines by treating the entire contents of the internet as an extension of RAM. I once wrote a small bare-metal Lisp interpreter in x86 assembler, which ran off a 1.4Mb floppy on an old laptop. The hardest part was writing the floppy disk driver, which has to handle frequent hardware errors. USB drivers are many times harder and I didn't attempt that. If the Mezzano developer(s) succeeded, I'm even more impressed.
- spaceheeder 10y agoI 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?
- DonaldFisk 10y ago
- mikecsh 10y agoSomewhat off-topic but can anyone point me to any resources that explain the hardware architecture differences between x86 CPUS and the old LISP-machines? Was there hardware level support for s-expression evaluation?
- varjag 10y agoThey were microcode machines with certain optimizations for handling Lisp data structures. The memory had also extra tag bits per every word for the benefit of runtime type dispatch and garbage collection.