&quot;Citations please. This is the second time I&#x27;m asking.&quot;<p>I was giving you no references, only stuff you could Google, because you opened with an insult. I don&#x27;t do homework for people that do that. That said, I think I figured out where this really started:<p>&quot;by someone who says that &quot;performance assertion showed he was full of crap&quot;... which I have demonstrated isn&#x27;t true&quot;<p>This assertion <i>wasn&#x27;t</i> about M:N or STM. Those came way after the performance assertion. In his third paragraph, he tried to dismiss unikernels with a blanket assertion about [basically] how their performance can&#x27;t be good enough. Sums it up as saving context switches isn&#x27;t enough, as if that&#x27;s supporters&#x27; key metric. Other commenters wanted actual <i>data</i> on different types of unikernels and alternatives supporting his assertion. Instead of providing that, he says &quot; let’s just say that the performance arguments to be made in favor of unikernels have some well-grounded counter-arguments and move on.&quot;<p>Seriously? He just opened a counter to unikernels by saying their bad performance makes them worthless compared to alternatives like his, gives context-switches as a counterpoint, and then asks the reader to just take his word otherwise that there&#x27;s a good counter to anything they&#x27;d ask? Unreal... How could I not look at it as either arrogant or propaganda piece after that?<p>That was the performance assertion some others and I we&#x27;re talking about. That&#x27;s what I meant when I said &quot;plus&quot; the performance assertion. I can see how it could be read like it was connected to other two. The M:N and STM claim I made came from this sweeping statement he did for show far as I can tell:<p>&quot;the <i>impracticality of their approach for production systems</i>. As such, they will join transactional memory and the M-to-N scheduling model as&quot;<p>That was outside his section on performance toward the end after he talked about all kinds issues. So, he just says they were impractical for production systems. Despite being used in production systems beneficially. Not for ultra-high performance, like you said, but delivered on claims in some deployments and not purely a fad. So, he doesn&#x27;t substantiate his prior claims on HN when asked (with references supporting counters), his opening claim there, and doesn&#x27;t qualify those two. So, I called him out on all of it with the assumption this is an ego or ad piece more than any collection of solid, technical arguments. Only debugging claim really panned out and only partially.<p>I think we just got to talking cross-purposes from then on where the discussion conflated what the performance assertion was with my gripe about his overstatemetns on other two technologies. So, I&#x27;m dropping that tangent from here on now that I see what happened. Pointless as I don&#x27;t disagree with <i>your</i> performance assertion about two technologies so much as <i>his</i> unsubstantiated assertion about unikernels and overstatements about two technologies. So, I&#x27;m done there.<p>Far as my original comment, we&#x27;re still waiting on him to back up that performance assertion he made that unikernels provide no performance advantage despite reports to contrary from users. I&#x27;m also waiting for his security claims on OS vs hypervisors as I&#x27;ve seen more robust, even formally-verified, hypervisors than OS&#x27;s in general with <i>ZERO</i> verified or secure UNIX&#x27;s. Merely attempts. I&#x27;ve got citations going back to the 70&#x27;s supporting a minimal-TCB, kernelized model as superior to unrestrained, monolithic kernels in security. Love to see what his counterpoint is on that. Well, counterpoints given the volume and quality of evidence on my side. :)