Live data from Hacker News

Canonical bringing Snappy Ubuntu to phone and desktop

rainveiltech.com

21–30 of 48 posts

Re: Canonical bringing Snappy Ubuntu to phone and desktop

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

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#22
post #11
post #7

Earlier quoted context omitted.

You mean sort of like npm?

npm is an example of a bad solution to dep management. So I want you to run my 6kb node.js script you need to: 1) Build obtain node for your platform (and now you've hit the exact problem I'm talking about) 2) install npm (which I can't really define as a dep, you're just expected to have it) 3) install all the deps I've defined and hope they all work on the version / configuration of node you have (execjs only works…

Agreed. Have two dependencies which have the same underlying dependency? Install and compile that dependency twice (with two different versions, by the way)[1]. Want to use grunt? Need to set that up as a dependency for your project, but only for development. A problem while installing? Have fun with the debug output detailing the fetching a building of every dependency, and every dependency's dependency, and every dependency's dependency's dependency... etc.

[1] I can't believe how many distinct copies and versions of the 'shell' module are downloaded and compiled when pulling in a seemingly simple set of modules.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#23
post #14
post #11

Earlier quoted context omitted.

npm is an example of a bad solution to dep management. So I want you to run my 6kb node.js script you need to: 1) Build obtain node for your platform (and now you've hit the exact problem I'm talking about) 2) install npm (which I can't really define as a dep, you're just expected to have it) 3) install all the deps I've defined and hope they all work on the version / configuration of node you have (execjs only works…

I don't think you can really complain about having to have node.js installed in order to run a node.js script. If you want self-contained binaries, learn Go. If you want lightweight scripts that run effortlessly on all unix systems, learn bash scripting. It sort of sounds to me like you're complaining about not being able to shoehorn your chosen language into all possible scenarios.

I think that's a very reasonable thing to complain about in the context of dependency management. The runtime (node.js) and it's compile time + run time options are actually a dependancy of your application.

As an end user, I shouldn't be expected to know how to configure x dependancy for my system to run y app and as a software developer I shouldn't have to build / package apps to match the client's system configuration.

The sticking point is (back to my point) that the vast majority of distributions don't give the app a way to manage the deps and get specific deps in required, the best you can do is list x as a dep in your package and hope that it won't break your app or the system in some way.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#24
post #7

Earlier quoted context omitted.

You mean sort of like npm?

I wouldn't use npm as an example of a stellar package manager.

Not using it as an example of a 'stellar' package manager. Just one where the dependencies can be defined with version. I was under the impression that apt-get will just use the most recent version.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#25
post #24

Earlier quoted context omitted.

I wouldn't use npm as an example of a stellar package manager.

Not using it as an example of a 'stellar' package manager. Just one where the dependencies can be defined with version. I was under the impression that apt-get will just use the most recent version.

apt-get/dpkg do have the ability to specify package versions, including specifying versions equal to, greater than, or less than. It also has the ability to specify build time and run time dependencies separately.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#27
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 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.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#28
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 maintainer for it isn't updating for library updates? or do we cause system-wide insecurity because we need that one app to work?

I'm in favor of the former, but I think both sides have good arguments.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#29
post #4

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.

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

Re: Canonical bringing Snappy Ubuntu to phone and desktop

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

Post reply on HN