Obviously you're the idiot here, because he never said that's what WILL happen, or that's what COULD happen. He said IF IT COULD RUN UNSIGNED CODE, not "SEEING HOW IT CAN RUN UNSIGNED CODE". Apparently you've never heard of an "If, then" statement.
What he said was, if the 3DS could run unsigned code, homebrew apps could be made to run on a regular 3DS when an exploit comes about. I don't see how this logic is wrong.
I saw that. Is there proof that it requires some type of key? No. That's why I said "if"
There's no proof that a 3DS can't spit out chocolate jellybeans with the right tweaks, either. So while your point is theoretically possible, my idea about the jellybeans is far more likely.I saw that. Is there proof that it requires some type of key? No. That's why I said "if"
That statement is half-true and half-false - like in the case of many Nintendo consoles, Intelligent Systems created the devkit as a two-parter - the test units and the development units. In the case of the 3DS, the unit which is used for programming can be connected to a flashcart of sorts and writes unsigned code onto the card while at the same time signing it. The debug unit is capable only to run flashcarts with content which was signed by the bundled development unit to prevent foul play (unless the content was signed using a universal code, which is rather rare and probably only limited to in-house Nintendo titles). Sharing the tested code among other developers in the same team is handled before writting the signed code using the development unit in its unsigned form.
