It’s just so phenomenally little it doesn’t make any sense, a full routine wouldn’t even full charge a smartphone battery (not even close). Put solar on the studio roof instead.

I think you’re wrong on that one. E.g. when cycling, 100W for 15 minutes is achievable for most people, which corresponds to 25 Wh of energy. To charge a modern phone you need about 15 Wh. So if your overall system efficiency is at least 60%, which seems realistic, you’d be able to charge a phone with that.

I guess it’s just not financially viable. Because those 25 Wh would still correspond to less than 1 cent in value (at 0.3€/kWh).

The saves should be in your old Wine prefix. If you didn’t delete that, you should be able to copy them to the new prefix.

I think the problem is that the license grant (that has been in place for a decade) is not that clear.

You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE

• See MIT-COMPILED-LICENSE.md included in compiled versions for details

You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:

1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or […]

I read it as releasing the binaries under MIT and granting people an AGPL license for the (non-enterprise) code. Some read it as not granting you the full AGPL rights.

To me, the fact that they advertise Mattermost as “open-source” and the statement on the “reciprocal license” above indicates that Mattermost also reads this as an AGPL license grant. However, they don’t seem to be interested in fully clarifying the license situation. But, I think they would have a very hard time to argue in court that this license doesn’t allow AGPL forks. And I haven’t seen any evidence of them acting against any of the existing forks.

Eh, that post title is quite sensationalistic.

1. Nothing regarding the license has changed in the last 2 years.
2. It seems like they consider the non-enterprise code to be licensed under the AGPL:

Thank you for the community discussion around this topic. I do recognize that our licensing strategy doesn’t offer the clarity the community would like to see, but at this time we are not entertaining any changes as such.

UPDATE Feb 2, 2026: To be specific, our license is using standard open source licenses, a reciprocal AGPL license and a permissive Apache v2 license for other areas. Both are widely used open source licenses and have multiple interpretations of how they apply, as showcased in this thread.

When we say we don’t “offer the clarity the community would like to see”, that refers specifically to the many statements in this thread where different contributors are confused by other people’s comments and statements.

For LICENCE.txt itself, anyone can read the history file and see we haven’t materially changed it since the start of the project.

If you’re modifying the core source code under the reciprocal license you share those changes back to the open source community. If you’d like to modify the open source code base without sharing back to the community, you can request a commercial license for the code under commercial terms.

Maybe we can hold the pitchforks a while longer, unless they actually make a negative change.

Yes… and it also seems to me like (6) (d) would prevent Motorola’s policy of only providing security updates:

(d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;

But the language here is quite tricky… I’m not 100% sure that points © and (d) force a manufacturer to provide updates under point (a) if Google updates AOSP.

Debian strongly recommends against adding repos from other distributions or other versions of Debian: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian Doing that can easily break your system. They also recommend against adding repos for specific software packages (e.g. for LibreWolf), but this is generally less problematic.

Personally, on Debian, I try to get packages in this order:

1. From the official Debian packages
2. From Flatpak
3. Pre-built binaries (I put them in my home, not in /usr/bin)
4. Build from source (I also put those in my home)

He certainly claims to have used the correct Bazzite images:

A few folks have asked but yes every machine got it’s own specific install, each machine has it’s own Bazzite ISO download for their specific hardware. No cloning, no short cuts, each was treated like a brand new machine with a fresh install 🕊️. After updates installed I rebooted and checked updates again, I’ll never take PC benchmarks for granted again 😅

He also mentions that he used the “Nvidia (GTX 9xx-10xx Series)” image for the 1080 Ti system.

Of course, it could be that he messed up, but it could also be that Bazzite didn’t work as intended. It certainly wouldn’t be the first time that Nvidia drivers broke on a Linux distro.

And in case this was indeed user error, perhaps it would be a good idea to have a mechanism to let users know that they chose the “wrong” image.

If that was the intent, then I think this was a very bad way to show that. A much better way would’ve been showing that it didn’t work on system X and resolving it (e.g. with some external help). Instead he just showed a large number of invalid/irrelevant benchmarks. This now leaves people thinking that Linux has a massive performance deficit instead of an issue with the driver installation. I would like to see a follow-up to address the driver issues and explain what went wrong, s.t. we can actually learn something from this.

I would also hope that the typical experience is that it works out of the box, especially on a distro like Bazzite, but that’s besides the point.

Yes, they could even show a list of detected GPUs, the driver used, and some status indication (e.g. warning if NVK is used).

One of the main selling points of Bazzite is that it works out of the box. They even advertise this on their website:

Bazzite focuses on hardware compatibility out of the box, with full support for accelerated video encoding and decoding, built in Nvidia drivers, additional HID drivers, and just about every udev rule you could need.

On Bazzite, one should not need to look up how to install drivers.

MangoHud may be able to show the driver too, but I’ve never used that myself.

Agreed. I think the main takeaway from the video is that it’s still hard to set up Nvidia GPUs on Linux, even on Bazzite :(

I love flatpak for how easy it makes it to install apps on almost any distro, but I also hate the spokes that it puts in the wheels. Drivers are ugly (that’s true for containers in general) and I also often stumble over file system permissions issues :(

In the video, it was sometimes showing the driver version at the end of the benchmarks (e.g. in Horizon Zero Dawn). If it says llvmpipe or NVK there, it’s not using the proprietary Nvidia driver.

But, if you want to check if your Nvidia GPU is detected correctly, you can run nvidia-smi on the terminal and if it shows you the installed GPU and driver, then it’s using the proprietary driver. Most desktop environments also have a “System Information” / “About this system” screen to show this information in the GUI.

It looks like most of the Nvidia systems were not running the proprietary Nvidia drivers (580/590) but instead falling back to NVK or even LLVMpipe (CPU rendering). All of the tested Nvidia GPUs are supposed to run using the proprietary driver on Bazzite. So, assuming that he downloaded the correct images, Bazzite really screwed up here.

But, unfortunately for the video, this doesn’t really show the typical gaming experience on Linux, it just highlights a Bazzite bug (?).

Personally, I’m quite happy with Plasma Wayland on multiple machines and distros. However, Plasma has already been forked to create Sonic DE: https://github.com/Sonic-DE/sonic-win No idea if this will gain any traction once Plasma drops X11. For now, the activity seems to focus on the readme file…

Spreading false information about Gnome claiming it is insecure sounds like a valid concern for the Gnome team.

Could you point me to that, I couldn’t find anything related to Gnome security in the linked article.

A bit unfair IMO by the downvoters to not explain their downvotes?

There were disagreements between Gnome and System76 and they decided to go separate ways. The whole “contributing to upstream” situation is also kind-of muddy at best. Maybe that’s grounds to write a disappointed blog post 4 years ago, but saying that they are “not to be trusted” today goes too far IMHO.

Also, looking at how Gnome and System76 behave upstream (e.g. in Wayland) today, it seems to me that Gnome is the bigger problem…

I don’t know if there are any differences between the two packages. But, the CachyOS version is part of their official repositories and doesn’t depend on the AUR. I don’t know if that would have any implications regarding how often you need to rebuild the module.

Sure, I’d consider that the main option (and it had already been proposed by multiple people here). But, it also seems like that would come with quite a bit of additional hassle, as discussed below. I’ve personally had some quite annoying issues with incompatible DKMS modules… So, instead of using the unsupported AUR option, it might also be worth considering switching to a very similar distro that actually still supports this hardware configuration.

One option that you could also consider is switching to CachyOS. It seems that they’re handling support for these legacy GPUs in a much nicer way: https://discuss.cachyos.org/t/announcement-maintenance-notice-nvidia-driver-restructuring-580xx-590xx/20010

I have 3080 and I’ve seen significant performance issues too (e.g. in Cyberpunk 2077, KCD2). I think it depends a lot on the games you play. Apparently DX12 (via vkd3d) doesn’t perform well on Nvidia cards.

My next GPU will probably not be an Nvidia card.