Exactly! My code has a handful of “expect()” calls in it, and each one self-documents why it’s okay. It’s like a comment, but it appears in logs if it ever triggers.

Exactly. If there’s only one thing I could bring from Rust into another language, it would be Mutexes. It’s so nice to guarantee safe access to data.

I kind of disagree here. .lock() has the following behavior:

• panic() if the lock is already held by this thread - should never happen
• error - if the current lock holder paniced

The second case is incredibly rare, so it’s one of the few cases where I think .unwrap() makes sense in production code. But it should be an option to handle it in robust code that should never go down. This is rare, but it’s not so rare that we should force all locks to exist in a context where we can recover from panics.

.try_unlock() should never exist because there should only be one way to release a lock: drop(). Having a way to maybe unlock a mutex adds a ton of issues. If we assume this was a typo, .try_lock() absolutely exists, and it’s for a non-blocking lock.

It doesn’t, I just figured that if I’m going to go through the effort of switching the client launchers, I’ll look for something that also works w/ servers. My kids are the ones who play Minecraft, not me, and I’ve largely avoided bothering with mods, but if something handles it well, I’ll use it.

Right now, to add a mod, I have to copy the mod to a few computers (could probably automate w/ Syncthing or similar), and then filter by whatever server mods are needed. And if I upgrade Minecraft, I need to upgrade the server as well, which is a bit of a pain.

Huh, I didn’t realize it was so commonly liked. We currently use MultiMC, which was the go-to launcher some years ago, but maybe I’ll give PrismLauncher a try.

Does it do anything about launching servers? I currently launch Minecraft w/ systemd on boot, and I’m thinking of moving it to my NAS instead of my desktop (that way it’s always on), so I’m interested in any way of better managing it since I need to keep the mods consistent between the server and our computers.

That might be relevant if OP was talking about using Proton VPN, but they’re talking about Proton, the compatibility layer shipped with Steam for Linux.

There are a ton of documented cases where bans falsely identify Linux users as cheaters, and later many (most?) of those bans get overturned. It seems to come in waves (likely an anti-cheat update), and it’s annoying every time.

My solution is to just not play games with anti-cheat, because there’s no way I’m going back to Windows, and there’s also no way I’m going to play the ban/appeal game. My time is worth more than that.

Eh, the only “seasons” I play special games for are Halloween (something spooky) and Christmas:

• Halloween - last year it was Darkside Detective and Return of the Obra Dinn - usually something spooky, but not into horror itself
• Christmas - last year it was Arida: Backland’s Awakening and Opus Magnum; usually puzzles and heavier stories

This year, it’ll probably be:

• Halloween - finally finish Metro 2033 series
• Christmas - probably some long game I’ve been sitting on, like The Witcher series or RDR II

Other than that, I don’t really games based on the season, but based on time I have available and whatever interests me.

Hokkaido somewhere?

Sure, but I guess I don’t really understand the argument. Why would Rust need to be involved earlier in the process? Isn’t the point to have a way to compile rustc completely from source?

I guess it’s cool to have multiple ways to get there, but that project would take way less work and get to the same end goal. It sounds to me like the author is trying to justify a cool project instead of trying to solve a real problem. That’s completely fine, but I think most people would be happy with the mrustc project.

It seems it would be a lot easier to work on the GCC compiler, and work with others to bootstrap GCC (if it hasn’t already been done). Getting the GCC Rust compiler able to compile some version of rustc probably wouldn’t be that hard, and then you can just use that version to compile up the chain to modern Rust.

I switched to Linux a little before Steam came to Linux, and I made my Steam account pretty much as soon as it came. I’ve been here a while and it has been a wild ride. I went from mostly buying games through Humble Bundle (best way to find good native Linux games in the early 2010s IMO), to Linux native games through Steam, and finally to Windows games through Proton (I did play a handful through WINE, but it was always a pain).

It’s been amazing to see gaming on Linux go from something enthusiasts do to something that’s a mass market product.

This has absolutely nothing to do with Linux gaming.

It doesn’t.

Or Portal 3. I’d be down for either.

At least when I tried, it was easier to get Windows Steam to work than Linux Steam. Maybe the Linuxulator has improved since then.

Yup, I used to use FreeBSD and it worked okay. When I used it, the Nvidia drivers were better than AMD, but I don’t know if the FOSS AMD drivers have been ported to FreeBSD.

I just watched this mental outlaw video about it, and he breaks down what this means, what cards it applies to, etc.

I’m probably not getting NVIDIA for my next card, but this certainly is a step in the right direction. If they prove they can keep up with the Linux ecosystem and play nice (e.g. the debacle around Wayland), I’ll consider getting one.

For now, AMD provides a fantastic Linux experience and that’ll need to be matched for me to even consider NVIDIA. NVIDIA used to be way better on Linux, but they broke that trust and it’ll take a while for me to give them another shot.

IDK, I think snakes would also eat a crab, not sure about dragons. I don’t trust either, you’ve got to be on your guard when you’re this delicious.

I don’t think crustaceans should be trusting a cephalopod. Seems kinda sus…

Yup, our webapp has a bunch of security advisories in our NPM packages, but we only use node.js for the build step, so most are completely irrelevant since they only matter in a server context. It’s valuable to keep the alerts to a minimum so we don’t miss something important (e.g. an XSS vulnerability), but it’s not critical.