[0] https://www.ftc.gov/business-guidance/resources/ftcs-endorse...
It's part of the terms of service of a number of social networks, I can almost see how someone might confuse that for the law. If I squint.
I agree with you, that ad is placed in a odd place. It looks so out of place, I would believe it was copy-pasted there by mistake, if it weren't for the HTML link.
Project has been dead for many years now btw.
I might add RISC-V support myself, as I am the author of libriscv. We'll see.
Code doesn't die. Especially code targetting the c abi.
But... "So IncludeOS can compile C and C++ applications natively. Currently, these are the only programming languages supported. We’ll add support for other language runtimes in 2019."
Last blog update is 2019. Is the project still alive?
edit: github shows recent activity, so it is encouraging.
(Ok this leaves out Go but they picked their path)
Besides, supporting c++ must be a goddamn nightmare.
I don't know. Then again I had my mandatory lobotomy when I started to professionally program in C++ 20 years ago (and still do to this day).
Everything about JavaScript WATs applies equally well to C.
An interesting example would be GRiSP where Erlang's BEAM was ported to an Arm Cortex M7 microcontroller with 64 MB of external RAM. https://www.grisp.org/
And actually, x86 started life as an embedded processor :)
I know you can run BSD on AWS for example.
So for the cost of <1 core and a small amount of RAM>, you get full Linux, full debuggability, SSH, file systems, networking, etc. and your app still runs as fast as it can on the CPU.
Spend your innovation budget on your app, not the OS.
Then again, you can run a linux vm on one core and your unikernel app on the other cores on top of an hypervisor.
This page is much better, telling me how it is different/interesting https://www.includeos.org/technology.html
[1] https://github.com/cloudius-systems/osv
[2] https://osv.io/
If you need real-time low-latency, you don't want any virtual hardware.
I'm not sure what's the practical application here. Either you use containers because you have complex dependencies so you want to just package the whole thing in isolation, or you don't and you might as well run as a normal process. Here you have a simple self-contained executable image anyway.
But to be honest I never understood the point of virtualization.
It feels like so much of the world focuses on docker images that alternatives are pretty hard to get going.
EDIT: I see, their GH page actually uses this term, but this landing page does not.
> Node.js-style callback-based programming - everything happens in one efficient thread with no I/O blocking or unnecessary guest-side context switching.
> No race conditions. Delegated IRQ handling makes race conditions in “userspace” “impossible”. …unless you implement threads yourself (you have the access) or we do.
