I honestly don't even check anymore - everything I'm interested in is compatible, except for gacha games where I assume it's not compatible. Still, I still have the ProtonDB extension installed (obligatory warming regarding inherent insecurity of using random extensions).

https://chromewebstore.google.com/detail/protondb-for-steam/ngonfifpkpeefnhelnfdkficaiihklid [External Link]

https://addons.mozilla.org/en-US/firefox/addon/protondb-steam/ [External Link]

View this comment - View article - View full comments

Yeah, I hope it is Flathub. Flathub+others would be fine, but I really really hope Flathub is a focus because it's just the defaults for Steam Deck and most other Linux distros. I'd rather it not be Snap or .deb...

View this comment - View article - View full comments

The fact that replacing GNOME with KDE for Fedora Workstation was even discussed is crazy. I do hope that they really will put both as equals - if one is labeled Fedora Workstation and the other Fedora KDE, then I wouldn't call that equal...

View this comment - View article - View full comments

Quoting: dziadulewiczIndeed. It's an absolute shitshow. It is mandatory to use terminal and somehow *know* commands and what else. You are expected to just *know* there is this thing called RPMFusion (that you have to manually enable, and from where to start with, also a mystery as not any website or link is given). The installer doesn't express any of this. You also need to install additional codecs.

Fedora doesn't ship patented media codecs by default as for example Ubuntu and Linux Mint do.

It is beyond any normally thinking user *why there are no couple of simple boxes to tick* during install to achieve this totally basic functionality to watch videos.

So basically a new comer "can't watch YouTube, Dlive and Twitch on Linux" OOTB if you happen to choose Fedora as a first distro.

It's codecs. It's related to patents. Patent laws are a mess. Ubuntu, and its downstreams, choose to ignore the issue. Fedora follows a stricter guidelines. There's really not much you can do with what Fedora's rules vs Patent rules.

If it doesn't fit your preference, then use one of its downstreams like Nobara, Aurora, Bazzite, UltrarisiOS, or risiOS which are more newcomer-friendly. Fedora is meant to be a very unopinionated and cleanly-operated community project

View this comment - View article - View full comments

Is there an UMU counterpart to Scout / Steam for Linux?

View this comment - View article - View full comments

I would love if people add the various VN stores to this. Including Itch, of course.

View this comment - View article - View full comments

Umu! That is some good news. Looking forward to integration in Heroic, Lutris, and Bottles.

View this comment - View article - View full comments

Quoting: pleasereadthemanual

Quoting: fenglengshunjust general Remote Desktop stuff).

Server RDP or desktop RDP? And what issues?

(as a curious person who runs a GNOME-based RDP server)

Desktop. I mainly used Rustdesk + TeamViewer + AnyDesk, for redundancy in case of connectivity weirdness. Last I tested, unattended access is wonky on KDE and unattended login doesn't work on Wayland at all.

Quoting: EduardoMedina

Quoting: fenglengshunI won't lie, as a Bazzite user who builds my own custom image, I kind of wished that Valve would switch to a an rpm-ostree or similar infrastructure. I would love to have SteamOS images, with my own tools pre-baked in.

IMHO, OSTree is a very bloated software that steps on things that systemd can do. Even GNOME OS tries to replace it with parts of systemd.

I think that SUSE immutable systems are better focused. transactional-update seems smaller than OSTree and Snapper manages the snapshots. Moreover, in SUSE and openSUSE immutable systems you can rollback things the /etc folder, while with OSTree you only can rollback through the system images. In Aeon Desktop the automatic updates are scheduled with a systemd timer.

Finally, with Aeon Desktop you have a rolling release system, while with Fedora you have a point release system if you don't use the rawhide repo, but rawhide is nothing more than an experimental repo.

I like Fedora, but if you try Aeon Desktop, you can see that it's a lighter system than Silverblue, although the presence of x86_64-v3 packages in Aeon Desktop may be influencing.

I don't disagree that it's bloated, but it is bloated in a way that doesn't bother me and for a benefit that I think is worth it.

For me, I just don't like messy packages list. Even in a Distrobox, it bugs me when I have packages that I don't intend to use, that isn't part of the default. The biggest benefit of OSTree for me is their infrastructure- if you take a look at Blue Build system (the now independent image builder aspect of Universal Blue), the effect is that you have a semi-declarative OS image where I can cleanly and clearly put in "Take Bazzite as base, and add these packages." Then Github will build them, and keep 90 days history of them, while my devices has previous image as fallback.

What really made an impression on me was when mainline Kinoite was having an issue once. I just trace each day's image, found when the issue started, test the upstream ublue Kinoitr image of that day, then test the ublue image's upstream in mainline Kinoite... I can just say "Here, this is where the problem started, and it's likely because of this commit." That was a great bug reporting experience, likely both on my and the devs' end. I liked that, and that's why I have a strong feeling towards rpm-ostree.

View this comment - View article - View full comments

I won't lie, as a Bazzite user who builds my own custom image, I kind of wished that Valve would switch to a an rpm-ostree or similar infrastructure. I would love to have SteamOS images, with my own tools pre-baked in.

Then again, I don't need THAT much stuff on host system anymore (vs user-space) so I could settle with SteamOS official desktop installer once my Wayland and Portals woes are settled (currently, mainly usb-portal for gnome-boxes and just general Remote Desktop stuff).

View this comment - View article - View full comments

I hope they succeed. Some of these protocols do take too long and way too many arguments on the correct way to do the same thing. Sometimes I get why, and sometimes I do think they should be more willing to just try things out and iterate.

View this comment - View article - View full comments