ChrysaLisp is an Assembler/C-Script/Lisp 64 bit OS. MIMD, multi CPU, multi threaded, multi core, multi user, and will build from source in ~2 seconds on most OS X or x64 Linux desktops.
Maybe this will let me live vicariously through someone who has actually built the project I always dream of creating in my free time.
I started on this path, got through the boot-up, interrupts etc. and to a simple shell. Once that was done, instead of targeting something simpler like malloc(), I wanted to get a VGA driver working. VGA drivers are notoriously hard and I really wanted my OS to have a UI so after a couple of weeks of studying and getting nowhere, I gave up on the whole project.
I think the one major thing that caused me to give up on the project was whenever it became time to refactor or to think about the big picture (for ex. where do the drivers live? what about a libc implementation - can you just get glibc to work on your OS? Or do you have to rewrite the whole of libc?), I found that I was just copying whatever linux had already done. The feeling that I wasn't really doing any original work and am making a shittier version of an existing system demotivated me for some reason even though this was just supposed to be a learning exercise. So some advice for anyone attempting this - be prepared to go out of your way to rewrite significant amounts of helper code that has nothing to do with actually building your OS.
I made similar OS. ACPU OS run on mobiles/desktop/browsers/bare-metal, with multiuser p2p team development livecoding, time travel debugger, multiple libraries, startup in 30 seconds on iPad in development mode with synchronization, compile sources & symbol navigations, etc. Powered by ACPUL programming language.
A bit of a stretch to call this a "Lisp OS" yet. If you look at the project's history, you can see that it was written in nasm, and at some point the author "slapped some parens around" and took steps to make it into an actual Lisp dialect, but it's not there yet, as it lacks many of the features you'd expect from a Lisp. Also see README_LISP.md.
>Does this roughly offer the same benefits that the old lisp machines provided?
This project is cool, but, in short, no.
Please take a look at this paper, which answers the questions of which benefits could be obtained with a Lisp OS. This goes regardless of if such OS has or does not has a nice IDE.
I expect this will be a fairly controversial comment, so I want to preface this by saying that I'm a big Lisp fan (just look at my handle). Lisp is my favorite programming language. I've been using it for nearly forty years. My first Lisp was P-Lisp on an Apple II in 1980. And I worked on Symbolics Lisp machines in the 1990s. They were very cool, but there's a reason they failed: general-purpose computing is infrastructure, and the economics of infrastructure are such that having a single standard is the most economical solution, even if that standard is sub-optimal. For better or worse, the standard for general-purpose computing is the C machine.
Because it's general-purpose you certainly can run Lisp on a C machine (just as you could run C on a Lisp machine). You can even do this at the system level. But Lisp will always be at a disadvantage because the hardware is optimized for C. Because of this, C will always win at the system level because at that level performance matters.
But that in and of itself is not the determining factor. The determining factor is the infrastructure that has grown up around the C machine in the last few decades. There is an enormous amount of work that has gone into building compilers, network stacks, data interchange formats, libraries, etc. etc. and they are all optimized for C. For Lisp to be competitive at the system level, nearly all of this infrastructure would have to be re-created, and that is not going to happen. Even with the enormous productivity advantages that Lisp has over C (and they really are enormous) this is not enough to overcome the economic advantages that C has by virtue of being the entrenched standard.
The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level. I use Clozure Common Lisp. It has an Objective-C bridge, so I can call ObjC functions as if they were Lisp functions. There is no reason for me to know or care that these functions are actually written in C (except insofar as I have to be a little bit careful about memory management when I call C functions from Lisp) and so using Lisp in this way still gives me a huge lever that is economically viable even in today's world. I have web servers in production running in CCL on Linux, and it's a huge win. I can spin up a new web app on AWS in just a few minutes from a standing start. It's a Lisp machine, but at the application level, not the system level. My kernel (Linux) and web front end (nginx) are written in C, but that doesn't impact me at all because they are written by someone else. I just treat them as black boxes.
I don't want to denigrate ChrysaLisp in any way. It's tremendously cool. But cool is not enough to win in the real world.
[UPDATE] ChrysaLisp is actually doing the Right Thing with respect to its GUI by using a C-library (SDL). But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand. There are already many Lisps that can run on bare metal (ECL was specifically designed for that). None of them have succeeding in displacing C, and I believe none ever will because the economic hurdles are insurmountable.
One can debate whether or not this is a "true" operating system, but I'd like to coin a (new?) term: "virtual operating system"...not to be confused with emulation or virtual machines, but rather an OS that runs on top of a host OS. One obvious use for such a thing is reskinning an underlying operating system in a non-trivial way, i.e. completely changing the UI paradigms. Another use is allowing programmatic access to virtually everything.
Firmworks has a open source implementation of OpenFirmware which is part of the OpenBIOS project, can be used with Coreboot, and implements TCP/IP with various protocols including HTTP, all in Forth.
What this reminded me of most is the Connection Machines, which allowed you to configure the interprocessor connection topology. It had specialised C, FORTRAN and Lisp languages. They were also the best looking computers I ever saw!
It was almost mainstream in the 1980s when there were four Lisp Machine companies (Xerox, Symbolics, Texas Instruments, LMI) and symbolic AI, particularly expert systems, were used. Not so much now.
I still use it. If you know it you can be much more expressive and productive in it than in other mainstream languages, and when there's something you need that's missing from Lisp, you can extend Lisp to include it.
There are reasons it's fallen from favour, some of which lisper has given here. It's a mistake to languages necessarily succeed or fail on their merits.
>I would like to know if any HN'ers would provide me some insight into why Lisp is so popular?
In the late early 80s it was rather popular but it required expensive specialized hardware and software. Or you could execute it on more common hardware, but memory requirements were pretty high, which adds to the expense.
It's not like in 2017 where you can have many excellent Lisp implementations for free and they run blazingly fast on your machine, without needing more memory than what you have already.
It also has something to do with the triumph of UNIX over the Lisp machines
JavaScript has been called "Lisp in C's clothing". What it lacks is macros basically but you can get a lot of practical work done in JavaScript and it is as mainstream as it gets. So how about a JavaScript OS/Machine/Hardware anybody?
>JavaScript has been called "Lisp in C's clothing". What it lacks is macros
No, it lacks a lot of things in comparison, and if it only lacks macros, then it's lacking a lot as well.
Considering, for this case, "Lisp"="Common Lisp", this is what Javascript lacks:
1. Strong typing. CL is very strongly typed. Javascript is very weakly typed. Typescript doesn't fix this 100% because the runtime is still javascript, and thus the running code is weakly typed.
2. Code should be a first class citizen; code can be processed/sliced/diced/handled as easily as data. That is, code is data so most of the functions that apply to data, also apply to code. This doesn't happen in Javascript. Thus in Lisp metaprogramming is very easy and can be applied in many ways, greatly enhancing the power of the language, making it a "programmable programming language."
---------------
I could stop here, because these two above are strong, significant differences enough to tip the balance towards CL. But there's more:
---------------
3. A really good object system. CLOS might be the most advanced OOP system out there.
4. Really good numeric support. Javascript numbers are internally floats. In CL you have a full numeric tower. Complex numbers? check. Arbitrary-length numbers? check.
5. Image-based interactive development
6. A killer exception handling system: The condition-restart system.
7. Speed. CL can execute significantly faster than JS and can approach C/Fortran speeds if needed (by using tricks.)
8. Optional static type checks, and type declarations for increased performance if needed.
9. In javascript, you code so you define what happens at runtime. In CL, you can define when is your code going to be run: "at read time" versus "at compile time" versus "at runtime". So there are three "times" you can leverage!!
JavaScript is really nothing like Lisp. Macros/code is data and simple syntax are basically the defining features of a Lisp. Apart from these, JavaScript's type system is totally different (way weaker, based on objects but nothing like CLOS), JS isn't based on lists/pairs as the primary data structure, JS emphasizes imperative programming, etc. I don't know where this myth came about (probably because rumor that Brendan Eich initially intended to use Scheme instead of JS, although this never happened).
For me, calling something an OS requires it to have it's own kernel ... maybe thats just me, but I think this is the 2nd project this month which has called itself an OS when in reality it is just a GUI.
It already has a kernel, except it uses the host OS's system calls instead of its own drivers. Once you have a runnable OS that runs as a separate Unix process in its own address space, it is actually possible to port it over to bare metal by providing all the modules that the OS would normally provide: memory management, graphics, device management and HAL, keyboard/mouse input.
Operating systems manage IPC/resources and facilitate I/O. This one does the former but as yet depends on another underlying kernel for the latter. It's just a matter of writing the drivers/platform specific code and it can stand on its own. So not that much of a stretch to call it an OS, IMO.
I think it's worth noting the distinction between OS and kernel is a bit messy. I think that you could argue that this together with a kernel creates an OS (In the same way that Linux + GNU creates an OS). You don't have to write the kernel yourself to create an OS, just have a kernel. It is kinda false advertising though - it's like saying you wrote an "OS with CoreUtils" when you just wrote a set of CoreUtils. It's still really good, but not what people are thinking of when you that.
That said, I agree with you that it kinda stinks this doesn't have its own kernel - it really is just a GUI without it. It surprises me that so many people are blowing it off as no big deal. Writing the kernel is not a simple detail, we're talking about a lot of functionality that is missing that takes a lot of work to get right.
I think the discussion of what constitutes an OS is mostly academic.
That said, to me, an operating system is basically any environment that allows me to run applications.
Usually, that implies a kernel, since you can't do much without one, but in some circumstances, you might not have a "kernel" in the traditional sense.
For example, LXC containers don't have their own kernel, but they provide an environment - binaries, libraries, etc - where I can run applications. I can rightly call that an OS, I think.
I agree. These things aren't OS's. They're platform emulators that run using the low-level plumbing of actual OS's. Going from that to bare metal has been hard enough for hobbyists that many barely got anything done on it or didn't try. We should only call them OS's when they run on bare metal or something like VirtualBox.
[+] [-] bespoke_engnr|8 years ago|reply
ChrysaLisp is an Assembler/C-Script/Lisp 64 bit OS. MIMD, multi CPU, multi threaded, multi core, multi user, and will build from source in ~2 seconds on most OS X or x64 Linux desktops.
Maybe this will let me live vicariously through someone who has actually built the project I always dream of creating in my free time.
[+] [-] tejaswiy|8 years ago|reply
I think the one major thing that caused me to give up on the project was whenever it became time to refactor or to think about the big picture (for ex. where do the drivers live? what about a libc implementation - can you just get glibc to work on your OS? Or do you have to rewrite the whole of libc?), I found that I was just copying whatever linux had already done. The feeling that I wasn't really doing any original work and am making a shittier version of an existing system demotivated me for some reason even though this was just supposed to be a learning exercise. So some advice for anyone attempting this - be prepared to go out of your way to rewrite significant amounts of helper code that has nothing to do with actually building your OS.
[+] [-] d08ble|8 years ago|reply
I made similar OS. ACPU OS run on mobiles/desktop/browsers/bare-metal, with multiuser p2p team development livecoding, time travel debugger, multiple libraries, startup in 30 seconds on iPad in development mode with synchronization, compile sources & symbol navigations, etc. Powered by ACPUL programming language.
Here is OS API:
https://github.com/d08ble/acpul-demo/tree/master/sys
Simple multiplayer DOTA game prototype:
https://github.com/d08ble/acpul-demo/tree/master/dota
Some demos:
https://www.youtube.com/watch?v=pk58kWIAqMM
https://www.youtube.com/watch?v=UsQklNVUDwM
https://www.youtube.com/watch?v=ubNfWarTawI
Follow us: https://twitter.com/ACPUStudio
[+] [-] dogprez|8 years ago|reply
You too!?
[+] [-] bluefox|8 years ago|reply
[+] [-] tyingq|8 years ago|reply
I've never used one, but have heard people rave about how productive they were on them.
[+] [-] flavio81|8 years ago|reply
This project is cool, but, in short, no.
Please take a look at this paper, which answers the questions of which benefits could be obtained with a Lisp OS. This goes regardless of if such OS has or does not has a nice IDE.
http://metamodular.com/lispos.pdf
This is a really good paper, recommended lecture.
[+] [-] lisper|8 years ago|reply
I expect this will be a fairly controversial comment, so I want to preface this by saying that I'm a big Lisp fan (just look at my handle). Lisp is my favorite programming language. I've been using it for nearly forty years. My first Lisp was P-Lisp on an Apple II in 1980. And I worked on Symbolics Lisp machines in the 1990s. They were very cool, but there's a reason they failed: general-purpose computing is infrastructure, and the economics of infrastructure are such that having a single standard is the most economical solution, even if that standard is sub-optimal. For better or worse, the standard for general-purpose computing is the C machine.
Because it's general-purpose you certainly can run Lisp on a C machine (just as you could run C on a Lisp machine). You can even do this at the system level. But Lisp will always be at a disadvantage because the hardware is optimized for C. Because of this, C will always win at the system level because at that level performance matters.
But that in and of itself is not the determining factor. The determining factor is the infrastructure that has grown up around the C machine in the last few decades. There is an enormous amount of work that has gone into building compilers, network stacks, data interchange formats, libraries, etc. etc. and they are all optimized for C. For Lisp to be competitive at the system level, nearly all of this infrastructure would have to be re-created, and that is not going to happen. Even with the enormous productivity advantages that Lisp has over C (and they really are enormous) this is not enough to overcome the economic advantages that C has by virtue of being the entrenched standard.
The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level. I use Clozure Common Lisp. It has an Objective-C bridge, so I can call ObjC functions as if they were Lisp functions. There is no reason for me to know or care that these functions are actually written in C (except insofar as I have to be a little bit careful about memory management when I call C functions from Lisp) and so using Lisp in this way still gives me a huge lever that is economically viable even in today's world. I have web servers in production running in CCL on Linux, and it's a huge win. I can spin up a new web app on AWS in just a few minutes from a standing start. It's a Lisp machine, but at the application level, not the system level. My kernel (Linux) and web front end (nginx) are written in C, but that doesn't impact me at all because they are written by someone else. I just treat them as black boxes.
I don't want to denigrate ChrysaLisp in any way. It's tremendously cool. But cool is not enough to win in the real world.
[UPDATE] ChrysaLisp is actually doing the Right Thing with respect to its GUI by using a C-library (SDL). But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand. There are already many Lisps that can run on bare metal (ECL was specifically designed for that). None of them have succeeding in displacing C, and I believe none ever will because the economic hurdles are insurmountable.
[+] [-] dsgfhasgjklas|8 years ago|reply
[+] [-] gavanwoolery|8 years ago|reply
[+] [-] steelbird|8 years ago|reply
$ clone https://github.com/vygr/ChrysaLisp.git ChrysaLisp
$ cd ChrysaLisp
$ sudo apt-get install libsdl2-ttf-dev
$ make -j
$ ./run.sh
To quit:
$ ./stop.sh
[+] [-] antimass|8 years ago|reply
0) Make sure you have a recent Xcode installed
1) Install the libsdl2 and libsdl2_ttf frameworks under /Library/Frameworks
2) git clone https://github.com/vygr/ChrysaLisp.git ChrysaLisp3) cd ChrysaLisp
4) make (takes about 2s!!)
5) ./run.sh (shows full working gui. Amazing!)
[+] [-] scottyelich|8 years ago|reply
[+] [-] scottyelich|8 years ago|reply
[+] [-] nicklaf|8 years ago|reply
http://www.firmworks.com/ofwfeatures.htm
http://GitHub.com/openbios/openfirmware
[+] [-] avodonosov|8 years ago|reply
[+] [-] avodonosov|8 years ago|reply
[+] [-] rurban|8 years ago|reply
[+] [-] xenophonf|8 years ago|reply
[+] [-] derefr|8 years ago|reply
[+] [-] autcrock|8 years ago|reply
[+] [-] colesantiago|8 years ago|reply
Does anyone use it in production? Is it comparable to JS?
[+] [-] DonaldFisk|8 years ago|reply
It was almost mainstream in the 1980s when there were four Lisp Machine companies (Xerox, Symbolics, Texas Instruments, LMI) and symbolic AI, particularly expert systems, were used. Not so much now.
I still use it. If you know it you can be much more expressive and productive in it than in other mainstream languages, and when there's something you need that's missing from Lisp, you can extend Lisp to include it.
There are reasons it's fallen from favour, some of which lisper has given here. It's a mistake to languages necessarily succeed or fail on their merits.
[+] [-] flavio81|8 years ago|reply
In the late early 80s it was rather popular but it required expensive specialized hardware and software. Or you could execute it on more common hardware, but memory requirements were pretty high, which adds to the expense.
It's not like in 2017 where you can have many excellent Lisp implementations for free and they run blazingly fast on your machine, without needing more memory than what you have already.
It also has something to do with the triumph of UNIX over the Lisp machines
[+] [-] Annatar|8 years ago|reply
[+] [-] jstewartmobile|8 years ago|reply
[+] [-] galaxyLogic|8 years ago|reply
[+] [-] flavio81|8 years ago|reply
No, it lacks a lot of things in comparison, and if it only lacks macros, then it's lacking a lot as well.
Considering, for this case, "Lisp"="Common Lisp", this is what Javascript lacks:
1. Strong typing. CL is very strongly typed. Javascript is very weakly typed. Typescript doesn't fix this 100% because the runtime is still javascript, and thus the running code is weakly typed.
2. Code should be a first class citizen; code can be processed/sliced/diced/handled as easily as data. That is, code is data so most of the functions that apply to data, also apply to code. This doesn't happen in Javascript. Thus in Lisp metaprogramming is very easy and can be applied in many ways, greatly enhancing the power of the language, making it a "programmable programming language."
---------------
I could stop here, because these two above are strong, significant differences enough to tip the balance towards CL. But there's more:
---------------
3. A really good object system. CLOS might be the most advanced OOP system out there.
4. Really good numeric support. Javascript numbers are internally floats. In CL you have a full numeric tower. Complex numbers? check. Arbitrary-length numbers? check.
5. Image-based interactive development
6. A killer exception handling system: The condition-restart system.
7. Speed. CL can execute significantly faster than JS and can approach C/Fortran speeds if needed (by using tricks.)
8. Optional static type checks, and type declarations for increased performance if needed.
9. In javascript, you code so you define what happens at runtime. In CL, you can define when is your code going to be run: "at read time" versus "at compile time" versus "at runtime". So there are three "times" you can leverage!!
There are even more differences, to be honest.
[+] [-] nv-vn|8 years ago|reply
[+] [-] alekratz|8 years ago|reply
Please, no.
[+] [-] pjmlp|8 years ago|reply
[+] [-] xmichael99|8 years ago|reply
[+] [-] phoe-krk|8 years ago|reply
See https://github.com/froggey/Mezzano for something that can run on bare metal.
[+] [-] tyingq|8 years ago|reply
"Could move to bare metal eventually but it's useful for now to run hosted while experimenting"
And this: https://github.com/vygr/ChrysaLisp/blob/master/sys/kernel.vp
[+] [-] Santosh83|8 years ago|reply
[+] [-] DSMan195276|8 years ago|reply
That said, I agree with you that it kinda stinks this doesn't have its own kernel - it really is just a GUI without it. It surprises me that so many people are blowing it off as no big deal. Writing the kernel is not a simple detail, we're talking about a lot of functionality that is missing that takes a lot of work to get right.
[+] [-] disconnected|8 years ago|reply
That said, to me, an operating system is basically any environment that allows me to run applications.
Usually, that implies a kernel, since you can't do much without one, but in some circumstances, you might not have a "kernel" in the traditional sense.
For example, LXC containers don't have their own kernel, but they provide an environment - binaries, libraries, etc - where I can run applications. I can rightly call that an OS, I think.
Edit: clarity
[+] [-] nickpsecurity|8 years ago|reply
[+] [-] rbanffy|8 years ago|reply