Includeable minimal operating system for C++(includeos.org)
includeos.org
Includeable minimal operating system for C++
https://www.includeos.org/
49 comments
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
Is it a legal requirement? I thought it (disclaiming ads) was something one did to avoid the proverbial pitchforks and nothing more.
The FTC has guidance on when it considers a compensated endorsement to be "deceptive advertising", which is something they can legally enforce. [0]
[0] https://www.ftc.gov/business-guidance/resources/ftcs-endorse...
[0] https://www.ftc.gov/business-guidance/resources/ftcs-endorse...
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.
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.
> This seems like a farce. Most advertising in america is deceptive.
Yes, that's because many of the regulatory and consumer protection agencies are neutered by illegal businesses.
Yes, that's because many of the regulatory and consumer protection agencies are neutered by illegal businesses.
16 CFR Part 255 Guides Concerning the Use of Endorsements and Testimonials in Advertising https://www.ftc.gov/sites/default/files/attachments/press-re...
There is no such legal requirement whatsoever.
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.
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.
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.
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.
The members seem to mostly be from Norway and Norway has a law against "hidden" advertising, which I believe applies here.
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.
@dang can change the URL to https://github.com/includeos/IncludeOS
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.
Project has been dead for many years now btw.
Project has been dead for many years now btw.
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.
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...
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.
> Project has been dead for many years now btw.
Code doesn't die. Especially code targetting the c abi.
Code doesn't die. Especially code targetting the c abi.
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.
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.
A game server could perhaps be another valid use case for this technology. A simple program, performance maximized, cost minimized.
Isn't this what's more typically called a unikernel?
EDIT: I see, their GH page actually uses this term, but this landing page does not.
EDIT: I see, their GH page actually uses this term, but this landing page does not.
Reminds me of Cosmopolitan C Compiler / Actually Portable Executables.
This 2016 podcast discusses this in depth:
https://cppcast.com/alfred-bratterud/
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.
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.
You get another layer of address space separation.
Then again, you can run a linux vm on one core and your unikernel app on the other cores on top of an hypervisor.
Then again, you can run a linux vm on one core and your unikernel app on the other cores on top of an hypervisor.
Sounds neat but very minimal:
> 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.
> 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.
Oh this is wildly cool! Do cloud providers like aws allow you to upload a custom system image to run as a vm?
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.
My information is probably out of date but historically yes. Also historically operating systems other than Linux were pretty iffy.
I know you can run BSD on AWS for example.
I know you can run BSD on AWS for example.
[deleted]
so is anyone actually using it?
[deleted]
Very cool.
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:
https://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf
https://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf
Pretty cool way to turn x86es into embedded machines.
For a similar embedded RTOS there is RTEMS https://www.rtems.org/ https://en.wikipedia.org/wiki/RTEMS
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/
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/
Checkout https://osdev.org
And actually, x86 started life as an embedded processor :)
And actually, x86 started life as an embedded processor :)
Ah, much simpler than I anticipated. Thank you for sharing
This seems very interesting!
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.
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.
(Ok this leaves out Go but they picked their path)
Besides, supporting c++ must be a goddamn nightmare.
> who the hell with two neurons to rub together uses C++ anymore?
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).
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).
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.
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.
> I just find it very difficult to imagine a C++ programmer I'd trust as much as the rust compiler.
It's even more difficult to imagine a javascript programmer I'd trust more than any C++ compiler.
It's even more difficult to imagine a javascript programmer I'd trust more than any C++ compiler.
How is that relevant? Who is suggesting replacing c++ with javascript?
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++.
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++.
[deleted]
Lets put it this way, C++ is C's Typescript.
Everything about JavaScript WATs applies equally well to C.
Everything about JavaScript WATs applies equally well 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.
It feels like so much of the world focuses on docker images that alternatives are pretty hard to get going.
I found the linked page very confusing, the whole page just say some generic unikernel stuffs
This page is much better, telling me how it is different/interesting https://www.includeos.org/technology.html
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/
[3] https://seastar.io/