Canonical want help testing their Steam snap package for Ubuntu

So, there is a working .deb of Steam provided by Valve and then Canonical decides, nah, that is working to well on our distribution, let's introduce additional points of failure by wrapping it into lot's of additional bubble wrap with our personal logo this totally open and free packaging standard that everyone could use if they went a little bit out of their way and accepted a few performance and efficiency regressions - on it an then ask the community - assuming said community can fit the 'improved' product's more ...chunky... dimensions into their existing gaming spaces and time schedules - to QA it because otherwise to big a task?

At first glance one might be tempted to ask: Why?
But then I remembered something that is easily forgotten these days: this is Linux! So if someone is doing to do some crazy and unnecessary Stuff - just because!- , you take a casual, fascinated glance at this marvel, offer a barely audible, but heartfelt 'Neat!' as commentary, and move on with your life.

Well, we don't actually have a .deb package. The .deb package is just the Steam installer, not Steam itself. When you run that .deb package you actually run the Steam installer which then installs/updates Steam for you and runs it. If the Snap package saves that step and makes the Steam installs and updates happen through Snap itself then that's a welcome move as that'll mean reducing the package formats on Ubuntu from three (deb, snap, and steam proprietary package) to two (deb, snap).

So, there is a working .deb of Steam provided by Valve and then Canonical decides, nah, that is working to well on our distribution, let's introduce additional points of failure by wrapping it into lot's of additional bubble wrap with our personal logo this totally open and free packaging standard that everyone could use if they went a little bit out of their way and accepted a few performance and efficiency regressions - on it an then ask the community - assuming said community can fit the 'improved' product's more ...chunky... dimensions into their existing gaming spaces and time schedules - to QA it because otherwise to big a task?

At first glance one might be tempted to ask: Why?
But then I remembered something that is easily forgotten these days: this is Linux! So if someone is doing to do some crazy and unnecessary Stuff - just because!- , you take a casual, fascinated glance at this marvel, offer a barely audible, but heartfelt 'Neat!' as commentary, and move on with your life.

While I am among the crowd that hates containers with a passion I must say that _if_ there ever would be a use case for containers on a desktop then a browser and a games store would be it.

A browser because it is a major target and thus benefits much from being sand-boxed, also all browsers use heavily forked dependencies so they already have to bundle all their dependencies anyway making the practical difference between a container and a .deb

And a games store have all of the above _and_ also hosts closed source, so not trusted, applications combined with the fact that those applications (aka games) don't really have to interact with the rest of the system.

The supplied .deb from Valve is also nothing else than a small script that downloads the real steam package, so it is not a .deb containing the Steam application.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

I know. Red Hat. With their NIH syndrome. Painful. They didn't want to contribute to upstart. They had to dish out systemd. How lame. They didn't want to support Unity, no they had to had it their way and concoct Gnome Shell. They could have supported Snap, but no, it had to be flatpak. Because all the Canonical alternatives preceded the Red Hat implementations. Mir was a different beast altogether - Canoncial actually wanted to use Wayland, but Wayland was years from being usable and then Mir served a different purpose.

Now I know this is a troll... but the only one of those that is accurate is upstart. Gnome Shell was around much longer than Ubuntu / Unity, in fact, Unity was a 'we don't like Gnome Shell, but are going to use the Gnome Libraries to make our own thing... that's really close to what Gnome Shell is anyhow' Literally upstart, which was a partial implementation of anything, and didn't cover a lot of use cases, is the only thing Ubuntu did really that wasn't in direct competition first. (By the way, Wayland is still a few years away from being truly usable, and Mir was ditched).

Oh puhleeze. The usual BS. This has been the mantra for at least the last 15 years (because that's how long I use Linux on my desktop). The availability of commercial software has never been hindered by "having two or three package formats". Never. I do have my (paid-for) commercial products as DEBs, AppImages, Flatpaks, Tars, script installers. So if companies want to sell their stuff they are perfectly capable and willing to do so.

Yeah, and I've been using Linux for 25. And? Right, they are perfectly capable of doing it. But look at complaints from different developers... hell Valve switched SteamOS from Debian to Arch because some of them hated packaging things for Debian. I don't know about you, but I've talked to many developers over the years, and one of the things they've always hated about trying to create software for Linux is how many different installation methods are there.

Many years ago, you'd mostly see on forums things like 'if you don't know how to do ./configupre; make; make install, then you can GTFO'. I can guarantee you that there have been and will continue to be developers that don't want to deal with that crap, so simply don't release software for Linux.

Snaps...Flatpacks, I'd rather use neither. Apps installed via Snaps or vice versa seem to load slower and are harder to remove from the system. For instance, I can't even uninstall Steam Snap. It fails everytime and the Software Center can't remove it either without error.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

Right, but who would want to bother when you can just use flatpak? :)

Right, but who would want to bother when you can just use flatpak? :)

Actually I think someone did make a proof of concept alternate store to snapcraft, it just never gone anywhere. I don't even remember what its name is, I just remembered it exists.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

Right, but who would want to bother when you can just use flatpak? :)

Of course, but then perhaps also at the same time stop the hate for snap? I mean that was the context, not that you had to use it ;)

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

Right, but who would want to bother when you can just use flatpak? :)

Of course, but then perhaps also at the same time stop the hate for snap? I mean that was the context, not that you had to use it ;)

My actual problem with snap is how difficult it is to remove it from an Ubuntu system... well less about how difficult it is, but it's annoying that it breaks the Ubuntu Software Center when you do. If you want to just use flatpak / debs, you're basically going to be using gnome-software (if you want gui).

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

Right, but who would want to bother when you can just use flatpak? :)

Of course, but then perhaps also at the same time stop the hate for snap? I mean that was the context, not that you had to use it ;)

My actual problem with snap is how difficult it is to remove it from an Ubuntu system... well less about how difficult it is, but it's annoying that it breaks the Ubuntu Software Center when you do. If you want to just use flatpak / debs, you're basically going to be using gnome-software (if you want gui).

One can always criticize the implementation of course. I have zero experience with the software center since I only use apt directly and thus had zero problems removing snap from e.g servers (I run a few micro servers at aws where I had to really squeeze out every available byte of RAM).

But I can guess that it is difficult since they obviously want their users to use snap so they have built it into the system basically.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

Right, but who would want to bother when you can just use flatpak? :)

Of course, but then perhaps also at the same time stop the hate for snap? I mean that was the context, not that you had to use it ;)

My actual problem with snap is how difficult it is to remove it from an Ubuntu system... well less about how difficult it is, but it's annoying that it breaks the Ubuntu Software Center when you do. If you want to just use flatpak / debs, you're basically going to be using gnome-software (if you want gui).

I think with time it'll become harder and harder to remove snap from Ubuntu because it looks like Canonical's plans are to move in the direction of Ubuntu Core where system services are installed as snaps. This obviously will make Ubuntu more solid since there is less chance for packages to step on each other, but will pretty much force every Ubuntu user to use snaps.

I bet you if there could be alt stores to snap, no one would hate it as much as they do.

Well that is the situation today but people still hate it as much as they do. Now there AFAIK does not yet exist such a store, but there _could_ do since everything needed to build it is available, it's just that no one have bothered and that is hardly Canonical:s fault.

I'd like to be proven wrong, but I'm pretty sure their backend is tied very much into their client.

The URL to the store is most likely hardcoded in the source code of snapd, but the code is open so it can be forked and so far we don't know how Canonical would treat a patch that changes that to a config value under say /etc/snap.d/.

Right, but who would want to bother when you can just use flatpak? :)

Of course, but then perhaps also at the same time stop the hate for snap? I mean that was the context, not that you had to use it ;)

My actual problem with snap is how difficult it is to remove it from an Ubuntu system... well less about how difficult it is, but it's annoying that it breaks the Ubuntu Software Center when you do. If you want to just use flatpak / debs, you're basically going to be using gnome-software (if you want gui).

I think with time it'll become harder and harder to remove snap from Ubuntu because it looks like Canonical's plans are to move in the direction of Ubuntu Core where system services are installed as snaps. This obviously will make Ubuntu more solid since there is less chance for packages to step on each other, but will pretty much force every Ubuntu user to use snaps.

Yeah, this is what I think will happen, and it'll basically make it no longer a Debian based distribution with decent defaults (which is what I used it for up until they dropped Evolution for Thunderbird. Sure is Thunderbird sufficient for a large swath of people using desktop Linux. Yes. Is it sufficient for enterprise use? No. (at least it wasn't at the time, some stuff has matured so that it's better than it used to be, though Evolution still beats it as far as being a full groupware suite).

I'd like to say it doesn't affect me, but then I've seen a few apps already that are limited to being distributed via the snap store (or tar ball), so are more difficult to install on Debian.