90 karma · joined April 13, 2010
Also, KD8KLW.
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.)
But, seriously, isn't this just an export of the functionality (and interface, even!) that's been in GMail for ages?
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 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
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.
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.
That space is your 'whitespace'.
I wouldn't worry...
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 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.
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 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.
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?
I'd be scared if someone were to look at a codebase of component-type-X codebase with a find-fault-fast attitude, if they didn't have extensive experience in designing and building components-type-X already. It sounds like diving head-first into a Dilbert strip or DailyWTF story.
It looks like the advertisers can force you to click through to get the security code. (e.g. Catfish's "Click through to see the security code!") I'll pass.
I've been the newest part of a four-man company for the past three years. I chose "computer programmer" for my job title. It seems that whatever your job title is in the tech industry, any appearance of actively working directly with the tech carries more prestige than sounding like you have some kind of managerial role.
It used to be that it wasn't the company's president you wanted to satisfy, but his secretary--yet which held more prestige?
Also, said account's avatar looks like some kinda of three-way orgy. Not investigating that image farther...
I do notice they're using additional hardware acceleration in IE9 only. I wonder what the limitation is in NPAPI that prevents them from supporting other browsers. (And whether/when that limitation would be resolved.)