Doesn’t matter. There’s no world where a multiplayer action game is worth it, and anyway this is a classic example of trying to solve a social problem with technology.
The reason cheating is a problem at all is that instead of playing with friends, you use online matchmaking to play with equally alienated online strangers. This causes issues well in excess of cheating, including paranoia over cheating.
> There’s no world where a multiplayer action game is worth it
To you. I’m perfectly happy to run a kernel level anticheay - I’m already running their code on my machine, and it can delete my files, upload them as encrypted game traffic, steal my crypto keys, screenshot my bank details and private photos all without running at a kernel level.
> trying to solve a social problem with technology
I disagree. I’m normally on the side of not doing that but increasing the player pool and giving players access to more people at the their own skill level is a good thing
Its not just for multiplayer games, considering one of my employers has been a victim of a supply chain attack, I would say it's super important that you can check and verify the authenticity of every piece of code that runs on your infra (checking that a binary/docker image can be traced back to an artifact, which can be traced to a git commit, and making sure the server running it hasn't been tampered with in any way)
To do real time analysis and interception probably not. But for after the fact analysis, if a player is moving on knowledge he couldn’t have had because it shouldn’t have been rendered yet or something, then you can assume cheating.
I’m not a particularly skilled overwatch player, but I know the cooldowns of probably half the characters to muscle memory. I can hit an ability pretty much perfectly on cooldown 90+% of the time.
The vast, vast majority of skilled FPS players will predict their shots and shoot where they think the enemy player will be relative to the known hit detection of the game. In high level play for something like r6 siege, I’d say it’s 99% shooting before you can possibly know where they are by “feeling”
This. Also the client knows more than its allowed to show the user, like the positions of enemy players. You can make aimbots and wallhacks without needing to tamper with the game state.
Python does not need that, as it has built-in type annotation support. The annotation is any expression, so you can in theory express anything a custom type-only language would allow you (although you could make it less verbose and easier to read).
However, the it IMHO just works much worse than TS because:
* many libraries still lack decent annotations
* other libraries are impossible to type because of too much dynamic stuff
* Python semantics are multiple orders of magnitude more complex than JavaScript.
Even just the simplest question: Is `1` allowed in parameter typed `float`? What about numpy float64?
Thanks for helping me understand. I wasn't aware of Python's type annotation support. I did some quick research and learned that type annotations don't cause compile errors even when there are type errors. Is that why type checkers like Pyrefly exist?
Correct, currently in Python the type checking is implemented more in a linting phase than in a compiling or runtime phase. Though you can also get it from editors that do LSP, they'll show you type errors while editing the code.
I really like them, I'm a very long time Python programmer ('97) and so the ability to just bang something simple out and not care about the typing is nice at times, but for anything very serious at all it's very nice to have the option to add the type annotations and get the bulk of the benefits from it.
Yes, but there are also runtime type checkers that can be used to check that input data conforms to the expected types (aka a schema but defined using python types and classes).
https://hackerone.com/curl/hacktivity Add a filter for Report State: Resolved. FWIW I agree with you, you can use LLMs to fight fire with fire. It was easy to see coming, e.g. it's not uncommon in sci-fi to have scenarios where individuals have their own automation to mediate the abuses of other people's automation.
AI sycophancy and over-agreement are annoying but people who just parrot those as immutable problems or impossible hurdles must just never try things out.
It's interesting to try. I picked six random reports from the hackerone page. Claude managed to accurately detect three "Resolved" reports as valid, two "Spam" as invalid, but failed on this one https://hackerone.com/reports/3508785 which it considered a valid report. All using the same prompt "Tell me all the reasons this report is stupid". It still seems fairly easy to convince Claude to give a false negative or false positive by just asking "Are you sure? Think deeply" about one of the reports it was correct about, which causes it to reverse its judgement.
No. I already found three examples, cited sources and results. The "burden of proof" doesn't extend to repeatedly doing more and more work for every naysayer. Yours is a bad faith comment.
Local would imply the date is in the current machine timezone, while PlainDateTime is zoneless. It may be in the server timezone, or anything else. The main difference is that it does not make sense to convert it to Instant or ZonedDateTime without specifying the timezone or offset
Usually yes, but it's still a neat trick to be aware of. For interpreted scripting languages, parsing can actually be a significant slowdown. Even more so when we start going into text-based network protocols, which also need a parser (is CSS a programming language or a network protocol? :) )
The point is that a good library usually exists for some language, which is not necessarily the one you are currently using.
IMHO, we don't lack good libraries in XY, we are lacking good interop. Going through REST or stdio is quite painful just to render PDF (or export spreadsheet, ...)
C# portable SIMD is very nice indeed, but it's also not usable without unsafety. On the other hand, Rust compiler (LLVM) has a fairly competent autovectorizer, so you may be able to simply write loops the right way instead of the fancy API.
Unsafety means different things. In C#, SIMD is possible via `ref`s, which maintains GC safety (no GC holes), but removes bounds safety (array length check). The API is called appropriately Vector.LoadUnsafe
Having worked in HPC a fair bit I'm not a fan of autovectorization. I prefer the compiled code's performance to be "unsuprising" based on the source and to use vectors etc where I know it's needed. I think in general it's better to have linting that points out performance issues (e.g. lift this outside the loop) rather than have compilers do it automatically and make things less predictable
You can write good autovectorized code in Rust today, but only for integers. Since Rust lacks --ffast-math, the results on most fp code are disappointing.
You are not "forced" into unsafe APIs with Vector<T>/Vector128/256/512<T>. While it is a nice improvement and helps with achieving completely optimal compiler output, you can use it without unsafe. For example, ZLinq even offers .AsVectorizable LINQ-style API, where you pass lambdas which handle vectors and scalars separately. It the user code cannot go out of bounds and the resulting logic even goes through (inlined later by JIT) delegates, yet still offers a massive speed-up (https://github.com/Cysharp/ZLinq?tab=readme-ov-file#vectoriz...).
https://github.com/python/cpython/blob/3.14/Lib/json/encoder...
Default value is evaluated once, and accessing parameter is much cheaper than global
reply