Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atmanos: Build Go programs that run directly on the Xen hypervisor

github.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#51

Post by pjmlp »

dnautics wrote: post #45
im_down_w_otp wrote: post #26

Earlier quoted context omitted.

Brenden Gregg also has a great post on unikernel models: http://www.brendangregg.com/blog/2016-01-27/unikernel-profil... From my read, it counters Bryan Cantrill's claim that, "unikernels are undebuggable". From personal experience I'm also quite certain Bryan Cantrill's claim is spurious in that regard, as I've used both debugging and tracing facilities w/ LING unikernels to assess a number of runtime and clustering…

Ling is a special beast since erlang is basically begging to be it's own runtime os.

A language runtime is an OS, when running bare metal.

That is how we used to program many 8 and 16 bit applications, and how many keep programming embedded systems nowadays.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#52

Post by pjmlp »

Annatar wrote: post #49
testcross wrote: post #44

Earlier quoted context omitted.

He has no choice but to say that as it is a threat for his business.

How are theoretical applications which are designed to do just one specific thing a threat to a fully featured hypervisor with 15000 packages used in production?

By slowly gaining market adoption, until it actually starts to matter.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#53

Post by Annatar »

pjmlp wrote: post #50
Annatar wrote: post #48

Earlier quoted context omitted.

Apart from disassembling the machine code, assuming one could even attach a debugger to such an application, how would you debug a unikernel application in production?

Just like debugging Java and .NET applications running bare metal on production. By having a rich runtime (kernel) that exposes the internals to the world, like Mission Control, TraceViewer and the respective debuggers, when the right set of flags/authentication are enabled. Unikernel are no different from running embedded applications, bare metal.

I know they are no different since they are one and the same. Now imagine your unikernel application is running inside of a vehicle and there is a bug in the head-up display code. Without re-inventing DTrace and kdb from Solaris / illumos from scratch, how would you debug your unikernel application in order to find and even fix the bug? (With kdb, it can be done on the fly.)

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#54

Post by pjmlp »

Annatar wrote: post #53
pjmlp wrote: post #50

Earlier quoted context omitted.

Just like debugging Java and .NET applications running bare metal on production. By having a rich runtime (kernel) that exposes the internals to the world, like Mission Control, TraceViewer and the respective debuggers, when the right set of flags/authentication are enabled. Unikernel are no different from running embedded applications, bare metal.

I know they are no different since they are one and the same. Now imagine your unikernel application is running inside of a vehicle and there is a bug in the head-up display code. Without re-inventing DTrace and kdb from Solaris / illumos from scratch, how would you debug your unikernel application in order to find and even fix the bug? (With kdb, it can be done on the fly.)

Sokaris/Ilumnos don't run inside vehicles, maybe one day they will. Can you give an actual production example?

Unikernels on the other hand, do actually run on vehicles. There are a few embedded runtimes based on the same architecture.

They have debugging support to attach to graphical debugger, probes, JTAGs, and a few other vendor specific tools.

Of course someone trying to sell me Solaris/Illumnos, will have prejudice to anything else.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#55

Post by Annatar »

pjmlp wrote: post #54
Annatar wrote: post #53

Earlier quoted context omitted.

I know they are no different since they are one and the same. Now imagine your unikernel application is running inside of a vehicle and there is a bug in the head-up display code. Without re-inventing DTrace and kdb from Solaris / illumos from scratch, how would you debug your unikernel application in order to find and even fix the bug? (With kdb, it can be done on the fly.)

Sokaris/Ilumnos don't run inside vehicles, maybe one day they will. Can you give an actual production example? Unikernels on the other hand, do actually run on vehicles. There are a few embedded runtimes based on the same architecture. They have debugging support to attach to graphical debugger, probes, JTAGs, and a few other vendor specific tools. Of course someone trying to sell me Solaris/Illumnos, will have preju…

Can you give an actual production example?

Inside of a vehicle, not yet; production example, yes.

Back in the day, there was a kernel bug which prevented Solaris 10 installer from booting on systems with a Pentium III processor. The workaround was to boot the kernel with -k, let it crash and drop into kdb, then patch a certain kernel structure and drop out of the debugger, continuing execution. The same mechanism would work in a car or a Boeing 787, which I understand were actually running Solaris as the control & navigation system.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#56

Post by xena »

zenlikethat wrote: post #25
Timothycquinn wrote: post #23

Bryan Cantrill has a great post on unikernel models: https://www.joyent.com/blog/unikernels-are-unfit-for-product... From my read, the benefits do not outweigh the costs. If you want light weight microservices, OS level virtualization is the way to go.

AtmanOS says in the README it's highly experimental and doesn't imply you should use it for production at all. So who cares? What else is HN for if not for posting cool hacks and projects and encouraging fellow builders?

Every product shipped into production today started as a highly experimental prototype.
Post reply on HN