Just to clarify, I was in a small town (Atwater). It's the kind of place where everyone knows your name (and in a biblical sense, probably your cousin). Elsewhere YMMV.
Last time I beat a speeding ticket in that state... I paid for it dearly. Six tickets for less than 3 mph over the limit in a month. I find, although morally repugnant, it's much cheaper to pay up now and complain later; rather than to invert the order.
Parece que he perdido mi copia de la guía, pero como yo soy un príncipe de Nigeria, con mucho gusto a comprar uno por $ 10 millones de dólares EE.UU., si usted me ayudará a transferir fondos de mi hermano, que ha robado mi difunto padre trono. Por favor, responda con su información bancaria para que podamos ayudarnos mutuamente.
Yes, I am familiar with that idea... the point however is access control. How do you decide the X lucky recipients of your partial key? How do you assume they are trustworthy? Then again, if you're not watching the logs, how to you know they aren't cheating the system, and trying to assemble the full key without your permission?
The whole point of DRM is to give permission when you wish. Any system that allows someone to skip asking permission, and later beg forgiveness is broken. In that same vein, any DRM system gives you the keys at some point, and says "do not unlock this door"; therefore it always fails, even if we use it simply because it's easier to ask then to beg permission.
Perhaps I missed this in the TFA, but how exactly do they plan on actually releasing the keys? The whole point of DRM is to keep the keys out of your reach. I cannot think of a single, viable way to hide the key exchange without some black-box single point of distribution. Sure you can distribute the encrypted content via P2P... but unless the keys are decentralized as well... calling it a P2P system is just a touch disingenuous.
The key-servers still will represent a single point of failure, and a single point of ownership. Now we'll just pay for most of the bandwidth instead of them.
I see we have a RSTS/E (or RSX) programmer in the house. I hated doing the memory management, but those database routines were, well awe inspiring.
Well, writing on DEC hardware, most of the assembly instructions could be morphed by bit shifting into something else, useful, for example a Pointer Jump was just an overflow from a Jump Not Equal, so you could *cough* theoretically write an infinite looking loop that would exit when a strategically placed variable was overflowed. Thank god people don't write like that now, but when you had a 16k address space to work with, tricks like that were, well indispensable. As for the byte shifting, on a PDP, a bitwise shift (because most instructions began with a null byte) was a fast operator, rather than having to run a real decompressor.
Thinking about this, I miss the Good Old Days(tm).
Then for you, hungarian notation should be equally redundant.
Then you don't understand Hungarian notation... or you don't understand regular expressions. Either is quite sad, if you're a (Unix) programmer
Of course, this would also mean we'd need altars
You've never worked in a DEC RSTS/E, VMS, or a VAX Mini shop have you? (the alters are there, just behind the serial multiplexers)
The hardest part of climbing the ladder of success is getting through the crowd at the bottom.
