I didn’t discover Lemmy through search, nor did I ever use reddit - I found it from mastodon where a few people promote lemmy posts. Then gradually realised I preferred the community-focus here, compared to the individual-focus of mdon (although combining both could be good). As mdon has many more users, improving this inter-op would help to bring people here.
Is it ready for primetime supporting everybody’s random hardware and everyone’s software without crashes, stutters and slow downs or be free of the requirement for weird configuration tweaks?
Probably not.
Can it work perfectly well with a lot of hardware and a lot of situations for a lot of games Yes.
Is it ready for primetime on a steam deck? Yes.
Last OS change I threw bookworm on a random laptop asked it to install steam, enabled proton for my games and everything just worked. But that doesn’t mean it will work for everyone and for every game.
Mixing ram is one of those no-nos that a lot of us do anyway. Ideally everything just slows down to the slowest piece of RAM and everything runs fine. And you wouldn’t think that the board would care if you have 16s in one side and eights and the other. But if you’re having problems with your stability that’s absolutely the first place to look. Even if all the RAM is perfectly matched, from a stability standpoint it’s better to run two sticks than four. I’d pull it back to 16 and see if it stops crashing. If it stops doing that so all your RAM and get two 16gb sticks.
On a quick skim I don’t see a way on it to set volume profiles, let alone program behavior based on certain events, is there some menu I might have missed?
I believe that they had stereo mixing pretty figured out by the 70s…
Early-mid 60s though? Sure.
Unless you’re referring to when they started mixing mono albums into stereo, then yeah. Those albums were never meant to be listened in stereo, and I wouldn’t listen to a remaster of any of them unless they were officially approved by the band, or done by the band’s own producer. And even then…
The thing is if you degoogled for privacy, then I would say stop paying with any and all card as these are heavily tracked by anybody and everybody. Instead, opt for paying cash
This is what the last sentence in my post was about; I shouldn’t have to include it. Please try to refrain from doing it in future as it perpetuates the toxicity that Reddit had (and still has) a reputation for. Its fine to pass over a post if you don’t know the answer. It is also fine to pass over a post if you would never find an answer useful.
That being said, since COVID lockdowns were lifted, a hell of a lot of places have become card only, making it necessary to carry one. Some people may have the privileges to be able to use cash whenever they want, but not everyone can. There are places where disability benefits disallow you from taking out the money you receive as cash; I think this is some sort of war on drugs thing. Another reason is that women’s clothing is quite infamously lacking pockets.
No, but how could it? Let’s say Feddit.dk receives a Like from mastodon.social. Then Feddit.dk would have to tell the other instances that mastodon.social sent that Like. But how can Feddit.dk prove that the Like actually did come from mastodon.social, i.e. it is not just a fabricated Like that Feddit.dk made up and hid by pretending it came from mastodon.social. That’s not easy.
This is in fact how Feddit.dk knows that the Like came from mastodon.social at first. The problem is that the signature is a HTTP Signature which is only associated with the HTTP request that mastodon.social makes to Feddit.dk. It is not on the Like object itself. Thus that signature can’t be transferred to the Like object if Feddit.dk wanted to share it further.
There’s not such a thing as a “Lemmy style” upvote. It’s all Like objects under the hood shared via the ActivityPub protocol. But ActivityPub has no mechanism for sharing an activity further than the original receiver (i.e. forwarding from A to B to C and so on). It’s really only made for direct sharing from A to B.
Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.
This requires implementing sharedInbox support, but I believe this should permit federating any content of choice to any server.
That would still be directly from one server to another server. I.e. from A to B and from A to C. But forwarding is a different matter, i.e. A sends something to B which sends it further to C. There’s complications with signatures and verification in that case and it’s less clear how to handle that.
Unfortunately it is not that easy. It’s not Mastodon that places the signature like that, it is the ActivityPub protocol. Lemmy, Mastodon and all other ActivityPub instances do it this way. You’d need to extend or change the protocol to somehow fix this. That is not easy and not something that will be done overnight.
But surely the receiving server could validate that signature by verifying the existence of the received activity (by asking the origin server for the object referenced and validating the signature).
If like objects are distributed in URL form, this is already how it works. The extra load wouldn’t be fun, for sure, but the lack of an embedded signature makes it very easy to falsify anything on the Fediverse.
Lemmy doesn’t do it currently. It blindly trusts communities to not lie to people. I just found out about this myself.
In theory the JSON body could include all the necessary information to validate a signature and the signature itself. Then, a simple HEAD request could validate the contents without having to re-download everything, and users’ public keys could be cached to minimise HTTP requests necessary.
The like is an activity. Any activity has an actor. Every actor has a public key. If the activity is sent with a cryptographic signature (like LD signatures, which Mastodon does implement) then any one can verify that the activity is legit.
I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see endlesstalk.org/c/[email protected], which re-wrote posts from people (which is only possible if the posts weren’t validated, or at least re-fetched from their origins)).
There is a way to re-share and validate remote activities, either through LD signatures (ew, JSON-LD processing :vomit:) (which only Mastodon and Misskey implement) or the newfangled FEP-8b32 Object Integrity Proofs (which nobody relevant on the microblogging space implements).
There were communities using this blatant security issue for non-malicious purposes (see endlesstalk.org/c/[email protected], which re-wrote posts from people (which is only possible if the posts weren’t validated, or at least re-fetched from their origins)).
The reason this is possible is because of the way Lemmy federates activities.
When you on instance A post, comment or upvote something in a community on instance B, your instance sends the activity to instance B, regardless of the instance of who you’re replying to or upvoting. It is sent to the community, and the community then shares it out to all other instances. AFAIK, lemmy does nothing to verify that received content from a community actually comes from the original instance. See here for one of the main Lemmy devs commenting on this..
Is this secure or reasonable? I’m honestly not sure but it doesn’t feel great. Signatures on objects could fix this I think.
Instead of sending the entire object embedded in the activity the secure way would be to only the URI instead. This is permitted by JSON-LD.
In the receiving side, if the object is untrusted (i.e. if it isn’t signed or if it’s from a separate authority from the parent object containing it) it should be thrown away and the id should be fetched from the remote instance directly (same as it would happen if it was a URI instead of an inline object). This is completely an oversight on Lemmy’s implementation and not a protocol problem.
“Synchronous 26” and “Synchronous 320” sounds super weird. Are you combining RAM with different clock frequencies / timings? that can and often will cause problems like instabilities and crashes. i would take out the one you added and try the games again.
kbin.life
Oldest