4 ms·

I must be getting old because I can't tell if this is sarcasm or not.

by c-linkage 4y ago

kitd 4y ago
Why should it be? It's basically a unikernel in a zip file.
- jart 4y ago
  That's correct. Redbean is already capable of booting on bare metal. We do what we must because we can. The executable file format redbean uses is a DOS Master Boot Record with a partition table, so it's technically a valid disk image you can `dd` too. If you're willing to trade away Windows support, then it can be an EFI image. The main blocker is figuring out how to get an e1000 and/or VirtIO driver in there with a TCP/IP stack. Right now Cosmopolitan bare metal support is only adequate for stdio applications, which use the serial port and read from the zip fs.
  - branon 4y ago
    For the good of all of us! Except the ones who are dead.
    - egeozcan 4y ago
      This, and "we do what we must because we can" from the GP are references to the ending credits in Portal, the game, if anyone is wondering.
      - csdvrx 4y ago
        Recently, I took this approach to get proper ACPI S01x sleep on my Lenovo X1 Fold (a wonderful device BTW, once you take the time to work around Intel drivers bugs) A battery discharge rate of 0.5%/h in sleep is just great... but I think I can do better: I'm now trying for 0.25%/h. Imagine if you could immediately resume your foldable oled tablet, and it'd have only lost like 6% of the battery. With a 20% hibernate trigger, it would remain immediately available for over 3 days straight!
  - unsafecast 4y ago
    That sounds amazing, I love your work! Is ARM support planned? A raspi seems like the perfect target for this.
    - capableweb 4y ago
      The page for APE (https://justine.lol/ape.html https://justine.lol/ape.html) says the following about ARM: > It'll be nice to know that any normal PC program we write will "just work" on Raspberry Pi and Apple ARM. All we have to do embed an ARM build of the emulator above within our x86 executables, and have them morph and re-exec appropriately, similar to how Cosmopolitan is already doing doing with qemu-x86_64, except that this wouldn't need to be installed beforehand. The tradeoff is that, if we do this, binaries will only be 10x smaller than Go's Hello World, instead of 100x smaller. The other tradeoff is the GCC Runtime Exception forbids code morphing, but I already took care of that for you, by rewriting the GNU runtimes. Also this, from a GitHub issue (https://github.com/jart/cosmopolitan/issues/354#issuecomment-1125306493 https://github.com/jart/cosmopolitan/issues/354#issuecomment...): > Probably related to #399. The recommended approach would be to use a full emulator like Bochs. It's not something we use at the moment so we can't provide support on this. Although we do intend to have APE support ARM at some point in the future.
      - unsafecast 4y ago
        Thank you!
  - csdvrx 4y ago
    > That's correct. Redbean is already capable of booting on bare metal. We do what we must because we can. I love the spirit :) > The main blocker is figuring out how to get an e1000 and/or VirtIO driver in there with a TCP/IP stack. Why? Is it for performance reasons or security reasons? (or both) > Right now Cosmopolitan bare metal support is only adequate for stdio applications, which use the serial port and read from the zip fs. I'd suggest you "think different", and use instead something like ppp to create a TCP/IP stack over a serial link. Modern btuart implementations already routinely achieve >1Mbps on commercial devices. The GSI as seen on the Intel Serial IO devices support bitrates over 20Mbps. This could buy you time until you find a better solution, if it's ever needed (which I doubt as back of the envelope estimations make me believe you'll hit other limitations before)
    - jart 4y ago
      It's less about perf/security and more to do with simply needing the time to wrap my head around how to do it. Entering ring0 is a whole different world. My productivity depends on a responsive TDD workflow and it's hard to test kernel code. I currently do it using an emulator I wrote called Blinkenlights, because the existing ones (Bochs and QEMU) couldn't be integrated into my Makefile / Emacs build system. So I not only need to build the kernel but I need to emulate the CPU features the kernel needs too.
      - csdvrx 4y ago
        > It's less about perf/security and more to do with simply needing the time to wrap my head around how to do it. I can have a look at using ppp for creating a network connection using stdio. It doesn't look very complicated. > it's hard to test kernel code Exactly why I suggest pppd (userland) instead of VFIO > So I not only need to build the kernel but I need to emulate the CPU features the kernel needs too You have stdio? No need for anything else.
c-linkage 4y ago
I can't edit my comment (maybe I waited too long?) so I'll add more here... My comment about not knowing if running redbean on bare metal was sarcasm was a comment about me, not about redbean or Justine, so no disrespect intended. There's a lot of "turtles all the way down" today (a web server compiled to WASM so it runs in a browser running on a OS hosted in QEMU that's running on another host OS that's a virtual machine running in a linux container on top of a hypervisor running on an X86 simulator...) so I quite honestly couldn't tell if the idea of running redbean on bare metal was sarcasm or a joke. But Justine says its true, so I guess it's not a joke. Consider me schooled.
- jart 4y ago
  I agree because the whole point of being able to run on metal is to have fewer turtles. How many vendors control the space between your code and your computer? Who controls your memory? I think those are questions worth asking. My goal is simply to help people get closer to the source.

I must be getting old because I can't tell if this is sarcasm or not.

kitd 4y ago

Why should it be? It's basically a unikernel in a zip file.

jart 4y ago
That's correct. Redbean is already capable of booting on bare metal. We do what we must because we can. The executable file format redbean uses is a DOS Master Boot Record with a partition table, so it's technically a valid disk image you can `dd` too. If you're willing to trade away Windows support, then it can be an EFI image. The main blocker is figuring out how to get an e1000 and/or VirtIO driver in there with a TCP/IP stack. Right now Cosmopolitan bare metal support is only adequate for stdio applications, which use the serial port and read from the zip fs.
- branon 4y ago
  For the good of all of us! Except the ones who are dead.
  - egeozcan 4y ago
    This, and "we do what we must because we can" from the GP are references to the ending credits in Portal, the game, if anyone is wondering.
    - csdvrx 4y ago
      Recently, I took this approach to get proper ACPI S01x sleep on my Lenovo X1 Fold (a wonderful device BTW, once you take the time to work around Intel drivers bugs) A battery discharge rate of 0.5%/h in sleep is just great... but I think I can do better: I'm now trying for 0.25%/h. Imagine if you could immediately resume your foldable oled tablet, and it'd have only lost like 6% of the battery. With a 20% hibernate trigger, it would remain immediately available for over 3 days straight!
- unsafecast 4y ago
  That sounds amazing, I love your work! Is ARM support planned? A raspi seems like the perfect target for this.
  - capableweb 4y ago
    The page for APE (https://justine.lol/ape.html https://justine.lol/ape.html) says the following about ARM: > It'll be nice to know that any normal PC program we write will "just work" on Raspberry Pi and Apple ARM. All we have to do embed an ARM build of the emulator above within our x86 executables, and have them morph and re-exec appropriately, similar to how Cosmopolitan is already doing doing with qemu-x86_64, except that this wouldn't need to be installed beforehand. The tradeoff is that, if we do this, binaries will only be 10x smaller than Go's Hello World, instead of 100x smaller. The other tradeoff is the GCC Runtime Exception forbids code morphing, but I already took care of that for you, by rewriting the GNU runtimes. Also this, from a GitHub issue (https://github.com/jart/cosmopolitan/issues/354#issuecomment-1125306493 https://github.com/jart/cosmopolitan/issues/354#issuecomment...): > Probably related to #399. The recommended approach would be to use a full emulator like Bochs. It's not something we use at the moment so we can't provide support on this. Although we do intend to have APE support ARM at some point in the future.
    - unsafecast 4y ago
      Thank you!
- csdvrx 4y ago
  > That's correct. Redbean is already capable of booting on bare metal. We do what we must because we can. I love the spirit :) > The main blocker is figuring out how to get an e1000 and/or VirtIO driver in there with a TCP/IP stack. Why? Is it for performance reasons or security reasons? (or both) > Right now Cosmopolitan bare metal support is only adequate for stdio applications, which use the serial port and read from the zip fs. I'd suggest you "think different", and use instead something like ppp to create a TCP/IP stack over a serial link. Modern btuart implementations already routinely achieve >1Mbps on commercial devices. The GSI as seen on the Intel Serial IO devices support bitrates over 20Mbps. This could buy you time until you find a better solution, if it's ever needed (which I doubt as back of the envelope estimations make me believe you'll hit other limitations before)
  - jart 4y ago
    It's less about perf/security and more to do with simply needing the time to wrap my head around how to do it. Entering ring0 is a whole different world. My productivity depends on a responsive TDD workflow and it's hard to test kernel code. I currently do it using an emulator I wrote called Blinkenlights, because the existing ones (Bochs and QEMU) couldn't be integrated into my Makefile / Emacs build system. So I not only need to build the kernel but I need to emulate the CPU features the kernel needs too.
    - csdvrx 4y ago
      > It's less about perf/security and more to do with simply needing the time to wrap my head around how to do it. I can have a look at using ppp for creating a network connection using stdio. It doesn't look very complicated. > it's hard to test kernel code Exactly why I suggest pppd (userland) instead of VFIO > So I not only need to build the kernel but I need to emulate the CPU features the kernel needs too You have stdio? No need for anything else.

c-linkage 4y ago

I can't edit my comment (maybe I waited too long?) so I'll add more here... My comment about not knowing if running redbean on bare metal was sarcasm was a comment about me, not about redbean or Justine, so no disrespect intended. There's a lot of "turtles all the way down" today (a web server compiled to WASM so it runs in a browser running on a OS hosted in QEMU that's running on another host OS that's a virtual machine running in a linux container on top of a hypervisor running on an X86 simulator...) so I quite honestly couldn't tell if the idea of running redbean on bare metal was sarcasm or a joke. But Justine says its true, so I guess it's not a joke. Consider me schooled.

jart 4y ago
I agree because the whole point of being able to run on metal is to have fewer turtles. How many vendors control the space between your code and your computer? Who controls your memory? I think those are questions worth asking. My goal is simply to help people get closer to the source.