Quoting: akselmoEdit: I think they don't have enough players in their lootbox circus, so this is their last hurrah trying to get players?

They don't have lootbox anymore, just a stupid battle pass and per-item purchases, but they are being desperate after a bunch of people declared the game dead following the cancellation of the PvE campaign.

View this comment - View article - View full comments

I personally want this to be turned on, opt-out by default. I saw the proposed design and it seems fine to me. And the potential benefit to me is that Fedora and Gnome may stop being so out of touch that so many people uses the thing they refuse to ship by default for no reason and see any other user experience issues on the platform.

View this comment - View article - View full comments

Quoting: CanadianBlueBeerIf I set monitor scaling to 125%, then steam seems to be the right size.
Everything ELSE is too large though.

sigh (and the scaling button in steam does nothing)

You can probably fool it for Steam by appending your desired scaling through env vars. AFAIK the env var related to scaling for GTK are either `GDK_SCALE` or `GDK_DPI_SCALE`, and for Qt I think it should be `QT_AUTO_SCREEN_SCALE_FACTOR` (checked with `env | grep -i scale`).

View this comment - View article - View full comments

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