Amazing how we've come full circle. Type II hypervisors treat VM guests as processes, so is it any wonder we've developed ways to develop them as processes? A paravirtualized VM is just a process with a different (and arguably better) system call interface.
The distinction started with rings of protection which was orthogonal to processes. Roger Schell said the guy who designed the one for Intel’s 286 had security kernels like GEMSOS in mind. Here’s GEMSOS and STOP so you can see how they did that back in the 1980’s:
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/
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 but the C abi includes basically all languages. Frankly they could toss C++ in the trash with basically zero impact to their value because who the hell with two neurons to rub together uses C++ anymore?
(Ok this leaves out Go but they picked their path)
Besides, supporting c++ must be a goddamn nightmare.
I agree that people still use C++, I just find it very difficult to imagine a C++ programmer I'd trust as much as the rust compiler. Hence my comment.
FWIW, I programmed C++ for 15 years—it's a useful tool, but it doesn't have much use anymore outside of legacy tooling, codebases, and developers who can't learn new things.
It's as relevant as someone suggesting replacing C++ with rust. They're both great languages, and one just happens to be memory unsafe. In C++ vs javascript, they're both great languages but one just happens to be type unsafe. Regardless, each language has its own target purposes. That's how it's relevant.
So:
> I just find it very difficult to imagine a C++ programmer I'd trust as much as the rust compiler
I don't think anybody could reasonably say that C++ from 20 years ago is competitive with rust particularly since rust wasn't around back then. But the C++ of today isn't what it was 20 years ago. C++ isn't a single revision of the language. There are many versions of the language. There's no reason a new version of C++ can't improve upon one of its weaknesses... or even some of its strengths. Whether that's by learning different techniques from other languages or building upon its own, it would take solid C++ engineers, not rust engineers, to improve the language.
I'm only saying: there are a lot of software engineers who treat software engineering as their day job (eg, little if perhaps any passion about the language) but there are also plenty, if perhaps a minority, of engineers with a passion for the language; and the language can evolve to be more safe and has continuously done so over the past 20 years and will continue to do so well into the future. Rust certainly has its passionate engineers too, and a lot of other engineers on the bandwagon because they don't have to learn hard things like how to design software well in the first place.
All that to say: having the a good compiler (rust or not) is great but it won't save you from a poorly experienced engineer's design. Poorly experienced engineers aren't exclusive to C++.
I've seen this come up here and elsewhere before, always very cool! I always wonder who's actually using it for production workloads, in what context, etc.
It feels like so much of the world focuses on docker images that alternatives are pretty hard to get going.
What's with the recommendation for a YouTube MP3 converter near the bottom? There seems to be no technological relation so I can only guess the author got paid to include it, but you're legally supposed to disclose if something is a paid ad
This seems like a farce. Most advertising in america is deceptive.
Edit: they seem to only enforce disclosure and they don't actually evaluate whether the ad is deceptive or not. Still this does seem to foreclose on the domain user in question's use of ads, if anyone cares
> If the advertiser doesn’t have proof that the endorser’s experience represents what people will generally achieve using the product as described in the ad (for example, by just taking a pill daily for two months), an ad featuring that endorser must make clear to the audience what the generally expected results of following that same regimen are.
Pathetic and spineless. If this were actually enforced 99.99% of ad claims would be illegal.
Is that a legal requirement where the owner of that website is?
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.
We are indeed Norwegian! The domain is owned by a squatter now. He wants EUR 3000 to release it back to us. It's simply too much right now. So, I wish that this HN post could change from the squatter URL to GitHub instead.
according to wayback machine the domain expired at the end of 2021. Months later it came back with the sneaky ad. Their page at github https://includeos.github.io/ does not have it. It is safe to assume whoever grabbed the domain has no association to the authors.
You're completely right. It's a squatter and he wants money. The project is not dead, however. It's currently used for research at University of Oslo, and I think we can expect much more activity in the coming years, such as ARM support.
I might add RISC-V support myself, as I am the author of libriscv. We'll see.
> You're completely right. It's a squatter and he wants money. The project is not dead, however. It's currently used for research at University of Oslo
If someone bought the domain and is re-using the same assets to put advertisements up then the author of includeos would have some real teeth in courts...
Yes, we have spoken to a lawyer and it is indeed the case. It still costs money, and we are not sure how to proceed yet, outside of removing links to the domain.
Absolutely. Everyone who deploys unikernels to the public clouds does this. Some are better fits than others. AWS for instance you can build an image and deploy an ec2 instance in a matter of seconds.
> 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.
It's cool, but this only runs with VirtIO hardware.
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.
There's almost no reason to do anything weird with operating systems today, because you can run Linux on a single core of your multi-core machine, and your app at full throttle (no context switching) on the remaining cores.
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.
49 comments
[ 5.4 ms ] story [ 121 ms ] threadhttps://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf
And actually, x86 started life as an embedded processor :)
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/
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).
FWIW, I programmed C++ for 15 years—it's a useful tool, but it doesn't have much use anymore outside of legacy tooling, codebases, and developers who can't learn new things.
It's even more difficult to imagine a javascript programmer I'd trust more than any C++ compiler.
So:
> I just find it very difficult to imagine a C++ programmer I'd trust as much as the rust compiler
I don't think anybody could reasonably say that C++ from 20 years ago is competitive with rust particularly since rust wasn't around back then. But the C++ of today isn't what it was 20 years ago. C++ isn't a single revision of the language. There are many versions of the language. There's no reason a new version of C++ can't improve upon one of its weaknesses... or even some of its strengths. Whether that's by learning different techniques from other languages or building upon its own, it would take solid C++ engineers, not rust engineers, to improve the language.
I'm only saying: there are a lot of software engineers who treat software engineering as their day job (eg, little if perhaps any passion about the language) but there are also plenty, if perhaps a minority, of engineers with a passion for the language; and the language can evolve to be more safe and has continuously done so over the past 20 years and will continue to do so well into the future. Rust certainly has its passionate engineers too, and a lot of other engineers on the bandwagon because they don't have to learn hard things like how to design software well in the first place.
All that to say: having the a good compiler (rust or not) is great but it won't save you from a poorly experienced engineer's design. Poorly experienced engineers aren't exclusive to C++.
Everything about JavaScript WATs applies equally well to C.
It feels like so much of the world focuses on docker images that alternatives are pretty hard to get going.
This page is much better, telling me how it is different/interesting https://www.includeos.org/technology.html
EDIT: I see, their GH page actually uses this term, but this landing page does not.
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.
[0] https://www.ftc.gov/business-guidance/resources/ftcs-endorse...
Edit: they seem to only enforce disclosure and they don't actually evaluate whether the ad is deceptive or not. Still this does seem to foreclose on the domain user in question's use of ads, if anyone cares
> If the advertiser doesn’t have proof that the endorser’s experience represents what people will generally achieve using the product as described in the ad (for example, by just taking a pill daily for two months), an ad featuring that endorser must make clear to the audience what the generally expected results of following that same regimen are.
Pathetic and spineless. If this were actually enforced 99.99% of ad claims would be illegal.
Yes, that's because many of the regulatory and consumer protection agencies are neutered by illegal businesses.
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.
If someone bought the domain and is re-using the same assets to put advertisements up then the author of includeos would have some real teeth in courts...
Code doesn't die. Especially code targetting the c abi.
I know you can run BSD on AWS for example.
> 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.
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.
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.
[1] https://github.com/cloudius-systems/osv
[2] https://osv.io/
[3] https://seastar.io/