Ubuntu 18.04 LTS Policy Forming For Allowing Snaps By Default

[OneBitUser]

The biggest problem for those software vendors, especially game publishers, though, is that they in many cases don't react to security problems in the libraries they use. Not a problem on a system with traditional packaging systems, since the distro developers will care about the problem, but an application in such a sandbox can potentially come with insecure libraries that get never fixed. When I then see packages that are not properly sandboxed by design because they need outside-of-container access coming as Snap packages, I see Linux going down the Windows way: a conglomerate of not trustworthy libraries lying around on the system for everyone to abuse.

Nope, not interested, broken-by-design.

I'm not saying that the dominant form of software distribution has to be flatpak... but some form of self-contained application distribution method is essential. It can be appimage as well, or snap. Or even all three as options, my guess is that maintaining all three would still be less hassle then testing on three different distributions.

I don't understand what alternatives you are suggesting for moving forward. Because improvement is needed in this area on Linux, and that's a fact.
You also have to make it easier for devs to distribute their software to the whole Linux population, otherwise you will never have a decent coverage of Linux distros.
If the tradeoff is a lot of out-of-date libraries, then you need proper sandboxing of each application.
But keeping the current model is definitely not the answer: it has been tried and it has failed... just look at the patchy cross-distro support of non-OSS software.

[F.Ultra]

I'm not saying that the dominant form of software distribution has to be flatpak... but some form of self-contained application distribution method is essential. It can be appimage as well, or snap. Or even all three as options, my guess is that maintaining all three would still be less hassle then testing on three different distributions.

I don't understand what alternatives you are suggesting for moving forward. Because improvement is needed in this area on Linux, and that's a fact.
You also have to make it easier for devs to distribute their software to the whole Linux population, otherwise you will never have a decent coverage of Linux distros.
If the tradeoff is a lot of out-of-date libraries, then you need proper sandboxing of each application.
But keeping the current model is definitely not the answer: it has been tried and it has failed... just look at the patchy cross-distro support of non-OSS software.

What we need are library devs who are more committed to provide a backwards compatible ABI when they release new versions and when that is not possible due to release a shim version of the old ABI that simply translates the calls to the new library. That way you could have a 50-year old application using v1 of a library that would work out of the box with v998 with all the security and other bugs fixed. Yes it would be lot's of overhead due the shim calls shim calls shim for that particular application but rather that then going this Windows-crazy route.

[mike44]

Linux is everything, except professional.

They don't share anything and even don't see installed software. Looks like a quick hack to me.

[OneBitUser]

What we need are library devs who are more committed to provide a backwards compatible ABI when they release new versions and when that is not possible due to release a shim version of the old ABI that simply translates the calls to the new library. That way you could have a 50-year old application using v1 of a library that would work out of the box with v998 with all the security and other bugs fixed. Yes it would be lot's of overhead due the shim calls shim calls shim for that particular application but rather that then going this Windows-crazy route.

Even though what you are saying does seem to be a better, more elegant solution theoretically, it would raise a lot of practical problems.
What concerns me is that this approach would add a lot of development overhead, i.e. a lot of extra work compared for devs. That might not be a realistic solution seeing that they often cannot even cope with current workloads.

[F.Ultra]

Even though what you are saying does seem to be a better, more elegant solution theoretically, it would raise a lot of practical problems.
What concerns me is that this approach would add a lot of development overhead, i.e. a lot of extra work compared for devs. That might not be a realistic solution seeing that they often cannot even cope with current workloads.

The dev workload is IMHO mostly on the distro maintainer side and not on the upstream side (I'm a upstream library dev myself). I.e what I propose is that if you develop library X and you make a new version that is not backwards ABI compatible with the previous version then you create a small shim for the previous version that uses the new version. This would actually help development since the devs could test their new library with the vast amount of older application that still uses the older versions.

[yurikoles]

Michael there is a typo:

Snaps fro mstable channels

[treba]

Actually snap has stronger sandboxing than flatpak, at least in its reference implementation on Ubuntu. It may of course be weaker in distros that support snap but where apparmor and the other security features required are not available (Arch comes to mind). The same is true for flatpak, by the way.

Well the flatpak crew (redhat in the end) is also developing PipeWire and other components (gnome as the major wayland implementation) that are necessary to make proper sandboxing possible in the first place. Snap will probably use them, too, eventually, but from what I'm reading the push for flatpak is a bit broader overall. Anyway it's nice to see both maturing!