3 ms·

This looks great, but I'm wary of projects that sound this great but don't include a "downsides" section. I'd love to know what the tradeoffs are, so I don't ha

This looks great, but I'm wary of projects that sound this great but don't include a "downsides" section. I'd love to know what the tradeoffs are, so I don't have to spend time discovering them myself. Please consider adding a section like that.

tomashubelbauer 7y ago
They link to one: > A longer list of features and limitations can be found on our documentation site. But unfortunately it looks like the linked page doesn't actually talk about limitations :) Unless you consider a warning about hlt-ing yourself in the foot a list of limitations I guess.
- fwsgonzo 7y ago
  Some downsides then: - You can't just port anything to IncludeOS. Since you have direct hardware control and you can schedule work directly to numbered CPUs you can take advantage of things, but if you don't do that then you are just living in a limited C++ environment. - The network stack hasn't been built with multiprocessing in mind, and some parts need to be rebuilt because of that - There are codepaths that could lead to C++ exceptions, such as being out of memory, which trounces performance. - There is a paging and memory allocation system in the OS which doesn't have to be there (for example paging can be "burned in" to the image for the most part, while only leaving room for adding pages for stacks. Memory can be handled by donating everything to the C standard library) - the goal being to keep the attack surface lower. - Debugging is hard - you will have to connect to GDB while pausing somewhere in the OS. This is really just me thinking out loud. Add salt.
MaxBarraclough 7y ago
There was a damning security paper (not peer-reviewed) about IncludeOS, a few months ago. It turned up on HN: https://news.ycombinator.com/item?id=19738905 https://news.ycombinator.com/item?id=19738905 I don't know whether things have improved since then.

tomashubelbauer 7y ago

They link to one: > A longer list of features and limitations can be found on our documentation site. But unfortunately it looks like the linked page doesn't actually talk about limitations :) Unless you consider a warning about hlt-ing yourself in the foot a list of limitations I guess.

fwsgonzo 7y ago
Some downsides then: - You can't just port anything to IncludeOS. Since you have direct hardware control and you can schedule work directly to numbered CPUs you can take advantage of things, but if you don't do that then you are just living in a limited C++ environment. - The network stack hasn't been built with multiprocessing in mind, and some parts need to be rebuilt because of that - There are codepaths that could lead to C++ exceptions, such as being out of memory, which trounces performance. - There is a paging and memory allocation system in the OS which doesn't have to be there (for example paging can be "burned in" to the image for the most part, while only leaving room for adding pages for stacks. Memory can be handled by donating everything to the C standard library) - the goal being to keep the attack surface lower. - Debugging is hard - you will have to connect to GDB while pausing somewhere in the OS. This is really just me thinking out loud. Add salt.

MaxBarraclough 7y ago

There was a damning security paper (not peer-reviewed) about IncludeOS, a few months ago. It turned up on HN: https://news.ycombinator.com/item?id=19738905 https://news.ycombinator.com/item?id=19738905 I don't know whether things have improved since then.