Given that this is (AFAICT) a way to efficiently run exactly one program on a machine (probably a VM), I would have liked to see more time spent on the particulars of getting a program running on it. Like, can you easily run existing software on BareMetal? Could you compile nginx to run on it? Or does software have to be written specifically for this environment? And either way, how exactly do you actually build your software for/into(?) the image?
I would think that with a bit of work, it should be possible to implement a baseline for a language like Rust or Go to target that environment with a "bare" application that may or may not have a direct filesystem interface to use.
Which could be pretty nice. Just Enough OS, so to speak.
Sorry this might be an extremely stupid question, but can you please explain the benefits of this and what other (larger?) alternatives are?
I understand that this "exokernel" provides more performant hardware access for software and it seems to be written from scratch in assembler.
Does this mean that one should expect a lot of security and robustness issues, which means it should only be used for internal services and never be exposed to untrusted networks?
One thing that comes to mind is latency in a HPC context.
If you can fit your entire software stack into L3 cache, you never have to access memory and benefit from insanely good latency.
This was a thing in HFT like ~5-7 years ago, where you might have bought a 28 core Xeon, disable all but one or two cores and benefit from ~30mb L3 cache, which can fit an entire Linux Kernel, an SSH server and your trading software.
If one decides to boot an arbitrary system, pointing at whatever would be the latest version of exec.asm, it doesn't even matter what the project is today and whatever the setup script is doing.
If one chooses to use this, one decides to handover the virtual machine ownership. Your system is whatever OP decides, now or in the future.
Edit: made a clear mistake here. One would clearly not be booting on lates version of exec.asm.
It would be libBareMetal.asm instead.
Sorry for confusion guys, totally safe and effective
Wow, that's some nostalgia for me. I remember encountering BareMetalOS and its bootloader Pure64 back when I still lurked the OSDev.org forums, probably more than 15 years ago at this point. Glad to see you're still at it!
Given that this is (AFAICT) a way to efficiently run exactly one program on a machine (probably a VM), I would have liked to see more time spent on the particulars of getting a program running on it. Like, can you easily run existing software on BareMetal? Could you compile nginx to run on it? Or does software have to be written specifically for this environment? And either way, how exactly do you actually build your software for/into(?) the image?
You can’t run most Unix/Linux apps without porting.
https://github.com/ReturnInfinity/BareMetal-Examples/blob/ma...
The plan is to get existing *nix programs ported over, yes. That will require some more work (ideally a compatibility layer/library).
I would think that with a bit of work, it should be possible to implement a baseline for a language like Rust or Go to target that environment with a "bare" application that may or may not have a direct filesystem interface to use.
Which could be pretty nice. Just Enough OS, so to speak.
Sorry this might be an extremely stupid question, but can you please explain the benefits of this and what other (larger?) alternatives are?
I understand that this "exokernel" provides more performant hardware access for software and it seems to be written from scratch in assembler.
Does this mean that one should expect a lot of security and robustness issues, which means it should only be used for internal services and never be exposed to untrusted networks?
One thing that comes to mind is latency in a HPC context.
If you can fit your entire software stack into L3 cache, you never have to access memory and benefit from insanely good latency.
This was a thing in HFT like ~5-7 years ago, where you might have bought a 28 core Xeon, disable all but one or two cores and benefit from ~30mb L3 cache, which can fit an entire Linux Kernel, an SSH server and your trading software.
If one decides to boot an arbitrary system, pointing at whatever would be the latest version of exec.asm, it doesn't even matter what the project is today and whatever the setup script is doing. If one chooses to use this, one decides to handover the virtual machine ownership. Your system is whatever OP decides, now or in the future.
Edit: made a clear mistake here. One would clearly not be booting on lates version of exec.asm. It would be libBareMetal.asm instead.
Sorry for confusion guys, totally safe and effective
if [ -x "$(command -v curl)" ]; then curl -s -o libBareMetal.asm https://raw.githubusercontent.com/ReturnInfinity/BareMetal/m... else wget -q https://raw.githubusercontent.com/ReturnInfinity/BareMetal/m... fi
Does look alien. When Going to http://baremetal.returninfinity.com/ one can only see some b0rken plaintext in the browser:
Wow, that's some nostalgia for me. I remember encountering BareMetalOS and its bootloader Pure64 back when I still lurked the OSDev.org forums, probably more than 15 years ago at this point. Glad to see you're still at it!
Could you provide a link to a libc equivalent for this?
I was hoping for some documentation on how to get networking but I can't find anything immediately in the README
Newlib has been ported: https://github.com/ReturnInfinity/BareMetal-newlib4
Is there a system call reference somewhere?