3 ms·

interesting, although the old mantra of "hardware is cheap, developers are expensive" is still true. you could hire 10 perl/c/c++/javascript/php/etc dev with ea

by n0body 12y ago

interesting, although the old mantra of "hardware is cheap, developers are expensive" is still true. you could hire 10 perl/c/c++/javascript/php/etc dev with ease for your project, but struggle to find one ocaml dev. And even then your ocaml dev will need to know the mirage library, xen and have a good knowledge of way more stuff than your project scope that said, it's still really cool, but it's not something i'd use, and especially not in production

rjsw 12y ago
There is nothing stopping people from implementing something similar in other languages. The developer using this doesn't need to know anything about Xen, they just see a single address space system that runs their code.
- n0body 12y ago
  i didn't say there was, but it's still complicating the task. i'm not saying it isn't cool, but it's a very round about way of doing something, and as such it becomes more expensive in development time and skill required
  - amirmc 12y ago
    More roundabout than the current paradigm of duplicate Linux stacks and supporting services for DevOps just to get stuff deployed? That doesn't make sense to me. Your argument is actually "It seems very new. Not enough people know/use it. Therefore, I won't use it." -- which is fine, but please don't mischaracterise it in terms of increased complexity or expense.
    - n0body 12y ago
      My argument is that you'll need better developers who cost more money. Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug. and you've also got the added overhead of running xen. all in all it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms, since you get the bare metal, and a little bit of a environment to bootstrap from.
      - lmm 12y ago
        > My argument is that you'll need better developers who cost more money. Frankly I wouldn't want a developer who's too dumb to learn OCaml anywhere near my production code. Is this thing new? Yes. Will developers take time (=your money) to get up to speed on it? Yes. But do you need "better" developers, long-term? I don't think so. > Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug. Maybe a valid concern, but I remember very similar arguments from C++ programmers in the early days of the JVM. Turns out the JVM is rock-solid and nowadays has better debugging tools than those for C++. There's no reason that couldn't be true for this approach. Or if it's easy to make a multi-target project that builds both a linux binary and a unikernel image, then debugging would be no harder than it is for existing OCaml code. > and you've also got the added overhead of running xen. If you're already running linux-in-xen then this is reducing overhead. Even if you're not, it could still improve overall performance by reducing context switching, in the same way as user-mode networking stacks. > it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms This sounds rather like "this can't be a good idea because if it was we'd have it already". It's only in the last few years that xen and the "cloud" approach have become so popular, so a lot of new ideas and approaches are still being found.
- toolslive 12y ago
  for Haskell, there's HaLVM: https://github.com/GaloisInc/HaLVM https://github.com/GaloisInc/HaLVM for Erlang, there's ErlangOnXen: http://try.erlangonxen.org/zerg http://try.erlangonxen.org/zerg There are others, if you care to search for them.

by n0body 12y ago

rjsw 12y ago

There is nothing stopping people from implementing something similar in other languages. The developer using this doesn't need to know anything about Xen, they just see a single address space system that runs their code.

n0body 12y ago
i didn't say there was, but it's still complicating the task. i'm not saying it isn't cool, but it's a very round about way of doing something, and as such it becomes more expensive in development time and skill required
- amirmc 12y ago
  More roundabout than the current paradigm of duplicate Linux stacks and supporting services for DevOps just to get stuff deployed? That doesn't make sense to me. Your argument is actually "It seems very new. Not enough people know/use it. Therefore, I won't use it." -- which is fine, but please don't mischaracterise it in terms of increased complexity or expense.
  - n0body 12y ago
    My argument is that you'll need better developers who cost more money. Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug. and you've also got the added overhead of running xen. all in all it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms, since you get the bare metal, and a little bit of a environment to bootstrap from.
    - lmm 12y ago
      > My argument is that you'll need better developers who cost more money. Frankly I wouldn't want a developer who's too dumb to learn OCaml anywhere near my production code. Is this thing new? Yes. Will developers take time (=your money) to get up to speed on it? Yes. But do you need "better" developers, long-term? I don't think so. > Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug. Maybe a valid concern, but I remember very similar arguments from C++ programmers in the early days of the JVM. Turns out the JVM is rock-solid and nowadays has better debugging tools than those for C++. There's no reason that couldn't be true for this approach. Or if it's easy to make a multi-target project that builds both a linux binary and a unikernel image, then debugging would be no harder than it is for existing OCaml code. > and you've also got the added overhead of running xen. If you're already running linux-in-xen then this is reducing overhead. Even if you're not, it could still improve overall performance by reducing context switching, in the same way as user-mode networking stacks. > it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms This sounds rather like "this can't be a good idea because if it was we'd have it already". It's only in the last few years that xen and the "cloud" approach have become so popular, so a lot of new ideas and approaches are still being found.
toolslive 12y ago
for Haskell, there's HaLVM: https://github.com/GaloisInc/HaLVM https://github.com/GaloisInc/HaLVM for Erlang, there's ErlangOnXen: http://try.erlangonxen.org/zerg http://try.erlangonxen.org/zerg There are others, if you care to search for them.