3 ms·
> It is just a matter of tool maturity. Err.. today's remote debugging is strongly based on the premises of the issues being isolated to some degree: broken ap
by minipci1321 8y ago
> It is just a matter of tool maturity.
Err.. today's remote debugging is strongly based on the premises of the issues being isolated to some degree: broken app will not hit the network stack over which you run you remote session, misbehaving network stack doesn't impact serial communication, so using gdbserver is still possible (but already significantly harder), etc.
Will it be the same with unikernels?
- pjmlp 8y agoI don't see why not, it is a matter of what the runtime allows and debugging tools. When I talk to JEE servers via JMX I don't care if they run on as OS process, on a container, hypervisor or even a bare-metal JVM. Likewise I get to enjoy cluster monitoring tools like Visual VM, Java Mission Control, New Relic APM, DataDog and many others, all blissful unaware of how the JEE server are actually deployed. So I don't see why unikernels can't provide debugging access points for such kind of tooling.
- minipci1321 8y ago> When I talk to JEE servers via JMX I don't care if they run on as OS process, on a container, hypervisor or even a bare-metal JVM. But I think the whole point on the thread was that, making all this possible on unikernels, would require putting back a big part of the code that went away when making the unikernel lean and mean (and interesting because of that).
- pjmlp 8y agoThat is what people that favor an UNIX userland advocate. An optional debug layer for JVM, Erlang, CLR running bare-metal (just as possible language examples) is tailored made for such runtimes and much thinner than all the services a general purpose OS needs to provide.