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. 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. A related effort here in Qubes OS (https://wiki.qubes-os.org/wiki/UserFaq ) doesn't even try this, presumably for the reasons above. -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
