Zangoose @ Zangoose @lemmy.world

Posts

9

Comments

331

Joined

2 yr. ago

Apparently (from another comment on a thread about arm from a few weeks ago) consumer GPU bioses contain some x86 instructions that get run on the CPU, so getting full support for ARM isn't as simple as swapping the cards over to a new motherboard. There are ways to hack around it (some people got AMD GPUs booting on a raspberry pi 5 using its PCIe lanes with a bunch of adapters) but it is pretty unreliable.

It's naive to think that someone is at fault for falling prey to the psychological tactics publishers use to push people toward micro transactions.

If you think about it, it's really not that different from saying people with gambling addictions deserve to be broke. Microtransactions might seem like an obvious scam to a lot of people, but a lot of people fall it and waiving it away and saying they deserve it will only make the problem worse.

"React is a library" developers when a UI library they need doesn't have a separate React extension

And turns out, everything that they give you in the package is actually third party! Meaning, stuff that has access to the lowest depths of your hardware, to stuff that you use to enter your bank details are all made by different people. So many people you have to put your trust into.

And if that's not enough, the people who compile it and send it to you might be totally different people from those who made the code!! What kind of heresy is this?

You joke but I've met people that actually think like this

Couldn't aimbots be picked up as odd movement and be detectable on a server though? Kind of similar to how those "not a robot" checks can tell if a human is clicking on the box just by looking at the movements of the cursor.

In addition, things like textures and game-modifications could be picked up in part by things like checksum verification to make sure the client is unmodified (assuming the files are modified on the disk and not in memory)

I feel like most client-side changes like see-through walls or player highlighting make themselves pretty obvious when aggregated over multiple games. A good user-reporting system could probably catch most of these.

I definitely agree though, allowing multiple random companies to install ring 0 rootkits should not be the norm. Honestly, even a Windows-level anticheat would be problematic because it would only worsen the monopoly Microsoft has on competitive games as a platform. A new solution would need to be cross-platform or else it would only be marginally better than what already exists.

That's kind of my point with hacks like player highlighting, I feel like a good user-reporting system would get us a lot of the way there. E.g. If someone is using see through wall hacks in an FPS I feel like it would be pretty obvious for other players to tell in a lot of cases. Other times things like erratic movements from aimbots could probably be detected by the server.

Games probably do this in some way already with something like a checksum but the problem is you could have some separate program reading from game state/display at runtime to get around this. That's part of why a lot of cheats are installed at a kernel-level.

Preface: I'm not an expert in this yet but I'm pretty interested in learning about systems-level topics so if I'm wrong please correct me!

Yes, the thing about anticheats and anti viruses is that they are only useful when they have access to the underlying resources that a virus or cheat engine might try to modify. In other words, if cheating software is going to use kernel-level access to modify the game, then an anticheat would also need kernel-level access to find that software. It very quickly became an arms race to the lowest level of your computer. It's the same with anti viruses.

IMO the better strategy would be to do verification on a server level, but that probably wouldn't be able to catch a lot of cheats like wall hacks or player outlines. At some point you just have to accept that some cheaters are going to get through and you'll have to rely on a user-reporting system to get cheaters because there will always be a way to get past the anticheats and installing a separate rootkit for each game isn't exactly a great idea.

That's fair. I was mostly commenting on my own experiences with JS/TS, I've never used PHP so I can't say if it's better or worse but a few people I know have said that modern PHP is actually pretty good for personal projects. I'm guessing it would have its own set of nightmares if it was scaled to an enterprise level though.

Funny you mention pillow salesmen: https://www.theguardian.com/us-news/2024/jan/15/mypillow-ceo-expand-lindell-tv-network-trump

It's not joever until it's joever! Biden VP 2024

/s

That's true but at the same time the fact that JavaScript equality is so broken that they needed a === operator is exactly the problem I'm talking about.

And those examples were low hanging fruit but there are a million other ways JavaScript just makes it easy to write buggy code that doesn't scale because the JavaScript abstraction hides everything that's actually going on.

For example, all of the list abstractions (map, filter, reduce, etc.) will copy the array to a new list every time you chain them. Doing something like .filter(condition).map(to new value) will copy the list twice and iterate over each new list separately. In most other languages (Java, C#, Rust, Go, etc.) the list abstractions are done over some sort of iterator or stream before being converted back into a list so that the copy only has to be done once. This makes using list abstractions pretty slow in JavaScript, especially when you have to chain multiple of them.

Another simple but really annoying thing that I've seen cause a lot of bugs - Array.sort will convert everything into strings and then sort if you don't give it a comparison function. Yes, even with a list of numbers. [ -2, -1, 1, 2, 10 ] will become [ -1, -2, 1, 10, 2 ] when you sort it unless you pass in a function. But if you're looking over code you wrote to check it, seeing a list.sort() won't necessarily stand out to most people as looking incorrect, but the behavior doesn't match what most people would assume.

All this is also without even getting started on the million JS frameworks and libraries which make it really easy to have vendor lock-in and version lock-in at the same time because upgrading or switching packages frequently requires a lot of changes unless you're specifically isolating libraries to be useful (see any UI package x, and then the additional version x-react or x-angular)

Tldr; Why can't we have nice things JS?

That's true but in practice it wouldn't take 60^11 tries to break the password. Troubador is not a random string and all of the substitutions are common ( o -> 0, a ->4, etc. ). You could crack this password a lot easier with a basic dictionary + substitution brute force method.

I'm saying this because I had an assignment that showed this in an college cybersecurity class. Part of our lesson on password strength was doing a brute force attack on passwords like the one in the top of the xkcd meme to prove they aren't secure. Any modern laptop with an i5 or higher can probably brute force this password using something like hashcat if you left it on overnight.

Granted, I probably wouldn't use the xkcd one either. I'd either want another word or two or maybe a number/symbol in between each word with alternating caps or something like that. Either way it wouldn't be much harder to remember.

Instructions unclear installed Alpine linux

Short answer:

Long answer:

There are a lot of gatcha moments in JS with weird behavior that makes it really easy to shoot yourself in the foot. It does get better as you get more experience but a lot of the oddities probably shouldn't have existed to begin with. For what it was originally intended for (adding light scripting to websites) it's fine but it very quickly gets out of hand the more you try to scale it up to larger codebases. TypeScript helps a little bit but the existence (and common usage) of 'any' has the potential to completely ruin any type safety guarantees TypeScript is intended to provide.

Worth noting that a GPU could be useful if they want to do game development courses but realistically you should be fine.

I'm a rising senior in college for CS and the only thing I've ever had that was remotely hard on my PC was my poorly-optimized freshman year assignments and an intro to cyber security assignment that had us using password hashing tools (it was a really cool assignment but kind of sucked for people who didn't have access to a computer with a decent GPU)

🙃 (it was over 100 earlier today, I'm on the east coast US)

You know what I'd really love nothing more than to do over Thanksgiving and spring break? Multiple CS assignments all conveniently given right before the break and due right after! Free time? Time with family? What's that?