Mine's even simpler than your attic: I just throw absolutely everything the / directory.

And often (at least for me) knowing that others can benefit from my project is critical to even motivating me to do it. Knowing that the work I do can be built on means it's more worthwhile. Makes me look forward to doing Arduino stuff in the future.

It's all legit. The device behaves like nothing more than a human who can press and release the controller buttons in arbitrary patterns every frame. The kind of abuse of glitches is a whole other world with tool-assistance.

Since it's well-known that toddlers can break any electronic device, even if they have no buffer-overflow vulnerabilities, what will happen when the toddlers themselves are electronic? Will they spontaneously break, or be a super-race that cannot be defeated?

If it's just cheap and affordable you're looking for, take a look at the MSP430 LaunchPad. Less than $5.

The $4.30 (+shipping) looks to be a promo price, since you get the whole thing in a box, along with a mini USB cable. I doubt they would sell you several at that price. You get a device that looks to require the included programmer to modify it. With Arduino boards, you either have a USB on the board, or a header for connecting an FTDI serial cable to (or anything else that does 5V serial). The development environment is a commercial trial version, apparently only for Windows.

Once I get back into microcontroller stuff, it's a clear choice to get an Arduino-compatible board. It's going to be around for a long time, tools are going to be there, people who understand the boards, etc. Saving a few dollars on some obscure thing like this one from TI just doesn't seem worth it. For $13 you can get the Arduino-compatible RBBB kit which includes PCB, programmed chip, and parts.

Arduino didn't win because its Arduino, it won because it used a microcontroller that had already cornered the market.

That's how it always seemed to me. The bare-bones Arduino-compatible boards are little more than an Atmel microcontroller and voltage regulator. There's nothing surprising about this, since microcontrollers pack everything: CPU, Flash ROM, RAM, I/O, ADC/DAC, counters, interrupt controller, low-power mode. It seems that it's the complete package and network effects that make Arduino valuable. Each part of the package benefits from the others, and the standardization allows easy sharing of people's programs.

In SOVIET AMERICA, Sony fucks itself, repeatedly.

Guilty as charged. Still, my point was that in the case you describe, there is a problem with the design of the system, not merely the contract.

The idea of contracts is that clients write their code to work with anything which fulfills the contract. So let's say you have some client code written, but then determine that there's a bug in the contract. What does this mean? The client code is either written for the "buggy" contract, or the client code was ALSO buggy and written for the intended contract. At that point, it seems that the client has failed to grasp what the contract is in the first place. The idea is that the contract cannot be buggy, since it is the definition of correct. If your clients code to the contract, you can't go changing it without breaking clients. The contract may be badly-designed, and it's good to avoid bad designs, but once you have clients, to go in and try to fix a "buggy" contract is to water down what contracts mean in the first place. It encourages clients to ignore contracts and code to what they imagine the routine should do. At that point, you might as well abandon contracts because they aren't being used as the definition of what is correct anymore, just a vague guide as to what the routine might do.

It's all syntactic sugar. The point is to reduce the cost of development. Contracts should be distinct from implementations; a user should be able to consult the contract in order to find his obligations when calling a routine. By optionally checking contracts at run-time, you can be reasonably confident that they are actually being followed.

If the contract is violated, the program should be terminated immediately. The point is that there are no side-effects when the contracts are observed.

I agree, does this not rely on the developer actually specifying the contract? Also, would it not be possible to have bugs in the contract itself?

What would it mean to have a bug in the contract?

I wonder whether you're making it harder to detect fraud on your card specifically. I could imageine the fraud-detection algorithms looking for a consistent zip code, followed by a different one. If you always give a random one, they won't see any difference when your card is stolen and yet another different one is entered. Anyway, this seems like a possibility.

Yes, if you enter something like ijbhihgviherithoijsxcfimser for your mother's maiden name.

How could anyone in this thread have known this? Their criticism is understandable. Er, wait, there's a while website explaining BitCoins, never mind...

I've just had this kind of scary revelation. This and another thread have people criticizing something up and down, even though they haven't read about the thing and their critiques aren't even of the thing, but their flawed idea of the thing. It makes me wonder whether virtually all the threads here are like that, just that it's not always as obvious. Ugh.