All of the studios that are enabling support for Proton with BattlEye and EAC are going to realize that Epic shipped a fundamentally broken anti-cheat system that will work for "some games", as long as you don't care about cheaters.

View this comment - View article - View full comments

To make your competitive game available for Linux distributions, you need to suffer more cheaters. Who is going to take a proposition like that?

Well, it was fun while it lasted. There's no crossing this roadblock unless developers/publishers intentionally handicap themselves for potential profit while the rest of the playerbase complains because of the significant increase in cheaters.

Tim Sweeney's argument about the profile of the game doesn't make sense in the context of EAC. Cheaters will be attempting to bypass EAC, not the game itself, so their strategy will work for all EAC games that work on Linux.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: pleasereadthemanualAs long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

 
apt source <package name>
or if you want to download and build, add -b.

If it's not in the repos, most source trees have a 'debian' folder, so you should be able to build it fairly easily on any deb based distribution. If it doesn't have a Debian folder, then there are now tools to try to automate that. Though I haven't needed to use those, so not sure exactly how they work.

PKGBUILDs are very simple to make and really are one of the shining things about Arch. Documentation is the other one. The only other free operating system that has comparable documentation would be FreeBSD, in my experience.

The package I was trying to build from source was yt-dlp about half a year ago. I spent about an hour looking around, but there didn't seem to be a clear-cut way to do it, so I inevitably just gave up and built it from source "the normal way". I'm not sure about the other reasons for building from source, but I'm so used to using Pacman to manage packages that I build with `makepkg` because it's an easy way to keep track of packages and cleanly uninstall them.

I made the mistake of using pip to install protonvpn a year ago...never again. Using pip is a surefire way to create an unmanageable mess of packages that Pacman inevitably gets confused with.

The documentation is really a goldmine. I always find myself there, learning new things about software that often the upstream developers haven't bothered to document. I've heard about FreeBSD, but haven't had the occasion to look into it.

View this comment - View article - View full comments

As long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

View this comment - View article - View full comments

While checking to see if Flatpak supports musl-based distributions like Alpine (it does), I found the antithesis to this article: Flatpak is Not the Future. [External Link] Well-reasoned and includes points that I simply didn't know about.

View this comment - View article - View full comments

Quoting: CyborgZeta

Quoting: pleasereadthemanual

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn a rolling-release distribution like Arch? No way. All of the packages are up-to-date, and if they're not, they are up-to-date in the AUR. Flatpak is way too much complexity for me.

I'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

I look at it this way. The less dependencies on my root filesystem, the less chance of breakage I have when updating the OS or programs. I have encountered dependency hell issues on Ubuntu + Debian before; so that's one reason I like using Steam as a Flatpak, because I'm not introducing a bunch of 32-bit binaries to my filesystem.

This is the primary reason I avoid the AUR. It has nothing to do with trust. I did my research before switching to an Arch-based system, and most of the people I talked to told me that the majority of stability issues they'd run into with Arch involved programs installed from the AUR. I don't use the AUR because I don't want anything from outside the official repositories on my computer. Flatpak at least has the courtesy to not touch my filesystem and update independently of the core OS. Perhaps your experience running Arch is different, but I've been doing things this way for over a month now since installing EndeavourOS and have had zero issues with the OS itself.

As for Firefox, well I only have few extensions installed myself, uBlock included. I just like the sandbox because the way I see it, if my browser is somehow compromised then at least it's separate from the root filesystem. Also, I've noticed that using the Flatpak gives me a less identifiable fingerprint when checking https://www.deviceinfo.me/ [External Link]

From a stability perspective, sure, I can see the virtues of Flatpak. And it might be a good way to go for newbies in the future—but only if it's more reliable than ordinary binaries. I've seen people having more issues with Flatpak packages (including Steam; I've heard people say they couldn't get Proton to work through the Flatpak version, etc.). So while the stability of the system overall is improved, Flatpak packages themselves may not be reliable—this is one reason I always go to the AUR first, because I know things will generally "just work". Flatpak packages by their nature are far more complex and prone to issues you won't find in ordinary binaries. I hope this is improving over time, but I wouldn't have a clue.

It's good that you don't avoid the AUR out of trust issues. The trust level should be exponentially higher than installing a PPA binary that somebody has compiled for you versus a short bash script that you can examine closely for issues. AUR packages can certainly be less reliable, that's true, but it depends on the package. AUR packages are exactly the same as ordinary Arch packages; the only difference is that they aren't in the official repositories. They are all built with PKGBUILDs. The differentiating factor is the quality of packaging.

Take Anki as one example: it was dropped from the official repositories, but seems to still be maintained by developers/packagers for Arch. The quality of this package should be high. AUR packages are also compiled inside of a fakeroot and don't touch the root filesystem until after they've been compiled, and then most only enter the root filesystem (with your permission) to add the package to the PATH and maybe add some documentation. I personally haven't faced any stability issues with the packages I've used, as you speculate.

I'm not saying that you should use the AUR if you don't want to and you're doing something that's already working for you, but that it's certainly a valuable place to find software.

Perhaps it's separate from the root filesystem, but your most important information tends to be in your home directory, which software don't need any permissions to access. The best way to protect against malware and exploits, unfortunately, is to not get hit in the first place. Relevant xkcd. [External Link]

View this comment - View article - View full comments

Quoting: Eike

Quoting: pleasereadthemanualI still don't really get what the audience for the Steam Deck is. I kind of want to buy one, but then I remember I have no use for it. I can play games in bed with my laptop. I have 4 GNU/Linux computers already. If I'm outside, I don't want to play games, otherwise I wouldn't have gone outside.

I guess I don't really understand the portable gaming idea to begin with. I did play Pokemon a lot as a kid, but those days are long gone. I played a lot of mobile games when I was younger, too, but that was mostly the novelty of it rather than them being any good. I don't think that phase lasted very long.

I guess it doesn't help that a lot of the games I play involve using Textractor, copying text to the clipboard, looking it up in a J-J dictionary, and creating an Anki card. Not really the type of gaming suited for a small, portable device without a keyboard.

I just have no idea what to think, because I am clearly not the target audience for this.

Well, there's obviously a target audience for mobile gaming. The target audience for Steam Deck is mainly the intersection of these with the Steam users. They already own (often lots of) games running on Steam Deck, and they can play games bought for mobile on their PC as well.

The appeal of mobile gaming? Well, I'm not into it either, but I can understand that a laptop is too big for bed for many. And back in the days, before Covid, I was using public transports for a 3/4 hour to work and a 3/4 hour back. Time for gaming, maybe?

I would guess also that a lot of people don't own laptops. It's not hard to see why. They're harder to maintain, upgrade, or replace parts (or at least more expensive).

Half of my computers are old Dell laptops (fantastic to repair while still in warranty). In the past 6 months, the USB hub in one of them appears to have shorted out or something and can only push enough power to storage devices and nothing else, the NIC in another laptop died and I had to buy a USB NIC (which meant several hours trying to get the out-of-tree realtek driver work on a new Arch install, but I learned a few new tricks), and the battery in my other Dell laptop no longer charges (thankfully it has an extra bettery).

Oh yeah, and with the ASUS laptop I bought exactly 2 years ago, the cord for the power brick, as it's called, stopped working and I needed to replace it with one of the cords I kept from somewhere or other. This led me to look up finding a replacement charger for this laptop—not easy, ASUS lists it but doesn't sell it. There's an Ebay listing, and that's about it.

All this to say...yeah, I get the appeal behind a smaller, easier-to-maintain device where the vendor actually sells replacement parts and is happy to let you repair your own device or find a willing third party to. I don't even know what I'm going to do when the power brick for my ASUS laptop dies...go to Ebay, I suppose.

I have half a mind to blame GNU/Linux for breaking all of these laptops (as I only installed it on them in the past year or so), but realistically, they've probably just seeing a lot more use than before.

I had a friend who got into XCloud or something similar while commuting, but me, I just don't really care for playing games in public or out and about; I'd rather read a book, personally.

Now, if only Worm came out in paperback...

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: pleasereadthemanualAs for a "free copy", what does this mean? There is no free version of CrossOver Linux. There's a 14-day free trial. There's a yearly subscription. There's a lifetime subscription. And there's the CrossOver One one-time purchase (which doesn't exist right now). So based on what version it is, that will determine the value of it. Given that they don't say "1 free year", I suppose it's meant to be lifetime or a particular version (CrossOver 21) forever.

They say it's Crossover Linux One, which is not listed officially by CodeWeavers. We've asked for clarification. Will update if / when we get a reply.

Ah, i know that one.

CrossOver One is not officially listed by Codeweavers as of ~August last year. It was a version of CrossOver that received no support and only contained that year's version of CrossOver. There were no software upgrades. It was $39.95USD.

You can see the store page as it originally appeared a year ago with the CrossOver One option here: https://web.archive.org/web/20210102011151/https://www.codeweavers.com/store/ [External Link]

View this comment - View article - View full comments

Quoting: ShinyaOsen

Quoting: pleasereadthemanualOn a rolling-release distribution like Arch? No way. All of the packages are up-to-date, and if they're not, they are up-to-date in the AUR.

Use flatpaks on my arch install for handbrake, fre:ac, ungoogled chromium, and Jellyfin Media Player.
Reasons being handbrake has a bug in the arch repo that made HEVC/265 encode take 10 times longer(10fps on flatpak to 0.4fps on arch repo) aur versions dont fix this and the flatpak version is official the only thing I'm missing is fdk-aac which i only use when using 264. Fre:ac only available in AUR crashes constantly and the GUI doesn't show some times so pretty unusable and flatpak version is official. Ungoogled Chromium don't want to compile and flatpak is offical. Jellyfin media player don't want to compile and flatpak is official.
I'll be using the OBS flatpak in the next release as it will be official and have all features available with out needing to compile the missing features from the AUR.
On my laptop that is running opensuse tumbleweed I use the flatpak for asunder as on opensuse asunder isnt up to date and is deprecated since it uses gtk2 still and the creator endorsed the flatpak version.
Not that flatpak stuff is perfect switched off the Firefox flatpak after it bugged my profile and 264 videos playback can be bugged some days probrobly switch back to it sometime in the future again tho.

I suppose it's a matter of taste, for the most part.

From my perspective: I use plain FFmpeg, the brave-bin package (so no compilation), and only use basic features of OBS.

I'm not saying the AUR is without its issues, but it's a lot better than a PPA or nothing. I'll relay my own frustrating experience with the recent Anki situation. Anki was removed from the official repositories following an announcement from Anki that they were going to change their compilation process significantly yet again. I guess the maintainer just got tired of having to deal with it. Now there are 3 or 4 different versions in the AUR, and the best one for compilation is still incredibly involved and failed for me a few times. With the recent update, I couldn't get it to work at all and ended up using the official binary bundle (which worked fine).

Anki is not the typical AUR experience for me; it's very complicated and has a moderate chance of failing to compile. Most of it is stuff like Gazou and xow-git; small programs.

But it can also be better than the alternative. With Audacity 3.0+, all of the AppImages are broken, the Flatpak also seems to fail, and Arch doesn't maintain a version of it past 2.4.2 in the official repositories. The AUR package compiles within 5 minutes and works great. Aside from wxWidgets just being wacky in general, but nothing will fix that.

I personally would still rather contend with the AUR than Flatpak for software right now. Maybe that will change in the future.

View this comment - View article - View full comments

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn a rolling-release distribution like Arch? No way. All of the packages are up-to-date, and if they're not, they are up-to-date in the AUR. Flatpak is way too much complexity for me.

I'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Of course, there's nothing stopping you from using Flatpaks on Arch Linux, but I think the AUR addresses some of the biggest issues that distributions like Ubuntu, Debian, and Fedora don't handle well without Flatpak.

I'm a GNOME user that doesn't use any extensions :P

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

Does Flatpak have a package for php7.2/php7.2-fpm? Because that would certainly be less of a headache than compiling it from the AUR. I don't really think it's the type of thing you can package with a Flatpak, though. Otherwise, I personally don't have much use for it.

View this comment - View article - View full comments