Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

271–280 of 313 posts

Re: WebAssembly: Docker Without Containers

#271
post #256
post #202

Earlier quoted context omitted.

Genuine question: How much of that financial improvement is due to them requiring companies to now pay for Docker Desktop on macOS? We found ourselves essentially with no option but to pay up for a full year on short notice. We want nothing of their other paid offerings like builds or repo hosting. The sales rep basically confirmed we're just paying for the thing we used to get for free now. The whole call was a gian…

Last time I checked, it was completely possible to install Virtualbox and normal Docker CLI on a Mac, and everything worked well (for me), without Docker Desktop at all. But that last time was on Intel Macs; maybe the situation is completely different on ARM.

It doesn't work on M1 last I checked. And anyway even if they updated Virtualbox for ARM, Oracle is predatory and sends nasty emails about paying up if they detect anyone in your company uses it.

Re: WebAssembly: Docker Without Containers

#272
post #202

Earlier quoted context omitted.

Genuine question: How much of that financial improvement is due to them requiring companies to now pay for Docker Desktop on macOS? We found ourselves essentially with no option but to pay up for a full year on short notice. We want nothing of their other paid offerings like builds or repo hosting. The sales rep basically confirmed we're just paying for the thing we used to get for free now. The whole call was a gian…

Genuine question: do you think people creating software that’s incredibly valuable for you should’t get paid? You had it for free for a long time? Lucky you!

It feels like a bait and switch. They got us hooked on a free product and then slapped us with a bill and only short time to change all of our software to not use it if we didn't want to. Also the pricing jumped up the longer you waited to sign. So we had little time to evaluate Rancher and others.

I do agree it is a product that is potentially worth paying for. I do NOT think that the product is worth the amount we were suddenly forced to pay. It felt like extortion.

Re: WebAssembly: Docker Without Containers

#273
post #221

Earlier quoted context omitted.

> Obviously we're going to focus heavily on dumping Docker Desktop as fast as possible in the next quarters. If you need to invest significant effort into dumping it, it's almost certainly cheaper to just pay for it. Especially so if the alternative makes any sort of compromise on developer experience.

My workplace is also working on dumping docker desktop. Their website says it's $24 per month per user if you have over 100 users. We have around 2000 engineers, so it's half a million dollars a year for something that used to be free. If it takes two engineers half a year to get a replacement working you're already back in black, and honestly I'm not even sure why (in our specific case) it would take that long when…

In our case we have multiple tools that wrap docker and at first try none of them worked with podman. Podman doesn't actually have an API socket you can interact with. There is something called podman-helper but for the life of me I could not get it to work reliably. Also the API responses were not formatted the same way so now our code has to detect and fork logic if it is podman

And this is only the first example I saw. Now we have to root out all apps everywhere across the company that might integrate this tightly with docker.

Then there are performance considerations. Docker Inc apparently did quite a bit to improve performance, especially disk perf. We need to verify all of our existing workflows still work reliably.

None of this is hard, it just takes time and effort.

Re: WebAssembly: Docker Without Containers

#274
post #271
post #256

Earlier quoted context omitted.

Last time I checked, it was completely possible to install Virtualbox and normal Docker CLI on a Mac, and everything worked well (for me), without Docker Desktop at all. But that last time was on Intel Macs; maybe the situation is completely different on ARM.

It doesn't work on M1 last I checked. And anyway even if they updated Virtualbox for ARM, Oracle is predatory and sends nasty emails about paying up if they detect anyone in your company uses it.

I remember that the open-source Virtualbox part is free from any nagware. The closed-source parts are those needed for desktop integration (good screen, clipboard, file sharing, etc), but they are not needed for running a Linux VM with Docker (or some other container runtime BTW).

Re: WebAssembly: Docker Without Containers

#275
post #202

Earlier quoted context omitted.

Solomon is no longer at Docker (hasn’t been for a while) and Docker Inc is doing extremely well financially after the split and renewed focus on developers. This Wasm release also shows they are very forward looking… I am very positive on the company and what they are doing (no affiliation other than like Scott and the team over there)

Genuine question: How much of that financial improvement is due to them requiring companies to now pay for Docker Desktop on macOS? We found ourselves essentially with no option but to pay up for a full year on short notice. We want nothing of their other paid offerings like builds or repo hosting. The sales rep basically confirmed we're just paying for the thing we used to get for free now. The whole call was a gian…

I’m mixed on this because I generally like paying for tools but this was too fast (institutional budget year pain) and Docker Mac was characterized by long-running unfixed bugs like high CPU usage. I think they really screwed up their business model and are burning through goodwill trying to recover but I wish they’d tried working with the community.

I mostly use the CLI so I have Podman a try and it took less than a single lunch to completely replace Docker for me. Performance is excellent for ARM, and acceptable for the x86 containers I infrequently use.

https://gist.github.com/acdha/9be1c3521af4f18d9f86264a889581...

Re: WebAssembly: Docker Without Containers

#276
post #168
post #102

Earlier quoted context omitted.

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's value proposition is convenient, reproducible, self-contained packaging of software. 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 Doc…

Docker containers solve the packaging-for-deployment problems that a ton of people used to have. Were they not solving it, they won't be so predominant.

Docker does handle deduplication on a certain level: every layer is only built once, and shared among all images that use it. This can be strategically used to seriously reduce the summary size of your containers.

Desktop users are not the target audience of Docker, except if you consider running a sham prod configuration on your dev machine desktop use. Containers are intended for the server side, and they are fine there.

Not sharing too much, and plainly embracing the existing chaotic practices of software creation and containing them, so that they don't interfere with each other, is the core value proposition of Docker containers. They do not require you to change your existing key practices at a lower level; your Babel / CMake / pyenv / whatnot setup can remain. But it changes the deployment story of it.

Re: WebAssembly: Docker Without Containers

#277
post #53

Earlier quoted context omitted.

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything

The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.

Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.

Re: WebAssembly: Docker Without Containers

#278
post #165
post #143

Earlier quoted context omitted.

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'...

Ah the typical only others are bad coders.

“Bad” is a value judgement. I’d go more with “taking on problems we don’t have” - J2EE made more sense if you were in a business like Atlassian’s where you sell an app to customers who wants to be able to run in it a bunch of different ways and configure many things without access to the source code. That especially made sense in the older era where apps were managed by sysadmins who didn’t have compilers and wouldn’t have gotten the source code from a vendor or wanted to pull it out of CVS.

That’s legitimate but, especially for open source developers, overkill and it pulls in a ton of maintenance work (e.g. I have several apps with a ton of CVEs in components which were never used but can’t be removed without breaking things, and thousands of lines of XML configuration which has to be analyzed to look for intentional customization to upgrade to the release version which has been patched. Now, maybe that’s doing it wrong but that’s multiple separate Java specialist development shops so it’s not just me being dense.).

Re: WebAssembly: Docker Without Containers

#279

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

@nine_k shared this https://programming-language-benchmarks.vercel.app/wasm-vs-r... in the comment tree. The results are pretty bad. You could lose 2x or more in cpu perf. There're cases where wasm is pretty close to native though.

I wouldn't call 50% loss "pretty bad". I mean sure, it's not great, but if you were to go from Rust to C# or Java you would most likely see a similar loss.

Re: WebAssembly: Docker Without Containers

#280

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

@nine_k shared this https://programming-language-benchmarks.vercel.app/wasm-vs-r... in the comment tree. The results are pretty bad. You could lose 2x or more in cpu perf. There're cases where wasm is pretty close to native though.

yeah I have known about this for a while, but no one I've spoken to personally believes me. to them WASM is pure win and there are no downsides.

when I mention performance, they kinda waffle a bit, saying "CPU is cheap" or something similar, and they start to show a hint of understanding when I say that cloud resources are billed by unit of CPU time, and by amount of RAM used. then I say that our mutual employer invokes lambdas hundreds of trillions of times per year and I think they briefly understand before being caught up in "new stuff is awesome" technology fetishism again.

it's exhausting.

everyone should live overseas for a couple years because it changes how you view the world... everyone should be a game developer for a couple years as well, because you will quickly notice just how unbelievably slow modern software is. more people need to see that.

security is important! portability is important! other things are important, always, and when you gain a sense of just how slow software is today in comparison to how unbelievably fast modern hardware is, it becomes very hard for me to think positively of anything that lowers performance further for almost any reason.

Post reply on HN