4 ms·

Forgive me if I'm totally clueless, but isn't the idea of the unikernel basically a throwback to the earliest, pre-OS days of computing when all programs needed

Forgive me if I'm totally clueless, but isn't the idea of the unikernel basically a throwback to the earliest, pre-OS days of computing when all programs needed routines to initialize the base hardware resources before they could perform tasks? The idea of the unikernel and the libOS in general where applications can be linked with their bare minimum OS runtime and packaged is certainly nifty, but it's kind of funny that people are being so hyped over what sounds like a more advanced form of what was regularly done in mainframes 60 years ago.

pjmlp 12y ago
Because in 60 years the OS got useless layers of abstractions when used as server OS with programming languages that come with batteries included. If the programming language has a rich ecosystem with a runtime that is already taking care of hardware abstractions and scheduling, why replicate it a few times in lower layers? How many schedulers or device drivers are needed to serve network requests?
- krakensden 12y ago
  It's only useless until you discover that you're reimplementing it from scratch on a full-time basis.
  - monocasa 12y ago
    Because you don't use libraries?
  - pjmlp 12y ago
    I assume you program in pure C without libc, using only syscalls for your OS of choice.
monocasa 12y ago
And it's what's being done now on mainframes too. What was lacking in the commodity processor space was hardware support for mature hypervisors that stay out of the data plane (IBM got this right pretty close to the first try). We're almost there, but there's still some work IMO.
- pjmlp 12y ago
  OS/400 with kernel JIT, quite a nice design.
  - monocasa 12y ago
    Actually OS/400 isn't quite what I'm talking about (despite being really cool!). {AS|OS}/400 is more like a cross between a minicomputer and all of those promises of a Java OS we were given in the 90's. I'm talking more about the mainframe level stuff, like z/TPF on the software side and adding address space tags to the channels on the hardware side. Basically that last one is a better implementation of an IO/MMU where a device knows that it's probably running under a hypervisor, can get requests directly from multiple VMs without the hypervisor's intervention, and the VMs requests are implicitly tagged with the address space of the VM so it's still memory safe. ie. a VM can't request DMA from a device that would be outside of it's allocated space, but it can still directly ask the device for DMA without involving the hypervisor directly, and the device can service multiple VMs (that last bit is what isn't really present with current IO/MMUs).
    - pjmlp 12y ago
      I used to start backup jobs on a AS/400 during a summer internship back in 1994, just logged in and started the respective job. Only more than a decade later I bothered to delve into how it actually works. I was quite surprised to discover that Java, .NET, Android, Windows Phone concepts were already successfully implemented in the marked in such systems, so many years before. And that the majority of developers out there are unaware of them. Thanks for the z/TPF overview.

pjmlp 12y ago

Because in 60 years the OS got useless layers of abstractions when used as server OS with programming languages that come with batteries included. If the programming language has a rich ecosystem with a runtime that is already taking care of hardware abstractions and scheduling, why replicate it a few times in lower layers? How many schedulers or device drivers are needed to serve network requests?

krakensden 12y ago
It's only useless until you discover that you're reimplementing it from scratch on a full-time basis.
- monocasa 12y ago
  Because you don't use libraries?
- pjmlp 12y ago
  I assume you program in pure C without libc, using only syscalls for your OS of choice.

monocasa 12y ago

And it's what's being done now on mainframes too. What was lacking in the commodity processor space was hardware support for mature hypervisors that stay out of the data plane (IBM got this right pretty close to the first try). We're almost there, but there's still some work IMO.

pjmlp 12y ago
OS/400 with kernel JIT, quite a nice design.
- monocasa 12y ago
  Actually OS/400 isn't quite what I'm talking about (despite being really cool!). {AS|OS}/400 is more like a cross between a minicomputer and all of those promises of a Java OS we were given in the 90's. I'm talking more about the mainframe level stuff, like z/TPF on the software side and adding address space tags to the channels on the hardware side. Basically that last one is a better implementation of an IO/MMU where a device knows that it's probably running under a hypervisor, can get requests directly from multiple VMs without the hypervisor's intervention, and the VMs requests are implicitly tagged with the address space of the VM so it's still memory safe. ie. a VM can't request DMA from a device that would be outside of it's allocated space, but it can still directly ask the device for DMA without involving the hypervisor directly, and the device can service multiple VMs (that last bit is what isn't really present with current IO/MMUs).
  - pjmlp 12y ago
    I used to start backup jobs on a AS/400 during a summer internship back in 1994, just logged in and started the respective job. Only more than a decade later I bothered to delve into how it actually works. I was quite surprised to discover that Java, .NET, Android, Windows Phone concepts were already successfully implemented in the marked in such systems, so many years before. And that the majority of developers out there are unaware of them. Thanks for the z/TPF overview.