Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by Kithop
Dangeresque: The Roomisode Triungulate now available for Linux
15 March 2024 at 4:43 pm UTC Likes: 2

Did the quadratic formula explode? I see a "Strong Ba..." in there, but it's getting eaten by some... Linux or something.

( https://youtu.be/Az49aNuYeJs )

Game over for Roblox on Linux / Steam Deck as it's now blocked
1 March 2024 at 2:26 pm UTC Likes: 14

Simple solution to any of these that I (mostly) try to stick to:

Don't buy/play or support multiplayer games that don't support you hosting your own dedicated server, on hardware you control (none of this forced 'rent a server from our partners' BS either), using configs and settings you control, including the ability to opt out of and disable whatever anti-cheat they support.

Something like Minecraft Java? Amazing - totally the kind of thing an interested person can set up a private server for, mod and customize to your heart's content, invite friends and family onto and be able to admin (cheat) to fix when little Timmy's house gets blown up for the 5th time.

Any kind of 'live service' game? Not so much.

Now even I admit this can't be a 100% hard and fast rule - this means no MMOs, nothing ranked or hyper competitive, and not even the likes of casual things like VRChat (which *has* anti-cheat that works on Proton and they explicitly court Steam Deck support on, but that could change at any moment!), so you can be flexible if you so choose, but this is a general concept I try to stick to.

Kind of how hearing a cool game everyone talks about is some console exclusive, for a console I don't have nor have any other use for? That's nice, but I'll pass...

OpenAI say it would be 'impossible' to train AI without pinching copyrighted works
9 January 2024 at 11:18 pm UTC Likes: 3

Quoting: scaineI'd love to know where the money is being made with this shit.

Venture capitalists pouring money into it in the hopes that there'll be a bump in all this 'interest' in LLMs, so they can dump it when it peaks. It's just another dot-com bubble, or 2008 bubble all over again.

I wouldn't be surprised to learn all these AI companies are just burning cash in the hopes that they're the ones 'on top' when it all comes crashing down. As to how to 'monetize' it and actually make money off of all that wasted electricity and questionable results? That's the next guy's problem.

Cross-distribution support improvements coming for Canonical's Snap packages
9 January 2024 at 10:32 pm UTC Likes: 3

Quoting: mattaraxiaYou have a need to snadbox *everything* already. I'm blown away this mindset exists.

Ah yes, I'm going to sandbox 'ls' from the filesystem, and then explicitly fiddle to punch holes in to make it useful again...

Facetious and hyperbolic, yes, but let's not get into absolutes here. Sandboxing is great when you want it, but it's most definitely not for *everything*. There is a time and place for it, and I believe there are distros that lean on it extensively. It's great tech, but also *incredibly frustrating* as a user if you're not expecting it. All the Wayland xdg-desktop-portal stuff comes to mind - I love Wayland, but it shouldn't take *three separate popups* to allow OBS or Discord to screenshare a particular app, with no option to 'remember my choice forever please'. We're going to end up with Windows UAC level annoyances again, and then people will just turn it off entirely.

Should apps like Steam be sandboxed from accessing anything outside of ~/.steam (or equivalent)? Sure. Should your browser be sandboxed to not access things outside of your Downloads folder? Sounds like a good starting point. But remember, you may want to preview that PDF from your Documents or a thumb drive, or a static HTML page you're working on off a network drive, so it's got to be easy to do so and yes, explain and understand the implications.

If you want to run a Flatpak or Snap, you should understand that yes, you get sandboxing and the double edge that goes with it in terms of 'why can't this app see my files'. Unless your distro is explicitly designed for it, though, I believe it should not replace your native package manager. If I want to switch, let me make the choice to switch, don't start forcing Snaps on me when I call apt and expect a .deb.

Cross-distribution support improvements coming for Canonical's Snap packages
9 January 2024 at 7:01 pm UTC Likes: 1

Quoting: damarrinSnaps/flatpaks are there to make packaging and distribution easy for software creators and make them independent of distro maintainers who may or may not include a given piece of software, or may be including an ancient version of it.

Totally agree - that is 100% a valid use case for this, and a better way of putting what I was trying to get at: if your distro *does* ship an up to date version, you should use that as your first choice, since it may need to have been customized for said distro, it'll be kept up to date with shared libraries, etc., but if it *doesn't* (and you don't want to go down the rabbit hole of compiling it yourself... I've written my own janky PKGBUILDs for that, in fact, and it's not user-friendly), these are a great fallback.

My issue primarily is that Canonical likes to push the snap version of a package as the first choice, regardless if there's a perfectly valid .deb available, and I think that's wrong, because that pulls Ubuntu even further away from upstream Debian and introduces yet another unique distro-ism when trying to troubleshoot. The cynical part of me worries that 'pulling away from upstream Debian' is their big goal.

That said, it's been a few years since I ran Ubuntu on a desktop - does an 'apt install firefox' still pull in the snap by default? If they've walked that back since, then my argument is invalid and out of date.

Cross-distribution support improvements coming for Canonical's Snap packages
9 January 2024 at 3:08 pm UTC

Yeah, I don't mind stuff like Flatpaks for devices like the Steam Deck, where you don't normally get write access to the entire filesystem, but on desktop?

Unless you have a need to sandbox something, just use your distro's packages - they will be compiled with the recommended versions of libraries for the whole ecosystem, instead of storing multiple, slightly different (and potentially way out of date!) versions depending on what you're installing.

Security vulnerability in a shared library? Update it through your distro and you're reasonably well covered across everything on your system. Flatpaks and Snaps? Time to download updates to every single sandboxed app... if they updated at the exact same cadence, if they bother to update it at all. (Yes, it shouldn't mean a *ton* of wasted space as they link and share the same library copy once you've downloaded it once, AFAIK) Almost as bad as all the 'native' apps just using downright ancient, vulnerable versions of Electron for way longer than they should. (*cough* Discord)

It's cool tech, but it should remain specialised, and *definitely* not the first thing you reach for for regular day to day usage, IMO. Heck, snapd was always pretty much the first thing I purged (the Firefox snap was way, *way* underperformant compared to the regular .deb at the time) when I used Ububtu, until I switched distros entirely. You don't *need* to keep five different versions of a library to cover two dozen Flatpaks or Snaps on disk in almost all normal use cases, unless the library update is an API/ABI breaking one.

All that said, one of the biggest criticisms I've seen of Canonical's behaviour is that it feels like vendor lock in, so if it's being opened up to other distros (and it's easy for communities to host their own Snap repos *not* on Canonical's servers), then it's still interesting tech to watch and potentially keep in your back pocket for those situations where it makes sense, so good on them for at least trying, now.

PipeWire 1.0 is out now for modern Audio and Video on Linux
27 November 2023 at 7:52 pm UTC Likes: 4

Absolutely loving Pipewire, been using it for a while now. Reminds me a lot of CoreAudio on the Mac, though with a bit more up front configuration.

It being a drop in for PulseAudio, JACK, and ALSA, all at the same time while still being great on latency is just *chefkiss*. I can go from gaming to recording music tracks in Ardour with no messing around.

Welcome to the new and much the same GamingOnLinux
22 October 2023 at 6:05 pm UTC Likes: 6

Patreon's... definitely not my first choice, considering some of the stuff they've pulled over the past few years, but I appreciate there's at least another option (even if Paypal is *also* scummy... But pick your poison, I guess).

Glad to see it all going to good use and making this better for everyone! We appreciate the work you do. <3

Swords of Freeport is a text-mode social RPG like retro MUDs and BBS door games
5 October 2023 at 2:53 pm UTC Likes: 1

As someone who still hosts an old social MU* for friends off an old RasPi in a drawer, and learned Multi-User Forth (MUF) and MPI as some of my first programming languages in... elementary school...

This is certainly A Thing. I never got big into the combat-heavy MUD way of doing things, but it's fun seeing people keeping this style alive!

Counter-Strike 2 is out now with Linux support
30 September 2023 at 4:23 pm UTC

Quoting: Samsai
Quoting: Kithop...really, the sound issue is because it's trying to hit ALSA natively? PulseAudio is... *checks notes*... 19 years old at this point. (GitHub issue link )

Though at least later on it sounds like it's from people using the Flatpak version instead of native - and yeah, that's the first thing I'd say for almost anyone: don't use Flatpaks for this. Use your distro's native Steam package as your first choice, and then move down the line to like, getting it direct from Valve or whatnot if they don't have one. Running Steam in Flatpak or Snap just sounds like a Bad Time. But hey, at least there's validation that the sandbox is, uh, sandboxing things!

...like your own app from a decent audio API... ;p

That's not how that works, the sandbox isn't just arbitrarily deciding to block a game from using ALSA (there's a bunch of other games that also use ALSA which work just fine). And, funnily enough, I tried it out on Flatpak Steam today and it seems to work fine, sound and all.

So, it's almost like the game either had regular launch problems or some setup-specific problems, but which weren't the fault of Flatpak. So, it seems your blame was misplaced.

I've admittedly never bothered with Flatpaks at all outside of the Steam Deck, and yes, there are potentially plenty of complicating factors, but multiple people had Flatpak issues; that's all I mean to reference, there. It sounds like it wasn't blocking ALSA, but access to PipeWire, so presumably there just needs to be some updated default configs upstream somewhere.