Could this be used for GPU computation?
Depends on the browser. There's standards here but not everyone is conforming.
Show HN: Docker in the browser using x86-to-WASM recompilation
21–30 of 32 posts
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#22If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
For driving development costs to zero.
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#23Earlier quoted context omitted.
It's very true. However what is intrinsically better about a .deb or .rpm apart from having been there first? Are they the epitome of something? This is an honest question, I am really not sure. I vaguely remember that making an rpm was unpleasant and not very well documented, but it's been about ten yeats now...
An rpm just needs to add the missing scripts and binaries to your existing operating system. It doesn’t need a full mini OS image to run. So an rpm will be ~2mb while a docker image of the same thing might be 150mb. Rpm and deb packages also usually contain startup scripts so any services can be set to start when your computer starts. And they can put log files and database files in your regular filesystem without an…
As a counterpoint, a disadvantage of deb/rpm is that the installed code can actually scribble crap anywhere they like in your system. Did you just install a setuid program? Did it just install a service? Who knows!
As much as I’m not a fan of Docker, it does isolate the container’s file system and other resources from the OS, something that deb/rpm/brew etc don’t do.
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#24Earlier quoted context omitted.
An rpm just needs to add the missing scripts and binaries to your existing operating system. It doesn’t need a full mini OS image to run. So an rpm will be ~2mb while a docker image of the same thing might be 150mb. Rpm and deb packages also usually contain startup scripts so any services can be set to start when your computer starts. And they can put log files and database files in your regular filesystem without an…
As a counterpoint, a disadvantage of deb/rpm is that the installed code can actually scribble crap anywhere they like in your system. Did you just install a setuid program? Did it just install a service? Who knows! As much as I’m not a fan of Docker, it does isolate the container’s file system and other resources from the OS, something that deb/rpm/brew etc don’t do.
You can unpack those formats with `bsdtar xf PACKAGE` and that's something that is much harder to do with Docker.
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#25This is awesome, we have come full circle.
Not until we can have a browser within this docker container
JSLinux [0] can run a whole Alpine Linux distribution with a x window server and a built in browser. We are already past the days of browsers within operating systems within browsers.
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#26If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
There's a generation of people who appear to treat docker images as a combined packaging/distribution mechanism. Instead of learning to create a .deb or .rpm, they write a dockerfile. I tend not to use that sort of thing, but not just because of docker - there's a bundle of related practices that tend to turn my eye elsewhere. YMMV.
The next step is to replace the kernel with a type 1 hypervisor, doing container orchestration.
Thanks to them we already have a way out of POSIX monoculture.
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#27If you already have x86 to WASM, what do you need docker for? Seems like you already have all the encapsulation you could want at that point.
For driving development costs to zero.
Did I say zero? Overcomplicating development will drive costs into the negative because your payroll will decrease when people quit and no one wants to maintain that jenga tower.
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#28Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#29Earlier quoted context omitted.
As a counterpoint, a disadvantage of deb/rpm is that the installed code can actually scribble crap anywhere they like in your system. Did you just install a setuid program? Did it just install a service? Who knows! As much as I’m not a fan of Docker, it does isolate the container’s file system and other resources from the OS, something that deb/rpm/brew etc don’t do.
You can unpack those formats with `bsdtar xf PACKAGE` and that's something that is much harder to do with Docker.
I'm not sure if I understand the advantage here. Aren't container images trivial to export? I've done this many times as part of build pipelines
Re: Show HN: Docker in the browser using x86-to-WASM recompilation
#30Earlier quoted context omitted.
An rpm just needs to add the missing scripts and binaries to your existing operating system. It doesn’t need a full mini OS image to run. So an rpm will be ~2mb while a docker image of the same thing might be 150mb. Rpm and deb packages also usually contain startup scripts so any services can be set to start when your computer starts. And they can put log files and database files in your regular filesystem without an…
As a counterpoint, a disadvantage of deb/rpm is that the installed code can actually scribble crap anywhere they like in your system. Did you just install a setuid program? Did it just install a service? Who knows! As much as I’m not a fan of Docker, it does isolate the container’s file system and other resources from the OS, something that deb/rpm/brew etc don’t do.
I’ve been meaning to check out Nix for awhile for this exact reason. I want the state of my operating system to be a simple state machine managed by a package manager. Right now the filesystem on Ubuntu and friends it feels like a horrible mess of random stuff. You end up in a different OS state if apt fails halfway through installing, or if you install an old package, configure it then upgrade it vs installing a new package. The classic “make install” just puts files wherever it wants. And then there’s the layered complexity of language-specific package managers - which are needed because apt isn’t up to task.
This is one big advantage of docker. Applications are actually portable and isolated. We need more of that in our Linux distributions.