"In assuming that there are discrete laws of physics, we also assume there is a subset of all 'possible' events; events that 'can happen'. (Given a certain arrangement of the universe at T1, there is a set of possible arrangements of the universe at T2)."
False. Possibilities can be mutually exclusive, so if one occurs, the other can't. Yet, after the fact, we considered them both to be events that could have happened.
(Unless you subscribe to absolute determinism, but I don't believe that's clear to be the case. Also, IME, discussions of determinism mechanisms in, e.g. quantum mechanics, tend to talk more about whether that's where Diety lives.)
Gravity doesn't pull you forward, it pulls you down. Unless a particular human never learned to walk or sit upright, their natural tendency in balance is to hold themselves in-line with gravity*, not necessarily at a perpendicular angle to the surface they're standing on. (There is some input from the eyes, which trick house attractions and the like exploit, but we're usually pretty good about it.)
This is what learning balance is all about, and most of us pick it up by the time we're two years old. Segways detect the human riders' effort at balancing (which most do without effort or awareness), and exploit it.
I run a website that gets occasional buzz in programming channels. As a result, I'm in a dozen or so IRC channels, with hilight rules set up to ping me when someone's talking about the site--that way I can dive in and address misconceptions or problems, or just generally interact with an interested community.
I had an idea for a bot that would allow temporary, rule-based bridging of conversations in participating channels. I never got around to coding, but I did blog the concept in more detail: http://mmol-6453.livejournal.com/213900.html
Digital signal transmission tends to include an increase in error tolerance, which I mentioned. The margin reduces the strain on the error tolerance, which is also needed to cope with signal loss issues.
So, no, the margin spaces aren't completely unnecessary with digital signaling.
Furthermore, I'll pick a couple nits and point out that it's only television broadcasting which has completely switched to digital in the US. AM/FM radio is still analog by definition, and there are large swaths of spectrum which use those and other signaling methods.
Area in the spectrum normally reserved for television, but not intentionally actively used by television broadcasters.
Simplified (it used to work this way, now it's slightly more complicated), each television channel frequency required a certain small range (the tuner frequency +/- a certain number of MHz) to carry its signal. Ideally, the affected range of spectrum wouldn't exceed that specced amount, but electronics aren't perfect, and RF is a tricky matter.
In practice, you tend to see splatter near a particular channel, outside its allotted frequency range. Furthermore, receivers have to filter out any signal not within the frequency range for the channel they want to watch, but the filtering circuitry (called a bandpass filter) will tend to cause distortions within the intended frequency range the better they are at filtering frequencies outside that range. There are also other complicating factors, like signal overloading receivers, and mis-tuned transmitters.
This resulted in a margin space between channels, so that adjacent channels would interfere with each other less. As receiver electronics have gotten better, more selective and more error tolerant, these margin spaces became less necessary, and we have space in the spectrum that's no longer required for its original purpose of providing a margin.
People would have to Like the relevant blog post to provide feedback, or Like any of the latest batch of "I hate the new Facebook design" groups that would arise.
They have (or had; not checking again) one on their sign-up form. That they don't have one on their contact page suggests they don't know what CATPCHAs are for...
If it has any real depth, you'll see things the second time that you didn't see the first. If it's actually good, the same will hold true over and over. There are folks out there who watch "The Usual Suspects" in groups, regularly, picking up on details they'd missed the first fifteen times. I could watch "Ergo Proxy", "Eerie Indiana", TV-form of "Avatar: The Last Airbender", "Ghost in the Shell: Stand-alone Complex", "The Usual Suspects" or "Cypher" a dozen more times, and be suprised each time by picking up on new pieces of detail or references.
I think the part I may have misunderstood was where you said, "With Googles CDN, they have to hack either my website, or Googles CDN.", and I interpreted that as an exclusive condition, rather than an inclusive one. Probably the "either" that did that.
With that misunderstanding corrected, I believe you're generally correct on the security argument. There's still some plausible variation in terms of server security policy and implementation of things like intrusion detection, (Is it safer to keep all your money in your home, or is it safer to keep most of it in a safe deposit box in a bank?) but that's not the key problem I thought I noticed in your argument, and not one worth devoting energy into.
You were critiquing the security cost of hosting on your own server verses that other server. It was pointed out to you that the admins of that other server would likely learn of (and react to) a breach on their end at a lower latency than you would for your server.
You implied that the security cost for hosting on your server was actually lower, because you weren't as much of a target. My reply was an attempt to point out to you at a technical level why that was a specious argument; your servers are likely being scanned by the same botnets that are scanning mine with automated exploit attempts against old and vulnerable software, and common errors in securing a server.
It's going to be far easier and cheaper for them to take a shotgun-scanner approach against a large class of average systems than to apply manual, concerted effort against a small set of high-value targets like CDN nodes.
The cost to the attacker to attack your system with automated tools is near nil. They'll attack, and if they get in, that's gravy. Using "we're not a target" as a security model makes about as much sense as putting an unpatched Windows box in your home router's DMZ.
That's not a very high cost. They don't choose to hit you, they let their scripts and botnets look around for old and vulnerable software.
Have you looked at your raw httpd logs? When I look at mine, and grep away known-cookies, I see that I'm frequently scanned by hundreds of IPs looking for vulnerabilities in common software packages.
And that's just the stuff that shows up in logged HTTP queries. I don't want to think about how likely it is that tools like nessus are constantly being scan-run against IP ranges that I sit within.
Ok, sure, you can believe you're going to be more on top of things keeping your site secure than a high-value target like Google. I don't know how the target value of your site, but I doubt it's as high as the server the jQuery plugin you're afraid of pulling remotely sits on--and you can bet that Google knows they have high-target-value externally-facing assets, and are watching them even harder and with more eyes than you would.
I fell in love for the first time in 2nd grade, with an Apple ][e. I was born in 1983. I was let out of the classroom into the hallway to use the arithmetic practice software on the computer, but turned on the computer without the floppy disk in it, and got the ] prompt.
I tried typing some things into it, but all I got back was "SYNTAX ERROR". (Wow! Another word with an X in it!) Someone (probably my bio-dad) told me that that was a programming interface. I forget how, but I found out that there were three books on programming in the school library, one each for PASCAL, LOGO and BASIC. Through trial and error, I discovered that the commands in the BASIC book gave me responses other than "SYNTAX ERROR".
I had a lot of fun on that. Eventually, I convinced my mother to buy the family a computer, and she got a Tandy RLX 1000. I think I first played with GW-BASIC on there. It was cool.
Then I found QBASIC, and was frustrated that my program didn't start when I typed RUN, and kept restarting itself after I finally got it to start.
Later played around with VB for DOS, then Win16. Win95-and then jumped to Perl on Linux, because all my friends were using Linux. (No joke; I started with Red Hat 5.2, but switched to Debian potato, because my friends could only answer questions about Debian.)
Fun times. And yes, I was very, very lonely as a kid.
True enough. Archive formats like zip and tar preserve timestamps, but I wouldn't necessarily even trust your average power user to know how to reliably get at them.
Users creating and using free accounts have costs associated with them. Those costs need to be met in order for the service to continue, either by tying a revenue model to the users directly, via charity, or by subsidizing their use of your resources by using something they contribute, such as content.
Selling user content is not a stable net in proportion to user use of the site; you don't know that the content will continue to sell at a rate keeping pace with user-incurred costs.
Charity is also not a stable net in proportion to user use of the site; nothing directly and reliably ties charity income to user-incurred cost, and nothing can--it's charity.
The only way to meet proportionate cost incurred by user use is by tying a proportionate revenue to user use. Even if you don't charge a user to use the service, even if you only ask that they fill out a text box to use the site, just as they might with reCAPTCHa, it suddenly becomes 'milking the user'.
Sadly, users no longer merely expect services to be free for them, they get offended if the service provider derives any money at all for their activity. (I think I sort of understand the mentality--"Why are they getting money for my work, when I'm not?"--but that logic doesn't hold up if no money was changing hands while they did the work anyway.)
You're also rather vague about what "the actual problem of spam" is. What strikes you as a mere symptom, and what strikes you as a cause? Yes, these peoples' particular implementation of challenge-response is pretty poor. Is that what you were specifically referring to, or did you have something else in mind?