3 ms·

> The biggest problem with Unikernels like Mirage is the single language constraint Do you write all your software in C? Of course not. The single language con

by _wmd 11y ago

> The biggest problem with Unikernels like Mirage is the single language constraint Do you write all your software in C? Of course not. The single language constraint doesn't exist, for the same reasons we can write Go software that runs on the Linux kernel

lmm 11y ago
Non-C programs on Linux either implement the C ABI (or the Linux system call interface) or run via interpreters that do. Can your preferred language link to the OCaml ABI? Do you have an interpreter written in OCaml for it?
- Guvante 11y ago
  Are we talking about microservices that talk over TCP of some sort? If that is the case it is a moot point as the other end need not even compile against a unikernel at all, it can sit on a traditional OS.
  - nickpsecurity 11y ago
    Exactly. They seem to be creating unsolvable, strawman problems instead of assuming we start with the middleware approach to getting things to work together. And there's both very efficient and very robust tooling available for that these days.
  - lmm 11y ago
    No, we're talking about running things under unikernels. I mean yes, you could have some of your app implemented in OCaml and then it talks over TCP to some Fortran running on Linux to do linear algebra, but that approach has its own problems.
    - Guvante 11y ago
      You are splitting the problem at the wrong place. Microservices is a well known thing and is what is providing the fire under unikernel research, you cannot simply ignore the aspect of "do the hard thing in a different environment" when talking about microservices.
      - lmm 11y ago
        IMO the popularity of microservices is a lot more about languages that provide very weak isolation guarantees (i.e. Ruby). OCaml is a strongly typed language with an excellent module system, and so microservices offer relatively little value.
- kryptiskt 11y ago
  It's much easier than you think. OCaml can expose functions with a C ABI. You can put newlib on top of MirageOS, calling down to OCaml for basics (and newlib needs only a handful of IO and memory functions to be provided, so it isn't particularly hard), and then you have instant POSIX. Now you can run most anything you want from C-land.
- pjmlp 11y ago
  That is no different from the days C was only meaningful to UNIX users. The languages have to implement the OS ABI, whatever that is. Lisp Machines had Fortran, Ada and C compilers available.
geofft 11y ago
But the entire point is that unikernels aren't like the Linux kernel, that there isn't a userspace/kernelspace boundary in the way that there is on Linux and other traditional OSes. From the paper (http://unikernel.org/files/2013-asplos-mirage.pdf http://unikernel.org/files/2013-asplos-mirage.pdf): > We present unikernels, a new approach to deploying cloud services via applications written in high-level source code. Unikernels are single-purpose appliances that are compile-time specialised into standalone kernels, and sealed against modification when deployed to a cloud platform. In return they offer significant reduction in image sizes, improved efficiency and security, and should reduce operational costs. Our Mirage prototype compiles OCaml code into unikernels that run on commodity clouds and offer an order of magnitude reduction in code size without significant performance penalty. > An important decision is whether to support multiple languages within the same unikernel. [...] The alternative is to eschew source-level compatibility and rewrite system components entirely in one language and specialise that toolchain as best as possible. [...] existing non-OCaml code can be encapsulated in separate VMs and communicated with via message-passing [...] > We did explore applying unikernel techniques in the traditional systems language, C, linking application code with Xen MiniOS, a cut-down libc, OpenBSD versions of libm and printf, and the lwIP user-space network stack. That is, there is absolutely a single language constraint, on purpose, as arguably the primary differentiation from non-unikernels.
- _wmd 11y ago
  Just because some concrete system call interface is missing doesn't mean you can't glue layers of code together from different languages, that's some logical jump I don't understand. The single language constraint you're continuing to claim exists is addressed by their own blog posts: https://mirage.io/blog/modular-foreign-function-bindings https://mirage.io/blog/modular-foreign-function-bindings . After reading this, I can see approximately 50 lines code that would let me run a Python interpreter (another mostly memory-safe language, btw) within the unikernel, assuming enough of the Unix syscall interface was already implemented in shims back into OCaml land, something I presume will likely be released in the coming months in preparation for making their stuff useful to the general public.
  - 11y ago

by _wmd 11y ago

lmm 11y ago

Non-C programs on Linux either implement the C ABI (or the Linux system call interface) or run via interpreters that do. Can your preferred language link to the OCaml ABI? Do you have an interpreter written in OCaml for it?

Guvante 11y ago
Are we talking about microservices that talk over TCP of some sort? If that is the case it is a moot point as the other end need not even compile against a unikernel at all, it can sit on a traditional OS.
- nickpsecurity 11y ago
  Exactly. They seem to be creating unsolvable, strawman problems instead of assuming we start with the middleware approach to getting things to work together. And there's both very efficient and very robust tooling available for that these days.
- lmm 11y ago
  No, we're talking about running things under unikernels. I mean yes, you could have some of your app implemented in OCaml and then it talks over TCP to some Fortran running on Linux to do linear algebra, but that approach has its own problems.
  - Guvante 11y ago
    You are splitting the problem at the wrong place. Microservices is a well known thing and is what is providing the fire under unikernel research, you cannot simply ignore the aspect of "do the hard thing in a different environment" when talking about microservices.
    - lmm 11y ago
      IMO the popularity of microservices is a lot more about languages that provide very weak isolation guarantees (i.e. Ruby). OCaml is a strongly typed language with an excellent module system, and so microservices offer relatively little value.
kryptiskt 11y ago
It's much easier than you think. OCaml can expose functions with a C ABI. You can put newlib on top of MirageOS, calling down to OCaml for basics (and newlib needs only a handful of IO and memory functions to be provided, so it isn't particularly hard), and then you have instant POSIX. Now you can run most anything you want from C-land.
pjmlp 11y ago
That is no different from the days C was only meaningful to UNIX users. The languages have to implement the OS ABI, whatever that is. Lisp Machines had Fortran, Ada and C compilers available.

geofft 11y ago

But the entire point is that unikernels aren't like the Linux kernel, that there isn't a userspace/kernelspace boundary in the way that there is on Linux and other traditional OSes. From the paper (http://unikernel.org/files/2013-asplos-mirage.pdf http://unikernel.org/files/2013-asplos-mirage.pdf): > We present unikernels, a new approach to deploying cloud services via applications written in high-level source code. Unikernels are single-purpose appliances that are compile-time specialised into standalone kernels, and sealed against modification when deployed to a cloud platform. In return they offer significant reduction in image sizes, improved efficiency and security, and should reduce operational costs. Our Mirage prototype compiles OCaml code into unikernels that run on commodity clouds and offer an order of magnitude reduction in code size without significant performance penalty. > An important decision is whether to support multiple languages within the same unikernel. [...] The alternative is to eschew source-level compatibility and rewrite system components entirely in one language and specialise that toolchain as best as possible. [...] existing non-OCaml code can be encapsulated in separate VMs and communicated with via message-passing [...] > We did explore applying unikernel techniques in the traditional systems language, C, linking application code with Xen MiniOS, a cut-down libc, OpenBSD versions of libm and printf, and the lwIP user-space network stack. That is, there is absolutely a single language constraint, on purpose, as arguably the primary differentiation from non-unikernels.

_wmd 11y ago
Just because some concrete system call interface is missing doesn't mean you can't glue layers of code together from different languages, that's some logical jump I don't understand. The single language constraint you're continuing to claim exists is addressed by their own blog posts: https://mirage.io/blog/modular-foreign-function-bindings https://mirage.io/blog/modular-foreign-function-bindings . After reading this, I can see approximately 50 lines code that would let me run a Python interpreter (another mostly memory-safe language, btw) within the unikernel, assuming enough of the Unix syscall interface was already implemented in shims back into OCaml land, something I presume will likely be released in the coming months in preparation for making their stuff useful to the general public.
- 11y ago