vinkelhake

Let's not forget about heartbleed!

I'm not saying there aren't weird things going on, but this article sure does a lot of guilt-by-association. We're putting neoreactionaries, polyamorous rationalists, doomsday AI researchers and the Zizians in one big web.

These seem like some fairly standard approaches for reducing memory usage. I can't help to think that the approach of joining several distinct list into a single one in some way undercuts Rust's safety guarantees.

If you previous had three distinct Vec objects, then Rust would guarantee that you can't index out of bounds. If you now put all those objects into a single Vec and rely on offsets, then you now open the door to indexing out of range of these sub-slices without any panics.

It's a minor point, and it doesn't really invalidate the optimization, but I'm surprised the article didn't mention it.

I don't think Molyneux's issue ever was due to industry pressure. The guy made some great games back in the day, but as long as he has been in the spotlight he has been known for overpromising and underdelivering.

Don't get me wrong, a game like Fable was pretty good, but it was nowhere near what he was effectively selling back when it was known as Project Ego.

That Molyneux chose to make a mindless clicker as his first game with 22cans really can't be blamed on anything or anyone other than Peter himself.

Give me a ping Vasily. One ping only please.

Sad.

I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits.

I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the term "web UI slop" clearly tries to do), but rather to figure out how to improve the native toolkits.

The opportunity to improve those toolkits was always there, and the ball was dropped.

This is "just" about providing the official Chrome binary to ARM64 "desktop" Linux.

You've been able to build and run Chromium on ARM Linux for a long time (I'm running it right now), it's just that they haven't provided an officially branded Chrome.

This is a good thing. While Chromium works well, there are a few things (like syncing) that is a bit of a pain to set up.

Is there an equivalent to Godwin's law wrt threads about Google and Google Reader?

See also: any programming thread and Rust.

I recently had my Framework Desktop delivered. I didn't plan on using it for gaming, but I figured I should at least try. My experience thus far:

    * I installed Fedora 43 and it (totally unsurprisingly) worked great.
    * I installed Steam from Fedora's software app, and that worked great as well.
    * I installed Cyberpunk 2077 from Steam, and it just... worked.

Big thanks to Valve for making this as smooth as it was. I was able to go from no operating system to Cyberpunk running with zero terminals open or configs tweaked.

I later got a hankering to play Deus Ex: Mankind Divided. This time, the game would not work and Steam wasn't really forthcoming with showing logs. I figured out how to see the logs, and then did what you do these days - I showed the logs to an AI. The problem, slightly ironically, with MD is that it has a Linux build and Steam was trying to run that thing by default. The Linux build (totally unsurprisingly) had all kinds of version issues with libraries. The resolution there was just to tell Steam to run the Windows build instead and that worked great.

This felt like a blast from the past. At a few times reading this article, I had to go back and check that, yes, it's actually a new article from the year 2025 on STM in Haskell and it's even using the old bank account example.

I remember 15 or 20 years (has it been that long?) when the Haskell people like dons were banging on about: 1) Moore's law being dead, 2) future CPUs will have tons of cores, and 3) good luck wrangling them in your stone age language! Check out the cool stuff we've got going on over in Haskell!

That would depend on your idea of "good". It would be an upstream swim in most regards, but you could certainly make it work. The Asahi team has shown that you can get steam working pretty well on ARM based machines.

But if gaming is what you're actually interested in, then it's a pretty terrible buy. You can get a much cheaper x86-based system with a discrete GPU that runs circles around this.