Hacker News Reader

Comment by jart | Hacker News Reader

We're working on improving our bare metal support. Once we embed a TCP/IP stack your redbean will optionally be able to run as its own autonomous operating system with the absolute lowest network latency and minimal attack surface area. It's a idea whose time has come now that everything runs under a hypervisor in the cloud. If the hypervisor is the new operating system, then it'd be nice to not need a second operating system too.

View on HN

I love your work! How do you find the time to work on readbean/ape/etc? I sponsor you on github, but surely donations pale in comparison to what you could earn at an engineering day job.

Do you plan on writing your own tcp/ip stack with cosmopolitan? Why not pull in the networking stack and syscall libraries from MirageOS?

It's not so much could but have. I used to work at Google Brain. I decided I'd rather be doing this instead. I make it work by living modestly, eating ramen, and avoiding doctors. Thank you for sponsoring me! It helps a lot.

I have really enjoyed your submissions in the past year. Just sponsored you on Github. I feel like your work is of sufficient excellence and utility that you shouldn't need to eat unhealthy food to get by. Have you considered applying for grants from the non-profit arms of big tech companies? I do think that if you can combine Python in redbean in a seamless way, it would really drive adoption and lead to more sponsors for your work. Anyway, thanks for many hours of entertainment watching blinking lights.

I'll certainly consider it. Are there any in particular you'd recommend?

Something different entirely, but look at https://www.mercatus.org/emergent-ventures

I don't know much about the subject, but some quick searching leads me to believe that the first step is to create a legal non-profit entity, since that looks to be a requirement for all these big companies to dispense grant money. I think it costs a fair amount of money in fees and legal help to make a 501c3, so maybe you can do a Gofundme to raise the money for that (or ask for help from lawyers). Once you have the entity set up with you and people you trust in control, you can write a basic grant proposal, which wouldn't look that different from the articles you've already written explaining the project and the benefits. Then you can customize this with an addendum that responds to specific questions for each grant request application. And then send it to any organizations you can find that seem like good fits. I'm not a lawyer (and this isn't legal advice), but if you can get enough funding, perhaps you can "hire yourself" as the first contractor to the organization (I don't know if this runs afoul of the rules). I guess it's a lot of work if you've never done it before. Your best bet would be to find someone who has done this a bunch of times (maybe someone associated with the Internet Archive or something) who can help put it together for you.

Well that might put grants off the table. I'm not starting an NGO. There are better ways for corporations to support our work.

I’ve been part of over 5 501(c)3 and 501(c)6 startups and unless something drastic has changed in the last few years since COVID, it is not that expensive (well under 1k). Consult with someone who does nonprofit creation and they will let you know what 501(c)X that the effort would best be described as and absolutely shouldn’t break the bank.

Better get your Redbean As A Service business plan going

> minimal attack surface area

Just double-checking--it is still written in c?

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

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

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.

For the good of all of us! Except the ones who are dead.

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.

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!

That sounds amazing, I love your work! Is ARM support planned? A raspi seems like the perfect target for this.

The page for APE (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...):

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

Thank you!

> 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)

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.

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

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.

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.

Reply on news.ycombinator.com