161–170 of 313 posts
Earlier quoted context omitted.
Well, http://nestedvm.ibex.org/
If the best counterpoint I could find is a dead proof of concept project from over a decade ago that only works on an unsupported compiler released 17 years ago, I would reevaluate my position
Earlier quoted context omitted.
This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…
> It's also like 2x as slow, Do you have links to recent benchmarks? My understanding is that there were investment in bridging the gap recently.
(Comparisons with small input sizes are not informative; look at larger runs.)
Earlier quoted context omitted.
Let me rework and clarify my point here a bit. The JVM has historically and famously sucked at sandboxing untrusted/partially trusted code. The JVM also isn’t a suitable compilation target for arbitrary and existing codebases. WASM is built to sandbox untrusted/partially trusted code. WASM is built as a compilation target rather than a complete hosted VM with bells and whistles. There are advantages and disadvantages…
"The JVM has historically and famously sucked at sandboxing untrusted/partially trusted code. The JVM also isn’t a suitable compilation target for arbitrary and existing codebases." We need to drill into this a bit more, because the WASM ecosystem can certainly learn lessons and do better than the JVM but this isn't quite the right set of lessons to learn. The JVM spec was written from day one to sandbox arbitrary an…
Earlier quoted context omitted.
- Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.
Literally every single one of those are well supported by Kubernetes and YAML. 1 and 3 are actually foundational to how k8s works. Forgive me for saying this, but I’m getting a “i don’t want to invest any effort understanding anything and so Kubernetes is bad” vibes from these comments.
Earlier quoted context omitted.
- Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.
I'm perfectly capable of writing correct code by hand (be it XML or YAML), my problem is with the contents of the configuration files. Especially for the legacy Java EE servers there's loads of boilerplate stuff that has to be there for some reason but you don't have any idea why. Until something breaks and somewhere a magic setting has to be 'fixed'...
Earlier quoted context omitted.
"The JVM has historically and famously sucked at sandboxing untrusted/partially trusted code. The JVM also isn’t a suitable compilation target for arbitrary and existing codebases." We need to drill into this a bit more, because the WASM ecosystem can certainly learn lessons and do better than the JVM but this isn't quite the right set of lessons to learn. The JVM spec was written from day one to sandbox arbitrary an…
I don’t really have much else to add to this discussion right now (it would require too much brain power whilst sitting next to a fire), but I would like to thank you for this very detailed and informative comment.
Earlier quoted context omitted.
Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.
> you have tp put it in a VM , which gives you a performance penalty This claim is dubious for many configurations of hardware accelerated virtualization. The hardware creates another ring 0 for each guest kernel, and guests run at the same level as the host. It's true that layering things like filesystems and networking incur overhead, but it's just as easy to pass through a physical disk, and bridge virtual TAP int…
Consider VMs like those which run Javascript, or WASM. JIT compilation can get pretty close to C performance, as JVM and LuaJIT show though, given enough RAM at runtime, and money for development.
Earlier quoted context omitted.
Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.
Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies . It's more like Flatpak or AppI…
Docker doesn't solve any packaging problems, though. It just piggybacks off of other package management solutions and allows ad-hoc, unmanaged modifications to OS images (the convenience) and contains that result for easy distribution.
But nothing in that process ensures reproducibility— the package managers wrapped in Dockerfiles are typically non-deterministic: what any set of commands for them will do depends on the state of the internet at the time they run. Similarly, composing Docker layers is not like composing packages: reuse of packaged objects is minimal rather than maximal, granularity is course, dependency management details may vary from container to container (as they may be based on different Linux distros or language-specific package management ecosystems), and it's very easy to end up with software and configuration installed with which there is no associated package management metadata.
Docker doesn't know anything about packages. Container scanning tools that do things like produce a bill of materials or scan for known vulnerabilities inside Docker containers simply have to guess at what distro is installed inside the container and then reconstruct that information in a distro-specific way to the best of their ability! Docker doesn't solve package management issues so much as punt on them (which is, of course, convenient, because package management is hard).
> [Docker is] more like Flatpak [...] only more popular and easy.
I don't think this is a sound comparison, either. Flatpak is a desktop-oriented containerization solution, for packaging graphical software that will predictably need to interact with the local filesystem, GPU, sound, and other resources. It's also a solution that tackles security updates and deduplication in a serious (and effective) way involving some discipline and enriching shared runtimes with actual metadata rather than just composing filesystem layers together.
It may indeed be easier to crap out something which will be considered a valid Docker image than it is to crap out something which will be considered a valid Flatpak application, but that does not make Docker easier. It's not easier for a desktop user to keep a collection of 50 Docker containers patched for security fixes than it is for a desktop user to keep a collection of Flatpak applications patched for security fixes. It's not easier to take a random Docker container and plug it into your operating system's native file picker or sound system for use with graphical applications than it is to do so with a random Flatpak application. It's not easier to determine what the heck exactly is actually installed in a Docker container than it is to see what is in a Flatpak container. It is not easier to plug a random Docker application into your operating system's default password manager, and so on, and so on.
Writing Flatpak packages requires actually thinking about things that Docker doesn't because Flatpak actually solves package management issues (and other things) that Docker doesn't.
Earlier quoted context omitted.
Literally every single one of those are well supported by Kubernetes and YAML. 1 and 3 are actually foundational to how k8s works. Forgive me for saying this, but I’m getting a “i don’t want to invest any effort understanding anything and so Kubernetes is bad” vibes from these comments.
So fundamental that those tools don't exist at all.
It’s not a particularly pleasant experience to discuss anything with you, as after you make a particularly vapid comment that is naturally rebuffed you seem to just try to make snarky replies rather than engage.
Please understand that if you post your hot takes here they may be discussed and challenged, and if you don’t want this then I would refrain from initially commenting.
In response to your comment: They do. All Kubernetes resources are typed with JSON-schema definitions. Because of course they are, how else would kubernetes validate anything. https://kubernetesjsonschema.dev/
Anyone who’s used k8s at all knows this, if only from the error messages. From this you get autocompletion and a wide ecosystem of gui configuration tools that work with everything, including custom resource definitions, which is really cool.
I used to like lens (https://k8slens.dev/desktop.html), but now I use the k8s plugins from IntelliJ
Despite the sandboxing one still cannot run untrsuted WASM code in the same process as trusted code due to hardware bugs. CPU vendors are not going to fix those anytime soon. Their message is to always use separated address space for security isolation. And since one need an external process in any case, native containers wins as they are faster by factor of two over WASM. EDIT: It does not even make sense to use WAS…
If your threat model includes hardware bugs, then a container doesn't really help, no? You can't really trust your containers without sandboxing them, and then you're killing your performance anyway.