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++.
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.
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.
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.
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:
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.
> 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.
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.
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/
This page is much better, telling me how it is different/interesting https://www.includeos.org/technology.html