4 ms·

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

by kitd 4y ago

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.

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

by 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.