• 0 Posts
  • 5 Comments
Joined 1 year ago
cake
Cake day: September 24th, 2024

help-circle

  • If you don’t mind revealing (hi ninjas), how were you playing this on PC? Only, there’s a lot of options these days. There’s the time-tested N64 emulators, but more recently we’ve got two new methods:

    The PC port of the source code decompilation:

    And the recompilation of the binary:

    For anybody who’s unfamiliar with decomps ports and recomps, they have outwardly similar results but are achieved using very different methods.

    Using the old “source code == recipe” analogy, a decompilation is where you purchase a meal and take it back to the lab where a team of scientists painstakingly analyze it to uncover the original recipe that made it, both in terms of ingredients and the cooking method. Once you have that, you can either make an exact copy of the meal or change it to suit your preferences. Dropping the analogy for a minute, you can modify the game any way you like and even go as far as building it for completely different platforms, across as many CPU architectures as you like.

    Recompilation is a bit harder to describe using the recipe analogy, because at no point do you actually uncover what the original recipe was. Let’s say you have a fancy Klingon delicacy prepared which is utterly inedible to humans. Unfortunately, you are human. Without knowing how it was made, you feed the dish into the back end of a replicator, which puts it back together in a form which offers the same flavor profile but is edible by humans. In this analogy, the Klingon meal is a game built for the Nintendo 64’s MIPS CPU, while your human anatomy requires food for an x86-64 CPU. However, you can’t feed the output to a Vulcan for the same reason you couldn’t eat the Klingon meal.

    As an end-user, the result doesn’t change that much if your goal is just to play Mario Kart 64 on PC. Decompilation is the more labor-intensive process which eventually results in a more flexible “recipe” you can mix around as you like, while recompilation gets you a meal without necessarily helping you understand what went into it or how to make it yourself or change its composition to your preference. Both of these analogies undersell the amount of work that goes into either approach, so I do apologize for making it sound as easy as the sci-fi technology suggests.




  • Everyone else took all the good critiques of this article, so here’s mine.

    We’re still bullish on the fediverse, and on Bluesky, if it manages to become a truly federated platform.

    Bluesky appears to have reached their goal as far as federation. Users can self-host a personal data server (PDS) which federates with Bluesky. If you want an analogy from somebody extremely unqualified to offer it, it’s sort of like bringing a bucket of water to a swimming pool. You can’t go swimming in the bucket, but you can pour it into Bluesky’s pool and swim in there. If the pool closes down or implements segregation and if somebody else opens a swimming pool, you can take your bucket to their pool instead. However, if nobody else wants to open another swimming pool, your bucket is useless. In this analogy, buckets are only useful to very slightly fill somebody else’s swimming pool and for no other purpose. It’s a very good analogy.

    Bryan Newbold, the protocol engineer at Bluesky, said the following about PDSes and federation:

    Overall, I think federation isn’t the best term for Bluesky to emphasize going forward, though I also don’t think it was misleading or factually incorrect to use it to date. An early version of what became atproto actually was peer-to-peer, with data and signing keys on end devices (mobile phones). When that architecture was abandoned and PDS instances were introduced, “federation” was the clearest term to describe the new architecture.

    i.e. In Bluesky’s terminology, federation is not a future goal they’re hoping to achieve, it’s what they’re already doing right now.

    The (ActivityPub) fediverse is different, because … damn, I really screwed myself with this swimming pool thing … it’s like a bunch of boats in the ocean. There’s one-person dinghies and giant cruise ships, all with different owners. You can bring your own boat, or you can hitch a ride with a friend or a generous stranger. If you want to hang out in a different boat from the one you arrived in, that’s fine too. Ultimately, we all float on the same ocean which we all have to share. Crucially, nobody is in charge of the water. There’s rules on the boats, but the ocean is just the ocean. If your boat crashes into an iceberg and sinks, the ocean will still be there. You might lose some of your stuff, but there’s plenty of other boats to pick you up.

    The failure state in both cases is better than nothing. With Bluesky, you lose the swimming pool, but keep the bucket. With ActivityPub, you lose the boat, but keep the ocean. If Bluesky dies, ideally you can take your federated identity with you to an alternative service that exists in the future, but you no longer have access to Bluesky, because it’s gone. When a Lemmy instance dies, you pretty much have to start over: register a new account, subscribe to all your communities again, etc. But the whole fediverse is still there: all the communities you were subscribed to, the people you followed, all your old comments, they’re still out there floating on the ocean.