Quoting: alexleducI have set the environment variable with an export so that it's permanent, but Steam doesn't seem to use it. I does work when ran from the command line with:
steam -forcedesktopscaling 1.5
or
STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam

Launching it from a Plasma shortcut or just having steam start on boot ignores the environment variable (at least on X11)

`export` only sets the variable for the current terminal session, to make it "permanent" you need to put it somewhere else like `~/.profile` or `~/.bashrc` (there's a hierarchy to it, but I can't remember ever since I made home-manager's nix sort it out for me).

As for setting env vars in shortcuts, you're best off using kate/kwrite to edit the .desktop file manually, and prepend `env VAR=value` in the `Exec=` field.

View this comment - View article - View full comments

Well, to all the people who asked "If snaps is a universal package manager, when can I use it to install my kernel?" here you go.

For me, it's an interesting project. Snaps, while having certain issues with their GUI portion, for the most part seems to work pretty well on the back-end and non-GUI stuff. But it's just not for me, as I'm already too invested in Flatpak and Nix to deal with a Snaps-exclusive system. I guess I could invest further into Conty, but I like Nix as a way to manage my config and Flatpak for its sandboxing with certain apps.

Besides, I really like the cloud-native approach of uBlue, and while I considered trying out blendOS v3, in the end I'm not interested in doing package installation to host natively anymore and would rather use GitHub to test, build, and pull an image from (gotta love being able to charge Microsoft to build me my Linux system lol). So it's uBlue and Vanilla OS 2.0 only for me.

Quoting: Mountain ManI guess I don't understand how an immutable distro is significantly different in terms of security and stability from the current way of doing it with a locked root account. Aren't they basically different paths to the same end?

After dealing with Arch (glibc and grub update anyone?) and managing Ubuntu PPAs for the past few years, I just don't have the patience to deal with system updates and installing packages anymore. I want my system update to always succeed and I don't need to monitor it.

This is why I like uBlue's approach. System updates are done by GitHub, who compiles the image with all the packages I need (including the printer packages I specified), and I always get the latest successful builds. If an issue occurred, then I can see the log, and it wouldn't get shipped to me. Worst case, I could just rollback to a previous update and go on with my day.

This is how I want my system to be managed, and this works well for me.

View this comment - View article - View full comments

Quoting: adolsonTime will tell. It's still early days, but so far, we're seeing the opposite effect due to Proton. Which, by the way, was the worry back in the Loki/LGP days (when I switched to Linux) with Wine/WineX and later on, Cedega.

For native games, I think the problem is that targeting Linux is such a moving target, that unless the engine is purpose-built for it, devs won't pursue it. Indie games has been pretty good in doing it, but then you got issues like the recent glibc issue, which really doesn't help.

OTOH, people does target Steam Deck more now, which ensures some form of compatibility with Linux devices. With Steam's Linux Runtime Container plus Proton archives, that would actually be a sustainable target with decent long-term compatibility as well.

I heard that GOG Linux games is just outright unmaintained, so if you ask me, the current state is MAJOR improvement even if it's not the ideal everyone wants.

Not knowingly, in most cases, which was my point.

We're past the point in time where people shops for operating system. What matters is that some form of Linux is shipped, by default, on a device that customer buys and devs are starting to adopt more as an additional target.

Again, this is all pretty theoretical at this point, and even with Steam Deck, the numbers are abysmal - as they have always been. I'm still not seeing anything to celebrate at this point in time.

Personally, I'm celebrating the upward momentum. It's there. It's not the greatest yet, but momentum is important in making Linux stays in public consciousness and more importantly, manufacturer's.

View this comment - View article - View full comments

Quoting: EikeWhy? The reason for Flatpak that I'm aware of is getting newer software, but Steam is updating itself...

Personally, I want to see more focus on Steam Flatpak. It's just more convenient to have a way of installing apps that works across distribution families. Plus, Flatpak is oriented towards GUI apps, and as it improves, it would have less issue with communicating between apps compared to Nix with its wrapping, Distrobox with podman/docker limitations, or Conty/AppImage/runimage with their specific image-based limitations.

Flatpak-Sync is also coming soon, so that'd make syncing between devices even easier compared to the current jank git-based solution I have.

It's not about Steam specifically -- it's about the ecosystem, and Flatpak's ecosystem is getting really good for my preferred usage.

View this comment - View article - View full comments

> Cafe Stella no longer crashes with 2 elements on the flowchart.

Praying for the entire Yuzusoft games, especially Tenshi Souzou once it comes out, to no longer need protontricks wmp11 and everything including the movies just works out of the box.

View this comment - View article - View full comments

Quoting: 14My impression so far is that Flatpak for everything adds annoyance to the user experience. It seems there are assumptions made of which people new to dealing with Flatpaks are ignorant

I feel the opposite -- I think that currently Flatpak kinda assumes the user either shouldn't care with the defaults (which, in some cases, often errs on being more restrictive than necessary) or they know enough to find out how to fine-tune them (Flatseal and even KDE's built-in permission management isn't even descriptive enough IMHO).

That said, I do find it to be a decent solution in order to not care about dependency anymore. I was trying to work out how to use Nobara's COPR to get a few stuff including Steam and it is actually a mountain of dependency hell. Nix, Conty [External Link], and Flatpak each have their own issues, but I honestly would rather not have to deal with managing whatever specific thing the distro needs and have something that works in any distribution.

Also, using uBlue's Kinoite base, I do find update to be more convenient. Every day, GitHub Actions will compile a new image, and uBlue's Kinoite comes with auto-update turned on AFAICT, so everything is just applied in the background and if there's an issue, I'd either get an email about how the GH Actions failed and/or I'd just be booted to the last working image.

And personally, I think the average home user is alright with any device that has a browser to connect to the internet, can open documents, and can run games. And for the most part, you can already do that with Flatpak.

View this comment - View article - View full comments

Quoting: pleasereadthemanualIs this different from including Firefox as an overlay?

Alright, long post incoming as I try to explain everything:

You can use overlay, but when I tried to do `rpm-ostree install --dry-run` in my Kinoite image to test things, whenever there's an already installed package, it will exit saying the package is already installed, instead of continuing with installing the other packages I listed in the comment.

By contrast, the ublue builder seems to take care of duplicates easily, unless you have a version conflict due to trying to install something using COPR (tried to install steam but I think the Nobara COPR and packages I enabled caused a conflict of mesa version). Also, they automatically build things in a single layer, I think, which prevents the issue of having too many overlays due to not doing a single `rpm-ostree install`.

In addition, when I asked around, having overlays may make it hard if you want to switch base to a different system image (say, Silverblue to Kinoite, or Kinoite to Onyx, or Kinoite to Kinoite-Nvidia).

If your worry are Firefox and codecs, I believe that uBlue base images currently have firefox and the freeworld codecs installed. I think they only added the firefox and firefox-langpacks on remove list of recipe.yml as an example of how to remove package from the image and probably under the assumption people be installing Firefox through Flatpak via the yafti flatpak installer. But if anyone worries about upstream removing firefox eventually, they can just add it to the install list to make sure it remains installed.

This [External Link] is the list of the packages they overlay by default on their images which you can use as your base image, this is the template recipe.yml [External Link] which is applied based on the base image you chose, and this is my recipe.yml [External Link] and yafti.yml [External Link] for an example of how I'm doing things (sorry about the mess though, still experimenting here -- check Actions if you want to see how messy installing Teamviewer is).

I still don't know everything yet, I've only been using it for a week, but it was easy enough to understand due to the playbook-like format. Getting started [External Link] was surprisingly easy, with the automated setup.

View this comment - View article - View full comments

Quoting: Jarmeryes exactly. The big question is "when" - I think I've been hearing some version of this exact same statement for years now. It's always "coming soon" so we shall see. For now I'm still on x11 just because it irks me to switch to wayland and then for all my games it's just running x on top of wayland. Why not just run x natively. I'll be very glad when it runs natively on wayland! But the when ...

Based on the pace of the merge requests, what's in the Collabora winewayland.drv directory [External Link], and what's in the winehq winewayland.drv directory [External Link], I would realistically say that Wine Wayland will land sometimes during the 9.x development cycle -- if we're being optimistic, it might land in the staging branch of 8.x development cycle, but I doubt it.

I really do not see it being well-tested enough to land in 9.0 stable release, I think it's more likely to land in 10.0 stable release, the stable release for 2025. And I don't foresee Valve creating a non "opt-in for separate beta branch" release of Proton Experimental with Wayland driver before 2025 as well -- even late 2024 would be optimistic in my opinion.

Of course, this is just my opinion, and I didn't even count the LoC or the complexity of the rest of unmerged winewayland driver. But I did test out wine-wayland in nix, and it still have issues, so that's why I feel pretty confident in saying 2025 as the "when", based on the current pace of the merge requests. Much like WoW64, it's best to not pay attention to it too much, until the devs are ready to announce something to users.

View this comment - View article - View full comments

Quoting: pleasereadthemanualI've been thinking about switching to Fedora Silverblue/Sericea soon, but the only problem with these distributions is their plan to remove Firefox from the base image [External Link] and install it as a Flatpak. It's not a good idea to install browsers with Flatpaks, because it weakens the sandbox and makes you more vulnerable to attacks. [External Link] I really don't want to play with my browser like that.

On the other hand, the project is kind of forced to pick the Flatpak because they can't legally distribute H.264/AAC and other codecs with a native Firefox package (I don't know why Flatpaks that come with the ISO are any different, buy anyway), so that results in significant usability compromises.

But I do love how you can have different versions of the same program installed with Toolbox. Really, that's game-changing. And I don't even need to install Gentoo to mess with slots...

If you don't like it, you can use ublue to just explicitly add it in the recipe.yml install list, so that there is always built-in firefox package installed in your image regardless of what upstream does. By default, they have firefox and firefox-langpacks in remove list, so it is literally just a copy-paste away.

It isn't as hard as you may think it is, I was a GitHub noob who didn't even know how PR works when I installed it, and now I'm slowly building up into the mix of kinoite and Nobara that I want (since Bazzite, the ublue image with SteamOS and Nobara packages which GE seems to contribute to, is still in alpha).

View this comment - View article - View full comments

Quoting: GuestWhat do you mean by "playing by the rules"? Yuzu is GPLv3 so you can build the source, redistribute it, redistribute binaries, and so on. This "Early Access" stuff is just a way to get some funding, you can totally get the latest version of Yuzu legally, even in binary form, without paying any money.

I know, but pineappleEA and Fan the Deck got criticized for sharing the way to get them for free (that I think EmuDeck switched to requiring the code given from patreon to get EA builds), so I'd imagine that they'd rather only people who pay the Patreon only use it.

And I might not mind, if there's a clear list of what I'm losing, when I'm getting it, and it isn't like 6 months of wait or something.

View this comment - View article - View full comments