15 ms·

Container Linux on the Desktop [slides]

126 points by soohyung 8y ago

tony-allan 8y ago
Running everything in a container is the definition of commitment! I am looking forward to the day when this is normal.
- jillesvangurp 8y ago
  It of makes a lot of sense to do that. One thing I appreciate with running server side stuff in containers is just how easy it is. Instead of installing mysql, having to worry about setting that up, creating a mysql user, etc. I just run it with a one liner and it runs. And when I stop it, I can cleanup the containers and volumes and it is gone. No surprise that this has become the norm for server side deployments. It seems that that could be a nice thing to have with basically any kind of software package on the desktop as well. In a way that is the attraction of having browser based software: you just go to a particular website to run a web app. No installation needed. No need to worry about updates. Just run it. I actually get the architectural purity that drove this person to do this. Why settle for less? Why accept all the kludges, legacy cruft, stupid hacks, and ugliness that we accept as normal? As, she's demonstrated, there's no good reason.
- tapoxi 8y ago
  I've been running Silverblue (https://silverblue.fedoraproject.org/ https://silverblue.fedoraproject.org/) for the past month or so and for the most part you can use it as a daily driver. The OS itself is an immutable image created and updated with OSTree, and you can layer RPMs on top if they don't fit a containerized workflow. For applications, you either run Flatpaks (for desktop) or Docker/OCI images through podman.
  - watersb 8y ago
    I am new to Silverblue, but also using it daily for the past month. An important aspect of it, I think, is "rootless" podman -- I can create and manage containers without elevated privileges. Any required root escalation is done in the containers. Still, it is weird. GUI apps do work, but hmm. Solaris Zones are better-integrated than this newfangled podman stuff that you kids are using these days.
willtim 8y ago
I must say I am tempted by Qubes OS as a way to get this level of isolation between apps. However I'd likely need a new laptop, as RAM requirements are much higher.
- AstralStorm 8y ago
  8 GB is easily enough for most cases. The main source of trouble is web browsers and IDEs having problems at low memory... (As if 2GB is not enough RAM for a web browser or a glorified text editor. Shame on them!) Those same applications cause trouble on 8GB system. Of course you will need more if you want to play high end games in a VM. Or run many Windows instances as that hog eats 512 MB RAM when fully loaded in and doing nothing. (Unless it is ReactOS which is still frugal.) 16 GB RAM essentially guarantees high comfort in a such VM system as you can usually allocate extra GBs to offending special purpose VMs.
- AllegedAlec 8y ago
  I've been considering QubesOS for my next laptop (won't do it on desktop yet; still like my gaming too much). My old netbook is dying, and I'm considering something more powerful to do coding on. However, given that the lead of Qubes just left, I'm wondering what the future of the project is going to look like.
- chupasaurus 8y ago
  I can't trust anything which based on Xen and doesn't have a battalion of paid engineers for support.
- AnIdiotOnTheNet 8y ago
  Qubes OS has a significant limitation in that it isn't designed to allow anything to run in dom0, so nothing can use the GPU.
yankcrime 8y ago
The corresponding talk is on Youtube, here: https://www.youtube.com/watch?v=gES4-X6y278 https://www.youtube.com/watch?v=gES4-X6y278
reacharavindh 8y ago
Very interesting work. I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it's done. On the other hand, running container images for wmeverything including text editor seems like a NIMBYism in OS and packages. There is a reason why our OSes evolved with package managers. Sharing and reusing common libraries so that they can be updated once safely. Bug in libsodium? Update libsodium in your system, and all applications that use it automatically get new version. With containers, you have to rely on each and every container to update libsodium... Secondly, it takes away the sharing so you have several copies of libraries for each applications you use as containers.. What does it do to memory usage, and disk usage? Very interesting either way, and got me thinking about using such for specific cases.
- m_mueller 8y ago
  I guess it's give and take - on one hand containers would isolate processes such that a security bug in an application shouldn't allow an attacker to propagate to the rest of the system. On the other, updates are not centralized anymore as you pointed out. Then again, the most commonly used distros have a slow update cycle anyways, so I don't think it would change that much if they rebuild container images rather than packages for each release. Plus, isolation would allow software to be tested independently from each other, so rolling distros could become easier to handle for the maintainers and more stable. IMO from a development perspective it makes sense as a step forward.
- the8472 8y ago
  It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its children. The pledge/unveil model is far more elegant. > What does it do to memory usage, and disk usage? You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient. But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.
xte 8y ago
In my own personal opinion container idea is "meh" and today's usage trends are AWFUL. They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. You can't run unsafe software in safety, it's a myth. Or worse is giving trust to a specific tech and so ignore both it's potential mistrust and other software security implications. The future for me is Nix{,OS}/Guix{,SD} certainly not "chroots"/"jails"/"zones"/"lpar"/*.
- trulyrandom 8y ago
  > They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. I agree. Especially Flatpak and AppImage facilitate this goal. I do run some software that communicates with the internet in a bubblewrap sandbox, like Chromium and Transmission, but other than that I shouldn't have to run every piece of software in a container to be safe.
  - xte 8y ago
    Not only that: take a look at Emacs: essentially no one Emacs is equal to another. It's so flexible that any users bend it (easily) to their needs and desire. Sharing their configs is a mean for any users to evolve, acquire knowledge easily; you have a problem or need something? Ok go look for others chances that they already see and solved that problem are really high. With "black boxes" you can only customize what black box dev's have leaved to their users, real changes are hard, you have to checkout code, study it, modify it, rebuilt, ... in the end you're became as "standard" as possible without freedom and personal experimentation even if you have the open code. That's easy for companies since they deal with "standard" "Ford model like" people, but that's a killer for evolution especially evolution driven by people/users, not upstream/companies. If you can tailor software to fit your needs as you like you get a friendly personal environment and you have "a bit of power" on society, you still need upstream work but you are also a bit independent, and the same is for upstream to have help from the community they need to comply with an heterogeneous community with users, not consumers. We are in the end interdependent so forced to cooperate in a relative peace. On the over side we totally depend on upstream being effectively powerless. Oh yeah, you can choose different software, at least for now, but that need to exists, that's no more a community. A simple example a proprietary software, Master pdf editor, gain a bit of success in GNU/Linux world and decide to insert watermark on modify pdfs by free version. If it's distributed by single distro, single distros can keep old version for long time. Leaving all needed time to their user to switch. If you relay direct on upstream you discover the new "feature" a day perhaps without warning because it's auto-updated for instance, and you may have no time, no choice. This also happen recently with the "tweaked" Android settings by Google and I think many many other cases. Freedom it's not only "being free of doing something" it's also can do something easily, have a system that let you be as free as you like.
aritmo 8y ago
You can get this running with LXD (system containers). Some people managed to get a whole GUI running in a LXD container.
DyslexicAtheist 8y ago
This is a really nice idea for anyone who wants to learn containers from scratch and get deeper into appsec. But I can't think of a valid reason why anyone would want to use this in practice when there is QubesOS. If the reason is to increase my base-layer of security for OpSec, then this is a poor choice. Perhaps this is what she meant in the slides when she says don't try this at home ... maybe she explained it better in the talk (I haven't watched it). Seriously don't do this at home unless it's for educational purposes (in that case I agree it is awesome).
ivnilv 8y ago
is there an actual talk we can listen/watch somewhere ? Thanks
- Jaruzel 8y ago
  Yes, already linked in a comment: https://news.ycombinator.com/item?id=18500903 https://news.ycombinator.com/item?id=18500903
larrywright 8y ago
I got a new MacBook Pro from work a couple of months ago, and decided to try a scaled back version of this. You can’t reasonably run graphical apps in Docker on MacOS, but most of the CLI tools that I would install via HomeBrew can be run in Docker. I took the same approach that Jess did, and set up a a shell alias for these commands. That way I run the command the way I would normally run it from Terminal.app, but the app isn’t installed at all on my host. To be clear: I have no real reason to do this, other than to just see how it works. It’s nice to know that if I got a new machine tomorrow, all of the CLI stuff I need is defined in some Dockerfiles and bash aliases, and could be reinstalled pretty quickly. There are other ways to do that, but it’s a fun experiment. In practice, there’s really very little noticeable overhead to running things this way on modern hardware, but I’m also not running things in tight loops where that overhead would matter. If you’re curious at all about this, Jess has a couple of Github repos worth looking at: https://github.com/jessfraz/dockerfiles/ https://github.com/jessfraz/dockerfiles/ https://github.com/jessfraz/dotfiles https://github.com/jessfraz/dotfiles Specifically, her aliases are set up here: https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc
- liveoneggs 8y ago
  I run as much python/node/ruby/whatever inside of containers as possible but packaging up something like vim would probably just make me angry with the little startup delays :)
ashrk 8y ago
I just want to be able to have multiple, suspendible desktop sessions with different apps running and/or installed and different files available. Ideally I should be able to kick up more than one at a time to let them exchange data. Preferably without having to run a full VM per session. Bonus points if I can ship them between physical machines, though I know that's a long shot. That's more interesting to me than individually-containerized applications. I want to have per-project and/or per-task-group desktop sessions that are right where I left them when I spin them back up, within reason. That's the one big "killer feature" I feel lacking in every modern desktop OS I use.
- fulafel 8y ago
  You can stop and continue tasks easily (eg just SIGSTOP them), but if you want them to stop using memory and kernel resources while suspended, then it's equivalent to process checkpointing. Which has proven a hard problem on Linux so far.
- yiyus 8y ago
  This is the main reason I prefer CLI programs: I can have several sessions inside dvtm running in abduco and suspend/restore sessions at any time. I'd love to see what you propose, but I don't think there is anything remotely similar.

126 points by soohyung 8y ago

tony-allan 8y ago

Running everything in a container is the definition of commitment! I am looking forward to the day when this is normal.

jillesvangurp 8y ago
It of makes a lot of sense to do that. One thing I appreciate with running server side stuff in containers is just how easy it is. Instead of installing mysql, having to worry about setting that up, creating a mysql user, etc. I just run it with a one liner and it runs. And when I stop it, I can cleanup the containers and volumes and it is gone. No surprise that this has become the norm for server side deployments. It seems that that could be a nice thing to have with basically any kind of software package on the desktop as well. In a way that is the attraction of having browser based software: you just go to a particular website to run a web app. No installation needed. No need to worry about updates. Just run it. I actually get the architectural purity that drove this person to do this. Why settle for less? Why accept all the kludges, legacy cruft, stupid hacks, and ugliness that we accept as normal? As, she's demonstrated, there's no good reason.
tapoxi 8y ago
I've been running Silverblue (https://silverblue.fedoraproject.org/ https://silverblue.fedoraproject.org/) for the past month or so and for the most part you can use it as a daily driver. The OS itself is an immutable image created and updated with OSTree, and you can layer RPMs on top if they don't fit a containerized workflow. For applications, you either run Flatpaks (for desktop) or Docker/OCI images through podman.
- watersb 8y ago
  I am new to Silverblue, but also using it daily for the past month. An important aspect of it, I think, is "rootless" podman -- I can create and manage containers without elevated privileges. Any required root escalation is done in the containers. Still, it is weird. GUI apps do work, but hmm. Solaris Zones are better-integrated than this newfangled podman stuff that you kids are using these days.

willtim 8y ago

I must say I am tempted by Qubes OS as a way to get this level of isolation between apps. However I'd likely need a new laptop, as RAM requirements are much higher.

AstralStorm 8y ago
8 GB is easily enough for most cases. The main source of trouble is web browsers and IDEs having problems at low memory... (As if 2GB is not enough RAM for a web browser or a glorified text editor. Shame on them!) Those same applications cause trouble on 8GB system. Of course you will need more if you want to play high end games in a VM. Or run many Windows instances as that hog eats 512 MB RAM when fully loaded in and doing nothing. (Unless it is ReactOS which is still frugal.) 16 GB RAM essentially guarantees high comfort in a such VM system as you can usually allocate extra GBs to offending special purpose VMs.
AllegedAlec 8y ago
I've been considering QubesOS for my next laptop (won't do it on desktop yet; still like my gaming too much). My old netbook is dying, and I'm considering something more powerful to do coding on. However, given that the lead of Qubes just left, I'm wondering what the future of the project is going to look like.
chupasaurus 8y ago
I can't trust anything which based on Xen and doesn't have a battalion of paid engineers for support.
AnIdiotOnTheNet 8y ago
Qubes OS has a significant limitation in that it isn't designed to allow anything to run in dom0, so nothing can use the GPU.

yankcrime 8y ago

The corresponding talk is on Youtube, here: https://www.youtube.com/watch?v=gES4-X6y278 https://www.youtube.com/watch?v=gES4-X6y278

reacharavindh 8y ago

Very interesting work. I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it's done. On the other hand, running container images for wmeverything including text editor seems like a NIMBYism in OS and packages. There is a reason why our OSes evolved with package managers. Sharing and reusing common libraries so that they can be updated once safely. Bug in libsodium? Update libsodium in your system, and all applications that use it automatically get new version. With containers, you have to rely on each and every container to update libsodium... Secondly, it takes away the sharing so you have several copies of libraries for each applications you use as containers.. What does it do to memory usage, and disk usage? Very interesting either way, and got me thinking about using such for specific cases.

m_mueller 8y ago
I guess it's give and take - on one hand containers would isolate processes such that a security bug in an application shouldn't allow an attacker to propagate to the rest of the system. On the other, updates are not centralized anymore as you pointed out. Then again, the most commonly used distros have a slow update cycle anyways, so I don't think it would change that much if they rebuild container images rather than packages for each release. Plus, isolation would allow software to be tested independently from each other, so rolling distros could become easier to handle for the maintainers and more stable. IMO from a development perspective it makes sense as a step forward.
the8472 8y ago
It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its children. The pledge/unveil model is far more elegant. > What does it do to memory usage, and disk usage? You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient. But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.

xte 8y ago

In my own personal opinion container idea is "meh" and today's usage trends are AWFUL. They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. You can't run unsafe software in safety, it's a myth. Or worse is giving trust to a specific tech and so ignore both it's potential mistrust and other software security implications. The future for me is Nix{,OS}/Guix{,SD} certainly not "chroots"/"jails"/"zones"/"lpar"/*.

trulyrandom 8y ago
> They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. I agree. Especially Flatpak and AppImage facilitate this goal. I do run some software that communicates with the internet in a bubblewrap sandbox, like Chromium and Transmission, but other than that I shouldn't have to run every piece of software in a container to be safe.
- xte 8y ago
  Not only that: take a look at Emacs: essentially no one Emacs is equal to another. It's so flexible that any users bend it (easily) to their needs and desire. Sharing their configs is a mean for any users to evolve, acquire knowledge easily; you have a problem or need something? Ok go look for others chances that they already see and solved that problem are really high. With "black boxes" you can only customize what black box dev's have leaved to their users, real changes are hard, you have to checkout code, study it, modify it, rebuilt, ... in the end you're became as "standard" as possible without freedom and personal experimentation even if you have the open code. That's easy for companies since they deal with "standard" "Ford model like" people, but that's a killer for evolution especially evolution driven by people/users, not upstream/companies. If you can tailor software to fit your needs as you like you get a friendly personal environment and you have "a bit of power" on society, you still need upstream work but you are also a bit independent, and the same is for upstream to have help from the community they need to comply with an heterogeneous community with users, not consumers. We are in the end interdependent so forced to cooperate in a relative peace. On the over side we totally depend on upstream being effectively powerless. Oh yeah, you can choose different software, at least for now, but that need to exists, that's no more a community. A simple example a proprietary software, Master pdf editor, gain a bit of success in GNU/Linux world and decide to insert watermark on modify pdfs by free version. If it's distributed by single distro, single distros can keep old version for long time. Leaving all needed time to their user to switch. If you relay direct on upstream you discover the new "feature" a day perhaps without warning because it's auto-updated for instance, and you may have no time, no choice. This also happen recently with the "tweaked" Android settings by Google and I think many many other cases. Freedom it's not only "being free of doing something" it's also can do something easily, have a system that let you be as free as you like.

aritmo 8y ago

You can get this running with LXD (system containers). Some people managed to get a whole GUI running in a LXD container.

DyslexicAtheist 8y ago

This is a really nice idea for anyone who wants to learn containers from scratch and get deeper into appsec. But I can't think of a valid reason why anyone would want to use this in practice when there is QubesOS. If the reason is to increase my base-layer of security for OpSec, then this is a poor choice. Perhaps this is what she meant in the slides when she says don't try this at home ... maybe she explained it better in the talk (I haven't watched it). Seriously don't do this at home unless it's for educational purposes (in that case I agree it is awesome).

ivnilv 8y ago

is there an actual talk we can listen/watch somewhere ? Thanks

Jaruzel 8y ago
Yes, already linked in a comment: https://news.ycombinator.com/item?id=18500903 https://news.ycombinator.com/item?id=18500903

larrywright 8y ago

I got a new MacBook Pro from work a couple of months ago, and decided to try a scaled back version of this. You can’t reasonably run graphical apps in Docker on MacOS, but most of the CLI tools that I would install via HomeBrew can be run in Docker. I took the same approach that Jess did, and set up a a shell alias for these commands. That way I run the command the way I would normally run it from Terminal.app, but the app isn’t installed at all on my host. To be clear: I have no real reason to do this, other than to just see how it works. It’s nice to know that if I got a new machine tomorrow, all of the CLI stuff I need is defined in some Dockerfiles and bash aliases, and could be reinstalled pretty quickly. There are other ways to do that, but it’s a fun experiment. In practice, there’s really very little noticeable overhead to running things this way on modern hardware, but I’m also not running things in tight loops where that overhead would matter. If you’re curious at all about this, Jess has a couple of Github repos worth looking at: https://github.com/jessfraz/dockerfiles/ https://github.com/jessfraz/dockerfiles/ https://github.com/jessfraz/dotfiles https://github.com/jessfraz/dotfiles Specifically, her aliases are set up here: https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc

liveoneggs 8y ago
I run as much python/node/ruby/whatever inside of containers as possible but packaging up something like vim would probably just make me angry with the little startup delays :)

ashrk 8y ago

I just want to be able to have multiple, suspendible desktop sessions with different apps running and/or installed and different files available. Ideally I should be able to kick up more than one at a time to let them exchange data. Preferably without having to run a full VM per session. Bonus points if I can ship them between physical machines, though I know that's a long shot. That's more interesting to me than individually-containerized applications. I want to have per-project and/or per-task-group desktop sessions that are right where I left them when I spin them back up, within reason. That's the one big "killer feature" I feel lacking in every modern desktop OS I use.

fulafel 8y ago
You can stop and continue tasks easily (eg just SIGSTOP them), but if you want them to stop using memory and kernel resources while suspended, then it's equivalent to process checkpointing. Which has proven a hard problem on Linux so far.
yiyus 8y ago
This is the main reason I prefer CLI programs: I can have several sessions inside dvtm running in abduco and suspend/restore sessions at any time. I'd love to see what you propose, but I don't think there is anything remotely similar.