Ultra is max reasoning level that splits the work and spawn subagents. Good for whole-project reviews (well, as long as the cybersecurity refusal doesn't appear for whatever reason), but unusable on the $20/mo tier
On consoles in general, backing up digital media (if even possible) requires full-system exploits, thus bypassing DRM, and decrypting them also requires breaking DRM
Woah, we're not talking about cracking your games. I think every console from at least the last two generations has supported copying game files to external/removable media.
Disabling DRM is required for basic archiving if the issue is someone else having the ability to decide the thing you bought will self-destruct. Copying doesn't matter if it doesn't produce a usable backup.
If you remove the DRM, then you do actually own the thing for practical purposes. And non-ownership of things you buy is unjust, so entertaining the law here is silly.
> Disabling DRM is required for basic archiving if the issue is someone else having the ability to decide the thing you bought will self-destruct.
Don't move the goalposts.
The only thing I am conceding is that conceptually it still ownership if you own the encrypted bits but they work fine with some other hardware that has the keys to decrypt them. I can backup my games on one playstation and play them on another.
Otherwise, we agree ideologically. At the same time I'm rhetorically supporting the point at the top of the thread that this has been a problem long before Sony decided to go digital. I am copyleft and anti-drm and whatever else you can imagine. It doesn't change the fact that there's a precedent that consumers will purchase drm games that require a rootkit to run under ambiguous terms that make it clear they don't own the bytes and it's a true observation that for some reason people allow this to happen on PC but when Sony does it it's the end of the world. I think to make progress here you need to address the root of the issue legally, not attack Sony for doing what society has condoned for decades.
You can't back up your encrypted bits on one machine and use them on another without constant permission from Sony though. Other hardware doesn't have the keys to decrypt them (actually this is it's own issue: it's obviously a very monopolistic, anticompetitive move that you can't run a PS5 game on a commodity PC because of their encryption). As far as I know, Valve's "DRM" just calls into a dll that asks Steam whether you own it, and you can just give it your own implementation of the Steam API dll that says you do. Or many titles on Steam don't have any DRM at all.
There are reasons to criticize Valve (gambling, microtransactions, "achievements"), but they seem to be too busy making money to want to do DRM.
You can’t back up your games on one PC and use them on another without constant permission from Value either. It’s the same and that is all I’m trying to point out. DRM is a red herring, the real problem is the phone home always online bullshit.
Both Valve and Sony run a completely legal video game platform service. There are minor differences here and there, of course… but this is 100% a general intellectual property law problem, not an instanced technical implementation issue.
Let's put the actual numbers in front of people: 1,924 out of 43,179 games, or 4.4%, as of today (according to PCGamingWiki) are DRM free.
The vast majority check whether you've purchased the game at runtime. If you stick to only indie games and the one off AA or AAA with no license check on Steam then sure thou-art-holier.
I think the argument is more precisely made by saying: on Steam, while the platform supports DRM, the decision is up to the publisher whether or not a game will use it and at least that provides the option for consumers to speak with their wallet and play only DRM free games. On Playstation it's all or nothing, you have to reject the entire platform/ecosystem if you want to avoid DRM.
At large, the problem still remains that our society allows DRM in the first place and if people want to avoid it then they need to be principled activists.
> The Steam DRM wrapper by itself is not an anti-piracy solution. The Steam DRM wrapper protects against extremely casual piracy... but it is easily removed
And it takes about 2 seconds to find the removal tools on github. So you can treat Steam's DRM as basically non-existent. This is unlike consoles, which require kernel exploits or hardware modifications to bypass.
So we agree that Valve, Sony, Nintendo, and Microsoft all operate platforms that support DRM. Wonderful!
I'm not interesting in bickering over who's DRM is the easiest to remove XD
In the US it's not piracy to make archival backups of digital media that you own in the first place, anyway. Even so, nothing gives you the right to use the software in ways that violate the EULA (except for your rights under the DMCA to create archival copies) regardless of whether you backed up the media with or without the DRM.
To put it plainly your right to create an archival copy does not extend to a right to run the media on unsupported/licensed hardware & software. I think that's an issue that should be solved, we likely agree, but let's not pretend that the situation with Steam is somehow healthy for society whereas with Sony it's not just because the DRM is slightly easier to circumvent.
> nothing gives you the right to use the software in ways that violate the EULA
Correct, that right is innate.
> your right to create an archival copy does not extend to a right to run the media on unsupported/licensed hardware & software
It does. Not even morally, but legally. Sony litigated this and lost, but bankrupted the emulator developer in the process. Emulators and compatible hardware and software have been consistently ruled legal. It is only the bypassing of copy protection that is not.
And if you're not interested in the feasibility of asserting your rights by removing the DRM, then naturally you'll never understand why people consider Valve and Sony materially different.
IMO it's fine if you use it to review hand-written code. Vibe-coding (and especially 100% slop projects) on the other hand, is indeed cognitive surrender as it's identical to cheating on homework back then.
Which is not that great for people using less than 50% every week, because the next reset date moves forward too. In essence, it is redistributing compute from people who haven't used their quota much to those who have.
Though I think they gave a banked reset this time.
Pretty much. I had 24 hours left with 80% remaining credit (planned big session tomorrow). There was reset one hour ago, that effectively halved my tokens for next 8 days!
Anything can be aliased by char, unsigned char, std::byte (as well as signed char in C), and usually uint8_t == unsigned char, thus by extension any valid void pointer can be cast to u8*.
Thus void*+size is usually the right type if ones only care for the memory representation of an object (cstring functions like memcpy, etc.)
With (2) being a wrapper to (1) that compilers will almost always inline, avoiding monomorphization costs (and (2) can also accept rvalues as argument).
(1) could also take std::span<const u8>, but (void*, size) is the more common idiom, more convenient to use and to read , as it is unambiguous which overload it is.
They make sense but reduce type safety, because once you add the cast the case might hide some real typing issue. I sympathize with the idea that the down-cast should be explicit though.
Yes, downcasting can be unsafe and should be used carefully, but what's the alternative? At least in C++ you can't cast between unrelated types without an explicit reinterpret_cast (or C-style cast).
and you CAN use static_cast to convert from void*; this silently keeps working if you refactor the void* into a matching-type pointer later, while raising a compilation error if you refactor to a different-type pointer.
Yes, a static_cast would be safe, but then most C++ seems to use a C-style cast because it is less clunky and then is less safe than the corresponding C code. The issue is not that the downcast is unsafe (it is, but once you have a void pointer you already accepted this), but that it becomes even less safe by adding a C-style cast.
It is also not clear what is gained by forcing programmers to add a cast. Void pointers should be used sparingly anyway.
If C++ programmers do not use modern safety features, that's really their fault. C-style pointer casts should be flagged in code review.
> but that it becomes even less safe by adding a C-style cast.
At least in C++ there is a safer option. If you really want to be on the safe side, you can even to a dynamic_cast (assuming your code base allows RTTI).
> It is also not clear what is gained by forcing programmers to add a cast.
I think the point is to make it explicit and stand out.
I see your point. It would be nice if a C-style cast behaved like a static_cast in C++, but that's not possible because of backwards compatibility. At least with GCC/Clang you can disable C-style casts altogether with '-Werror=old-style-cast'. (Maybe there is a similar option for MSVC.)
Yes, this is something that would need a new language edition to properly fix. Compiler vendors could split -Wold-style-cast into separate warnings for static_cast and other usage though so that you can only ban one of them.
The point is that, there is nothing else to be done with a void pointer, other then downcasting it, and it needs to be downcasted to be used. There is no other check that somehow validates the cast, so there is no upside to requiring the cast, while it does potentially silence accidental casts once the type changed.
reply