Anyone's using this in production? Or any other unikernels?
tl;dr: a unikernel means there's no standard OS other than the runtime execution environment specifically just for Golang in this instance; which means it should be much faster and much more lean (at the price of not having standard tools like SSH and all)
To add to others points and your own which may not be as obvious to some but my background stems from the financial world and security has always been a problem, breach du jour. The way things are done now are nothing short of broken, PCI and more, and all the glue holding the shattered "window" panes together certainly doesn't lead to anything secure or even a "window" you can see through. I'm certain there are millions that will disagree, job security of course, but when one has maintained critical uptime services on M$ as long as I have one begins to question there must be a better way. Solve your own problems first I always say as I am currently architecting that path, the sixth time of my career actually but this occurrence is different entirely.
I am building an new way to conduct a technology business end to end in entirety, hardware through software, THE BIG PICTURE. Obviously these are my words and likely further explanation could be redefined in other terms based on ones understanding however I have done this several times before with extreme security and efficiency in mind at every decision made, AUTOMATION because PEOPLE ARE THE PROBLEM. My background is payments, finance and banking which I need not elaborate the security that has been in this arena alone for quite some time but anyone nowadays, even a 7 year old, can use any search engine and find a recent breach referencing lost financial information and EVERYONE reading this has likely been issued multiple new credit cards or worse. There are several people and companies working towards unikernels and the like but my jam, and always has been, is to apply the new way of thinking to a business, a serial puzzle master if you will.
In short you are correct in using ONLY GO for absolutely EVERYTHING to reduce technical debt, ZERO TRUST architecture, automated everything and much much more. Might sound like hogwash to some but once more, if my past is an indication of my future as I love a challenge.
At least one or two order of magnitude more systems are using unikernels or rtos rather than a full-blown os. You can write a small scheduler even for a small 8bit microcontrollers (avr).
The main purpose of the unikernels or small rtos are handling multiple running contexts (aka threads or tasks). I wrote several smaller kernels for embedded sytems, before starting threos.io .
It's much easier to handle multiple tasks.
ex. one of our project was a wireless voting terminal, one task handles the communication (RF) interface (protocol, error correction etc.), the other handles the user interface (buttons leds etc), and one task is handling the vote application program or logic. The tasks are communication over message passing. All of this running in a cortex-M3 with 8k-32kb ram.
A more common example are wireless RF modems (WIFI, GPRS, GPS, Bluetooth etc.), nearly every RF modem uses some kind of unikernel or rtos.
FreeRTOS is a unikernel by that definition (by every definition I've seen, though they still use the term "Library OS" which seems essentially synonymous). It's quite common in embedded devices.
Well, the usual definition I see for unikernels also stipulates that there's only a single process. So FreeRTOS is still a unikernel, but early UNIX wouldn't be.
Though the distinction between "process" and "thread" gets very fuzzy when you have only a single address space.
Actually is the other way around, libc is the part of UNIX API ISO was willing to put into the language standard, while the remaining part of the C UNIX runtime ended up as POSIX.
I work a little on nanos..it clearly needs alot of usability work, stability, and feature work. but could you say explicitly what you mean by 'self service'?
tl;dr: a unikernel means there's no standard OS other than the runtime execution environment specifically just for Golang in this instance; which means it should be much faster and much more lean (at the price of not having standard tools like SSH and all)