Meaning every restart brings the system back to a fresh state. Most trojans/backdoors persist because they're able to modify the underlying OS to load them on b

Meaning every restart brings the system back to a fresh state. Most trojans/backdoors persist because they're able to modify the underlying OS to load them on boot. No, immutable OSes are -- by no means -- a new idea. This just uses the approach by default. Ok, then yes, Solaris read-only zones provide that level of immutability. Not talking about the kernel specifically. Although there's no reason the bootup time should be slowed down by loading unnecessary HAL, drivers, protocols, utilities that will never be used in a server setup. GBs of modules was referring to the rest of the OS made up mostly of features that will never be used by the server. A good operating system will be smart enough to only load what it needs; there will be some inefficiency, but protocols, drivers, HAL are actually used in server setups and are not usually the source of significantly increased boot times unless they're misconfigured. Also, with a proper service management facility and packaging, it should be possible to simply omit unnecessary items; services are usually what contribute the most to startup time. Crypto support is one big issue. I'd assume if the OS uses V8 at the base level, it should be able to be packaged with OpenSSL. Right, but you generally need more crypto administrative capability than OpenSSL alone provides to manage a sufficiently complex application. (e.g. gnupg, etc.) Security auditing at the OS level isn't required to the same degree it is on other OSes because the attack surface is so small. Sorry, I'll have to disagree on that point. Auditing is always important because it allows you to determine what happened and why when privileged operations are involved. The overhead of auditing is almost completely determined by what an administrator chooses to audit and how detailed that auditing is. For instance, you don't have to check for SSH vulnerabilities when there's no SSH. Perhaps you misunderstood what I referred to when I spoke of auditing; I don't speak of checking for vulnerabilities -- packaging should generally handle that in combination with metadata and reporting. I was referring to the recording of the assumption of privileged operations, system authentication, and related details. The userspace sandbox isn't necessary because everything that's network-facing already has to run through V8's sandbox. Disagree again; the point of having a userspace sandbox is in case something escapes V8's sandbox, which has been done in the past. It's an extra line of defense. Application-level vulnerabilities will always be an issue but that's nothing new. This doesn't solve all problems. Just reduces the potential for issues. While it reduces the number of problems in the existing space, I personally believe it creates new problems. I'm not sure the tradeoffs are worth it. I would rather see an immutable container with a minimised set of packages with proper auditing enabled. That's far easier to test and deploy and doesn't create new problems.