Yeah sure. But thanks again for the confirmation. And please, just stick to the facts you actually know of.

[…] you can absolutely remove/change/add as many repos as you want to your snapd config, exactly as you can with Flatpak. […]

I don't use Ubuntu or snaps.

View this comment - View article - View full comments

@poiuz: the tone of your reply is super-depressing, ngl. You contradict everything without saying anything positive, or offering solutions (not that I can even see a problem that needs a solution, tbh).

So I can assume you did look for the configuration & did not find it?

It's not invalid. It demonstrates Cononical support plans, for nearly a decade.

No, if anything it demonstrates Canonical abandoned any support plans nearly a decade ago. How much clearer can it get than Canonical themselves saying: It's not supported anymore?

The store acts as a proxy cache. You can keep it offline or connect it upstream. It refers to itself as a client, but it's also a server.

Please provide the documentation to run the server. I've checked the few lines of code of the client & I don't see anything you're claiming, it really seems to be just the client to connect with the store.

View this comment - View article - View full comments

You can absolutely remove/change/add as many repos as you want to your snapd config

Could you link the documentation for this, I'm not able to find it.

This "The Register" article from 18 months ago talks about how to set up your own "snap store". Still don't know why you'd do that, but there you go. https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/ [External Link]

Except, it doesn't. It explains how you can install .snaps with snap, book your store with Canonical and mentions a wondrous open source store which just shows it's not designed to do so:

lol is a variant of snap with support for a custom snap server. It's in beta, but you can daily-drive it. We'll be making it easier to publish snaps and be adding support for multiple repos.

It's a script that downloads .snap files (with curl because apparently snap can't even do that) and installs them via "snap install --dangerous".

Snap is simply not designed for repositories.

https://canonical.com/blog/howto-host-your-own-snap-store

It's a very old blog post from Canonical.

Exactly, it so old that it's no longer valid.

snapstore was a minimalist example of a "store" for snaps, but is not compatible with the current snapd implementation. As a result I have removed the contents here to avoid further confusion.

https://github.com/canonical/snapcraft/commits/main/snapcraft/store
Canonical developers actively maintain the store backend. Not sure what else you expect from them.

Snapcraft is the command-line build tool for packaging and distributing software and apps in the snap container format.

That is not the store backend.

View this comment - View article - View full comments

While WINE is certainly the basis without we wouldn't have Proton, remember that WINE absolutely stunk at running games before Valve chimed in.

Gallium Nine existed long before DXVK & showed what was possible. I'm certain something like DXVK would've been developed anyway. Maybe a lot slower, but I'd would've been done (maybe the route Zink took - Gallium Nine/Ten/Eleven via Vulkan).

The statement is still true - without Valve we wouldn't be able to run the vast majority of Windows games as flawlessly as we can do today.

The only fact we know: Without Wine there is no Proton. What would've been developed we can only assume.

View this comment - View article - View full comments

Because the other 99% still have an existing library on Steam and probably don't want to buy games again just to play them on a 3rd party handheld that's hard-locked to a proprietary store. Their target audience is pretty much existing Xbox owners that don't use Steam at all. In other words, a niche.

It's Windows, that's still the main platform of Steam. You'll be able to install it.

Even if not: The Xbox owner niche is still a lot larger than the Linux gamer or Steam Deck owner niche.

View this comment - View article - View full comments

I remember back when I worked at GOG.com (CD Projekt group) they announced internally they might release a version of Gwent card game for Windows Phone but not for Linux 😛

The industry works in mysterious and quite silly ways.

Except, Windows Phone sold a lot of devices (Lumia alone: https://en.wikipedia.org/wiki/Microsoft_Lumia#Sales [External Link] ).

Granted, not all of them were "gamers" but there were a lot devices by other manufacturers, too. In comparison, Steam Deck sales seem to be abysmal.

What puts the cherry on the cake is of course that Valve is the main reason why you can actually play your Epic-obtained Windows games on your open source OS.

That's not true. Wine is the main reason we can actually play Windows games on our system. That's really disrespectful to ignore the almost 32 years of development history. Without Wine, DXVK & Proton are nothing.

View this comment - View article - View full comments

How could Microsoft already be too late? The vast majority of PC gamers don't own a Steam Deck (according to Valve's statistics, less than 1% of all Steam users). The alternative would be that there's actually not much of a market at all.

And according to the latest estimates, 50% of all sold PC handhelds already are not Steam Decks. Valve must release their SteamOS 3rd party support really soon to keep up!

View this comment - View article - View full comments

Selling multiple millions, although we don't know the exact number since Valve don't really like to talk in such specifics.

Newest estimates (based on supply chains) put it to 4 millions:
https://www.theverge.com/pc-gaming/618709/steam-deck-3-year-anniversary-handheld-gaming-shipments-idc [External Link]

View this comment - View article - View full comments

You really like that "Why would you handle flatpak differently" statement.

Yes, because Flatpak was specifically designed to allow multiple sources.

Decentralized by design: Flatpak offers decentralized hosting and distribution, allowing developers or downstreams to host their own applications and application repositories.
https://docs.flatpak.org/en/latest/introduction.html [External Link]

Of course flatpaks are different from deb, rpm and other distro packages. Flatpak was created as a distro agnostic way to package applications

That doesn't imply that only once source must exist. The Fedora repo will be distro agnostic & usable on most distributions, too (there might be issues when an older flatpak version is used - but the same is true for Flathub) (I assume, since I haven't tested this).

so that developers wouldn't need to package in 10 different formats to release on Linux, similar in mission to snaps and appimage. […] If a developer only can or want to support one format in one place, I hope it's flatpak on Flathub.

Correct, that's why Flathub exists. But the packages in the Fedora repository are not maintained by the application developers. It's an alternative repository maintained by a third party to provide a specific use case (the same reason so many Linux distributions exist - even though it's a lot of redundant work).

The EU has forced Apple to allow 3rd party app stores so that the European users are not restricted by Apple policies (at least in theory). Most developers won't release their apps there, just the same way most game developers only release on Steam. But on Android it's a more common thing (e.g. F-Droid).

But unless Flathub really mess up or another repo offers something of value I see no reason to use anything other than Flathub. If a developer only can or want to support one format in one place, I hope it's flatpak on Flathub.

I hope so, too.

But there are many reasons, why something is not distributed on Flathub (e.g. legal reasons or applications Flathub doesn't want to distribute, e.g. wine applications) or distributed independent from Flathub / the developers (e.g. better security handling or maintaining a specific version longer).

View this comment - View article - View full comments

Because it's redundant?

That's the whole point: Every Linux distribution (especially the Ubuntu forks) are basically redundant - they do all the same work. Except, each distribution has some value for their users & everybody is ok with this. Why would you handle Flatpak repos (which is just another package manager) any different?

If every distro maintains their own flatpak repo we have made the situation more complex and even less enticing for app developers than before Flatpak/Flathub existed.

It's just another package manager. There are far more new Linux distributions than Flatpak repos (see https://distrowatch.com/dwres.php?resource=submit [External Link] ), so there's nothing special about the Fedora Flatpak repo. Even OBS has to deal with distribution specific issues (i.e. tell the reporter to report it to the distribution & close the bug report) & wondrously do it without any legal threats.

So no, I don't see how an additional Flatpak repo would make the situation more complex or less enticing for any developer. They don't interact that much with any of the third party repos (RPM, deb or whatever format). Obviously, people will report bugs in the wrong tracker (which they already do with distribution specific issues, e.g. very old versions). But that's it.

Linux Torvalds once said that if anyone is going to fix the Linux desktop it would be Valve. If Flathub doesn't manage to be *the* Linux app store then it's up to Steam.

They haven't fixed Windows in over 20 years, so I really doubt they'll fix Linux.

View this comment - View article - View full comments