[hugelgupf]

The number of system calls says close to nothing of the actual API surface present here. It's a poor measure. What actually matters is: what can I run?

That said, 42 is not enough to run a lot of applications.

It'll be interesting to get to the point where they can run a language's runtime or unit tests.

Take it from someone who worked on gVisor: this is gonna take a long time, and eventually you'll end up with a system that's just Linux. You'll end up either being bug-for-bug compatible, which means bringing in loads of compatibility code and architecting your kernel just like Linux, or you'll end up having to change applications (and then you're not all that compatible anymore).

Neither are fun or sustainable compatibility stories. You'd probably actually get Linux apps to work on a random OS faster & nicer by porting gVisor.

> Moreover, since implementing a system call is typically pretty simple [...]

You're in for a fun ride, folks.

[perbu]

(I work for Includeos)

I don't think we need to run everything. I think we'll be happy if we can take some common libraries and compile them and they work. That is currently our goal. Down the road, depending on interest, we can perhaps expand a bit.

>> Moreover, since implementing a system call is typically pretty simple [...]

> You're in for a fun ride, folks.

Thanks for the heads up. It was meant as opposed to implementing the syscall and layers on top of it.

[hugelgupf]

That sounds much more attainable than what the blog post suggested - sorry if I took that the wrong way!

[perbu]

No worries. I never meant for the blogpost to reach an audience outside of our pretty narrow knitting circle so I didn't pay much attention to detail. I very much appreciate your insights here.

[hugelgupf]

Given what I just read about IncludeOS (I'm not really familiar), it feels like implementing as much of musl as possible is probably the best you can do compatibility wise. There are going to be a lot of Linux features simply incompatible with includeOS, so claiming that 400 syscalls will be implemented is unlikely.

That said - why do you have to get musl compatibility by implementing the Linux syscalls? Is contributing to musl an option?

[perbu]

Your assumption is correct. IncludeOS will never be fully compatible with Linux. Our goal is to provide "just enough POSIX" so that the applications that are relevant for the OS will compile and run. Mostly we're concerned with various "gateway-like" applications - firewalls, load balancers and down the line also IoT-gateways.

Wrt. to why we have to implement Linux-like syscalls; Musl is written specifically for Linux so in order to "unlock" the relevant POSIX-bits that Musl can provide we have to provide the underpinnings that Musl requires.

I'm hoping we can upstream some of our non-intrusive changes to Musl. However since Musl has a very specific purpose (a Linux-specific C and POSIX library) I'm not certain that our changes are within the scope of the project. To date we've only concerned ourselves with a small subset of Musl and only on amd64.

[DSingularity]

Do you recommend gvisor over dune or kata containers?