6 ms·

Canonical bringing Snappy Ubuntu to phone and desktop

117 points by Beacon11 11y ago

grabcocque 11y ago
I had a feeling this would happen. Containerisation as a trend has just as much to offer desktop OSes as it does for cloud clusters.
- motoboi 11y ago
  Is this really containerization as we know it, like Docker? To me, Android and alike just have a good separation between processes. This is, of course, the core of linux containers. But I don't need to deploy a system image to run an Android application.
  - riskable 11y ago
    Snappy packages are definitely containers in the sense that they 'contain' an application along with all its (runtime library) dependencies. Think of containers in order of size/scope like this: 1. Physical appliances. 2. Virtual machine images. 3. Docker images. 4. Snappy packages (and similar) At the top we have an actual physical piece of vendor-chosen hardware that "contains" a vendor-controlled application and execution environment. The end user has almost no control. Then comes virtual machine images which "contain" a vendor-controlled application inside a vendor-chosen operating system. Up next we have Docker images which "contain" a vendor-chosen execution environment and application but run inside the end user's chosen operating system (in a special sandbox). Lastly we have Snappy packages which "contain" an application and it's build/run time dependencies but run just like a regular application with user-controlled restrictions (via AppArmor).
    - e12e 11y ago
      As docker still doesn't really provide security (by design) - the main thing that docker brings with it is an awareness of dependencies. Now anyone can whip up a microservice that's ready to run in chroot, with minimal access to the rest of the system. Looks like Snappy packages does much the same thing. Try to hand-craft a chroot for Firefox, and see how far you get (at least without cheating and doing something like xhost+). Even some daemons can be a bit of work do chroot - eg: a working webserver/webapp-server with php that needs to resize images (pictures). If we can get more people to target docker/snappy (and we do) we get more applications and daemons that are easy(ish) to run in a chroot (or jail).
      - nickstinemates 11y ago
        Can you point to the security tradeoff/design decisions regarding Docker? I would really appreciate it.
        e12e 11y ago
        First there was OpenVZ, then there was LXC - which essentially allow running an isolated instance of the kernel (very much like BSD jails). LXC can be locked down with capabilities, kernel namespaces, cgroups, and allow for quite fine-grained isolation. But the focus of Docker is more on use ability: the equivalent of asking a process to sit in the corner and stare at the wall. It's an easy way to get a lot of unruly children to stop interfering with each other, if you have many corners. But they're kind-a-sorta still in the same room. Not chained to their desks, not blindfolded. But generally, docker doesn't do all that much locking down - if you have the libc/code to do something in a docker container, you can in general do it. The layered fs is mostly like a chroot - it's safe as long as the kernel is safe, and then it's completely unsafe - if the kernel isn't safe. The flip side of this is that if you write a program/daemon that works on regular gnu/linux, it'll work (as long as you provide the needed library code) in a docker container. And docker helps focus dependencies, in particular data dependencies (the other tricky part of getting something to run in a chroot - where's /etc/shadow? Where's /etc/group etc)). I'm sure we'll see Docker move in a stricter direction, as more people are wrapping their minds around isolation -- apart from the running under same kernel, LXC can do more. And we have things like rkt with kvm backend that takes all the hard work put into containers and magically(ish) transplants that to work with minimal vms. Docker did/do(?) one thing: it didn't allow you to run Docker in docker (you need/needed to run a "privileged" container for that). I'm not sure if that was as coherent as what you hoped for, but that's sort of what I tried to imply wrt design tradeoff.
deleted 11y ago
[deleted]
edude03 11y ago
Slightly off topic, but I'm really frustrated with the state of software packaging these days. Every solution tries to solve the same problems (reliable dependancy resolution, reliable installation and removal) but they all try and solve it in different incompatible and flawed ways. Consider the following: I need a reliable way to deploy my app to clients. The popular options are: 1) Source code + Configuration system (automake for example) 2) Binaries built for popular platforms (debs, rpms, exes) 3) Docker Image Source code means that the client needs the whole build tool chain, which might be quite + computationally expensive (especially on mobile) packages have to be built and maintained, and don't fully solve the dependancy issues (IE I might expect Ubuntu 14.04 to have a specific version of libc, but the user might have upgraded it, and I can't install my own incompatible version) and of course docker, ship my clients a operating system and require them to have and know how to configure the runtime so they can run my 1mb compiled binary. Also doesn't work on embedded devices. Ideally, in the future most distributions will move to functional package managers, and at least for mobile will have binaries for every possible version of dependencies available, but at the moment that's just a pipe dream and things like snappy don't get us any closer to that
- hasenj 11y ago
  I think Docker is meant for dev ops, not for casual users.
  - edude03 11y ago
    It's supposed to be for devops, but in practice developers use docker as a way to solve dependency management on the server more so than to seperate instances of apps from each other. Especially with "microservices" it makes more sense to have docker available on the server and allow each team to upload a image with all the deps already baked in.
    - falcolas 11y ago
      Yup. The tradeoff is that in operations we then need to work around all of the inherit disadvantages of running docker containers (network slowness, disk slowdown, logging, etc) to keep their systems performant.
CSDude 11y ago
We have evaluated Snappy a lot. In Snappy you can only share executables as dependencies, not librarires. So, you can use curl as a program, however if you want to use libcurl in your application, you have to include the library in package. When this list goes large, you have to keep track of the state of the every dependency you include. Bugfixes, security patches.. However, in regular package managers, you can also depend on libraries. And this solves a lot of headache, since those packages are shared globally and updated by system. I have almost never seen a backwards incompability caused by an update (some program needs to update liba, but some other program cannot use that upper version), it happens very rarely. If you insist of using a specific library version, there is nothing stopping you from including it in your package , like snappy's. Lastly, when you include libc a million times, or static compile your binaries, the size goes up and storage/bandwith also becomes an issue. I agree that Snappy solves some problems, but introduces new serious ones as well.
- riskable 11y ago
  The only problem Snappy creates is one of (initial) size. When every package is a .snap that means you're going to have many duplicated dependencies all over the place. It also means that any security update that exists in a common dependency will require updating a zillion Snappy packages all at once. Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both.
  - binarycrusader 11y ago
    Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. That's not really a solution though, just a mitigation. Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both. That's because the solution alone can't be through packaging; it requires changes at every level of the stack. The system needs to provide robust backwards-compatibility and sane packaging. Applications need to use interfaces responsibly, pick dependencies carefully, and use a sane build environment. When developers attempt to solve everything with the blunt hammer of packaging, they end up with a lot of "bent nails".
rdtsc 11y ago
Has anyone evaluated this vs NixOS (http://nixos.org/ http://nixos.org/) ? They seem to have some overlap and I've heard good things about NixOS, I like the theory behind it, but I find its Haskell-based configuration language hard to understand.
- vezzy-fnord 11y ago
  Yes: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html http://sandervanderburg.blogspot.com/2015/04/an-evaluation-a...
  - rdtsc 11y ago
    Thanks!
davidw 11y ago
I wish they'd just focus on making Ubuntu work. I mean, look at one of the flagship Ubuntu laptops, by Dell: http://en.community.dell.com/techcenter/os-applications/f/4613 http://en.community.dell.com/techcenter/os-applications/f/46... I'll still buy the things, because it's important to me to put my money where my mouth is, but it looks like it could use some significant investment to make it a better product.
- mixmastamyk 11y ago
  Yeah, ubuntu has always spread itself too thin, while neglecting bugfixing on its core products.

117 points by Beacon11 11y ago

I had a feeling this would happen. Containerisation as a trend has just as much to offer desktop OSes as it does for cloud clusters.

motoboi 11y ago
Is this really containerization as we know it, like Docker? To me, Android and alike just have a good separation between processes. This is, of course, the core of linux containers. But I don't need to deploy a system image to run an Android application.
- riskable 11y ago
  Snappy packages are definitely containers in the sense that they 'contain' an application along with all its (runtime library) dependencies. Think of containers in order of size/scope like this: 1. Physical appliances. 2. Virtual machine images. 3. Docker images. 4. Snappy packages (and similar) At the top we have an actual physical piece of vendor-chosen hardware that "contains" a vendor-controlled application and execution environment. The end user has almost no control. Then comes virtual machine images which "contain" a vendor-controlled application inside a vendor-chosen operating system. Up next we have Docker images which "contain" a vendor-chosen execution environment and application but run inside the end user's chosen operating system (in a special sandbox). Lastly we have Snappy packages which "contain" an application and it's build/run time dependencies but run just like a regular application with user-controlled restrictions (via AppArmor).
  - e12e 11y ago
    As docker still doesn't really provide security (by design) - the main thing that docker brings with it is an awareness of dependencies. Now anyone can whip up a microservice that's ready to run in chroot, with minimal access to the rest of the system. Looks like Snappy packages does much the same thing. Try to hand-craft a chroot for Firefox, and see how far you get (at least without cheating and doing something like xhost+). Even some daemons can be a bit of work do chroot - eg: a working webserver/webapp-server with php that needs to resize images (pictures). If we can get more people to target docker/snappy (and we do) we get more applications and daemons that are easy(ish) to run in a chroot (or jail).
    - nickstinemates 11y ago
      Can you point to the security tradeoff/design decisions regarding Docker? I would really appreciate it.
      - e12e 11y ago
        First there was OpenVZ, then there was LXC - which essentially allow running an isolated instance of the kernel (very much like BSD jails). LXC can be locked down with capabilities, kernel namespaces, cgroups, and allow for quite fine-grained isolation. But the focus of Docker is more on use ability: the equivalent of asking a process to sit in the corner and stare at the wall. It's an easy way to get a lot of unruly children to stop interfering with each other, if you have many corners. But they're kind-a-sorta still in the same room. Not chained to their desks, not blindfolded. But generally, docker doesn't do all that much locking down - if you have the libc/code to do something in a docker container, you can in general do it. The layered fs is mostly like a chroot - it's safe as long as the kernel is safe, and then it's completely unsafe - if the kernel isn't safe. The flip side of this is that if you write a program/daemon that works on regular gnu/linux, it'll work (as long as you provide the needed library code) in a docker container. And docker helps focus dependencies, in particular data dependencies (the other tricky part of getting something to run in a chroot - where's /etc/shadow? Where's /etc/group etc)). I'm sure we'll see Docker move in a stricter direction, as more people are wrapping their minds around isolation -- apart from the running under same kernel, LXC can do more. And we have things like rkt with kvm backend that takes all the hard work put into containers and magically(ish) transplants that to work with minimal vms. Docker did/do(?) one thing: it didn't allow you to run Docker in docker (you need/needed to run a "privileged" container for that). I'm not sure if that was as coherent as what you hoped for, but that's sort of what I tried to imply wrt design tradeoff.

deleted 11y ago

[deleted]

edude03 11y ago

Slightly off topic, but I'm really frustrated with the state of software packaging these days. Every solution tries to solve the same problems (reliable dependancy resolution, reliable installation and removal) but they all try and solve it in different incompatible and flawed ways. Consider the following: I need a reliable way to deploy my app to clients. The popular options are: 1) Source code + Configuration system (automake for example) 2) Binaries built for popular platforms (debs, rpms, exes) 3) Docker Image Source code means that the client needs the whole build tool chain, which might be quite + computationally expensive (especially on mobile) packages have to be built and maintained, and don't fully solve the dependancy issues (IE I might expect Ubuntu 14.04 to have a specific version of libc, but the user might have upgraded it, and I can't install my own incompatible version) and of course docker, ship my clients a operating system and require them to have and know how to configure the runtime so they can run my 1mb compiled binary. Also doesn't work on embedded devices. Ideally, in the future most distributions will move to functional package managers, and at least for mobile will have binaries for every possible version of dependencies available, but at the moment that's just a pipe dream and things like snappy don't get us any closer to that

hasenj 11y ago
I think Docker is meant for dev ops, not for casual users.
- edude03 11y ago
  It's supposed to be for devops, but in practice developers use docker as a way to solve dependency management on the server more so than to seperate instances of apps from each other. Especially with "microservices" it makes more sense to have docker available on the server and allow each team to upload a image with all the deps already baked in.
  - falcolas 11y ago
    Yup. The tradeoff is that in operations we then need to work around all of the inherit disadvantages of running docker containers (network slowness, disk slowdown, logging, etc) to keep their systems performant.

CSDude 11y ago

We have evaluated Snappy a lot. In Snappy you can only share executables as dependencies, not librarires. So, you can use curl as a program, however if you want to use libcurl in your application, you have to include the library in package. When this list goes large, you have to keep track of the state of the every dependency you include. Bugfixes, security patches.. However, in regular package managers, you can also depend on libraries. And this solves a lot of headache, since those packages are shared globally and updated by system. I have almost never seen a backwards incompability caused by an update (some program needs to update liba, but some other program cannot use that upper version), it happens very rarely. If you insist of using a specific library version, there is nothing stopping you from including it in your package , like snappy's. Lastly, when you include libc a million times, or static compile your binaries, the size goes up and storage/bandwith also becomes an issue. I agree that Snappy solves some problems, but introduces new serious ones as well.

riskable 11y ago
The only problem Snappy creates is one of (initial) size. When every package is a .snap that means you're going to have many duplicated dependencies all over the place. It also means that any security update that exists in a common dependency will require updating a zillion Snappy packages all at once. Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both.
- binarycrusader 11y ago
  Fortunately, the creators of Snappy thought of that and included an atomic/delta update system. So when you have 100 packages that need to be updated because of a common dependency you only need to download 100 binary diffs instead of 100 full-size snap packages. That's not really a solution though, just a mitigation. Updating a single package for security fixes or other changes instead of a 1,000 is still vastly more efficient and faster. Unfortunately packaging appears to be a paradox of sorts: Either your app lives in an environment of shared libraries where you have no control or your app lives inside a container of some sort that bundles copies of all those libraries. You can't have both. That's because the solution alone can't be through packaging; it requires changes at every level of the stack. The system needs to provide robust backwards-compatibility and sane packaging. Applications need to use interfaces responsibly, pick dependencies carefully, and use a sane build environment. When developers attempt to solve everything with the blunt hammer of packaging, they end up with a lot of "bent nails".

rdtsc 11y ago

Has anyone evaluated this vs NixOS (http://nixos.org/ http://nixos.org/) ? They seem to have some overlap and I've heard good things about NixOS, I like the theory behind it, but I find its Haskell-based configuration language hard to understand.

vezzy-fnord 11y ago
Yes: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html http://sandervanderburg.blogspot.com/2015/04/an-evaluation-a...
- rdtsc 11y ago
  Thanks!

davidw 11y ago

I wish they'd just focus on making Ubuntu work. I mean, look at one of the flagship Ubuntu laptops, by Dell: http://en.community.dell.com/techcenter/os-applications/f/4613 http://en.community.dell.com/techcenter/os-applications/f/46... I'll still buy the things, because it's important to me to put my money where my mouth is, but it looks like it could use some significant investment to make it a better product.

mixmastamyk 11y ago
Yeah, ubuntu has always spread itself too thin, while neglecting bugfixing on its core products.