Canonical & Snappy
I sense a tension in the community about Canonicals move with snappy. Maybe it is the next Unity, the next Mir or any other thing that seems to come from a companies wish to get control. Maybe.
But here I am, a simple user wanting to use software. In my case Pencil .
It is not in my Ubuntu repository to begin with. So I have to grab the *.deb file myself. Turns out it requires me to use an OLDER version of xulrunner. No idea how to make that happen.
Now I could also:
- install it from an *.xpi extension file inside firefox instead of a standalone app
- install a signed version of the xpi from mozilla add-ons server
- get distro independen binaries
- switch my distro from Ubuntu to Arch Linux, NixOS or openSUSE
- compile the source code
- use OSX binaries
- use Windows binaries
My solution isn't even on the long list! I finally got it to run by installing the windows *.exe in wine. Isn't that embarrassing? I don't see what the maintainer role is adding to a solution, it rather seems to add to the problem. The current situation of distribution of binaries hurts freedom0 (run the software) and freedoms 2 & 3 (distribute copies and modified copies).
I see that there may be downsides to snappy and technically and ethically superior "alternatives", but from a software freedom angle I happily wait for whatever comes next - even if it turns out to be snappy.
jrobb likes this.
Stephen Michael Kellat shared this.
And you are. There is nothing technical which prevents you from installing a 3rd party .deb
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.
What makes you think that without maintainers you would have better chances to run the software you want?
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. (I'm also not saying there should be no additional processes to guarantee security or quality or whatever: I say nothing else should be a requirement to run code.)
If upstream did the same thing with snappy (flatpax, whatever) it wouldn't have worked anyway.
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. 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. 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.
- I don't think it will significantly increase the actual quality of upstream packages: if upstream provides a .deb that doesn't work there is no real reason why they should start providing snappy packages that do
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.
- It won't take care of fragmentation (note that snappy is ubuntu-only, fedora (and other distributions) has flatpax, and then there is guix which uses a different approach, and...
Evidently it didn't yet. But it could. All I'm saying is that it should - or any other competitor.
- It will mitigate a bit the dangers involved in installing 3rd party packages, but it will leave other significant dangers open (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.
- it will mean more work for upstream, which could be more productively used to work on their actual software (unless somebody else comes in and... becomes a maintainer for the snappy/flatpax/whatever package)
My assumption is that it saves time for developers that package on their own. And maintainers would only have to touch things once instead of X times for X distros.
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?
>> 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).
Ok so to wrap this up: You seem not to be impressed by the promises that come with snappy. Is there a solution on the horizon in your eyes? Or don't you even agree there is a problem with package managers these days?
Basically, I'm not impressed by the promises that come with any app-store-like system because I see a lot of disadvantages for the user and a lot of advantages for the producers of proprietary, user-hostile software.
Package managers have some issues, the biggest one is that the fact that they aren't considered "cool" anymore leads to a lack of volunteers, and that leads to a lack of packages in the repositories (but I have reason to believe that it's not an intrinsic scale problem, and that there is still room to add more manpower, if available, without any reduction in efficiency).
On the other hand, I believe that the advantages of the maintanership model are huge, mostly in the area of being able to trust your computing environment, and thus worth working with it and trying to work with it and improve it instead of substituting it with something else.