6 ms·

One 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

One 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 ago
  Thank you for the link! Turns out I completely missed these pages of computing history.
vertex-four 10y ago
I'd assume because a Lisp OS for modern-ish machines is interesting if you're into Lisp and its history.
ohyes 10y ago
Because it can be done!
- spaceheeder 10y ago
  One of the best reasons to write any software!
lispm 10y ago
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 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 ago
    That's one possible machine. Most Z80 and 6502 machines booted straight into BASIC in the early 1980s.
  - lispm 10y ago
    Apple IIe and IIc. A friend's father had an IIe and I got a IIc for myself, later.
    - eggy 10y ago
      My 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 ago
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 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 ago
  This 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 ago
  As 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 ago
  By 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 ago
You'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 ago
Why? 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

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 ago
Thank you for the link! Turns out I completely missed these pages of computing history.

vertex-four 10y ago

I'd assume because a Lisp OS for modern-ish machines is interesting if you're into Lisp and its history.

ohyes 10y ago

Because it can be done!

spaceheeder 10y ago
One of the best reasons to write any software!

lispm 10y ago

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 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 ago
  That's one possible machine. Most Z80 and 6502 machines booted straight into BASIC in the early 1980s.
- lispm 10y ago
  Apple IIe and IIc. A friend's father had an IIe and I got a IIc for myself, later.
  - eggy 10y ago
    My 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 ago

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 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 ago
This 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 ago
As 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 ago
By 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 ago

You'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 ago

Why? 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