Live data from Hacker News

Linux compatibility in IncludeOS

includeos.org

11–20 of 36 posts

Re: Linux compatibility in IncludeOS

#11
post #3

Claiming that they've "implemented" 42 syscalls seems like an overstatement: almost everything is a stub that does nothing, and the bits that are implemented are not even close to being half-baked. Even relatively easy stuff like dup is missing.

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 sys…

(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.

Re: Linux compatibility in IncludeOS

#13
post #11

Earlier quoted context omitted.

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 sys…

(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 imp…

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

Re: Linux compatibility in IncludeOS

#15
This is an exciting development that I am watching closely.

It should be noted that whatever the limits of the 42 system calls, network operations are very well supported. Many useful programs hardly need anything else.

Re: Linux compatibility in IncludeOS

#17
post #3

Claiming that they've "implemented" 42 syscalls seems like an overstatement: almost everything is a stub that does nothing, and the bits that are implemented are not even close to being half-baked. Even relatively easy stuff like dup is missing.

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 sys…

Do you recommend gvisor over dune or kata containers?

Re: Linux compatibility in IncludeOS

#18
post #12

So, what's wrong with newlib?

Nothing; it is just much smaller by not providing POSIX and Linux like interfaces.

Alpine proves full musl can already run a full distro's worth of programs and is very easy to port anything using glibc.

Newlib tends to be used in projects like Cygwin as a small C standard library, where the rest of the POSIX API is implemented separately (by proxying to Win32 system calls for Cygwin).

Re: Linux compatibility in IncludeOS

#20

I'm pretty ignorant on Unikernels so maybe there's another solution, but not being able to `fork()` is a significant problem for many applications.

My understanding is that unikernels are single-application by design. I agree that a mechanism to spawn other apps is useful, but in this case it won't be a simple fork but the creation of a complete new os instance.

I suspect GP is referring to single applications that aren't single process. Postgres is one example. Vacuum and checkpoint are separate processes.

Applications also sometimes have separate processes for sentinal functions, logging, etc. Or default configurations that are multi process, like many load balancers, web servers, API gateways, etc.

Post reply on HN