Just fine, at least I do. Just different sets of optimizations to keep in mind, as well as different expectations. I don't think any reasonable person would approach the two problems the same way, but it all boils down to basic computer science.

Light up pin 1 when the ADC says voltage is dropping which indicates that pressure is too low on the other side of the PPC. Compare that to indexing a few gigs of text into a search engine. Completely different goals, completely different expectations. I'm not master of the embedded domain, but I don't think it is a dark art.

Perhaps I'm looking at it the wrong way or perhaps my experience is unique or at least rare, but in my eyes it is all the same thing at different scales. Tell me my app is using too much memory then I'll first look at how I can reduce memory pressure, then I'll tell you what is and isn't possible to do and give you a list of sacrifices that would be needed to reduce memory pressure (time to refactor, concurrent operations, latency because of disk, etc etc etc. Not just talking about capabilities but the whole deal). Find the balance and go for it. On the embedded side the same sorts of compromises are made but the scale is just so much smaller. Finite number of IO pins, time to optimize your code to accommodate a new feature, meeting real-time, writing something in ASM to get around a GOD FREAKING AWFUL EMBEDDED COMPILER, etc etc etc.

I dunno, do I have my head on straight here? All seems fairly straightforward in the end. Specialists can do their bits faster than someone less familiar but with equal skill and understanding. Thats what earns the bucks, getting things done in a timely fassion.

((Or at heart I'm an embedded guy. Possible!))

Farily small. 60663.20 Peta FLOPS (60 exaflops) at my time of clicking if those numbers can be trusted (likely since the network hashrate can be derived from the average speed of blocks being found) Not that bitcoin mining uses floating point units since it is brute forcing a hash... but I digress.

That is really lazy work on the programmers part. It is trivial to use AJAX to submit the form and selectively wipe the captcha field whist refreshing the captcha. Thats what I do when we require a captcha for one reason or another.

I really agree with you.

My take on it, from both my personal experience and my interaction with my little cousins and the like, is that children don't have the breadth of knowledge, but they have great depth of knowledge. Kids can be schokingly insigtful in areas that they've explored.

I taught myself how to program starting when I was eight (I wanted to, though, quite badly.), and my parents gave me every single tool that they could to further that even though they are both highly non technical. Sure, they didn't like me spending all day on the computer, and they didn't really understand how the thing worked, but they encouraged my particular talent and intrest and I became very good at what I do because of it.

My wife is the same way, but she is a designer. Same situation (piles of her old art still haunts my in-law's house) and it was the same result.
Recognize what your kids are good at, help encourage it however you can. I'm certain that to any decent parent this is obvious, but I feel like it doesn't get said enough. I know what a difference that can make to a growing mind and it is how I plan to parent my child when I have one. I might try to sneak a little logic and critical thinking into them when they think they are having fun, though. Hope they don't mind.

A fair point. "Wholly custom" is hyperbole, on further reflection.
Especially considering that most of the changes I'm aware of were outside of the ALU and trickier main meory logic, like cache coherency, and I'm certain IBM was more than helpful. Way cheaper than developing a cell or some other new tech from scratch.

+1, very well considered point.

Nope! I was a bit checked to learn that it is a true-blue down-to-the-metal tri-core myself! but decapped processors don't lie http://www.dvhardware.net/article6606.html

Weird, right?

The processor in the xbox 360 was a wholly custom part. It has extra components to encrypt and hash memory to and from main memory (only the hypervisor is hashed, the rest of memory is encrypted) as well as e fuses for locking out downgrades. It is also a 3 core part, definitely uncommon.
Much more information in the google tech talk The Xbox 360 Security System and its Weaknesses .

Really good tech talk, worth watching if you are interested in that sort of thing, as well as the original Deconstructing The Xbox Security System for the original xbox.

Enjoy!

Some stream ciphers are as you say, but the keystream is not the same as the underlying key. One can't guess the next character in the keystream without deriving the key. Most modern stream ciphers use internal feedback much in the same way that block ciphers use external feedback modes, like CBC, to prevent these attacks.

In any system without feedback like this it is always considered insecure to re-use a key at all.

I'll undo my moderation in this thread just to tell you that you are wrong. One cannot determine the key from the ciphertext. If they can this is known as a "break" in the cipher.

A "break" in a cipher does not mean that it is practical to find the key, merely that it is more feasible than mere brute force. For example, a "break" could reduce the effective strength of a cipher from 256 bits to 212 bits under a known plaintext attack. This is a BAD break in the cipher given current standards, but it is the cipher is still completely uncrackable in human (or even geologic) timescales.

The "weeks or months" number, by the way, has nothing to do with cracking cryptographic keys. I would surmise that is a number more geared towards cracking passwords, which is an entirely different topic. Also, for some realistic numbers on cracking encryption keys, check out Thermodynamic limits on cryptanalysis