The spectrum of isolation: From bare metal to WebAssembly • Hacker News Board

Re: The spectrum of isolation: From bare metal to WebAssembly

#11

Post by pjmlp » Fri, Jan 16, 2026, 11:28 AM UTC

ianand wrote: post #3

ThierryBuilds wrote: post #2

I wrote this because I kept seeing developers (myself included) confuse language-level isolation like Python venv with OS-level isolation like Docker. I wanted to trace the actual technical boundaries between them. The article maps out the differences between common execution environments—from physical bare metal and VMs to containers, process sandboxes, and virtual environments—to create a mental model of where the…

Since you mention serverless it might be worth mentioning firecracker and v8 isolates.

Or CGIs running on httpd inside HP-UX Vaults, that is how old the idea happens to be.

Re: The spectrum of isolation: From bare metal to WebAssembly

#12

Post by cardanome » Fri, Jan 16, 2026, 11:44 AM UTC

nake89 wrote: post #8

bflesch wrote: post #6

> This website collects anonymous usage analytics data via GoatCounter and Umami. My uBlock origin shows that googlefonts.com and fonts.googleapis.com are being blocked. It irks me a bit that your message explicitly mentions two trackers but it fails to mention the Google tracking. Google is also not mentioned in your privacy policy. Is there a reason for this?

Your message sent me down a weird rabbit hole of trying to find privacy friendly alternative to google fonts. I found this: https://github.com/coollabsio/fonts They claim to be a privacy friendly drop-in replacement. Their main website: https://fonts.coollabs.io/

The easiest solution is to simply self host your fonts.

Re: The spectrum of isolation: From bare metal to WebAssembly

#13

Post by aragilar » Fri, Jan 16, 2026, 11:49 AM UTC

lateral_cloud wrote: post #9

ThierryBuilds wrote: post #2

I wrote this because I kept seeing developers (myself included) confuse language-level isolation like Python venv with OS-level isolation like Docker. I wanted to trace the actual technical boundaries between them. The article maps out the differences between common execution environments—from physical bare metal and VMs to containers, process sandboxes, and virtual environments—to create a mental model of where the…

Did you really write it though? Within the first paragraph it's fairly obvious this is heavily LLM-generated.

It also has weird definitions. Is nix a virtual environment? Is homebrew a virtual environment? Why is a sandbox different to a container? Type-1 vs Type-2 hypervisors are quite different, and there's no discussion about processes vs threads.

Re: The spectrum of isolation: From bare metal to WebAssembly

#14

Post by mrob » Fri, Jan 16, 2026, 12:09 PM UTC

cardanome wrote: post #12

nake89 wrote: post #8

Earlier quoted context omitted.

Your message sent me down a weird rabbit hole of trying to find privacy friendly alternative to google fonts. I found this: https://github.com/coollabsio/fonts They claim to be a privacy friendly drop-in replacement. Their main website: https://fonts.coollabs.io/

The easiest solution is to simply self host your fonts.

The easiest solution is to use the default font. This has the additional benefit of being the most legible font for every reader, because it's the one they have the most experience reading.

Re: The spectrum of isolation: From bare metal to WebAssembly

#15

Post by bmitch3020 » Fri, Jan 16, 2026, 12:14 PM UTC

The spectrum comes with multiple tradeoffs, and isn't a simple "bare metal is more secure" narrative. Because as you move into VMs, containers, and code sandboxes, you lose isolation which increases risks, but you also gain capabilities to limit the application which decreases risk. So I believe the most secure approach is layered with much multiple types of isolation working together.

For example, you may isolate a specific customer to bare metal so an escape doesn't compromise other customers. But within that bare metal, you may run containers because they make it easier to work with a read only root filesystem that's also trivial to upgrade. You can also add on user namespaces and seccomp in the container to minimize the risk of a container escape. And then the application may have its own sandbox that limits individual capabilities and which API calls it can run.

Every use case is different, and some layers may not be available depending on that use case. But rather than picking one point on the spectrum, one should pick a list of technologies that best solve each use case.

Re: The spectrum of isolation: From bare metal to WebAssembly

#16

Post by creata » Fri, Jan 16, 2026, 12:26 PM UTC

venv and sandboxes are such categorically different things that painting it as a spectrum the way this article does is more misleading than helpful.

I also think the article shouldn't mention chroot. From the man page:

> In particular, it is not intended to be used for any kind of security purpose,

I guess it could be part of a sandbox, but there are better tools for that purpose.

(I'm not sure what point there is in giving feedback on an article that's almost entirely LLM-generated, though.)

Re: The spectrum of isolation: From bare metal to WebAssembly

#17

Post by FjordWarden » Fri, Jan 16, 2026, 1:04 PM UTC

Ah, I think I found the reason as to why WebAssembly (in a browser or some other sandboxed environment) is not a suitable substrate for near native performance. It is a very ironic reason: you can't implement a JIT compiler that targets WebAssembly in a sandbox running in WebAssembly. Sounds like an incredibly contrived thing to do but once speed is the goal then a copy-and-patch compiler is a valid strategy for implementing a interpreter or a modern graphics pipeline.

Re: The spectrum of isolation: From bare metal to WebAssembly

#18

Post by Piraty » Fri, Jan 16, 2026, 1:05 PM UTC

cardanome wrote: post #12

nake89 wrote: post #8

Earlier quoted context omitted.

Your message sent me down a weird rabbit hole of trying to find privacy friendly alternative to google fonts. I found this: https://github.com/coollabsio/fonts They claim to be a privacy friendly drop-in replacement. Their main website: https://fonts.coollabs.io/

The easiest solution is to simply self host your fonts.

remember the times when common sense was to not accept the remote site's fonts, and thus web devs should not use them

Re: The spectrum of isolation: From bare metal to WebAssembly

#19

Post by syrusakbary » Fri, Jan 16, 2026, 1:14 PM UTC

FjordWarden wrote: post #17

Ah, I think I found the reason as to why WebAssembly (in a browser or some other sandboxed environment) is not a suitable substrate for near native performance. It is a very ironic reason: you can't implement a JIT compiler that targets WebAssembly in a sandbox running in WebAssembly. Sounds like an incredibly contrived thing to do but once speed is the goal then a copy-and-patch compiler is a valid strategy for impl…

> you can't implement a JIT compiler that targets WebAssembly in a sandbox running in WebAssembly

That's not completely true. With dynamic linking (now supported in WASIX), you can generate and link Wasm modules at runtime easily.

Re: The spectrum of isolation: From bare metal to WebAssembly

#20

Post by rafram » Fri, Jan 16, 2026, 1:39 PM UTC

bflesch wrote: post #6

> This website collects anonymous usage analytics data via GoatCounter and Umami. My uBlock origin shows that googlefonts.com and fonts.googleapis.com are being blocked. It irks me a bit that your message explicitly mentions two trackers but it fails to mention the Google tracking. Google is also not mentioned in your privacy policy. Is there a reason for this?

Google Fonts is not a tracker.

https://developers.google.com/fonts/faq/privacy

> For clarity, Google does not use any information collected by Google Fonts to create profiles of end users or for targeted advertising.