[pjmlp]

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.

[Annatar]

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.)

[pjmlp]

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.

[Annatar]

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.