I've read his work on-and-off for a long time and there's little no to incendiary click-bait junk, or bias in most (if any) of what he publishes. Obviously he can't dedicate 60-hour resources a post-doc might, but he conducts most of his tests with rigor, and this blog post is no exception to the high-standards to which he presumably holds himself. I'd love to see Anil (one of the MirageOS leads (co-founder IIRC; pedigree - PhD from Imperial or Oxbridge)) comment. Either way, this is an example of how one should construct posts (I know we're not in academia, but there's no excuse for that absolutely abysmal post[2] made on Friday).
Thanks for raising the caliber of conversation, my good man.
[0] http://www.amazon.com/gp/product/0132091518/ref=as_li_ss_tl?...
[1] https://blogs.oracle.com/brendan/resource/DTrace-cheatsheet....
[2] https://www.joyent.com/blog/unikernels-are-unfit-for-product...
https://news.ycombinator.com/item?id=10953766 for the discussion
I'm sure if Anil or someone from the unikernel community is really interested in this, we'll see a better profiler soon (of either type). The initial goal should be to gather stacks for making into CPU flame graphs, which solve a ton of issues.
Does a tweet count as commentary for you?
" Profiling MirageOS unikernels from a Xen dom0, an excellent and short howto -- http://www.brendangregg.com/blog/2016-01-27/unikernel-profil... " https://twitter.com/avsm/status/692396667576938497
Also, it's the Cambridge Computer Lab you're thinking of (at the University of Cambridge).
We also spoke about debugging (but not to this depth) on today's Docker Online Meetup about unikernels. We made the same points but Brendan's post is fantastic as he shows a worked example. There's a discussion thread [1] and there'll be a video of that webinar out soon too.
[1] https://devel.unikernel.org/t/docker-online-meetup-about-uni...
Maybe I'm being too much of a fanboy, but I appreciate good materials when I come across them.
Well he probably has historical interest in Solaris, and generally any platform which supports dtrace, though he's been doing Linux work (http://www.brendangregg.com/linuxperf.html) for the last few years, given Netflix is mostly Linux-based with some FreeBSD (for the CDN nodes).
One of that articles main ideas was:
"...the most profound reason that unikernels are unfit for production — and the reason that (to me, anyway) strikes unikernels through the heart when it comes to deploying anything real in production: Unikernels are entirely undebuggable."
There's also nothing stopping you from including a runtime debugger interface in your unikernel, just like any other kernel that supports debugging.
Mr. Cantrill was just wrong.