[Hoff]

While the term unikernel is fairly recent,the basic concept goes back a long time.

One example of this general design is VAX ELN.

The following is a brochure from the V2.2 release, from 1986:

http://bitsavers.trailing-edge.com/pdf/dec/vax/vaxeln/2.0/VA...

Compile and then link the application code with the particular pieces of the toolkits that you needed and with the provided kernel into a single download image, and either embed or boot or network boot the target box using it. Remote debugging was available, as well as a relational database, etc.

[noselasd]

This is also how most embedded applications utilizing an OS also works these days. The OS is a library, you link in whatever you need from the OS + compile time configuration of OS features etc. + link in whatever you need for your application.

[pjmlp]

Have they worked anyway differently?

I remember you always had to bundle everything together with the exception of what was already present in the firmware.

Also some books I had access in the mid-90's were all about creating your own libOS with tasks and lightweight communication primitives and then bundling everything together.

Coding since the 80's, but the most embedded stuff I did was PC (bypassing MS-DOS), Amiga and Symbian and reading also PIC programming on Elektor.

So maybe my perception might not be the correct one.

[noselasd]

Sure - I didn't mean to imply this was a new thing.

[pjmlp]

Thanks, I was just getting a clarification, trying to understand it.

As I mentioned, I have a very small view of how it all works.

[nickpsecurity]

Not just another that knows of VMS and the prior innovations but one whose site taught me many things about those days. Glad to get a chance to say (tips hat) thanks for the info. :)

Wish modern systems were designed and implemented with even half the skill that VMS, etc were. I've never gotten to experience an OS reliable enough that I temporarily forgot reboot command. Desktop Linux will have to do. ;)

[Hoff]

Thanks.

re: "those days" — FWIW, those days are still ongoing. The latest OpenVMS release shipped out in June 2015, and the native port to x86-64 is underway.

[nickpsecurity]

I knew HP would kill it after acquisition due to rule of no competing product lines (i.e. VMS vs NonStop). I was relieved that they spun it off to another company that began a Xeon port. Two quick questions that you might know already if you've contacted them:

1. Has the company been more clear privately than the website on how long it will be before a Xeon port materializes?

2. Have they significantly reduced the OpenVMS licensing costs that kept many off it?

[Hoff]

In no particular order...

OpenVMS and NonStop (NSK) do not compete. Entirely different products and markets.

VMS Software Inc (VSI) have licensed OpenVMS from HPE. They've not acquired the product.

The company was newly formed, not a spin-off of HP.

VSI have been circumspect on their x86-64 release schedule.

The team includes many of the same development folks that ported OpenVMS from Alpha to Itanium.

OpenVMS I64 Itanium software list prices are unchanged from those of HPE. Whether and how much the VSI sales reps might be discounting, you'd have to ask them.

Related: http://labs.hoffmanlabs.com/node/1917 http://www.vmssoftware.com/pdfs/VSI_DrawerSt_v2.pdf

[nickpsecurity]

Thanks for the info. Question about...

"OpenVMS and NonStop (NSK) do not compete. Entirely different products and markets."

Outside legacy market, I thought they both advertised as being for business-critical systems that can't afford downtime. I remembered plenty of HP advertisements on that for OpenVMS & its clustering. NonStop obviously does that stuff with even better availability due to FT HW/SW. What makes you say they don't compete?

Note: I'm not talking about the five 9's, HW-supported stuff that OpenVMS probably can't touch.