Jessie Frazelle

Maybe you already saw this:

https://blog.jessfraz.com/post/docker-containers-on-the-desktop/

It's pretty dated, but the state of containers has only improved since 2015, and this was usable for Google Hangouts (video) and YouTube all the way back then.

https://hub.docker.com/r/jess/chrome/

^ This got a push less than 24 hours ago

https://github.com/jessfraz/dockerfiles/blob/master/chrome/stable/Dockerfile

^ This is the Dockerfile, in a repo full of Dockerfiles for other things you might have had trouble putting into a container.

I tried this myself and had problems because (I think) I was on a very old LTS/stable distro with a necessity to use pretty old Docker release. This person is a maintainer on the Docker core team, so is most definitely tracking newest releases.

I use Chrome in a headless setup with Kubernetes and Docker (Jenkins with kubernetes-plugin) but it's not Headless Chrome, it's Xvfb that makes my setup headless. Chrome itself works great in a container. It's one excellent way to keep it from eating up gobs of RAM like it does: just give it less RAM (cgroups).

If you said "chroot jail" on purpose because you don't want Docker, I don't know why exactly, maybe because you don't think you can run graphical apps in a Docker container, but it's not true. You can!

You could also cobble something together and do it without Docker, but I'm not recommending that, I just saw this and thought it would be exactly what you're looking for. Hope this helps!

This is such a great thread, I'm excited to begin reading quite a few of the linked blogs (such as this one: https://acoup.blog/).

These ones are some of my favorites:
- www.wall.org/~aron/blog/ (physics, theology, history, philosophy)

- http://xahlee.info/ (math, emacs, keyboards, etc.)

- https://matt.might.net/articles/ (academy, compsci, etc.)

- https://www.joelonsoftware.com/ (programming, companies, etc.)

- https://danluu.com/ (technical topics)

- Mailing list in https://practicaltypography.com/

- http://paulgraham.com/

- https://math.ucr.edu/home/baez/ (math, physics)

- https://www.gwern.net/index (interesting articles)

- https://slatestarcodex.com/ and https://astralcodexten.substack.com/ (science, psychiatry, philosophy, rationality, etc.)

- http://steve-yegge.blogspot.com/ (programming)

- https://creativegood.com/blog/ (UX, and more)

- https://daringfireball.net/ (Apple)

- https://backreaction.blogspot.com/ (physics)

- https://thelastpsychiatrist.com/

- https://historyforatheists.com/ (historical myths)

- http://funcall.blogspot.com/ (programming, compsci)

- https://blog.fawny.org/ (accessibility, design)

- https://blog.jessfraz.com/ (technology)

- https://use-the-index-luke.com/blog (databases)

- https://weekendfisher.blogspot.com/ (God, love)

I can list some of my favorite articles from one of these blogs if anyone is interested.

Funny, I never thought about it that way. Namespaced processes being a linux kernel feature in the first place. That's where the whole container thing CAME from in the first place. It's only because the Windows and OSX kernels _don't_ support namespacing, that we have to run docker et al inside a virtual machine on those environments. It is not the container implementation, but the virtual machine, which makes containers "secure" on those platforms.

So put more finely: containers are not secure, anywhere. Virtual machines are. So you should run your containers inside virtual machines if security is important to you. Environments that can't run containers natively are forced into the more secure configuration.

If you're interested in the ongoing work to make containers more secure, Jessie Frazelle has very clear posts on the subject [1][2]. The Bubblewrap project also has a great summary of various approaches being used to "jail" container processes properly. [3]

[1] https://blog.jessfraz.com/post/containers-zones-jails-vms/
[2] https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/
[3] https://github.com/projectatomic/bubblewrap

It is very interesting. I don't want to intrude on their thread, but if others here vouch for this technique I'll politely ask them to look into the following:

- https://blog.jessfraz.com/post/docker-containers-on-the-desktop/

- http://boot2docker.io/

...has anyone here ever used this approach with nix apps that need to run on Windows "natively"? Writing a powershell script to silently install boot2docker with this special docker image wouldn't be too difficult. The DarkTable folks don't seem interesting in maintaining Win builds so this may be the perfect workaround.

NOTE: I realize that `File > Open Image` may be non-trivial, but surely there's a way to mount a host<->guest folder (e.g.: When using the application, the workspace is located in `C:\Users\$whoami\Documents\DarkTable\.jpg`)

Bryan is an O.G. systems engineer who worked at Sun and who's given many great talks and worked on lots of cool projects, and Jessie rose to prominence as a core docker developer and prolific and talented blogger/speaker, among other things. Both are well-known engineers with major contributions to open and closed source systems infrastructure. Steve Tuck I don't know yet, unfortunately.

Here are some more links if you're interested: https://blog.jessfraz.com/
https://www.youtube.com/results?search_query=bryan+cantrill

* Edit: Rephrased from "O.G. Sun Engineer", I don't know how accurate "O.G. systems engineer is", it's all relative anyway. For reference, I I'd consider Jess an "O.G. containerization engineer" :)

I started doing exactly that.

I've been reluctant to contribute to nodejs (e.g. electron) projects for some time, because I just don't want to run npm on a computer with any kind of remotely private data.

Lately there were just too many itches to scratch, so I went for a VM replicating my normal setup (dotfiles etc.), and I just use x2go, locally. Quick and dirty setup which is good enough when used infrequently.

My ideal setup would probably be closer to https://blog.jessfraz.com/post/docker-containers-on-the-desktop/, but it's more setup than I could be bothered with at the time. Maybe one day.