11 ms·

Bryan Cantrill seems to have some personal interest in denigrating OS research (defined as virtually everything post-Unix) as all being part of a misguided "ant

Bryan Cantrill seems to have some personal interest in denigrating OS research (defined as virtually everything post-Unix) as all being part of a misguided "anti-Unix Dark Ages of Operating Systems". He has expressed this sentiment multiple times before, and places a great deal of faith on Unix being a timeless edifice which needs only renovation. Naturally, he regards DTrace and MDB to be the pinnacles of OS design in the past 20 years and never stops yapping on about them, this article being no exception. It's his thought-terminating cliche. He voiced all this here [1], and so I countered by listing stuck paradigms in traditional monolithic Unixes, as well as reopening my inquiry on Sun's Spring research system, which he seems to scoff at, but over which I am impressed by the academic research it yielded. He has yet to respond to my challenge. [1] https://news.ycombinator.com/item?id=10324211 https://news.ycombinator.com/item?id=10324211

Joeri 11y ago
Your opinion on the author has no bearing on the contents of the article, which i found well argued.
- im_down_w_otp 11y ago
  They're overwhelmingly argument by assertion. I'm not sure that counts as "well argued"? Like the stuff at the end about STM and M:N scheduling. There are systems that use both to tremendous effect. Erlang only offers an M:N scheduling model, and it works extremely well for building the kinds of systems Erlang was built for.
  - nickpsecurity 11y ago
    Yeah, both examples plus him not backing up his performance assertion showed he was full of crap. Haskell did nearly bulletproof STM that I hear. I've seen other examples. Your Erlang example is good on M:N. Microkernel with work in AI planning still using it successfully with ever more efficient algorithms. JeOS performance characteristics of the past suggest unikernels might improve performance over monoliths or plain virtualization. Need real-world data rather than assertions. He seems to be all talk. He's also more critical of unikernel level security and robustness over well-known issues like POLA while ignoring that his own platform violates both POLA and other rules we've learned about INFOSEC over time. The only proven approaches were separation kernels a la Nizza architecture, capability model at OS or component level, and language-based protection w/ extra care on HW interfaces. He doesn't mention those because they oppose UNIX approach, which he ideologically supports, plus show his product is likely not trustworthy. This article isn't objective or reliable.
    - dmpk2k 11y ago
      I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems. Circa 2000, Solaris, Linux, and some (all?) BSDs had M:N threading, and all of them threw it away because there are numerous performance artifacts caused by two schedulers (OS and the M:N) conflicting with each other. Mr. Cantrill was there when this all happened, and even wrote a paper on it: ftp://ftp.cs.brown.edu/pub/techreports/96/cs96-19.pdf This doesn't affect Erlang as much simply because Erlang is really slow. I think of it as a waterline -- the lower the overhead of the language, the more likely you will run into the serious problems that M:N typically inflicts. E.g. priority inversion, and long and unpredictable latencies when the OS swaps out a thread that M:N wanted running. As for Haskell and STM, all I know on the topic is that some pretty damn smart engineers at IBM spent a good while trying to make STM work well, and gave up. See this ACM article: https://queue.acm.org/detail.cfm?id=1454466 https://queue.acm.org/detail.cfm?id=1454466. Perhaps Haskell managed to pull it off through the language restrictions it allows, but I’d like to see some compelling articles on that by engineers who know a thing or two; just because a language has STM doesn’t mean it does it well. Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's. While you might disagree with him, there’s sufficient literature to give his stance some legitimacy. Sweepingly calling his stance "full of crap" says a thing or two.
      - nickpsecurity 11y ago
        "I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems." "Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's." Probably was. Idk who he is or what he does. I'm aware there were fads to claim the two could solve every problem under the Sun in their category. I'm one of those few that ignore fads to focus on any lessons we can learn from certain tech or research. He made a blanket assertion against at least three technologies in one article with no context. Anyone reading might think the techs don't work well in any context. So, I briefly called that. As evidence, I gave an example of STM that worked. In OS's, it had mixed results unless hardware accelerated and one typically had to protect I/O stuff with locks due to irreversibility. Far as M:N, only found OS use for it in security kernels (eg GEMSOS) to help supress covert, timing channels. Didn't expect him to know that use-case, though, since the cloud products are usually full of covert channels. And then there's MirageOS on unikernel end using type- and memory-safety for robust, network applications already showing fewer 0-days than alternatives did. So, all three already have real-world, beneficial use. Quite the opposite of his claim that leads one to believe that never happens. "Sweepingly calling his stance "full of crap" says a thing or two." In other comments, I did present data and specific examples to reject his claims about UNIX being a usable foundation for this sort of thing among others. His approach to such things was to ignore all counter evidence and/or leave the discussion. Eventually, a new article shows him making an adverti... err, a bunch of claims, some backed up and some assertions, about all kinds of tech in an anti-unikernel rant. Strange that you're fine with him ignoring his critic's counterpoints... with references... to his major claims but have trouble with how I handle minor, tangential ones. Says a thing or two indeed.
  - mcguire 11y ago
    I personally, as a Rust guy, was disappointed by the loss of M:N threading; without that, you cannot effectively use threads as a design tool rather than simply ("simply" :-)) a parallelization/performance tool. Erlang has a lot of neat ideas.
    - masklinn 11y ago
      m:n does not an erlang make though (witness Go), and Rust was not headed in that direction.
      - mcguire 11y ago
        I know, I know. And Rust is a better systems language for it. Still, I can dream.
        im_down_w_otp 11y ago
        Take a look at pony-lang. It's sorta like what Rust was once going to be. It's sort of implicitly going for a bare-metal Erlang-shaped thing. There's a lot missing, not the least of which is a set of abstractions over the rich primitives which provide simple programming interfaces that don't force a lot of the language's complexity on you, but if what you want is something that might one day be a really fast Erlangish it's probably the front-runner at the moment. I still have high hopes for BEAMJIT existing as a production-grade thing someday. That way I don't have to drop into C in my Erlang applications as often. Sure BEAMJIT will probably never be as fast, but if it can be good-enough while also not forcing me across the safety boundary to get to that good-enough state... that's a huge win.
    - zokier 11y ago
      I thought the idea in Rust was to provide solid primitives so that libraries can then provide m:n/green threading if wanted. And sure enough we have stuff like coio and mioco which provide coroutines. Is there something missing in those that you'd want from m:n threading?
  - hinkley 11y ago
    Solaris used to have an M:N scheduling model and they've mostly abandoned it, didn't they? I wonder what Erlang got right that Solaris got wrong.
    - deleted 11y ago
      [deleted]
    - tormeh 11y ago
      Erlang is a low-throughput, low-latency language. It makes no apologies for the former and it even says so on the tin. That allows it to do stuff other languages/runtimes can't.
  - the_why_of_y 11y ago
    I'd say he's half-right on the M:N scheduling. For implementing POSIX threads, M:N threading has a lot of extra complexity and few advantages, and worse performance. But if you don't have POSIX threads, but something higher-level that's managed by a runtime anyway, you don't need to worry about things like ensuring enough VM space and at least one allocated page for each thread stack. Erlang's and GHC's threads start out needing much less space than a single page, so you can start 10x more threads in the same amount of RAM.
- shawn-butler 11y ago
  Well-argued? His point if there is one is that: >> Unikernels are entirely undebuggable. For which evidence he provides the sound of some applause at some random conference and I don't believe is even remotely true or is so general to be vacuous. Your notion of well-argued differs greatly from mine. Unikernels solve an important class of problems that Joyent is interested in solving with another platform.. it's own. I see no mention of a significant benefit of unikernels: their decreased attack surface. There is a fairly new community web site at http://unikernel.org/ http://unikernel.org/ for those interested.
  - chris_wot 11y ago
    Don't forget the following argument: https://twitter.com/bcantrill/status/690580959981211648 https://twitter.com/bcantrill/status/690580959981211648
    - shawn-butler 11y ago
      Yes losing more respect for the guy with every passing hour.
      - rodgerd 11y ago
        Don't Google his exchanges with David Miller then.
        wstrange 11y ago
        That happened in 1996. People make mistakes. Give it a rest.
        chris_wot 11y ago
        No, it's valid. This same person hasn't ever apologised, but then turned around making out to be the bastion of womens' equality. The hypocrisy is stunning.
    - 11y ago
jsmthrowaway 11y ago
It's also worth considering that Joyent is likely feeling threatened by Docker picking up unikernel wonks, because until now Joyent has been able to keep Docker in a "containerization and deployment" box, competing on other things in SmartOS and other parts of their stack. Now Docker is pretty plainly coming for more of their pie (with the winds of "hot new valley thing" behind them, which Joyent distinctly lacks), and this wouldn't be the first time Cantrill has blogged out of feeling threatened or angry. I don't agree with minimizing arguments based upon personal opinions of the author. Please don't interpret my comment that way. I'm just pointing out context, which is worth considering when evaluating the arguments.
- mwcampbell 11y ago
  The arguments are either sound or they're not. Why does it matter who wrote them and what motives he or his employer might have?
  - viraptor 11y ago
    Cherry-picking examples that match own interests. If you know less about the subject than the author then you can't verify whether they base their arguments on all available information or not. Or put another way. You have two people presenting arguments for database designs. Both base them on known and cited research papers. Both provide sound arguments for their design. One is an independent researcher and one works for Oracle. What are the chances one of the designs will be very similar to Oracle's database?
  - rodgerd 11y ago
    When someone offers, with no evidence, a bunch of claims than smoking is in fact safe, and their Employer is BAT, it's quite relevant.
- dekobon 11y ago
  I don't think the posting had anything to do with Joyent's strategy in the market, but everything to do with him being goaded on Twitter into writing the article: https://twitter.com/bcantrill/status/690215406317875200 https://twitter.com/bcantrill/status/690215406317875200
cthalupa 11y ago
There's a lot of stuff Solaris got right, long before the Linux world did, and in some ways, it's still catching up. DTrace? Sure, there's a plethora of dynamic tracing tools in linux, but it's honestly just now starting to catch up with eBPF. If eBPF stack traces make it into 4.5, that might be the first time I can look at Linux dynamic tracing and go "Yep, it's arrived" Systemd certainly apes quite a bit of it's functionality from SMF (and, personally, I'd argue SMF still does basically everything better...) ZFS? Still the king of filesystem/logical volume management. Btrfs might catch up someday Zones? Again, still ahead of the linux equivalent in functionality. And lx branded zones are awesome. I'm not saying nothing needs to advance ever again in the world of OS research, but I think we need to be honest about how much we owe to Sun for having created the modern template for a great amount of functionality that Linux is just now having come into existence, and it's not like things at Joyent, OmniIT, Nexenta, and other Illumos developing shops have stagnated either. I often disagree with Bryan on specific points, but I think you do him a disservice. While many of the things Sun did might be viewed as an incremental update to existing concepts, it's still something that the Linux community has yet to catch up with. Anyway, even when he is wrong, I think he often brings up a viewpoint that results in some interesting discussion.
- vezzy-fnord 11y ago
  I never said anything of Linux (I am critical of it), and I don't know how you came up with this odd Linux/Solaris dichotomy.
  - cthalupa 11y ago
    What are the alternatives, in the *nix world? The BSDs are in much the same place as Linux on most of those specifics, or further behind, or heavily using the tech from the Solaris side. HP-UX? AIX? What do you think is doing better than Solaris or Illumos on those things?
    - nickpsecurity 11y ago
      You don't do it in UNIX because UNIX is fundamentally broken. That's the point. You do it through specialist software that works around the various problems. A common approach (i.e. compromise) in high-assurance security was to split systems between an untrusted, UNIX VM and critical components running directly on a microkernel/hypervisor. The kernels themselves were built as robust as possible sometimes with every potential, control or error state known. The apps outside VM's often used Ada or Java runtimes whose assurance and features were customized for apps needs. Robust middleware handled mediation and sometimes recovery. Many systems like this survived strong pentesting and worked without reported failures the field (or only failed-safe). Then, there's the shit most people are doing and that Bryan advocates with UNIX. I also called him out on it listing numerous counters... with references backing them... to his comment at vezzy-fnord above. https://news.ycombinator.com/item?id=10325607 https://news.ycombinator.com/item?id=10325607 Secure UNIX had already been tried by geniuses for a decade or two with always same results: architecture, language, and TCB were inherently so complex and insecure that even smallest versions had many 0-days and dozens of covert channels. He didn't respond, likely since he uses assertions instead of evidence. And all published evidence that I've ever seen contradicts his view of UNIX model superiority in robustness of any kind, sometimes performance. Now, he's making all kinds of assertions about unikernels, deliberately avoiding evidence on some (eg performance), praising UNIX model/tech, and ignoring faults in his own approach. Should we take his word this time given prior result? Definitely not.

Joeri 11y ago

Your opinion on the author has no bearing on the contents of the article, which i found well argued.

im_down_w_otp 11y ago
They're overwhelmingly argument by assertion. I'm not sure that counts as "well argued"? Like the stuff at the end about STM and M:N scheduling. There are systems that use both to tremendous effect. Erlang only offers an M:N scheduling model, and it works extremely well for building the kinds of systems Erlang was built for.
- nickpsecurity 11y ago
  Yeah, both examples plus him not backing up his performance assertion showed he was full of crap. Haskell did nearly bulletproof STM that I hear. I've seen other examples. Your Erlang example is good on M:N. Microkernel with work in AI planning still using it successfully with ever more efficient algorithms. JeOS performance characteristics of the past suggest unikernels might improve performance over monoliths or plain virtualization. Need real-world data rather than assertions. He seems to be all talk. He's also more critical of unikernel level security and robustness over well-known issues like POLA while ignoring that his own platform violates both POLA and other rules we've learned about INFOSEC over time. The only proven approaches were separation kernels a la Nizza architecture, capability model at OS or component level, and language-based protection w/ extra care on HW interfaces. He doesn't mention those because they oppose UNIX approach, which he ideologically supports, plus show his product is likely not trustworthy. This article isn't objective or reliable.
  - dmpk2k 11y ago
    I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems. Circa 2000, Solaris, Linux, and some (all?) BSDs had M:N threading, and all of them threw it away because there are numerous performance artifacts caused by two schedulers (OS and the M:N) conflicting with each other. Mr. Cantrill was there when this all happened, and even wrote a paper on it: ftp://ftp.cs.brown.edu/pub/techreports/96/cs96-19.pdf This doesn't affect Erlang as much simply because Erlang is really slow. I think of it as a waterline -- the lower the overhead of the language, the more likely you will run into the serious problems that M:N typically inflicts. E.g. priority inversion, and long and unpredictable latencies when the OS swaps out a thread that M:N wanted running. As for Haskell and STM, all I know on the topic is that some pretty damn smart engineers at IBM spent a good while trying to make STM work well, and gave up. See this ACM article: https://queue.acm.org/detail.cfm?id=1454466 https://queue.acm.org/detail.cfm?id=1454466. Perhaps Haskell managed to pull it off through the language restrictions it allows, but I’d like to see some compelling articles on that by engineers who know a thing or two; just because a language has STM doesn’t mean it does it well. Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's. While you might disagree with him, there’s sufficient literature to give his stance some legitimacy. Sweepingly calling his stance "full of crap" says a thing or two.
    - nickpsecurity 11y ago
      "I think Bryan Cantrill is referring to both STM and M:N in the context of high performance applications (aka, the norm for him, since he's a kernel engineer). In that sense, both of them do have problems." "Honestly, I think your comments about M:N and STM are more revealing of your ignorance rather that Cantrill's." Probably was. Idk who he is or what he does. I'm aware there were fads to claim the two could solve every problem under the Sun in their category. I'm one of those few that ignore fads to focus on any lessons we can learn from certain tech or research. He made a blanket assertion against at least three technologies in one article with no context. Anyone reading might think the techs don't work well in any context. So, I briefly called that. As evidence, I gave an example of STM that worked. In OS's, it had mixed results unless hardware accelerated and one typically had to protect I/O stuff with locks due to irreversibility. Far as M:N, only found OS use for it in security kernels (eg GEMSOS) to help supress covert, timing channels. Didn't expect him to know that use-case, though, since the cloud products are usually full of covert channels. And then there's MirageOS on unikernel end using type- and memory-safety for robust, network applications already showing fewer 0-days than alternatives did. So, all three already have real-world, beneficial use. Quite the opposite of his claim that leads one to believe that never happens. "Sweepingly calling his stance "full of crap" says a thing or two." In other comments, I did present data and specific examples to reject his claims about UNIX being a usable foundation for this sort of thing among others. His approach to such things was to ignore all counter evidence and/or leave the discussion. Eventually, a new article shows him making an adverti... err, a bunch of claims, some backed up and some assertions, about all kinds of tech in an anti-unikernel rant. Strange that you're fine with him ignoring his critic's counterpoints... with references... to his major claims but have trouble with how I handle minor, tangential ones. Says a thing or two indeed.
- mcguire 11y ago
  I personally, as a Rust guy, was disappointed by the loss of M:N threading; without that, you cannot effectively use threads as a design tool rather than simply ("simply" :-)) a parallelization/performance tool. Erlang has a lot of neat ideas.
  - masklinn 11y ago
    m:n does not an erlang make though (witness Go), and Rust was not headed in that direction.
    - mcguire 11y ago
      I know, I know. And Rust is a better systems language for it. Still, I can dream.
      - im_down_w_otp 11y ago
        Take a look at pony-lang. It's sorta like what Rust was once going to be. It's sort of implicitly going for a bare-metal Erlang-shaped thing. There's a lot missing, not the least of which is a set of abstractions over the rich primitives which provide simple programming interfaces that don't force a lot of the language's complexity on you, but if what you want is something that might one day be a really fast Erlangish it's probably the front-runner at the moment. I still have high hopes for BEAMJIT existing as a production-grade thing someday. That way I don't have to drop into C in my Erlang applications as often. Sure BEAMJIT will probably never be as fast, but if it can be good-enough while also not forcing me across the safety boundary to get to that good-enough state... that's a huge win.
  - zokier 11y ago
    I thought the idea in Rust was to provide solid primitives so that libraries can then provide m:n/green threading if wanted. And sure enough we have stuff like coio and mioco which provide coroutines. Is there something missing in those that you'd want from m:n threading?
- hinkley 11y ago
  Solaris used to have an M:N scheduling model and they've mostly abandoned it, didn't they? I wonder what Erlang got right that Solaris got wrong.
  - deleted 11y ago
    [deleted]
  - tormeh 11y ago
    Erlang is a low-throughput, low-latency language. It makes no apologies for the former and it even says so on the tin. That allows it to do stuff other languages/runtimes can't.
- the_why_of_y 11y ago
  I'd say he's half-right on the M:N scheduling. For implementing POSIX threads, M:N threading has a lot of extra complexity and few advantages, and worse performance. But if you don't have POSIX threads, but something higher-level that's managed by a runtime anyway, you don't need to worry about things like ensuring enough VM space and at least one allocated page for each thread stack. Erlang's and GHC's threads start out needing much less space than a single page, so you can start 10x more threads in the same amount of RAM.
shawn-butler 11y ago
Well-argued? His point if there is one is that: >> Unikernels are entirely undebuggable. For which evidence he provides the sound of some applause at some random conference and I don't believe is even remotely true or is so general to be vacuous. Your notion of well-argued differs greatly from mine. Unikernels solve an important class of problems that Joyent is interested in solving with another platform.. it's own. I see no mention of a significant benefit of unikernels: their decreased attack surface. There is a fairly new community web site at http://unikernel.org/ http://unikernel.org/ for those interested.
- chris_wot 11y ago
  Don't forget the following argument: https://twitter.com/bcantrill/status/690580959981211648 https://twitter.com/bcantrill/status/690580959981211648
  - shawn-butler 11y ago
    Yes losing more respect for the guy with every passing hour.
    - rodgerd 11y ago
      Don't Google his exchanges with David Miller then.
      - wstrange 11y ago
        That happened in 1996. People make mistakes. Give it a rest.
        chris_wot 11y ago
        No, it's valid. This same person hasn't ever apologised, but then turned around making out to be the bastion of womens' equality. The hypocrisy is stunning.
  - 11y ago

jsmthrowaway 11y ago

It's also worth considering that Joyent is likely feeling threatened by Docker picking up unikernel wonks, because until now Joyent has been able to keep Docker in a "containerization and deployment" box, competing on other things in SmartOS and other parts of their stack. Now Docker is pretty plainly coming for more of their pie (with the winds of "hot new valley thing" behind them, which Joyent distinctly lacks), and this wouldn't be the first time Cantrill has blogged out of feeling threatened or angry. I don't agree with minimizing arguments based upon personal opinions of the author. Please don't interpret my comment that way. I'm just pointing out context, which is worth considering when evaluating the arguments.

mwcampbell 11y ago
The arguments are either sound or they're not. Why does it matter who wrote them and what motives he or his employer might have?
- viraptor 11y ago
  Cherry-picking examples that match own interests. If you know less about the subject than the author then you can't verify whether they base their arguments on all available information or not. Or put another way. You have two people presenting arguments for database designs. Both base them on known and cited research papers. Both provide sound arguments for their design. One is an independent researcher and one works for Oracle. What are the chances one of the designs will be very similar to Oracle's database?
- rodgerd 11y ago
  When someone offers, with no evidence, a bunch of claims than smoking is in fact safe, and their Employer is BAT, it's quite relevant.
dekobon 11y ago
I don't think the posting had anything to do with Joyent's strategy in the market, but everything to do with him being goaded on Twitter into writing the article: https://twitter.com/bcantrill/status/690215406317875200 https://twitter.com/bcantrill/status/690215406317875200

cthalupa 11y ago

There's a lot of stuff Solaris got right, long before the Linux world did, and in some ways, it's still catching up. DTrace? Sure, there's a plethora of dynamic tracing tools in linux, but it's honestly just now starting to catch up with eBPF. If eBPF stack traces make it into 4.5, that might be the first time I can look at Linux dynamic tracing and go "Yep, it's arrived" Systemd certainly apes quite a bit of it's functionality from SMF (and, personally, I'd argue SMF still does basically everything better...) ZFS? Still the king of filesystem/logical volume management. Btrfs might catch up someday Zones? Again, still ahead of the linux equivalent in functionality. And lx branded zones are awesome. I'm not saying nothing needs to advance ever again in the world of OS research, but I think we need to be honest about how much we owe to Sun for having created the modern template for a great amount of functionality that Linux is just now having come into existence, and it's not like things at Joyent, OmniIT, Nexenta, and other Illumos developing shops have stagnated either. I often disagree with Bryan on specific points, but I think you do him a disservice. While many of the things Sun did might be viewed as an incremental update to existing concepts, it's still something that the Linux community has yet to catch up with. Anyway, even when he is wrong, I think he often brings up a viewpoint that results in some interesting discussion.

vezzy-fnord 11y ago
I never said anything of Linux (I am critical of it), and I don't know how you came up with this odd Linux/Solaris dichotomy.
- cthalupa 11y ago
  What are the alternatives, in the *nix world? The BSDs are in much the same place as Linux on most of those specifics, or further behind, or heavily using the tech from the Solaris side. HP-UX? AIX? What do you think is doing better than Solaris or Illumos on those things?
  - nickpsecurity 11y ago
    You don't do it in UNIX because UNIX is fundamentally broken. That's the point. You do it through specialist software that works around the various problems. A common approach (i.e. compromise) in high-assurance security was to split systems between an untrusted, UNIX VM and critical components running directly on a microkernel/hypervisor. The kernels themselves were built as robust as possible sometimes with every potential, control or error state known. The apps outside VM's often used Ada or Java runtimes whose assurance and features were customized for apps needs. Robust middleware handled mediation and sometimes recovery. Many systems like this survived strong pentesting and worked without reported failures the field (or only failed-safe). Then, there's the shit most people are doing and that Bryan advocates with UNIX. I also called him out on it listing numerous counters... with references backing them... to his comment at vezzy-fnord above. https://news.ycombinator.com/item?id=10325607 https://news.ycombinator.com/item?id=10325607 Secure UNIX had already been tried by geniuses for a decade or two with always same results: architecture, language, and TCB were inherently so complex and insecure that even smallest versions had many 0-days and dozens of covert channels. He didn't respond, likely since he uses assertions instead of evidence. And all published evidence that I've ever seen contradicts his view of UNIX model superiority in robustness of any kind, sometimes performance. Now, he's making all kinds of assertions about unikernels, deliberately avoiding evidence on some (eg performance), praising UNIX model/tech, and ignoring faults in his own approach. Should we take his word this time given prior result? Definitely not.