Atomic workstation

[Josh Boyer]

On Wed, Dec 3, 2014 at 4:40 PM, Colin Walters <walters at verbum.org> 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