Canonical bringing Snappy Ubuntu to phone and desktop • Hacker News Board

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#11

Post by edude03 » Wed, Nov 04, 2015, 4:59 PM UTC

ant6n wrote: post #7

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 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 on node 0.10 but you have v4? Too bad! You didn't apply the increased memory patch before building node? Too bad!)

The ideal here to reiterate is given nothing but your installed OS, I should be able to give you a file that will go from nothing to a running app, and from the running app to a clean system if you decide to remove it, without you having to have any prerequisites (no node, no chef, no docker, etc)

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#12

Post by jhasse » Wed, Nov 04, 2015, 5:26 PM UTC

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…

There are solutions to this problem (e. g. ZeroInstall [1]), but the distributions don't support them, since they want to keep you vendor locked-in. Guess why Ubuntu is developing Snappy and not using xdg-app [2]? Also purely functional package managers exist [3], distributions just ignore them. It's hard to use something not based on deb or rpm these days.

[1] http://0install.net [2] https://wiki.gnome.org/Projects/SandboxedApps [3] https://nixos.org/nix/

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#13

Post by VLM » Wed, Nov 04, 2015, 5:30 PM UTC

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…

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?

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#14

Post by sebular » Wed, Nov 04, 2015, 5:33 PM UTC

edude03 wrote: post #11

ant6n wrote: 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…

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.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#15

Post by ordinary » Wed, Nov 04, 2015, 5:40 PM UTC

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…

> 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 responsibilies of the package system, and software vendors should feel no obligation to ensure compatibility with such changes.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#16

Post by vezzy-fnord » Wed, Nov 04, 2015, 5:45 PM UTC

jhasse wrote: post #12

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…

There are solutions to this problem (e. g. ZeroInstall [1]), but the distributions don't support them, since they want to keep you vendor locked-in. Guess why Ubuntu is developing Snappy and not using xdg-app [2]? Also purely functional package managers exist [3], distributions just ignore them. It's hard to use something not based on deb or rpm these days. [1] http://0install.net [2] https://wiki.gnome.org/Projects/…

I find it hilarious how you make the implication that Snappy is some deliberate NIH of xdg-app, when xdg-app itself is GNOME/Red Hat's NIH of Nix.

If anything, we should be lauding Canonical for keeping to themselves in their corner instead of seeking greater validity across the ecosystem with half-baked ideas.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#17

Post by edude03 » Wed, Nov 04, 2015, 5:57 PM UTC

ordinary wrote: post #15

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…

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

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#18

Post by falcolas » Wed, Nov 04, 2015, 5:59 PM UTC

edude03 wrote: post #10

hasenj wrote: post #6

Earlier quoted context omitted.

I think Docker is meant for dev ops, not for casual users.

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.

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.

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#19

Post by pnathan » Wed, Nov 04, 2015, 6:00 PM UTC

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…

I feel your pain. I'm trying to figure out how to get some code with some unique dependencies shipping to a wide range of users (both in skills and platform), and I don't even know of a good (multiplatform) solution that doesn't look like "bake it all into a static zip and unzip into /opt" or "run a docker container".

I need to think about that a bit more instead of solving the actual product problem at hand. :-/

Re: Canonical bringing Snappy Ubuntu to phone and desktop

#20

Post by edude03 » Wed, Nov 04, 2015, 6:00 PM UTC

VLM wrote: post #13

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…

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.