[imbriaco]

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments.

Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current state of available tooling for troubleshooting, instrumentation, and general debugging isn't a challenge.

[mirceal]

hah. they're a new technology/approach. of course there are going to be challenges.

[weberc2]

You're moving the goal posts and invoking a straw man. No one is advocating for "pretending", and the anti-unikernel argument is that the inherent cost of unikernels in general is the loss of kernel debugging tools; not simply that "right now the unikernel debugging experience is subpar".

[convolvatron]

in general right now, running on a full-featured monolithic kernel, the debugging experience is really pretty bad. especially in the target environment of horizontal clustered services or lots of little micro services.

so I actually believe there is an opportunity here to focus on the important pieces (network messages, control flow tracing, memory footprints, etc) after ejecting a huge amount of irrelevant stuff

[imbriaco]

No, I'm not moving any goal posts. I was reacting to the statement "Tooling/Perf/etc is not needed when running". I'm not sure where you'd get the idea that I'm anti-unikernel, I just wanted to not disregard that challenge since it does matter.