Elite Dangerous is my go-to lately.

It’s different to most other games, by not being goal-oriented except for the goals you set for yourself. No main quest line dictating progress. No mandatory tasks. No win condition. Instead, it drops you into a simulation of our entire galaxy roughly 1300 years in the future, where humanity has mastered hyperspace travel and spread through hundreds of star systems.

(To give an idea of the simulation’s scope: Around 85 million systems have been recorded by players so far, and those are a vanishingly small fraction of what’s out there. Space is big.)

I like that it offers a variety of activities to fit whatever mood I might be in on a given day. I can hunt pirates, mine asteroids, engage in a bit of piracy myself, find and collect bio samples, infiltrate rival settlements, venture into vast unexplored areas of space, discover Earth-like worlds that nobody has ever encountered before, defend humanity against hostile forces, photograph beautiful stellar phenomena, rescue stranded survivors, customize and finely tune my ship to perform beyond its original specs, team up with friends, pledge to a political power and expand their influence, or chill out as a space trucker and haul cargo to earn enough money for my next upgrade. It can occupy all my attention, or just be relaxing entertainment while I listen to music or an audiobook.

It’s an MMO in the sense of having a large game world (galaxy) shared by all players in real time, but PvP is optional. One mode exposes you to other players, while another limits you to NPC encounters. You can switch between them at will.

One warning: A space ship has more than a few controls to learn, and they’re better suited to a game controller or HOTAS than a keyboard and mouse. I use button combinations for almost everything beyond basic flight controls, since there aren’t enough buttons on a controller for everything.

tl;dr: It’s a Yuzu fork.

This might be an unpopular opinion, but I feel Tears of the Kingdom is overrated. Yes, it has some welcome quality-of-life improvements, and yes, it has more content, but I find the characters less interesting, the encounters less inspired, and the environments a bit repetitive compared to its predecessor. Every time I pick it up again, I get bored within a couple hours and go back to another play-through of Breath of the Wild.

I would vote for Baldur’s Gate 3 over TotK without hesitation.

This tool looked interesting to me until I noticed that its external dependency count is in the hundreds, each of which increases exposure to vulnerabilities and supply chain attacks.

I hope that Rust will some day have a rich enough standard library that the “trust everything” software development model falls out of favour amongst the developers who use it.

Some of the APIs in use on Linux today come from older Unix variants. (For this reason, I probably wouldn’t call one of these a “Linux API” as the author did, though I guess it works linguistically for those that are usually present on Linux.) These APIs have semantics that were designed before threading existed on many platforms. Making them thread-safe without breaking existing code can be challenging.

If setenv(3) is among these, it could explain why glibc’s implementation doesn’t support multi-threaded programs, and why its documentation states as much. To have used it in a multi-threaded environment, ignoring the docs, was a bug in the Steam client. Perhaps it never occurred to the people who ported Steam’s code to glibc that threading issues might be different from what they were used to on other platforms.

To be fair, the author might be aware of this, as he did refer to glibc’s implementation as a tradeoff rather than a bug.

I think zero RPM worked before (on cards that supported it) but wasn’t directly configurable in Linux.

It doesn’t necessarily mean putting it in a game’s launch options. Environment variables can be set in a startup script, or a flatpak config, or a command line, for example. But the Steam launch options approach is convenient when you’re just testing something for one specific game.

I would definitely try it. If it doesn’t help any game, or if it causes glitches/crashes, an environment variable is easy to revert.

I built a new machine pretty recently, also with an RX 7800XT GPU (factory overclocked). When sitting idle at the desktop, the system draws about the same amount of power as my old machine did with an RX 480. So I think trying to put the big GPU to sleep during desktop use might be barking up the wrong tree.

I suggest getting a power monitor, like a Kill-A-Watt, and taking measurements while you experiment. Here are some ideas to consider:

• Are you using multiple monitors? I have read that newer AMD GPUs sometimes draw more power than they should in this case. It might depend on the resolution and/or windowing system in use. (I don’t remember if the reports I read were on Wayland or Xorg.) It almost certainly is a driver issue.
• Are you using nonstandard timings? Have you tried different refresh rates? https://community.amd.com/t5/graphics-cards/which-monitor-timing-parameter-allows-gpu-vram-frequency-to/td-p/318483
• Have you been playing games for hours every day, with no frame rate limit? The graphics card can draw considerably more power pushing polygons at 1440p@180Hz than it does at 90Hz, for example, and I don’t think the wattage progression from idle to full load is linear.
• Are you using recent kernel and firmware versions?

“Welcome to the dark side of cozy.”

AFAIK, RetroArch is just a front-end for the emulators that actually use the controller, so getting this to work depends on the emulator you’ll be using.

I would expect any decent emulator on Linux to work with the standard Linux joystick and/or evdev APIs, which are supported by the Linux DualShock 4 driver. This driver is built in to the Linux kernel; nothing more should require installation. However:

It’s possible that your distro might not load that driver automatically. To check, connect the DS4, power it up with the Playstation button (if its light isn’t already on), and run lsmod |grep -E 'hid_sony|hid_playstation' in a terminal. If it responds with some lines containing hid_sony or hid_playstation, then the driver is loaded.

It’s possible that your distro might not have labeled the DS4 as a joystick device in udev, which isn’t strictly required, but some software expects to see. On the distros I’ve used, the easiest way to get this done is to install the steam-devices package. I think most desktop distros do it automatically these days, though.

You don’t want DS4Windows. That’s Windows software. There is a program (not a driver) called ds4linux, which creates a virtual Xbox controller alongside the real DS4, similar to what Steam Input does when you use it. You shouldn’t need this for games/emulators that were written properly for Linux, but it’s there for cases when a developer took a shortcut and assumed Microsoft game hardware is standard on our non-Microsoft OS. Alternatively, I think you can use Steam Input when launching non-Steam games in Steam.

There are various joystick test programs for linux, to give you an idea of whether the OS sees the controller. (This can be helpful when a game doesn’t appear to see it, to determine if it’s the game’s problem or a connection/driver problem.) KDE Plasma has one built in to the System Settings. There’s a also generic one called jstest-gtk, available with most desktop distros. There are probably more out there.

Keep in mind that test programs like that don’t necessarily know which inputs map to which buttons/sticks on the controller. Don’t panic if they look mixed up in a test program; try it in a game first. If they’re still mixed up, look for a way to remap the inputs.

Apple offered a Ms. Pac-Man port on these devices for a while, and it was surprisingly good.

It’s a bit of a leap to say the “owner” changed. Ryujinx is MIT licensed, allowing anyone to clone the original code locally, build upon it, and publish it to a public host. Looks to me like that’s what happened here. I don’t see any reason to think the original repo was renamed or moved to another user’s account.

The top contributor is gdkchan presumably because gdkchan’s commit history is still there.

Ah, so it is. I wonder when that happened. I guess .world might have outgrown beehaw’s ability to make up for spotty moderation.

I’m pretty sure they don’t block sdf. That’s where I am, and I’ve had several interactions with Beehaw folks while here. :)

Fun fact: Beehaw and sdf are among the few well-known instances that don’t hand their users’ traffic over to Cloudflare.

https://beehaw.org/instances

One of those is dead.

One is blocked by OP’s instance.

One is hosted on an instance that more than a few people avoid.

One is nearly empty, but maybe worth joining and starting some discussion? !patientgamers@lemmy.world

You can’t know with certainty on Signal that the client and the server are actually keeping your messages encrypted at rest, you have to trust them.

This is untrue. By design, messages are never decrypted on servers when end-to-end encryption is in use. They would have to break the encryption first, because they don’t have the keys.

Some advantages are listed in this /c/Technology comment:

https://lemmy.sdf.org/comment/15398090

Debian is also chill. There’s always unstable (can’t remember the current name. Debian Trixie?) For something that’s more up to date

Debian Unstable’s code name is always Sid. Debian Testing’s code name is always the one that will become the next Debian Stable release, currently Trixie.