I like this. There is strength in having many different species of operating system. Monocultures are vulnerable to all kinds of diseases, one way to combat that is to have a (much) larger variety of operating systems so that infecting any of them has a very low return-on-investment.
So any new operating system that is far from the beaten path should be very much welcomed, this one is more interesting than most since it is written using a high level language.
>So any new operating system that is far from the beaten path should be very much welcomed, this one is more interesting than most since it is written using a high level language.
I agree. But let's keep in mind that this isn't the first OS kernel written in Common Lisp.
Begs the question: is it possible to write a Lisp-based escape from the Lisp VM to the Virtualbox VM, then an escape from the Virtualbox VM to the host OS? Perhaps, but not something a casual attacker is likely to have resources for ;)
The idea of a VM is that it provides an iron box which nothing can break out of, because it's completely invisible. There's nothing a guest can do which could possibly distinguish a VM session from running on the bare hardware. Partly this is for compatibility, partly for ease of development (develop the next VM as a guest in the current VM!), and partly for simple security: You can't escape a prison if you are utterly convinced you're already out.
Maybe that part of the theory never made it into practice.
The idea of a VM is that it provides an iron box which nothing can break out of, because it's completely invisible. There's nothing a guest can do which could possibly distinguish a VM session from running on the bare hardware. Partly this is for compatibility, partly for ease of development (develop the next VM as a guest in the current VM!), and partly for simple security: You can't escape a prison if you are utterly convinced you're already out.
Maybe that part of the theory never made it into practice.
Have you ran the OS and seen this actual issue you're describing? If not, then what's your problem? If you're going to armchair quarterback, you should at least have thrown a football a few times first.
You may as well be complaining that the Windows 1.0 press release from 1985 has trouble with multitasking. Duh, this is pre-alpha software we're looking at.
This is true of any dynamic memory management unless very careful constraints are put in place. I would assume anyone writing an OS kernel, regardless of language, would be careful to avoid unbounded consing. (Of course, memory allocation in kernels is tricky even in C: http://lwn.net/Articles/627419/)
The "garbage velocity" is not the most important parameter. Remember that garbage is all the space which remains after we identify what is reachable. The traversal of the graph of what is reachable is mainly where the performance pitfalls lie. When garbage is generated at a high rate, it just means that collection has to be more frequent. However, real-time techniques avoid scanning the entire graph of everything that is reachable.
Under ephemeral garbage collection, if the software generates a lot of garbage fast, it means that it's rapidly making large numbers of "baby" objects (objects in the "nursery" or "generation 0") and immediately losing them. Whenever a generation pass comes along, there are hardly any nursery objects to visit (they almost all been lost due to the "garbage velocity"), and the tenured objects aren't traversed either, so ... it's quick. Quick isn't "free", but it's not "beyond the ability to cope".
Jon pls, do you even Lisp Machine? Seriously, you can't base your opinion on kernels/OS:s written in Lisp on this guy's hobby project. I know what you think of GC, but history shows what an industrial Lisp OS is like and it's awesome.
This looks very cool. I am going to wait until the source is posted on github before trying it. I was lucky enough to have received a Xerox 1108 Lisp Machine in the early 1980s, so having an OS written in Lisp seems reasonable :-)
Also, I agree with jacquesm's comment on the advantages of many operating systems.
Are people up voting this because they like the title or they like the link? Because there's literally more information about what this is in the HN title than the link. Is an anonymous paste the closest this thing has to a homepage?
But, as with many Lisp OS images, there is an issue with explorability: how do I discover system commands in the REPL? I know a bit of Common Lisp, but it's not clear to me how to discover what system can and what not, how to explore the environment. Neither Filesystem Viewer provides any clues, nor does REPL.
1) Install VirtualBox from https://www.virtualbox.org/
2) Download and ungzip the disk image from https://dl.dropboxusercontent.com/u/46753018/Mezzanine%20Demo%201-disk1.vmdk.gz
3) Create a new VM in VirtualBox with the following settings:
Type: Other
Version: Other/Unknown 64-bit
Memory size: 512MB
Use an existing virtual hard drive file, the one you downloaded
4) Open the settings for the VM and switch to the Network tab.
5) Open the advanced settings and change the adapter type to virtio-net
6) Click OK. The VM is ready to start.
Interesting that they need the virtio-net adapter (host hands off raw network packets to the guest instead of simulating a network card). How many other low level drivers are missing?
Of course, for a toy OS it doesn't really matter, but it does unfortunately constrain this to the toy OS category.
Heh. If you think "only runs in a VM" and "toy" are synonyms, you need a history lesson.
Back in the 1960s, one of the hot new things from IBM (you know, the company that wins on Jeopardy) was VM/CMS. VM is a VM, hence the imaginative name, and CMS stood for Conversational Monitor System, originally Cambridge Monitor System, for reasons I'll let you figure out.
Conversational meant "has a command line", as opposed to batch, which you might have heard of. CMS was, all told, somewhere between pond scum and MS-DOS on the complexity scale: it provided some APIs for applications, but didn't handle memory protection, multitasking, multiple users, or security policy. A mainframe running CMS on the bare metal would have been a really expensive version of a PC from twenty or so years later; obviously, you can only justify doing that in a Serious University.
However, it was convenient and user-friendly back before the term was coined, when that meant "not seeing raw machine code unless you asked for it", so the gag was to run multiple instances of CMS as guests under VM, which provided everything CMS didn't. Every user got their own copy of the OS, and the single physical mainframe was turned into dozens or hundreds of virtual mainframes by VM.
My punchline: As the decades wore on, CMS was never modified to take newer hardware into account. Why would it be? It never ran on the bare metal. VM gained emulation functionality, CMS grew to depend on that, and now CMS is effectively an appendage of VM, a friendly face to the thing which does all the hard work. You know, like marketing, or upper management.
Out of curiosity, have you written a driver for a real network card, or are you guessing as to its difficulty? One of my college OS class's assignments was to write an e1000 driver, and as I recall, it was way easier than, like, getting interrupt handling right.
Drivers are also pluggable, by nature. Why do you think this constrains the OS to the "toy" category? Or do you mean it constrains only the current version, and if so, do you believe there to be an observable difference between "toy" and "prerelease"?
Why do you think virtualized == toy? Is MirageOS a toy too then? They have no chance of ever getting enough device drivers to be able to support all the hardware out there. Running virtualized makes sense, and it's not a big performance hit.
A possible reason why "virtualized == toy" is that the virtualized system simulates certain specific hardware. The OS provides drivers for that hardware. But it hasn't been validated on the real hardware.
We don't know whether that is the case here. If the authors get a real box that has the same peripherals as the VirtualBox, and bring the OS up on that, then this "toy" argument can no longer be made, in any case.
Now this is looks pretty nice and I'd like it to take off. It can be the next Lisp Machine but unfortunately it raises a red flag with the licensing terms - MIT.
The author distributed the binary without the source code which is fine with MIT. He might release the code or change his mind and never release it. Again this is his choice.
But at this point, the distributed image is not any different than a proprietary solution. What good is it for me if I can't change it?
The .vmdk file you get after running gunzip on the downloaded file is a virtual hard drive.
When you create a new VM in VirtualBox, it asks if you want to create a new virtual hard drive or use an existing one. Select the one downloaded.
Yep, got it. I didn't recognize that funny graphic beside the pop-up menu in VirtualBox was supposed to be a button for opening a file. Creative UI choices like that do confuse me a great deal.
Screenshot: https://dl.dropboxusercontent.com/u/46753018/Screen%20Shot%2...