Smart article yes, but it's still incredibly stupid to buy a lottery ticket.

Unless you think it's fun to play. Idle daydreaming about what you'd do if you won; the excitement as the numbers are called; the rollercoaster of emotion as you realize you may win - no you won't - oh but you did get a small price.

It's only stupid if you see it as an investment. See it as entertainment and it's no more dumb than paying to watch a movie.

Certainly not 2X, that was normal slashdot hyperbole. 1.2-1.5X depending on what you compare with. But you are putting words in my mouth. Nowhere did I claim RISC was better than CISC or visa versa in any general sense. I said that compact instruction encodings are better than inefficient instructions encodings, which they clearly are for a broad class of CPU memory hierarchies that have been around in recent years. The decoding benefits of RISC were tangible for 1990 era CPUs, but the decoding overhead hasn't changed, while the rest of the CPU has got much bigger. So the decoding overhead is now negligible for the CPUs we put in phones and PCs, while the instruction bandwidth has a bottom line effect on performance. You can address it with wider buses and bigger caches, but then you can have wider buses and bigger caches with smaller instructions too.

I'm not seeking to prove a claim. It's just the way things are.

Accordingly a CPU with a real Huffman coded instruction set might be even better. Feel free to go implement one.

Which contradicts the evidence of the vast majority of CPUs ever made, which is they get faster as you throw more gates at them.

That puts me in the 2%. Is that good?

N machines where N > 2.

As long as N > 2, the problem is unchanged for any value of N.

But I did actually see that film. Making life easy for the marquee layout is clearly not the same thing as making money.

How about : "Pantone PMS 400-447 and a Couple More"

http://www.promosyon.us/Panton...

Yes. That's what makes the current news interesting. She wasn't hiding them. She handed them over in response to a request. She wasn't not-allowed to use personal email. The rules had no such restriction. But her actions conflict with what I remember her saying was motivating her to not use email.

I keep seeing people declare TLS's cipher choices to be mess and propose cleaning them up somehome. Look deeper. The problem is not adding things, it is retiring things. If you can't retire algorithms, you can't clean up. If you can't clean up, then negotiation is bad.

So you have to live with your initial choices. Make them well.

I suspect I'm much more likely to go and watch a film called "The Moon is a Harsh Mistress" than one called "Uprising".

It's certainly not simple. But there is a linear relationship between code density and the functional bandwidth of the instruction caching at every level.

I don't presume to understand why ARM do what they do. Whoever came up with that interrupt architecture needs a serious talking to.

One of the problems with TLS is we keep adding better ciphers, but the old weak ciphers hang around and implementation errors leave us vulnerable to downgrade attacks. A big problem with negotiable cipher suites is the inability to retire old ciphers. We might like to think it can be done, but it isn't a solved problem and TLS is a prime example of that failure.

But crypto has moved on a long way and we have a lot more of the basic crypto functions coming with mathematical proofs of the hardness bounds of attacks, which was simply not true when those older ciphers, hashes and macs were published.

I would prefer negotiation to be in terms of algorithm parameters we can negotiate on the fly, such as the number of rounds on the cipher, or the amount of entropy fed into a sponge construction. It's easy to increase an iteration count. It's hard to add a new algorithm to a device after it's been built. These methods come with their own problems, but they're a heck of a lot less of a problem and a heck of a lot more solvable than ciphersuite negotiation, which has failed year after year.

There is a reasonable physical arguments that even with quantum computers that can do what people claim they can do (not likely) that it is impossible to brute force anything above O(2^360). So lets accept that we can pick a secure key size, pick it and focus on the parameters we can alter over time, rather than those that we cannot. Also focus on things that are implementable by any reasonable programmer or circuit designer. It's incumbent on any crypto system designer to fight against complexity at all costs. Complexity will undermine your secure algorithms and protocols in ways you cannot control.

I am. This has led to many miscarriages of justice.

Prosecutor: "The DNA test shows there is a 1 in 10 million change that this person is not guilty"
Truth: "The DNA test shows that this person is one of around 35 people in the USA who could have deposited this DNA, I.E. 1 person in 10 million of the US population (assuming the US population to be 350 million)"

There needs to be something else to make it that person and not someone else. Scouring a DNA database of the whole US is going to throw up many false positives.

I didn't say she was smart. I don't think smartness is a one dimensional metric.

I mean like crypto algorithms with lots of security headroom. 256 bit keys and no known attacks, or equivalent security. DJBsque Edwards curve ECC to minimize the implementation errors that keep cropping up. No X.509 because it's seems impossible to implement securely. And on an on.

TLS is not fit for purposes. We should stop pretending and replace it. That's what I'm working on.

Ciphersuite Negotiation is a liability. A good security protocol will not have it. It is empirically impossible to get right.

Pick one set of algorithms, good enough for the lifetime of the device or system and any changes are done by replacing the single static suite on both ends, say once per decade. Make the whole thing so utterly simple to implement that it would be hard to get wrong.