>> mray:
 

“I can't in this instance since the provided .deb does not run for me. I know it *should be possible, but the fact is: it is not for me. I blame the package/distro cruft situation for it. I think if we were using snappy for more than ten years, just like windows uses *.exe installers for a long time we wouldn't have this mess.”

IMHO if the package is broken (or possibly meant for a different version of the distribution) the fault lies in the people who created it, not the people who maintain the distribution.

.exe installers work, except that sometimes they break between different releases of windows (reasonably), just like apps for android work out of the box, except when they don't: it all depends on how much time the authors decided to spend in supporting that specific platform / release.

“I'm not talking about maintainers, but about maintaining. The act of having to care about things after code has been written, compiled and packaged for my architecture. There should just not be another step necessary.

Well, the code has been written, compiled and packaged for your achitecture *and a specific number of dependencies*: if those change it can break. The only way to solve this is to include *everything* down to the c library in the executable, but that leads to huge executables and security issues.

Note that not even .exe files go to that extreme, and this is why they can break between windows releases.

“The way I understood this is that those systems make sure that dependencies just are met. Even if it means shipping them extra. Am I wrong about that? I know that theoretically the deb could have done that as well.”

I seriously doubt that they will be able to do that in an automagfical way. There are tools to detect dependencies while building .debs (and other packages), but they don't always just work, and I'd expect the situation with snappy to be very similar.

“ My limited understanding of things is that deb, rpm have a few thing in common: One is NOT to encourage doing this in the first place.”

There is just one thing that does that: distribution people not allowing packages that include 3rd party libraries in the official repository. There is absolutely nothing that prevents people from distributing .debs with embedded libraries, and even the distribution maintainers sometimes make exceptions (usually for projects who forked the 3rd party code to the point that making the program work with the original library would require too much effort).

The main reason for this is that every embedded copy adds more work for the distribution maintainers, expecially in case of security updates.

People who create .deb packages are free to ignore this part: of course by installing their packages you trust them to update it when a security problem happens either in their code or in the code they have embedded, in practice the chance that they actually bother doing so are slim, but that's a social problem, not a technical one.

“I just assume that if we were living in a "snappy world" chances of me just grabbing that package and starting it successfully would be orders of magnitude more likely.”

Only if the people who created that snappy package decided to cater for your version of the distribution, either by embedding the libraries that don't maintain a stable API between releases of by creating packages for your specific release.

No difference from 3rd party .debs here

“I do. If I were a developer and provide one kind of binary for all GNU/Linux users my incentives to make that one work are WAY higher than to always provide a gazillion and then finally and lazily point to some sourcecode that can compiled anyway - just in case.”

I seriously doubt that there is ever going to be such a situation: beside the fact that it's hard to see canonical and red hat agreeing on such a format, (and assuming that their targets are different enough that most ISV can choose to support just one of them) they would still have to support different releases of the basic distribution(s), just like it happens with phone app stores.

“ (see e.g. mjg59) This appears to be real issue. Yet you're talking of a specific downside of snappy, I'm talking about the general benefits of something like snappy.”

Actually, that's an issue with anything that is running under xorg, because of its architecture (and one of the reason the flatpax developers don't claim that they provide perfect isolation yet, because they can't).

Wayland may help here, but some of it is intrinsic in the fact that people have a need for screenshots, virtual keyboards and other things that require features that can be misused.

“I'm no expert in this, I never ever release or packged anything. I am an expert in being a user in the GNU/Linux world that constantly points to breezingly fresh beatuiful, honey sweet, sugar coated and velvet soft binaries for all major operating systems and then either shove 5 year old versions down my repository throat - OR - point to some source code. Snappy finally looks like a scratch to my itch. Am I really mistaken here?””

Canonical's PR did try to lead people into thinking something like this, but there was a lot of misleading marketing in there, including wide claim of support from other distributions that have been debunked from the distributions involved (specifically fedora).