Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

Post reply on HN
Print view View original

221–230 of 313 posts

Re: WebAssembly: Docker Without Containers

#221

Post by ahtihn »

mdeeks wrote: post #202
ridruejo wrote: post #132

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…

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

Re: WebAssembly: Docker Without Containers

#222

Post by pantry-man »

ahtihn wrote: post #221
mdeeks wrote: 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…

> 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 there already are free alternatives.

Re: WebAssembly: Docker Without Containers

#223

Post by spreiti »

blacklion wrote: post #207
et1337 wrote: post #121

Earlier quoted context omitted.

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

The biggest missing thing (for production) is observability. Look at old-good JVM. It has tons of tools to analyze and understand behavior of your production system. You could have thread dumps (stack traces of all existing threads) at any moment with negligible performance impact, you could dump heap and analyze it off-site, you could have tons of metrics, about each dark corner of mutexes, GC process, about JIT, in…

This a 1000 times. People like to hate on Java but when there are problems to diagnose on production systems it is second to none.

But from my experience most people don't know these tools even exist so the only thing they do is restarting and guessing where the problem might be if it persists.

Re: WebAssembly: Docker Without Containers

#224

Post by jjtheblunt »

azakai wrote: post #177
jjtheblunt wrote: post #173

Earlier quoted context omitted.

how does pthread_create compile down?

In Emscripten that uses a pthread implementation layer built on top of Web Workers + a shared wasm Memory. Basically memory is shared, and you have atomic instructions, and each thread of execution gets its own Web Worker. That has some limitations, but for the most part it works just like you would expect pthreads to.

what's the non-most part that differs?

Re: WebAssembly: Docker Without Containers

#225

Post by azakai »

jjtheblunt wrote: post #224
azakai wrote: post #177

Earlier quoted context omitted.

In Emscripten that uses a pthread implementation layer built on top of Web Workers + a shared wasm Memory. Basically memory is shared, and you have atomic instructions, and each thread of execution gets its own Web Worker. That has some limitations, but for the most part it works just like you would expect pthreads to.

what's the non-most part that differs?

The main thread is a little special on the Web since it can't block, which can cause issues (like pthread_create doesn't immediately create an available pthread). There are workarounds for most of those issues (like pre-allocating a threadpool), and many applications work well, but sometimes not out of the box. See

https://emscripten.org/docs/porting/pthreads.html#special-co...

Re: WebAssembly: Docker Without Containers

#227

Post by jjtheblunt »

azakai wrote: post #225
jjtheblunt wrote: post #224

Earlier quoted context omitted.

what's the non-most part that differs?

The main thread is a little special on the Web since it can't block, which can cause issues (like pthread_create doesn't immediately create an available pthread). There are workarounds for most of those issues (like pre-allocating a threadpool), and many applications work well, but sometimes not out of the box. See https://emscripten.org/docs/porting/pthreads.html#special-co...

thank you

Re: WebAssembly: Docker Without Containers

#228

Post by the_gipsy »

alzaeem wrote: post #226

How is it possible that the image size is so much smaller with the WASM image compared to the Docker image? They need to ship the entire php runtime compiled to WASM, so I don’t see how it can be smaller

What do you think is in the docker image?

Re: WebAssembly: Docker Without Containers

#229

Post by ridruejo »

ahtihn wrote: post #221
mdeeks wrote: 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…

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

Yes, there is not a clear, free alternative. The license kicks in at 10MM in revenue, at that point there are certain things that are easier to pay than try to replace (Slack, Google Apps… ). Everyone has to make their own decision of where they focus their attention/money, in my case I have authorized for every one of my reports that has needed it and just moved on …

Re: WebAssembly: Docker Without Containers

#230

Post by cma »

angelmm wrote: post #192
nikeee wrote: post #190

One important thing about containers is that they isolate the process and it can not access files it is not explicitly allowed to. If I'm getting this right, WASI is basically just POSIX for WASM. This means that it does not provide some level of sandboxing that - for example - Deno has done. When running a Deno program, you have to actively allow network access or write access to the disk. It uses the built-in stuff…

That's how WASI is designed. You need to specifically mount a specific folder so it can be accessed by the module. The sockets support is not ready yet, that's the reason there's no specific limitation around networking. For me, the most interesting part is the component-model. It's still a proposal, but it will allow developers to specify the permissions for other modules (libraries) a main Wasm module may use. With…

Why can't this be done with native code and sandboxing? Native code in a sandbox doesn't require a VM, and there is a big perf cost for wasm. Is it just for one extra layer of security?
Post reply on HN