It's a really interesting approach, considering how rampant Wii hacking was. Maybe instead of hacking the consoles, pirates will just buy dev kits, paying Nintendo a bit of a premium for the privilege?

Maybe they're hoping to make a little money on the pirates...

Modern dev consoles use the same DRM scheme as the retail consoles, they simply use a different (most of the time per developer) certificate, and won't boot retail signed titles.

But there's nothing stopping someone who wants to play a game "for free" from finding a torrent of a retail copy, downloading it, stripping the retail signature off it, using the SDK tooling to apply their own developer cert's signature, and then booting that on their console.

It's certainly possible—and already done—with iOS.

Likewise, "homebrew" on such a system would probably be like iOS homebrew is currently: an ecosystem of open-source projects where users are expected to download, compile, and sign the binaries themselves using their personal developer certs.

> But there's nothing stopping someone who wants to play a game "for free" from finding a torrent of a retail copy, downloading it, stripping the retail signature off it, using the SDK tooling to apply their own developer cert's signature, and then booting that on their console.

The way this has been impeded on previous consoles is to encrypt retail executables and lock the key in some "secure" coprocessor. These obviously do eventually get cracked, but at that point the system is probably so thoroughly exploited that you can do everything with a retail console anyway.

You're exactly describing how iOS AppStore apps work, i.e. Encrypted binary segment that is decrypted when paged in.

I've seen systems that don't allow you to have direct access to the signing tools; it's an online encryption oracle.

With this setup, it could easily blacklist known retail binaries and refuse to sign them.

The developer Switch does appear to be different hardware, although we don't know the full extent of the differences yet.

Nintendo accidentally showed a devkit with 64GB of internal storage rather than the 32GB you get on retail units.

https://twitter.com/_ferrums/status/826816397238030337

Why do they do that kind of thing? If anything, you might expect them to include less RAM & storage so that you're forced to work under tighter limitations.

It's so you can leave debug symbols in your executable: for a release you'll strip your binaries and pack them quite tight. For developing you'd like to have more uncompressed data in ram, and you want full debug symbols and debug info on the stack. Not to mention that debuggers themselves take a non-zero amount of ram.

Having more powerful hardware allows you to focus on designing/building the game and delay optimization until the game is mostly finished.

There is no reason to work under tighter constraints. You want developers to be able to push the retail version of the hardware to the limits. In order to do that and still be able to run debug builds you need the dev kit to be more powerful than the retail version.

I think that having the same hardware would be logic, but I feel that running (especially a game) in debug mode would in fact require more memory...

I can see using the same specs, but using even less would be weird. You don't win any points if you use less memory than the hardware has.

Previous gen Xbox dev kits generally had double the RAM and came with a Visual Studio license. They were very expensive. Now you can pay $19 to unlock a retail Xbox One to run any code you like with a 1GB RAM limit.

The Wii U kits make with a special version Unity too