On Wed, Dec 3, 2014 at 4:40 PM, Colin Walters <walters@xxxxxxxxxx> wrote: > On Wed, Dec 3, 2014, at 03:47 PM, Josh Boyer wrote: >> >> Out of curiosity, couldn't you have an atomic/ostree "base" layer that >> is immutable (perhaps shared between Base, Server, Cloud, >> Workstation), and then use Docker containers on top of that as the >> "live" system? > > Good point, I didn't bring up the Docker part of Project Atomic. I think > it makes a significant amount of sense for Workstation to be investigating > using Docker for developer tooling, and that's already happening. Actually > containers for server side code help bring together the Server/Workstation > story far more than we ever had before. > > Previously in the package model, you can of course "yum install httpd $language" > on your workstation and start making a web app and testing it locally, > and many people do this today. But taking that same app > and ship it to a server had a different model. With containers, it becomes > a lot easier. > > It's also a huge benefit for web apps on the desktop to have isolated ports - > Docker makes it easy to have two web apps that both think they're listening > on port 80, and on the desktop you just look at "docker ps" to find where > they are. > > That said, this story breaks down a bit when one introduces clustering, > and that starts to lead back to local Vagrant usage or the like. > >> That would still fit with the "atomic is for Docker" >> approach you have today, while also giving some flexibility at the >> application layer. One could imagine Software installations become >> "create a new Docker container with this app inside of it", which then >> leads to it be automatically sandboxed, etc. > > No. Docker (alone) is not a desktop sandbox tool. As soon as any process > connects to your X server it has total control and could be a keylogger, > write data into your terminals, etc. With X, yes. It's not _worse_ than just running it all from the same OS install though. I thought this was less of a concern with Wayland, but I will admit I could be wrong. > And even doing so has lots of potential to break things. A simple example > is opening downloaded files from Firefox. If it tries to run /usr/bin/libreoffice > on a downloaded ODP, that's going to fail. (Or more likely the Firefox container would > simply not have a mime type association and tell you there's no app for it) > > Functional desktop app containers require *deep* integration with the UI and toolkit, > and modifying apps. Um, I guess I was assuming with X being network transparent, all of the containers would remote their display (or similar with however Wayland works). For things like mime type association, I was thinking there would be a local proxy that connected via some protocol (like d-bus) that started the libreoffice container. I don't really know, I thought about all of this for like 30 seconds. Aren't containers supposed to be the magic solution these days? I wasn't expecting it to work without effort, but I also wasn't expecting "no that can't be done" to be the answer either. Good things often take effort. josh -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
