Lutris, the free and open source game manager for installing games on Linux from many stores, has a new version available as work continues to improve Steam Deck support.
While the headline feature from the developer is "Steam Deck support", it's not quite there yet. They've made plenty of steps towards it, but currently there's no Flatpak package that works properly, and so to install you still need to turn off the Deck's read-only filesystem (which we really don't recommend doing). Thankfully, work on the Flatpak is the priority for the next version! Additionally, there's a new "Create Steam shortcut" option to add games from Lutris to Steam so it can be used in Gaming Mode which sounds incredibly useful.
New features include
An expanded "Add Game" box with more options
Support for Origin and Ubisoft Connect. They work the same as their Epic Games Store integration, with it needing to install the Windows clients. Sadly though, for now Humble Store is broken as Humble updated their API so work is needed to re-do that.
Here's some of the other changes:
- Add a coverart format
- Download missing media on startup
- Remove Winesteam runner (install Steam for Windows in Lutris instead)
- PC (Linux and Windows) games have their own dedicated Nvidia shader cache
- Add dgvoodoo2 option
- Add option to enable BattleEye anti-cheat support (for those games that support it on Linux / Proton)
- Default to Retroarch cores in ~/.config/retroarch/cores if available
- Add support for downloading patches and DLC for GOG games
- Add --export and --import command line flags to export a game a lutris game and re-import it (requires --dest for the destination path, feature still experimental)
- Add command line flags to manage runners: --install-runner, --uninstall-runners, --list-runners, --list-wine-versions
- Change behaviour of the "Stop" button, remove "Kill all Wine processes" action
- Gamescope option is now disabled on Nvidia GPUs
- Enable F-Sync by default
discover, gnome appstore and others are there to help you install flatpaks. Flatseal to configure it.
Yeah, cool but, as always, that's third parties that comes to compensate what the main project lack. That model is getting a bit tiresome because more often than not these third parties doesn't integrate well with the main project and add their own set of shortcoming and problems to the stack.
With that mindset, you can't really use any Linux distribution because they are all made of code from different projects that are integrated with each other to add functionality.
All that flatseal does can be done with flatpaks cli. Flatseal is just one tool to do it graphically and I rather have such a tool from a third party, and not tied to a DE, then only a libadwaita based tool by the gnome project. Having both wouldn't hurt, though.
Of all the *portable app* solutions out there, flatpak is the one that most respects the package repository approach of linux. Rather then shifting all problems in the deployment, the flatpak base is an extension point - standardized, managable and configurable. The cost of that is mostly put on the maintainer of the flatpak - again, similar to package management in distributions.
The one thing maintainers can't really solve is filesystem access, as the way people store their data can not really be standardized. The alternative route of symlinking data in the preconfigured filesystem context is managable, but not intuitive at all.
With the increasing usage and reliance on flatpak, I hope most DEs will soon add context menus that can configure the accessible paths to their application menus or window decorators.
Last edited by const on 5 April 2022 at 7:54 am UTC
For installers, look at the ones GOG has for Linux, or the Loki Linux Installer, etc. They are almost identical to Windows installers.Flatpak is another in a long line of 'we don't want to manage packaging for multiple distributions' solutions. There have been installer type things for ages in Linux that work the same way as Windows. Flatpaks are a little more similar to how Macs package things.Note that I said "or something like it". I prefer AppImages, personally, but the Flatpak package I tried worked fine. Better than my distribution's package, which was broken for several weeks.
Downsides are that the sandboxing can break integration (like Discord with Steam), or Lutris with its wmulators. Another one is because it doesn't follow the system libraries, you could end up with explouted versions if the Flatpak isn't updated. Which has always been an issue with bundled software. They also take up a lot more disk.
Don't get me wrong, I quite like flatpaks, but the Cons definitely all need to be listed. AppImages have similar issues, but have also been around quite some time, and act more like the 'Mac Way'.
You mention other "installer type things", but I'm assuming you're referring to .sh install scripts. These are not really the same thing as Windows or macOS. For one thing, depending on how they're implemented, they may not solve the dependency issue at all. They're also often difficult to uninstall and create havoc on the user's system. Flatpak and AppImage are not like this.
I listed these cons in the comment you quoted, namely "Flatpaks can introduce issues that didn't exist before due to its complex nature", and "Storage space is less of an issue the more Flatpak software you install." Of course, you can end up with multiple versions of libraries which Flatpak can't de-duplicate due to compatibility issues, but then, your options are "don't run it at all" or "use more disk space".
I'm not sure what you mean by "because it doesn't follow the system libraries, you could end up with explouted versions if the Flatpak isn't updated." But it doesn't follow system libraries for a reason: if it did that, the software would break. There is old software that simply can't be run with current system libraries and needs older dependencies, which without something like Flatpak, is a lot harder to get running.
A downside I forgot to mention is that because Flatpaks duplicate system libraries if they are installed by your distribution's package manager, you will end up with more memory usage because multiple versions of the libraries are running at once. There's not much that can be done about this one. It's a similar issue to storage space, but potentially more impactful.
If you're interested in reading an article written by someone who completely disagrees with my arguments: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html
Though this advice isn't going to work for projects that have a long legacy and just aren't easy to build. Arch and almost every other distribution has stopped bothering to package Anki for the past 2 years because it's too much work. Where is the user left? Follow the developer's advice to install it through pip?
I'm not saying that Flatpak should replace distribution-built packages. I'm saying they should co-exist.
I'm not sure what you mean by "because it doesn't follow the system libraries, you could end up with explouted versions if the Flatpak isn't updated." But it doesn't follow system libraries for a reason: if it did that, the software would break. There is old software that simply can't be run with current system libraries and needs older dependencies, which without something like Flatpak, is a lot harder to get running.I have yet to run into any old software that wouldn't run by installing the libstdc compat package. That is pretty much the one. Hell, even old Loki titles have updated installers that will work on modern distros.
Personally, I would rather something stop working than to have libraries that would open your system to assholes. Anyhow, it is just the biggest con of the sandbox images, and doesn't usually pertain to open source stuff as someone can patch those... more about a comment on old proprietary software.
My biggest complaints, as I said, are more about terrible use of space, not cleaning up out of date libraries, and breaking integration with other apps (in the same way iOS walls off programs so they can't share the same data store.) An example of this is installing the new Gnome Text editor out of flatpak... pulls in the gnome platform 42. But if you no longer need 42 (like say when 43 comes out), 42 will remain installed and unused...
I accidentally found out I had three nvidia drivers installed in there... be ause of GreenEnvy needing one...
See more from me