The size feels like you can almost fit it in a L3 Cache-As-RAM

Sure, as long as you don't run out of `s

Hypervisor as a microkernel

Yes, there is a certain irony when you look at the cloud workloads with a type 1 hypervisor managing either serverless or container workloads.

Stripping away unused drivers (.config) and other "bloats" can get you surprisingly far.

And most importantly and TFA mentions it several times: stripping unused drivers (and even the ability to load drivers/modules) and bloat brings very real security benefits.

I know you were responding about the boot times but that's just the icing on the cake.

Mostly depends on how bloat correlates to attack surface, but you're right

But 150ms? That's boot time for dos or minix maybe (tiny kernels). 1s sure.

FreeBSD did some work to boot in 25ms.

Source: https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms...

You can do <10ms. I was working to see if I could get it under 1ms, but my best was 3.5ms

for example: https://firecracker-microvm.github.io/

Then the question becomes: to what extent do you trust Xen and Qubes RPC?

I do have to somewhat trust Xen, but Qubes' isolation relies on hardware virtualization (VT-d), which statistically has much less security issues than Xen itself. Most Xen advisories do not affect Qubes: https://www.qubes-os.org/security/xsa/

Verified software should satisfy the liveness property; otherwise, an infinite loop that never returns would pass as "correct."

Verifying realtime software goes even further and enforces an upper bound on the maximum number of ticks it takes to complete the algorithm in all cases.

Just append

  X-Crawl-Reason: Finding spare license plates, throttled ONLY to prevent service disruption. To the best of my knowledge, [legalese claiming good faith and compliance to all applicable laws]

(Mandatory disclaimer: IANAL, ignorance is no excuse for breaking laws)

> Code is an asset.

Funnily enough, this doesn't contradict "code is debt" because Asset = Equity + Liability.

My next malloc(3) is returning NAN.

I've always considered NaN too definitive for general industry languages like C, JS or Cobol where not even physics with calculus should be assumed. Maybe its ok for languages that at least expect math for engineers like Fortran or up..

How about we call it "Maybe a Number" and since equality can't work for it we still need a separate way to ask like: Math.whoIsTheMaN(me)