I believe Rust is a poor choice for games. Games have always needed to balance iteration times with performance. C++ has traditionally been a good middle ground, but nowadays computers/consoles are fast enough that even javascript is a solid choice.

Rust makes sacrifices to iteration times for safety, not even for performance. It's optimizing the wrong thing and making the wrong trade offs (for games), and probably the primary reason there are so few Rust games. Your character controller, dialog system, inventory management, renderer, physics engine, and 99% of your actual game systems don't need memory safety.

Multiplayer and file IO would benefit from memory safety, and it would probably be a good idea for existing C++ game engines to consider adopting Rust frameworks for those parts (even if it wouldn't be bullet proof).

With that said, game dev is an art/craft, and people should use whatever tools they like to create their art. It doesn't bother me. I'm just saying that, from a strictly engineering opinion, I don't think Rust is the most pragmatic choice for game dev.

opponents of truth, freedom, and systemd

Do you get paid by the Systemd Hate Club™ for your efforts? Are you full-time, or just a freelance clown?

I'm not saying it's okay for Bazzite to have shipped a broken update. That's sloppy.

But you really are being a dumbass here. The solution for your problem is a rollback. That's the whole point of atomic distros: rollback when something breaks using a single command (or just reboot and pick the grub option). Why bother with atomic if you're not going to use one of the killer features?

And in case you didn't know, Flatpaks aren't part of your OS, so you can still do flatpak update even if you don't update Bazzite. There is literally zero cost to doing a rollback, and that's by design.

Are we entering the Linux 11 era?

I just remembered that I'm the guy everyone in my family goes to when they need someone to scan their ID or passport for whatever stupid bullshit.

Guess it's time to sign all my conservative family members up to gay porn websites!

I see, by PC you mean you don't want a traditional 'tower' PC, which is perfectly reasonable. I personally consider anything within the umbrella of "PC gaming" to be a PC, including laptops (even Macbooks).

It was an idea he wrote about once for a high school homework assignment, and he got an A on it. (/s for people not familiar with Canonical's weird obsession with employee highschool performance)

I'm a simple man with simple tastes. Saltine crackers with mayo are a comfort food for me.

Wtf is þ and why is it invading your comment?

This doesn't appear optimal. The correct way to melt a CPU is to make use of as many functional units as possible in parallel, while avoiding pipeline stalls and cache misses. I'm not a Rust guy, but skimming through the code it seems like the only work it's doing is some integer math, so it's not even touching the FPUs. Also I see while running.load(Ordering::SeqCst). Idk if Rust's memory model is similar to C++, but does that mean it's using atomic operations? That's going to create a lot of unnecessary cache coherency traffic that works against the goal of melting. Each thread should have its own counter not shared with other threads, and it should only spawn enough threads for the number of physical cores (not logical cores) on the system, and ideally pin each thread to a single core to prevent the OS from acting like a firefighter.

The gpu parts I'm not sure about. There's might be some special consideration required when dealing with integrated graphics though.

Final nail in the coffin.

CouchDB (a no-sql db, but whatever) automatically provides a REST API that's designed to be exposed directly to clients. It even implements its own client-facing authentication system. "queries" are configured in advance from the admin side, and clients just pull the results, allowing for very efficient caching. Basically, if you RTFM enough to get a couchdb instance running, you have 90%-100% of your backend complete. You could create an entire scalable full-stack app using only client-side code... and if you're clever with HTMX, you might even be able to do it without writing any javascript at all! (I tried once, but failed because I'm not that clever, but it's definitely probably possible)

So TL;DR: I like couchdb, and the idea of exposing your database directly to users isn't unprecedented. I wonder if there are any SQL databases that offer a similar thing?