Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AN
Posts
0
Comments
257
Joined
2 yr. ago

  • The real risk is losing a bit of time with this. Since everything is backed up anyways, the data is just a restore away.

    If you don’t have a backup, that's the risk and has nothing to do with this procedure.

    For the Steamdeck the risk is even less, since Steam backs up savegames automatically and the games can be re-downloaded at any point for free (except for Unity developers, who have to pay 20 cents for this).

  • Well, CLI tools fall under that category, and they’re not exactly rare to be written in Rust these days.

    My most recent one had to use tokio anyways due to a library crate that used it (rtnetlink). Luckily, I don’t mind that at all.

  • This doesn’t look like anything out of the ordinary in a real-world application to me. We have way more complex queries in our service, even though ours are hand crafted.

    One thing we did notice though is that sometimes, it’s faster to just query the whole dataset and do the complex filtering in Rust. As soon as you hit the seq scan heuristic in PostgreSQL, there’s nothing to be gained from doing it in SQL.

  • As a software developer, that’s not how testing works. QA is always trying to come up with weird edge cases to test, but once it’s out in the wild with thousands (or more) of real-world users, there’s always going to be something nobody ever tried to test.

    For example, there was a crash where an unmarked truck with exactly the same color as the sky was 90° sideways on the highway. This is just something you wouldn’t think of in lab conditions.

  • XMPP has a few issues, like not being that great for tunneling through HTTP and also having a concept of presence built in at its core that’s no longer relevant in today’s always-online world.

    It also needs a lot of extensions to be usable, like session resumption.

  • NVIDIA has been struggling in recent years to find use cases for their graphics cards. That's why they're pushing towards raytracing, because rasterization has hit its limit and people no longer need to upgrade their GPU for that (they tried pushing towards 8k resolution, but that's complete BS for screens outside of cinemas). However, most people don't care about having better reflections and indirect lighting in their games, so they're struggling to get anywhere in the gaming market. Now NVIDIA is moving into other markets for their cards that don't involve gamers, and they're just left as an afterthought.

    I don't think that this will ever change again. Games like DOTA, Fortnite and Minecraft are hugely popular, and they don't need raytracing at all.

    I personally tried going towards fluid simulations for games, because those also need a ton of GPU resources if calculated at runtime (that was the topic of my Master's thesis). However, there have barely been any games featuring dynamic water. It's apparently not interesting enough to design games around.

  • Such an algorithm has to run server-side, since it needs access to the full database of content.

    It would be possible to allow users to upload their own algorithms (for example via Web Assembly), but I don’t know about any service that allows for that.