Hacker News Reader

Comment by eyberg | Hacker News Reader

htop and such don't make sense inside a single process system; logging usually gets sent to remote syslog/elk/etc. many apm solutions work out of the box

one of the biggest misconceptions about unikernels is that they are somehow of a slimmed down linux - it's easier to think about them as individual programs provisioned as vms - would you ssh into a process? why?

all 'debugging' tools work perfectly fine w/unikernels although I'd draw a fine line between real application level debugging which should never happen on production and ops tooling

View on HN

> I'd draw a fine line between real application level debugging which should never happen on production and ops tooling

Sorry, but that's just plain wrong. One very common reason why people do that is, because performance debugging may give very different results on dev, staging and production systems that's why people want tooling that gives them as accurate as possible application level debugging information without impeding the behavior of the system. It's a very common problem in large scale systems.

I think that can be solved by good tracing and logging facilities. Both of which are already available in Linux (eBPF, ftrace, tracepoints, perf events...). You may have to customize them or polish them further though and provide more user friendly interfaces/frontends for them.

Though the amount of tracing/logging to equate to debugging is so much that you will want to turn it on selectively.

And you will want a mechanism to iterate quickly to see effects of tweaks.

Eventually you have built an interactive debugger.

Maybe. But KGDB and friends do exist too in Linux. And (AFAIK) not everyone likes using those, some just like throwing a few printks here and there. That is not universal obviously :) My point is that yes, unikernels may not be as easy to debug etc at this point as regular usermode code, but it is something that can be worked around and I think if people begin to use them in-mass frameworks and solutions will emerge.

Yes. It is a deficiency/roadblock to adoption.

One that could improve.

> would you ssh into a process? why?

Oh god, I wish. It's more common that you probably think.

You have a lot of options approximating this with a lot of thicker runtimes like Java/JVMs and Erlang/BeamVM or interpreted REPL'd languages like Python or Lisps. And they're incredibly useful.

Pulling up a REPL into a running process like a JS console in the browser is basically the same thing.

Yes I agree. We have to refactor the way we debug and realize it’s devugging a single process and that process is the application.

Reply on news.ycombinator.com