But you phrased all your negative comments as hypotheticals...you haven't actually written anything that could be called libelous unless he wants to claim that he wouldn't sue if someone said these things, and to suggest he would sue represents some kind of damage to his reputation or business.
Of course, none of that matters if the guy decides to launch a SLAPP suit. Then again, that can be grounds for dismissal and countersuit in California.
What state is this guy suing in? I'd check his site for an address, but his server is down. No doubt due to all the pet supply consumer traffic this slashdot posting generated....
Yes it can, but it requires some constraints...it's not as elegant a solution, and it assumes a gateway server that's trusted by the recipient server:
The system mentioned here, probably intended primarily for anonymous mail servers and the like, has the server keep a database of spent tokens. If the tokens must incorporate the date or time in some fashion (along with a unique server string), then the database need be no larger than whatever time threshold the server applies (tokens with an out-of-range timestamp are automatically rejected).
If you're not using a gateway mailserver that's inside a network of trust, then sending email would involve computing a different destination-specific token for each email you send, which results in the situation you describe, which Adam Back addresses as 'interactive hashcash'.
I personally prefer interactive hashcash regardless of the delay. If you're on a slow machine, you send an email, continue working, and 5 minutes later you maybe get a note saying the mail was or wasn't sent (or you simply get bounced mail on failure, or whatever). You don't spend the time waiting, unless you're planning to disconnect the net connection or do something processor-intensive right after sending the mail. For sub-10-second delivery you either get a faster box or use a different protocol (e.g. instant messaging).
This could even be used in parallel with existing mail protocols. The presence of a successful hash token could just show up as another mail header line, and users could prioritize mail based on its presence (and the more computation performed by the sender, the less likely the message is a mass-mailing, assuming the sender isn't known to you). If this system became pervasive, tokenless mail would eventually be obsolete.
Taking 1 minute, or five minutes (or more) on a 486 isn't a problem if the computational effort can be done, at least partially, in advance. The total throughput on a 486 will be the same, but you'll be using up prepared results as you send email, after which you'll just have to wait until more are ready.
By advancing the price with Moore's law, it would always be expensive to set up a mass-mailing business, and even a little expense makes a big difference compared to none. This would also mean that sufficiently old machines would gradually go obsolete for the purposes of emailing strangers, of course, so you might have to pay a few dollars a month for an email service (with a reasonable daily outgoing email cap) if you didn't buy a new machine every decade or so.
Nothing is random! Things can just be reasonably complex, and seemingly unpredictable.
We don't know that. And if there are 'truly' random events (i.e. results that are genuinely independent of the initial state of the system), we'll never know it, since this would be indistinguishable from deterministic events we simply haven't figured out how to predict yet.
And given that practical randomness only requires that the participants be unable to predict the results (which is why 'eeny meeny miny moe' works among sufficiently young children), it would be harder to make a deterministic coin-flipping machine than a random one (if it did real flipping through the air). Actually, I'd like to get rid of some of the entropy in my mechanical coin-sorting machine, but that's a different problem....
" NVidia provides their own closed source, binary drivers. Hardware specs are not available to the DRI developers and NVidia cards are therefore not supported by the DRI.".
I interpreted this to mean that the other cards are supported via open source drivers. Was I wrong? Does the DRI project just use open source code to integrate closed binaries from various companies? I was avoiding nVidia, but if Matrox and ATI are doing the same things, I might as well pick up an nVidia card and try out this Gentoo 'LiveCD'....
I believe his claim is that Yahoo presents a simple page in an unnecessarily complex way, using an a large number of tags (some of which are deprecated) to provide a consistency of experience between browsers which (he asserts) no one cares about. He is implying that if they used simpler, more mainstream HTML and let people with different browsers see variations in presentation, they could significantly reduce the size of the HTML source document, and because they are such a high volume site and this would translate into saving a lot of money on bandwidth.
I won't comment on his suppositions, but the logic he builds from them seems sound.
I thought there used to be an 'obviousness' test, so that you couldn't patent an idea that was obvious based on existing art/technology/practices. Have they stopped applying that, or is the assumption that no application of technology is obvious to someone with a business degree?
"...fix a customer's tech support problems...", "...renew their customer's... domain reg...", "...tweak your broadcast equipment..."?
These are technical support jobs of various kinds, not programmer jobs. The ability to smoothly handle these tasks and the ability to design and implement good code are not strongly correlated.
For technical support jobs, seconds matter, and you want someone who can be counted on to do something reasonable immediately. For software engineering, decisions can have repercussions for years, and you want someone who does something intelligent and carefully reasoned after due consideration.
Slashdot Mirror
Of course, none of that matters if the guy decides to launch a SLAPP suit. Then again, that can be grounds for dismissal and countersuit in California.
What state is this guy suing in? I'd check his site for an address, but his server is down. No doubt due to all the pet supply consumer traffic this slashdot posting generated....
The system mentioned here, probably intended primarily for anonymous mail servers and the like, has the server keep a database of spent tokens. If the tokens must incorporate the date or time in some fashion (along with a unique server string), then the database need be no larger than whatever time threshold the server applies (tokens with an out-of-range timestamp are automatically rejected).
If you're not using a gateway mailserver that's inside a network of trust, then sending email would involve computing a different destination-specific token for each email you send, which results in the situation you describe, which Adam Back addresses as 'interactive hashcash'.
I personally prefer interactive hashcash regardless of the delay. If you're on a slow machine, you send an email, continue working, and 5 minutes later you maybe get a note saying the mail was or wasn't sent (or you simply get bounced mail on failure, or whatever). You don't spend the time waiting, unless you're planning to disconnect the net connection or do something processor-intensive right after sending the mail. For sub-10-second delivery you either get a faster box or use a different protocol (e.g. instant messaging).
This could even be used in parallel with existing mail protocols. The presence of a successful hash token could just show up as another mail header line, and users could prioritize mail based on its presence (and the more computation performed by the sender, the less likely the message is a mass-mailing, assuming the sender isn't known to you). If this system became pervasive, tokenless mail would eventually be obsolete.
By advancing the price with Moore's law, it would always be expensive to set up a mass-mailing business, and even a little expense makes a big difference compared to none. This would also mean that sufficiently old machines would gradually go obsolete for the purposes of emailing strangers, of course, so you might have to pay a few dollars a month for an email service (with a reasonable daily outgoing email cap) if you didn't buy a new machine every decade or so.
We don't know that. And if there are 'truly' random events (i.e. results that are genuinely independent of the initial state of the system), we'll never know it, since this would be indistinguishable from deterministic events we simply haven't figured out how to predict yet.
And given that practical randomness only requires that the participants be unable to predict the results (which is why 'eeny meeny miny moe' works among sufficiently young children), it would be harder to make a deterministic coin-flipping machine than a random one (if it did real flipping through the air). Actually, I'd like to get rid of some of the entropy in my mechanical coin-sorting machine, but that's a different problem....
" NVidia provides their own closed source, binary drivers. Hardware specs are not available to the DRI developers and NVidia cards are therefore not supported by the DRI.".
I interpreted this to mean that the other cards are supported via open source drivers. Was I wrong? Does the DRI project just use open source code to integrate closed binaries from various companies? I was avoiding nVidia, but if Matrox and ATI are doing the same things, I might as well pick up an nVidia card and try out this Gentoo 'LiveCD'....
I believe his claim is that Yahoo presents a simple page in an unnecessarily complex way, using an a large number of tags (some of which are deprecated) to provide a consistency of experience between browsers which (he asserts) no one cares about. He is implying that if they used simpler, more mainstream HTML and let people with different browsers see variations in presentation, they could significantly reduce the size of the HTML source document, and because they are such a high volume site and this would translate into saving a lot of money on bandwidth. I won't comment on his suppositions, but the logic he builds from them seems sound.
I thought there used to be an 'obviousness' test, so that you couldn't patent an idea that was obvious based on existing art/technology/practices. Have they stopped applying that, or is the assumption that no application of technology is obvious to someone with a business degree?
"...fix a customer's tech support problems...", "...renew their customer's ... domain reg ...", "...tweak your broadcast equipment..."?
These are technical support jobs of various kinds, not programmer jobs. The ability to smoothly handle these tasks and the ability to design and implement good code are not strongly correlated.
For technical support jobs, seconds matter, and you want someone who can be counted on to do something reasonable immediately. For software engineering, decisions can have repercussions for years, and you want someone who does something intelligent and carefully reasoned after due consideration.