@dziadulewicz

So the server back end is proprietary, as most websites server that people visit are.
Snap Store, snapd, AppArmor and everything else you run (in means of snaps) are completely open source.

No, that literally doesn't make Snap Store completely open source.

I'm not going to follow this conversation any further as I have no pony in this race. I simply prefer free and open source tech, and don't like it when people (and corporations) try to convince me that there's no difference.

View this comment - View article - View full comments

Quoting: scaineWhat bit are you looking at? Snap Store is only mentioned once in that Wikipedia entry, and I can't see any mention of its licence there.

You don't see the license information in the box under the logo? To me it says "GNU GPLv3 (Client & Runtime), proprietary (Backend)[2]".

Technically you could implement your own backend. Maybe there's even an official way to do this as you seem to imply, I wouldn't know or care to find out. But that doesn't change the fact that Canonical's own implementation is proprietary. Or the fact that "host your own" is a disingenuous thing to suggest when it's way more practical to simply use something else.

Whether or not you trust Canonical is up to you, obviously.

Quoting: Fester_MuddIt says also clearly on https://github.com/canonical/snapcraft.io [External Link] (Snap Store and where the source code is):

That repository hosts the code for the snapcraft.io website and doesn't include the snap store backend. This doesn't contradict the license information on Wikipedia.

View this comment - View article - View full comments

Quoting: lqe5433Has the Vulkan-mode been also improved?

This is the only mention of Vulkan in the update notes:

* Fixed screen tearing on Vulkan when VSync is disabled or set to Triple Buffering.

There's also a bunch of generic performance and stability fixes that should apply regardless of graphics API.

View this comment - View article - View full comments

Not sure what you're trying to say here.

I thought it was quite clear: Whether your whole system is optimized for your CPU architecture or not, optimizing the binaries in the Proton package might still yield some extra performance. Even a single library might make a difference, depending on what it is used for. Only benchmarks can tell I suppose.

View this comment - View article - View full comments

If you're on other distros, there's not much point in using it, compared to say Proton GE because your system libs are just vanilla x86 or v2 at best...

I don't know if there's a tangible benefit in this particular case, but in general that's just nonsense. Some binaries benefit from things like AVX2 in v3 a lot more than others, and the fact that something else on the system uses v2 doesn't change that fact.

View this comment - View article - View full comments

No. Gamescope is essentially an XWayland compositor. It uses Wayland protocols to draw X11 applications, but can't handle Wayland-only applications. At some point it will, and at some point the desktop session will use Wayland, but not yet.

Thanks for the clarification.

View this comment - View article - View full comments

The Deck doesn't use Wayland.

The desktop doesn't, but the gaming session uses gamescope, which is a Wayland compositor. Doesn't that mean that effectively games on the Deck run on Wayland?

View this comment - View article - View full comments

Can someone explain what kind of real life changes these bluetooth improvements in wine can bring? I thought bluetooth in wine was completely handled by Linux itself.

It's not enough to have a working Linux bluetooth stack. Windows software doesn't know how to access that stack, so Wine needs to provide wrappers or shims that look exactly like the Windows BT APIs. I've never used any Windows software that needs these APIs so I don't know how well it works currently, but based on the changelog it seems like some functionality was outright missing:

winebth.sys: Remove the first 2 zero bytes after byte-swapping Bluetooth addresses.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_START_DISCOVERY.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_STOP_DISCOVERY.
bluetoothapis: Implement BluetoothFindFirstDevice and BluetoothFindDeviceClose.
bluetoothapis/tests: Add tests for BluetoothFindFirstDevice, BluetoothFindDeviceClose.
bluetoothapis: Implement BluetoothFindNextDevice.
bluetoothapis/tests: Add tests for BluetoothFindNextDevice.
bluetoothapis/tests: Use the correct file name while skipping tests when no radios are found.
bluetoothapis: Add a basic implementation for BluetoothGetDeviceInfo.
bluetoothapis/tests: Add tests for BluetoothGetDeviceInfo.

View this comment - View article - View full comments

Linux native versions are usually subpar, due to them being a lot less maintained, sometimes even missing features. The only game that actually has better native Linux version that I'm aware of is Factorio and only because of reduced saving game stutter.

First of all, your anecdotes aren't data. And secondly, I don't see how that's in any way relevant, when I think all of the games listed in this article work just fine. I've either played or seen others play almost all of them natively on Linux.

View this comment - View article - View full comments

Ubisoft is "Triple iii" indie now?

what? where?!

The Rogue Prince of Persia, a game published by Ubisoft, is part of The Triple-I Initiative.

I guess you only need three of the letter "I" to build an "A". But their FAQ is honest enough. They're not trying to make a statement. They just picked a cool name for their multi-studio marketing project.

View this comment - View article - View full comments