Is this the laptop with the invisible trackpad?

View this comment - View article - View full comments

It would seem to me, that regardless of whether it's a native port or only supported through Proton, some of these games are eventually going to face regressions. Native is no guarantee of reliability, as seen in ARK's case. Buying games to play on Linux is inherently unreliable because the platform is unstable. Even Proton, which is more stable than Linux as a platform, still faces regressions like Deep Rock Galactic did last month.

No Tux, No Bux makes no sense in this context. No one, save for a handful of indie developers, cares that much about making sure their games keep working on Linux. A native port is a poor indication of which developers care, as in the case of ARK.

It's not hard to see why everybody likes Proton. Game developers don't have to put much, or any effort into supporting a Linux playerbase who naturally doesn't expect their support. Linux users don't have to rely on the developers to support them to continue playing the game. It's a win-win. Being a Linux user means accepting that 99% of the time, the vendor expects you to be using Windows or macOS, and you have to find a workaround to get it working on Linux—they're used to this shit.

Valve have built-in a workaround that has a very low amount of friction most of the time, which is impressive, but I don't think that any amount of duct tape will be able to obscure the indifference of developers toward Linux.

View this comment - View article - View full comments

I don't know how Textorcist made it onto the Verified list. That game freezes for a few seconds as soon as you type above 60wpm (this makes it difficult to dodge bullets), not to mention it's a typing game controlled entirely by the keyboard while simultaneously being a bullet hell. Protondb reviews mention input lag, which I don't remember, but I wouldn't be surprised if it had. How this makes a worthwhile experience on the Steam Deck, I do not know.

I had a decent time with it on a desktop despite these flaws. The writing and story is mediocre, but I think it's one of the better typing games.

There's an official announcement from the developers that it was Verified, but again, I really have no idea how such a clearly keyboard-centric game would make a good experience on the Steam Deck (even putting aside the bugs): https://store.steampowered.com/news/app/940680/view/3173356392642099069

But, TIL there's DLC for Textorcist. Nice to know.

Apparently someone has tried this on the Steam Deck but I don't really understand their explanation of their experience: https://steamcommunity.com/id/Chadworthy/recommended/940680/

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: pleasereadthemanualI tried to give Fedora a shot last year when my laptop's NIC died, but I couldn't figure out how to get the Wi-Fi driver compiled. I messed around with DNF, Yum, and probably yet another package manager but never ended up getting an internet connection after a few hours. On Arch, it took me about 2 hours to follow a pretty simple guide to getting my Wi-Fi drivers compiled.

I don't think I'll ever be able to use another distribution; Arch is the only one I've been able to figure out.

Hours to do what now? Sometimes I feel like using Mint and using most other distros is more like using a whole different OS. You install it, the stuff works, you start using it. Two hours? To compile a basic thing? Or worse? Gah. I don't have the time (or knowledge) for that nonsense.

To figure out how to do it. The guide was simple, but the process is not entirely intuitive and I screwed it up a few times by missing packages. Knowing how to do it properly now, it takes about 5 minutes to compile on a 2009 CPU.

Unfortunately the WI-Fi drivers are not mainlined, so you would have had to compile it on any distribution. https://github.com/RinCat/RTL88x2BU-Linux-Driver

I tried to follow the Github instructions on Fedora but couldn't get it to work, from memory. I just had no idea what to do, and couldn't find any easy way to get them working following Fedora's wiki.

View this comment - View article - View full comments

I tried to give Fedora a shot last year when my laptop's NIC died, but I couldn't figure out how to get the Wi-Fi driver compiled. I messed around with DNF, Yum, and probably yet another package manager but never ended up getting an internet connection after a few hours. On Arch, it took me about 2 hours to follow a pretty simple guide to getting my Wi-Fi drivers compiled.

I don't think I'll ever be able to use another distribution; Arch is the only one I've been able to figure out.

View this comment - View article - View full comments

Quoting: CFWhitman

Quoting: pleasereadthemanualYou 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.

Just for the sake of historical accuracy: Besides shell scripts there were things like InstallShield (basically still a script) available as distribution agnostic installers. Also, both of these things were pretty much exactly the same thing as Windows used for everything at the time (before the Microsoft Installer package manager existed). It's still possible to find Windows programs that use a script instead of a proper .msi package. Of course the scripts were only as good as the person creating them took the time for. However, generally, these old install scripts installed programs in /usr/local or /opt and didn't leave a mess behind (the weaker ones usually just left you with dependency issues for the so-called "installed" software they were for). You were more likely to get a mess when compiling software and using the 'make install' target that the developer created for make (though there were ways to deal with that cleanly as well).

The universal installer idea for Linux isn't very new. There were things like Zero Install (still maintained last I knew) and Klik (which AppImage is based on) quite a while back.

Thank you for the correction. I've only recently become a GNU/Linux user, so I don't have first-hand knowledge of what the landscape was like 10+ years ago. No one seems to mention these distribution methods in the histories I've read. The InstallShield Wikipedia page only mentions that it's used for Windows: https://en.wikipedia.org/wiki/InstallShield

I don't know how it was back then, but a considerable number of the scripts I've used in the past year or so didn't have uninstall scripts.

View this comment - View article - View full comments

Quoting: DerpFox

Quoting: pleasereadthemanualFlatpak tackles some long-standing distribution issues with GNU/Linux. It's not perfect, but something like it needs to exist in the future in order to deal with these problems that simply don't exist on macOS or Windows.

So do the "others". And each one of them have their own set of good and wrong. The one I had the least problem with is AppImage, and I don't particularly like it, it has plenty of design problems but each one I tried worked flawlessly. The one I want to try the most is Flatpack but each time I tried it was a huge pain in the ass to set up, didn't understand how I should do it, and it keeps throwing errors at me. Their doc makes it look easy, but when you get errors, you are on your own and good luck to find what they mean. And it seriously lacks a GUI to make installation fast and easy.

I remember having a bad experience with Flatpak a few years ago, but I tried it two weeks ago, and the process was as simple as installing Flatpak and following the on-screen instructions for the Flatpak package (which was [code]flatpak install flathub org.gnome.Evolution[/code]). Given I don't really use Flatpaks much (and I've since removed this package after Arch fixed Evolution), I don't know how much worse it gets.

I said "something like it needs to exist," not necessarily Flatpak. But it's pretty obvious AppImage is not going to win the mindshare battle.

View this comment - View article - View full comments

Quoting: slaapliedjeFlatpak 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.

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'.

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.

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.

View this comment - View article - View full comments

Quoting: ssj17vegetaApart from the Steam deck, is there any advantage from Flatpak packaging VS debian packages ?

Benefits of Flatpak are as follows:

• Because it ships with all necessary dependencies, it doesn't break when the operating system is updated.


• Flatpak works on 30+ GNU/Linux distributions, which means packaging is many times more efficient.


• Developers can package their own software, rather than relying on a third party who may or may not get around to it. And even if they do, they might not package it correctly due to the pressure they're under to get a swath of packages out. The developer cares more and is most familiar with their software. This is how it's done on macOS and Windows, for good reason, but up until now, that's just been too much work for developers. Flatpak makes it much easier.


• It's trivial for users to upgrade to the latest version if their distribution is behind on the latest version. Upstream will always be faster than downstream.


• If most distributions rely on Flatpak for most userland software in the future, package maintainers can spend more time on the packages that really do need their attention, namely core software like glibc, gcc, desktop environments, etc.

Flatpak tackles some long-standing distribution issues with GNU/Linux. It's not perfect, but something like it needs to exist in the future in order to deal with these problems that simply don't exist on macOS or Windows.

The downsides are that a lot of developers don't maintain their own Flatpak packages (or one doesn't exist at all), the sandbox is flawed, Flatpaks can introduce issues that didn't exist before due to its complex nature, it may be slower (at least in startup time), and the syntax for the package manager is just not as good as Pacman. Storage space is less of an issue the more Flatpak software you install.

View this comment - View article - View full comments

With any luck, this will solve most of the visual novels I play not being able to be fullscreened.

Though I'm probably misunderstanding something about how Gamescope works.

Re:

Quoting: GithubYou can spoof a virtual screen with a desired resolution and refresh rate as the only thing the game sees, and control/resize the output as needed. This can be useful in exotic display configurations like ultrawide or multi-monitor setups that involve rotation.

View this comment - View article - View full comments