Live data from Hacker News

Show HN: Redbean – Single-file distributable web server

justine.lol

131–140 of 264 posts

Re: Show HN: Redbean – Single-file distributable web server

#131

TLDR: This is a packed file format that can look to the OS as being executable (for Windows/Linux/OSX). The code is x86 and so offers native performance on those processors. On other platforms, an x86 emulator is built in so can't offer native execution speeds. While neat, its not the "best of all worlds" due to the lack of native code on anything other than x86/x64. Also, claiming "bare metal" is supported is a stre…

No I/O eh?

I'm sure the FP zealots will love it :-)

Re: Show HN: Redbean – Single-file distributable web server

#132
post #9

.apk files and .ipa files are secretly zip files too. With the addition of a few manifest files and other crufty things embedded in the zip, I bet you could add Android and iOS to the list of supported platforms too.

Jars, rpms, whls, Microsoft Office, probably a bunch of other stuff I don’t even know about are actually zip files.

Re: Show HN: Redbean – Single-file distributable web server

#134
post #55

Earlier quoted context omitted.

Author here. That error happens if you have binfmt_misc enabled. The solution is simple: sudo sh -c "echo ':APE:M::MZqFpD::/bin/sh:' >/proc/sys/fs/binfmt_misc/register" I intend to upstream a patch with the Linux kernel so it can do this automatically. If any kernel devs are reading, please email me!

Instead of sudo sh -c to sudo the redirects, consider echo 'abcde' |sudo tee /proc/bla. Less nesting :)

Do you mean less syntactical nesting? The pipe to sudo tee creates a new child shell, just as sudo sh -c does.

Re: Show HN: Redbean – Single-file distributable web server

#137

TLDR: This is a packed file format that can look to the OS as being executable (for Windows/Linux/OSX). The code is x86 and so offers native performance on those processors. On other platforms, an x86 emulator is built in so can't offer native execution speeds. While neat, its not the "best of all worlds" due to the lack of native code on anything other than x86/x64. Also, claiming "bare metal" is supported is a stre…

I'm just one woman. What Cosmopolitan does so far, it does really well. It was only as recently as a few days ago that I got mmap() and malloc() polyfilled on bare metal. It has serial uart i/o. It's going to have e1000/virtio sockets soon. You can help me will that future into existence. I need people who know o/s dev and can help me write code that does things like correctly set up pic controller.

Re: Show HN: Redbean – Single-file distributable web server

#138
post #64

Earlier quoted context omitted.

Author here. Thanks! I was deeply inspired when I read the source code to early versions of Linux and UNIX. The dream of that simple elegant power is something I'm hoping to restore for a new generation. All I'm doing to achieve that is simply standing on the shoulders of the giants who came before me.

Have you considered trying to make system calls inline to avoid the call overhead? Or already thought about it? I've been banging my head against the wall of trying to make a micro KVM guest and the glibc startup code uses inline SYSCALL everywhere, I assume to make things faster. It does seem to call CPUID a lot too, but I guess it's not as expensive as having to make full-blown system calls.

Cosmopolitan defines linkable symbols for all the __NR_syscall constants so you can absolutely use inlining if you like to live dangerously. For example: https://github.com/jart/cosmopolitan/blob/91f4167a45f811fde6... There really isn't any performance advantage to doing this, because the SYSCALL instruction itself has something like a 2000+ cycle cost due to all the copying that needs to happen on the kernel side along with things like spectre mitigations which have made is slower. So the 8 cycle cost of having a normal read() function wrapper is the wrong thing to be focusing on. Cosmopolitan aims to address the performance cost of SYSCALL by making it possible to run your binary on bare metal, where your program becomes a kernel, and therefore needn't pay any context switching costs at all.

Re: Show HN: Redbean – Single-file distributable web server

#139

Just make sure you don't have another server running on :8080. I had syncthing running and kept getting some error whenever I tried to run redbean. The error didn't make much sense, but eventually I realised that this was the casue of the error. I'm really impressed how portable this is. The only improvement I can see is if it auto-opened your browser to :8080. That way it would be easy to distribute the binary and h…

I think you could trivially issue a system() call, you'd just have to use the corresponding command to open the default browser for each particular system. (Linux: xdg-open, MacOs: open, Windows: start)

Re: Show HN: Redbean – Single-file distributable web server

#140
post #138

Earlier quoted context omitted.

Have you considered trying to make system calls inline to avoid the call overhead? Or already thought about it? I've been banging my head against the wall of trying to make a micro KVM guest and the glibc startup code uses inline SYSCALL everywhere, I assume to make things faster. It does seem to call CPUID a lot too, but I guess it's not as expensive as having to make full-blown system calls.

Cosmopolitan defines linkable symbols for all the __NR_syscall constants so you can absolutely use inlining if you like to live dangerously. For example: https://github.com/jart/cosmopolitan/blob/91f4167a45f811fde6... There really isn't any performance advantage to doing this, because the SYSCALL instruction itself has something like a 2000+ cycle cost due to all the copying that needs to happen on the kernel side al…

And it's even more overhead when exiting a VM, then?
Post reply on HN