|
|
|
|
|
|
by tomashubelbauer
2358 days 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. |
|
|
- 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.