4 ms·

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.

• nsajko 12y ago
  But hopefully with a smaller stack?? :)
• xyzzy_plugh 12y ago
  Yep. I don't get the value in this, pushing the problem somewhere else just creates new problems. Instead of being able to rely on distributions and gargantuan open software, now we go off and roll it all ourselves? This is a good path to job security, but I don't see what else.
  • MCRed 12y ago
    What's to roll yourselves? (Serious question, I might have missed it.) The erlang platform provides a great deal of everything you need. And if it doesn't, there's a library out there to do it. Elixir is extremely active, growing and moving fast and even if you do have to roll it yourself, it can still be a net win. For instance, I found it was easier to integrate a mail sending library or interface with mailgun than it was to get an STMP service working on linux. But then, I'm a developer, not ops.
  • corysama 12y ago
    Disclaimer: I have no idea what I'm talking about and should not be taken seriously. Eliding the virtualized network and disk interfaces is not what they are talking about though. They are sticking with those. So, given virtualized CPU, RAM, network and disk interfaces; a runtime that talks directly to those interfaces; and the intent to exclusively run a single process per VM; what do they really need Linux for?
  • justincormack 12y ago
    You don;t roll all a Linux distro yourself; aside from the fact you use open source libraries, you need much less as it is only for running networked applications, which needs less stuff.
• digi_owl 12y ago
  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 provisioning is done by the VM.
  • vog 12y ago
    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 separate your applications via users within your OS, but via VMs in your hypervisor. Not sure if this turns out to be a good idea or not, but it's an interesting approach that shouldn't be put down easily.
    • digi_owl 12y ago
      Yeah i may be coming across as overly dismissive.
• pjc50 12y ago
  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 entire categories of security hole and workaround.
  • pjmlp 12y ago
    While true, it would only help if C would be out of the picture as well. Plan 9 and later Inferno (with Alef and Limbo) would have been better, but they went nowhere.
  • smorrow 12y ago
    Research 9th and 10th had a /cs pretty much identical to Plan 9's /net. I doubt with any of that user-level control, though. IIRC Research's fmount(2) would've allowed people to run their own (unrestricted) copy of tcpmgr and mount it on by themselves.