81–90 of 91 posts
Earlier quoted context omitted.
No one has tried Node.js yet as far as I know (possibly under OSv not sure). PHP, yes, is running as a unikernel, using a rump kernel.
Can you post some links?
https://github.com/rumpkernel/wiki/wiki/Info:-Community
Ask on the mailing list/irc if you need help... its still under development so not completetly obvious yet ;)
Earlier quoted context omitted.
It is not a unikernel though, just a minimal Linux.
Boxfuse falls squarely into the "generalized" unikernel type mentioned in the presentation. You are only thinking of the "specialized" ones. In a sense it follows the same principle as OSv, just with a proven Linux kernel instead of a custom one. Update: Why the downvote? If you disagree, feel free to say why.
PS no idea who downvoted you, there is really no point in mentioning it.
Unikernels are cool to play with. Erlang is cool too. But... - [name] is a kernel thread not a user space process. - its libssl, not "libopenss" - installing rpc, some obscure 55k listening port, and calling it bloated.. heh so cheap. Once past all this FUD - what does a unikernel (basically the same as running linux and your app as /sbin/init except it's in Erlang and not C here)? - its obscure. you get security mai…
The problem with Mesa/Cedar, Modula-3/Spin, Modula-2/Lilith, Oberon/Native Oberon, Oberon-2/AOS, Sing#/Singularity and many others is compatibility and lack of buy-in from OS vendors. Personally I see application compartments, wider adoption of Swift, Java, .NET Native, OCaml, Haskell, Go, D, Rust, Erlang, ..., alongside unikernels as the way forward to mainstream adoption. One day we will get C free OS stacks.
I guess Rust and Nim are the real contenders, as only a language with "zero runtime" is going to cut it.
The next logical step is to elide the virtualized network and disk interfaces, and then we're back to shared hosting! See you again in twenty years.
Arguably we only got this way because, although UNIX neatly abstracted the file system with user access control, it predated networking which was slapped on the side with no way of allocating network resources between users. If SysV had had filesystem-like means of allocating the right to listen on a particular port to particular user accounts, the world would have been very different, and we'd have been spared entir…
Earlier quoted context omitted.
The problem with Mesa/Cedar, Modula-3/Spin, Modula-2/Lilith, Oberon/Native Oberon, Oberon-2/AOS, Sing#/Singularity and many others is compatibility and lack of buy-in from OS vendors. Personally I see application compartments, wider adoption of Swift, Java, .NET Native, OCaml, Haskell, Go, D, Rust, Erlang, ..., alongside unikernels as the way forward to mainstream adoption. One day we will get C free OS stacks.
C/C++ is the language you write the library in, so that it's callable from every other language. Hopefully Rust, Nim (and Golang one day) will be able to produce C-API compatible replacements. API can also be something better than what .so and .dlls provide, as long as everyone is on board. I guess Rust and Nim are the real contenders, as only a language with "zero runtime" is going to cut it.
This wasn't true in other OSes.
Windows is currently moving to COM as the main OS ABI, specially with the WinRT focus.
Android also has little support for C ABI, beyond wrapping .so in JNI wrappers.
Another example are mainframe systems like OS/400, where the ABI is bytecode based (TIMI).
http://wiki.xenproject.org/wiki/Unikernels 'nuff said.
Unikernels: Rise of the Virtual Library Operating System https://queue.acm.org/detail.cfm?id=2566628
Unikernels are cool to play with. Erlang is cool too. But... - [name] is a kernel thread not a user space process. - its libssl, not "libopenss" - installing rpc, some obscure 55k listening port, and calling it bloated.. heh so cheap. Once past all this FUD - what does a unikernel (basically the same as running linux and your app as /sbin/init except it's in Erlang and not C here)? - its obscure. you get security mai…
What FUD? There appears to be more FUD in your comment than I've seen from any of the unikernel projects. Most of the claims you've made seem to be coming from the existing paradigm of how people write code for the cloud. If you're determined to stay in that mindset, then unikernels will probably not make much sense to you. The whole point is to reevaluate our assumptions about developing for cloud-native environment…
I'm all for the positive attitude stuff - unless the presentations start like that, I then have no sympathy.
The linked presentation actually claims unikernels are the panacea, by the way. Have you read it?
Earlier quoted context omitted.
namespaced linux boots in Can someone show me this?
The OP means the creation time of a Linux "container" is less than 10ms, ie the time for the system calls you need to create the namespaces and cgroups. While you can boot a unikernel from nothing in that time.
Had to look for it in the HN history, look at this guy's implementation:
https://www.youtube.com/watch?v=6SxLvz6pcGs ~30ms here, the post indicates some kind of intel NUC (so not exactly the fastest thing)
The syscalls themselves are probably sub-millisecond
Unikernels are cool to play with. Erlang is cool too. But... - [name] is a kernel thread not a user space process. - its libssl, not "libopenss" - installing rpc, some obscure 55k listening port, and calling it bloated.. heh so cheap. Once past all this FUD - what does a unikernel (basically the same as running linux and your app as /sbin/init except it's in Erlang and not C here)? - its obscure. you get security mai…
The problem with Mesa/Cedar, Modula-3/Spin, Modula-2/Lilith, Oberon/Native Oberon, Oberon-2/AOS, Sing#/Singularity and many others is compatibility and lack of buy-in from OS vendors. Personally I see application compartments, wider adoption of Swift, Java, .NET Native, OCaml, Haskell, Go, D, Rust, Erlang, ..., alongside unikernels as the way forward to mainstream adoption. One day we will get C free OS stacks.
It might help bridging the current solutions, hopefully (even thus that will perhaps take 10 years)
Earlier quoted context omitted.
I can't seem to shake the first thought i had when reading about unikernels. That they are DOS in a VM. Maybe it is overly simplified, but as i understand it we are looking at a "kernel" stripped down to handling the disk and network interfaces provided by the VM. No user separation (there is only a single "user"), no memory protection (it is only running a single process as best i can tell), and resource provisionin…
The point is that you only run a single application in the VM anyway. And if you do that, you should make your VM as slick as possible, because anything in there that doesn't serve your application is just increasing the attack surface and the probability of errors through side effects. That's what is already done today, and unikernels are just the natural progression towards that goal. So you essentially don't separ…