Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Canonical bringing Snappy Ubuntu to phone and desktop

rainveiltech.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#31

Post by vezzy-fnord »

edude03 wrote: post #20
VLM wrote: post #13

Earlier quoted context omitted.

Seems to summarize down to a love/hate relationship with shared libraries. Most of the flaws are best explained as the devs, admins, users, security team, and distro maintainers sometimes having different positions on the spectrum of love/hate for shared libraries. Also don't forget architecture... you want that binary in 32 bit i386, 64 bit amd64, or arm?

In a nutshell yes. The binary argument is true as well, however many developers don't want to make their sources avaialbe which means other than going source -> some obfuscated IR -> native, thre is no way to allow the end user to run your app on any arbitrary platform.

There is. It's called fat binaries. Ryan C. Gordon was working on an ELF extension for it, but ended up quitting due to getting shit on by kernel hackers and common users alike.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#32

Post by vezzy-fnord »

rdtsc wrote: post #26

Has anyone evaluated this vs NixOS ( 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.

Yes: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-a...

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#33

Post by e12e »

riskable wrote: post #29
motoboi wrote: post #4

Earlier quoted context omitted.

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.

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 e…

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).

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#34

Post by Karunamon »

CaptSpify wrote: post #28
CSDude wrote: post #21

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…

> 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. And this is the back-and-forth problem that nobody has the answer for. Do we make this one app fail, because the maint…

Having been burned repeatedly by the primary problem you mention, I lean more towards the second case simply because security depends on the application involved and how it's used.

An insecure app may have mitigations available that don't reduce its usefulness. A broken app is just broken and useless.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#35

Post by fulafel »

edude03 wrote: post #5

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 syste…

You will be fine if the user installs a newer libc. Binaries and .debs linked against libc from 10 years ago work and install fine.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#36

Post by mixmastamyk »

davidw wrote: post #30

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/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.

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

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#37

Post by rdtsc »

vezzy-fnord wrote: post #32
rdtsc wrote: post #26

Has anyone evaluated this vs NixOS ( 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.

Yes: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-a...

Thanks!

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#38

Post by [deleted] »

edude03 wrote: post #5

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 syste…

[deleted]

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#39

Post by binarycrusader »

edude03 wrote: post #17
ordinary wrote: post #15

Earlier quoted context omitted.

> packages [...] 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) I feel that once a user circumvents the package system, it is unreasonable for that user to expect that the package system will continue to work correctly. In that case, the user has taken over some of the res…

I don't disagree, and of course swapping out libc might be an extreme example, but my point still stands - ideally I shouldn't have to rely on any specific dependencies being in place to deploy my software.

Some amount of dependencies is a reasonable expectation; for example, requiring a certain minimum version of libc is entirely reasonable. Or, requiring a certain minimum version of the kernel.

However, if newer versions of libc or the kernel are not backwards-compatible, that's a failure in the system itself (not the packaging). (Linus, as an example, has a strict rule about not breaking userland applications due to kernel changes.)

It's impractical (and undesirable from a security and other standpoint) to statically link all dependencies into every binary simply to "simplify" packaging. Not only would that be a waste of storage space and memory, but it prevents fixes (security or otherwise) applied to the libraries used by the application from taking effect without patching everything that statically-linked it.

Even if you ignore the storage space issue with some amount of hand-waving, larger binaries means greater I/O and network bandwidth requirements, which means it takes longer to update systems or create images for deployment. That in turn leads to increased downtime or increased sustaining costs, which effectively leads to reduced availability of the system.

This can be mitigated somewhat by using difference-only-style update mechanisms, but it only partially mitigates the issues created by statically-linked binaries; it does not eliminate them.

Dynamically-linking dependencies also ensures that future performance and security updates don't require a rebuild of existing applications; you can simply update the dependency, and if done properly, every application linked to it will automatically receive the benefits.

Obviously, if a given dependency is only ever used by a single component, and the component is always rebuilt when the dependencies are, it doesn't matter if they're statically-linked. I'm referring only to the system dependencies common to many system components (such as libc).

In the end, a carefully chosen set of dependencies that provide robust backwards-compatibility provides the least downtime and the most compelling administrative experience.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#40

Post by binarycrusader »

riskable wrote: post #27
CSDude wrote: post #21

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…

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…

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".

Post reply on HN