Hacker News Reader

Comment by mm321 | Hacker News Reader

isn't it hard to develop/debug/monitor an application with this approach? I mean you can't just run a debugger as another process and attach to the thing, you can't run tcpdump or strace, nothing of that sort. Also every bad pointer access will require a reboot, wouldn't it? I mean how do you develop an application with this approach?

View on HN

All good questions without a clear answer at the moment. Bad pointers in the application can overwrite kernel data structures because everything runs in a single address space.

The unikernel idea is 20-ish years old. I think those good questions cannot be much younger.

Because of that, I think “without a clear answer at the moment” is worrisome. Are there partial answers to these questions?

I mean "without a clear answer" for UKL which is only just over a year old and still in active and early development. There will probably be a way to attach gdb at some point.

> Also every bad pointer access will require a reboot, wouldn't it?

Hm, isn’t reboot just slightly more complicated than restarting your application? And most of the today’s apps would still require “rebooting” be it a container or a virtual machine

Containers get "rebooted" when they go wrong too, so I'm not sure this is so different.

You can debug a normal kernel over the network. I imagine you can do the same with a unikernel.

I guess you would use an emulator to debug. Which seems like good workflow design to me.

One of our engineers spent yesterday debugging a networking issue on Google Cloud for Nanos.

Not saying it is easy but at the end of the day it's just engineering work.

Probably best to use a memory safe language so you don’t have bad pointer accesses and generally minimize debugging significantly.

Reply on news.ycombinator.com