Well, fair enough, but as the citation provided - by either side - would conflict with the other, it really doesn't matter which of you does it. If you are able to support your position (instead of complaining about some sort of persecution) I would be forced to reevaluate my stance.
Back to the issue at hand, it is well known that welfare spending is the fastest way to pump money into a local economy - people who need money for, say, food, tend to spend their welfare check in *very* short order, where a wealthier person might put it in the bank. And it is also well known that Social Security is extraordinarily efficient - Wikipedia says that admin. costs as a proportion of assets is 0.39% ( http://en.wikipedia.org/wiki/Social_Security_Administration#Automation ). Private insurance is much more, with a smaller pot. And health insurance (vs. Medicare) is worse, also because private insurance is a smaller pot and administrative costs don't increase linearly with the assets.
So I suggest that the claim that "Social programs are the cheapest and best way to make a long term positive effect on society" makes sense on the face of it, at least to those who know a bit about the sort of social programs we actually offer. Which is why it's up to you to disprove it.
Nearly every word of your post needs citation. As far as I've seen (and I've looked) the pool of resources can be highly efficient. To my knowledge it hasn't been discredited. I may be wrong, but I'd like some evidence other than "well *everybody* knows it's nonsense"
Li-ions are 80-90% efficient. NiMH is a bit worse, 66%. Li-polys are 99.8% efficient, and NiCDs are 70-90%. So all these batteries don't waste much, but some do better than others.
I also forgot to mention that batteries+motors are significantly lighter than engine+transmission, so you'll probably be about 500 lbs lighter, which saves more energy.
Actually did the math on this one for a paper a few months back. Here's how it breaks down:
-The average efficiency of internal-combustion engines is about 18-20%, with a mathematical limit of 37%. ICEs in cars almost never operate at their peak efficiency. -The oldest, dirtiest, crappiest coal plant is 33% efficient, and 6.5% of that is lost in transmission - still more efficient than an efficient ICE running in real-world conditions -The large motors in electric cars are up to 99.99% (!) efficient. So even a particularly terrible coal plant, with an average grid and electric car, will use less energy
-Now, a new combined-cycle natural gas power plant operates at 50+% efficient, pulling the overall real-world efficiency well over even the theoretical maximum for an ICE.
We haven't even considered that as we come up with better ways to make power, they can be swapped out in the grid without modifying the car in the slightest. Throw solar or a nuke plant in your local grid? Everyone's car is now powered more efficiently. You can't do that for millions of small ICEs, without an expensive "cash for clunkers" program.
You discount, well, just about everything by claiming that fossil fuels are all the same, regardless of what they are or where they're burned. We may depend on fossil fuels, but almost no power plants burn oil. It's mostly natural gas (produced in Canada or the Northeast US) and coal (produced in the US or Australia).
I never claimed to be professing an objective truth regarding the merits of type systems. As I said, I like both. But both Java and C# are faster than Python and Ruby and Perl and JS and so on. People use Java/etc when performance "isn't a huge concern but let's not be ridiculous" (one way I've heard it said).
I happen to prefer to work on code with others when it's strongly-typed, because I have to dig around less to find what exactly I can do with it rather than letting it fail at runtime. That is personal preference, though I suspect most would agree with me.
But there are absolutely some objective reasons to avoid the RAD scripting languages. Like I said 4 posts above, "use the right tool for the job"
Are you being snarky? Java and C# are significantly faster than Python because they're JIT'd (hopefully this is changing with PyPy). They're also significantly more straightforward to maintain than Python because of their strong type structure. Having a rather-rigid interface is superior for teamwork, but more flexible structure is helpful for the sort of little utilities I was talking about.
The compiler wasn't written in assembly, but it had to output it and debugging required following large codebases generated from an object-oriented language. That's what I meant... running through 500 lines of assembly to make sure the vtable was properly generated.
To be fair, doing any nontrivial assembly will put some serious hair on your balls. But it's just not very good for (almost*) any real work.
I use C for performance-critical code, C++ for complex performance-significant components (like a OpenGL million-poly renderer), Java or C# (depending on target platform(s)) for large but otherwise-modest programs, and scripting languages (mostly Python) for one-off programs or little tools that don't justify the involvement of a more heavyweight language.
Use the right tool for the job, as always. Can't go too far wrong with Java, and if you're going to hit its performance wall, you should know up front.
* Only large-scale assembly coding I've ever had to do was for a compilers class, but there was obviously no way around it. Fascinating to learn and do, but I sure hope I'm done with it...
I figured, but even if he was joking, others weren't. There does seem to be a belief that truly-critical equipment shouldn't be so darn expensive, and that can be a dangerous conclusion.
Low level, in this context, means that there are a very few number of abstractions between the C and native assembly instructions. C++ adds an object model that the computer doesn't deal with, Java is of course a bytecode, and so on - but C maps very closely onto (non-exotic) hardware. Loops are 'jmp's, functions are 'call's, structs are a format for memory layout, pointers are raw memory addresses, and so on. It's quite straightforward to hand-compile most C code. Not so for C++, unless you feel like hand-coding vtables.
You're talking about something completely orthogonal to the level of abstraction. Unavailable specific processor features has nothing to do with it - if you used a 20 year old x86 assembler it wouldn't support SSE2, but would this make the assembly it supports not "close to the metal"? On the flipside, you could write a Python module that directly exposes the SIMD instructions as vector math ops, for example, and it would still be high-level. By car analogy, not having access to the valve timings doesn't make a manual transmission high-level shifting. It's higher-level than reaching in and moving gears around, but not by much.
And in any case, modern compilers know how to use SSE and MMX and other special features, particularly if you tell it so.
For all of Jobs' many faults, he doesn't seem to have any problem telling the RIAA to go fuck themselves. Hell, Apple has enough money to just buy up any particularly pesky label.
I think they would prefer not to roll the dice on whether their robot gun is going to shoot the enemy, shoot themselves, or just blow up spectacularly like a big "look who's hiding here" sign.
I work in EMS. Sure, I look at a $10k power stretcher and go "I could do that for cheaper"
But could I? Here's the thing - for mission-critical equipment, you don't fuck around. Be smart about how you spend your money - which means you should get the tool you need and know it'll work right every time. Don't waste it, by any means, but if you mean it, you'll need to pay.
And most importantly, if we have an equipment failure, we can point at the manufacturer. I'm sure some of the price goes to a lawsuit fund, but again - this is what you pay for.
For the record, that stretcher has worked for more than 5 years and more than 50% over weight specs, with no problems yet or for the foreseeable future. And it was worth every penny.
Unfortunately, and ironically, computers are too prevalent in cars to really be able to do that nowadays. I knew two kids in HS a couple years back that were building hotrods, but they were building the same hotrods you were talking about - '70s Corvettes and GTOs and things. Modern cars are really too complex to take apart and fiddle with, unfortunately.
It's knowing how to describe a calculation so that it can be automated by a machine.
I'd go further. It's about understanding your problem well enough to figure out how to *always solve it*.
My example is Sudoku, mostly because a solver is the first nontrivial program I wrote. You need to understand the game on another level, and in an entirely different way, in order to find the answer to (effectively) all of them. "I know how to solve Sudoku puzzles" is not the same, and not nearly as powerful, as "I can solve *every* Sudoku puzzle". Making that leap from the specific to the general is what's important for people to be able to do.
AT&T is actually not bad about unlocking phones. They do all their other phones after (IIRC) 6 months in good standing.
But it is on them to tell Apple to unlock, not the other way around. As I understand it, the iPhone asks the Apple server on activation whether it should be locked or not - but AT&T can tell Apple to change the flag and they'll do it, based on the fact that, well, they do in other countries.
I understand what fiat currency is, and you're right. As I posted in your sibling comment, I'm not quite sure how to express "it has no intrinsic worth, but we give it some".
As far as "cyber-credits" go, this is reasonable. Not everybody has or can get a credit card, but debit cards and prepaid cards temper this substantially to the point where a CC# is reasonably accessible to everybody who wants one. So I think it's a lot less useful than it might have been 15 years ago - and indeed I remember reading about 'e-cash' and 'e-wallets' and all sorts of other schemes to do just this. But such a scheme is - IMHO - more useful as a frontend to "real" currency. And then you get Paypal (if it didn't suck), which acts more as a broker than a currency, and hence much easier to understand and trust. I give the money to a third party and they ferry it along to my recipient. My grandparents would have called this a money order or a wire transfer, but now we have the internet.
Basically, I'm not sure why it has to be a new currency, if that's what it's best for. And it doesn't seem to fill any other needs particularly well.
I understand what fiat currency is. I must admit I don't know the term for a currency whose value comes ex nihilo, but I know this is a component of a fiat currency. I tried to temper that with "sure, it's decentralized", which obviously, a fiat currency isn't. Sorry for being less-than-clear.
Bitcoin is a fiat currency. Sure, it's decentralized, but it has no intrinsic value.
People already agree that dollars, Euros, etc. have value. What worth does Bitcoin bring to the table? I use my credit card; it's very convenient and I don't care who knows what I spend at Dunkin' Donuts. But if I was worried about privacy, I'd use cash everywhere. It's easy to exchange between nations, if you need to, and most people don't.
So other than being "distributed!" and "electronic!" and - admittedly - pretty cool, what is it actually good for? Anybody who won't accept cash for identity purposes won't accept Bitcoins, and anybody who might accept Bitcoins will almost certainly accept cash.
And it's really new. As a customer, I'm very nervous about spending "real" (cash) money on worthless bits. As a provider, I'm even more nervous about accepting payment in worthless bits. Not saying they are, but it's my money so the concern is enough to avoid it when cash is a perfectly viable alternative.
In short, why should I use Bitcoins? Why should I accept them for my labor? What assurances do I have that it won't all go belly-up when the fad dies down and people stop caring?
Falsifiability is when you describe an experiment that would show your theory to be false. Falsifiability is a requirement of a valid hypothesis. Gravity would be falsified by showing that objects with mass didn't accelerate towards each other - if you could show that, you disprove gravity. Evolution is falsified by watching a species spring from nothing. Creationism can't be falsified because "it's all God" - anything that happens that you didn't expect, God could've done - which is why creationism isn't science.
It's not about fabrications or hoaxes. The GP's question (I hope) is whether somebody could construct an experiment that shows that the boson *doesn't* exist, at least not as we understand it.
I'd go one further. IT employees who screw up their network infrastructure enough to need to specifically account for a standards-compliant device should be fired.
802.1x, TTLS, PAP, WPA, are *standards*. Any device that supports these standards can connect (this includes Android and iOS devices, and all 10k undergrads, almost as many grad students, a few thousand faculty, another few thousand staff, a hospital, and more), so they can't screw around. They block inbound port 139 and 445 to stop most worms, tell everyone to use a firewall, and simply kick people off (after notice) until you reformat if you get a virus. No magic security tool needed, it's the internet and it's your own damn problem if you get infected so use a FW. IMHO it's better that way.
My school uses 802.1x TTLS-PAP, with the SSO username/password, for authentication and encryption. On wired, there's a (standard HTML) portal that registers your (or an entered, for consoles) MAC address when you enter your password. I do IT support in the dorms; we don't officially support Linux, but it's usually even easier to configure than OSX (which is quite finicky with 802.1x) - on Linux, when you attempt to connect, it guessed the authentication method and just requires your user/pass. Windows needs a supplicant for TTLS - we use a configured SecureW2 installer.
The engineering school's big beefy server (appropriately named Eniac) runs a custom SuSE distro, as well as a few large labs (with home directories mounted over NFS). All my classes have either gone to great pains to be OS-agnostic, or require Linux - never Windows. For credit, all work must compile on the engineering school server (no "it worked at home!", you must check) but it's usually not an issue. For reference, my major coding classes have been a compilers class in OCaml (ugh), a graphics class in Qt/C++, a hardware class in C, and a number of classes with Java. For the most part, I did the work in OSX and tested on their machines before submission. I have an OS class next year that actually requires Linux, because we'll be using direct syscalls and they want to ensure consistency even across different Unixen.
The engineering school is really OSS-friendly, to the point where I think it'd be hard to graduate from it without Linux proficiency (though people sure try...). In fact, I can't think of a single class that's required proprietary software of any sort, even in the liberal-arts school.The networking folks are Linux-heavy as well, so the whole campus feels that. But the business school is a MS shop through and through (Exchange, domains, etc).
Slashdot Mirror
Well, fair enough, but as the citation provided - by either side - would conflict with the other, it really doesn't matter which of you does it. If you are able to support your position (instead of complaining about some sort of persecution) I would be forced to reevaluate my stance.
Back to the issue at hand, it is well known that welfare spending is the fastest way to pump money into a local economy - people who need money for, say, food, tend to spend their welfare check in *very* short order, where a wealthier person might put it in the bank. And it is also well known that Social Security is extraordinarily efficient - Wikipedia says that admin. costs as a proportion of assets is 0.39% ( http://en.wikipedia.org/wiki/Social_Security_Administration#Automation ). Private insurance is much more, with a smaller pot. And health insurance (vs. Medicare) is worse, also because private insurance is a smaller pot and administrative costs don't increase linearly with the assets.
So I suggest that the claim that "Social programs are the cheapest and best way to make a long term positive effect on society" makes sense on the face of it, at least to those who know a bit about the sort of social programs we actually offer. Which is why it's up to you to disprove it.
Nearly every word of your post needs citation. As far as I've seen (and I've looked) the pool of resources can be highly efficient. To my knowledge it hasn't been discredited. I may be wrong, but I'd like some evidence other than "well *everybody* knows it's nonsense"
Please back up your claims.
Li-ions are 80-90% efficient. NiMH is a bit worse, 66%. Li-polys are 99.8% efficient, and NiCDs are 70-90%. So all these batteries don't waste much, but some do better than others.
I also forgot to mention that batteries+motors are significantly lighter than engine+transmission, so you'll probably be about 500 lbs lighter, which saves more energy.
Actually did the math on this one for a paper a few months back. Here's how it breaks down:
-The average efficiency of internal-combustion engines is about 18-20%, with a mathematical limit of 37%. ICEs in cars almost never operate at their peak efficiency.
-The oldest, dirtiest, crappiest coal plant is 33% efficient, and 6.5% of that is lost in transmission - still more efficient than an efficient ICE running in real-world conditions
-The large motors in electric cars are up to 99.99% (!) efficient. So even a particularly terrible coal plant, with an average grid and electric car, will use less energy
-Now, a new combined-cycle natural gas power plant operates at 50+% efficient, pulling the overall real-world efficiency well over even the theoretical maximum for an ICE.
We haven't even considered that as we come up with better ways to make power, they can be swapped out in the grid without modifying the car in the slightest. Throw solar or a nuke plant in your local grid? Everyone's car is now powered more efficiently. You can't do that for millions of small ICEs, without an expensive "cash for clunkers" program.
You discount, well, just about everything by claiming that fossil fuels are all the same, regardless of what they are or where they're burned. We may depend on fossil fuels, but almost no power plants burn oil. It's mostly natural gas (produced in Canada or the Northeast US) and coal (produced in the US or Australia).
http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug
These kinds of stories make me nervous, because I always assume that crackers know about these and are using them secretly.
Though this is obviously not a OSS issue. Were this Windows, it might not have been found at all.
I never claimed to be professing an objective truth regarding the merits of type systems. As I said, I like both. But both Java and C# are faster than Python and Ruby and Perl and JS and so on. People use Java/etc when performance "isn't a huge concern but let's not be ridiculous" (one way I've heard it said).
I happen to prefer to work on code with others when it's strongly-typed, because I have to dig around less to find what exactly I can do with it rather than letting it fail at runtime. That is personal preference, though I suspect most would agree with me.
But there are absolutely some objective reasons to avoid the RAD scripting languages. Like I said 4 posts above, "use the right tool for the job"
Are you being snarky? Java and C# are significantly faster than Python because they're JIT'd (hopefully this is changing with PyPy). They're also significantly more straightforward to maintain than Python because of their strong type structure. Having a rather-rigid interface is superior for teamwork, but more flexible structure is helpful for the sort of little utilities I was talking about.
What's your point?
The compiler wasn't written in assembly, but it had to output it and debugging required following large codebases generated from an object-oriented language. That's what I meant... running through 500 lines of assembly to make sure the vtable was properly generated.
To be fair, doing any nontrivial assembly will put some serious hair on your balls. But it's just not very good for (almost*) any real work.
I use C for performance-critical code, C++ for complex performance-significant components (like a OpenGL million-poly renderer), Java or C# (depending on target platform(s)) for large but otherwise-modest programs, and scripting languages (mostly Python) for one-off programs or little tools that don't justify the involvement of a more heavyweight language.
Use the right tool for the job, as always. Can't go too far wrong with Java, and if you're going to hit its performance wall, you should know up front.
* Only large-scale assembly coding I've ever had to do was for a compilers class, but there was obviously no way around it. Fascinating to learn and do, but I sure hope I'm done with it...
I figured, but even if he was joking, others weren't. There does seem to be a belief that truly-critical equipment shouldn't be so darn expensive, and that can be a dangerous conclusion.
Low level, in this context, means that there are a very few number of abstractions between the C and native assembly instructions. C++ adds an object model that the computer doesn't deal with, Java is of course a bytecode, and so on - but C maps very closely onto (non-exotic) hardware. Loops are 'jmp's, functions are 'call's, structs are a format for memory layout, pointers are raw memory addresses, and so on. It's quite straightforward to hand-compile most C code. Not so for C++, unless you feel like hand-coding vtables.
You're talking about something completely orthogonal to the level of abstraction. Unavailable specific processor features has nothing to do with it - if you used a 20 year old x86 assembler it wouldn't support SSE2, but would this make the assembly it supports not "close to the metal"? On the flipside, you could write a Python module that directly exposes the SIMD instructions as vector math ops, for example, and it would still be high-level. By car analogy, not having access to the valve timings doesn't make a manual transmission high-level shifting. It's higher-level than reaching in and moving gears around, but not by much.
And in any case, modern compilers know how to use SSE and MMX and other special features, particularly if you tell it so.
For all of Jobs' many faults, he doesn't seem to have any problem telling the RIAA to go fuck themselves. Hell, Apple has enough money to just buy up any particularly pesky label.
I think they would prefer not to roll the dice on whether their robot gun is going to shoot the enemy, shoot themselves, or just blow up spectacularly like a big "look who's hiding here" sign.
I work in EMS. Sure, I look at a $10k power stretcher and go "I could do that for cheaper"
But could I? Here's the thing - for mission-critical equipment, you don't fuck around. Be smart about how you spend your money - which means you should get the tool you need and know it'll work right every time. Don't waste it, by any means, but if you mean it, you'll need to pay.
And most importantly, if we have an equipment failure, we can point at the manufacturer. I'm sure some of the price goes to a lawsuit fund, but again - this is what you pay for.
For the record, that stretcher has worked for more than 5 years and more than 50% over weight specs, with no problems yet or for the foreseeable future. And it was worth every penny.
Unfortunately, and ironically, computers are too prevalent in cars to really be able to do that nowadays. I knew two kids in HS a couple years back that were building hotrods, but they were building the same hotrods you were talking about - '70s Corvettes and GTOs and things. Modern cars are really too complex to take apart and fiddle with, unfortunately.
It's knowing how to describe a calculation so that it can be automated by a machine.
I'd go further. It's about understanding your problem well enough to figure out how to *always solve it*.
My example is Sudoku, mostly because a solver is the first nontrivial program I wrote. You need to understand the game on another level, and in an entirely different way, in order to find the answer to (effectively) all of them. "I know how to solve Sudoku puzzles" is not the same, and not nearly as powerful, as "I can solve *every* Sudoku puzzle". Making that leap from the specific to the general is what's important for people to be able to do.
AT&T is actually not bad about unlocking phones. They do all their other phones after (IIRC) 6 months in good standing.
But it is on them to tell Apple to unlock, not the other way around. As I understand it, the iPhone asks the Apple server on activation whether it should be locked or not - but AT&T can tell Apple to change the flag and they'll do it, based on the fact that, well, they do in other countries.
So it's very weird.
He fucked over Woz? Do tell.
IIRC, Woz himself has denied any particular animosity between them. And if you mean monetarily, I hope Jobs "fucks me over" next...
I understand what fiat currency is, and you're right. As I posted in your sibling comment, I'm not quite sure how to express "it has no intrinsic worth, but we give it some".
As far as "cyber-credits" go, this is reasonable. Not everybody has or can get a credit card, but debit cards and prepaid cards temper this substantially to the point where a CC# is reasonably accessible to everybody who wants one. So I think it's a lot less useful than it might have been 15 years ago - and indeed I remember reading about 'e-cash' and 'e-wallets' and all sorts of other schemes to do just this. But such a scheme is - IMHO - more useful as a frontend to "real" currency. And then you get Paypal (if it didn't suck), which acts more as a broker than a currency, and hence much easier to understand and trust. I give the money to a third party and they ferry it along to my recipient. My grandparents would have called this a money order or a wire transfer, but now we have the internet.
Basically, I'm not sure why it has to be a new currency, if that's what it's best for. And it doesn't seem to fill any other needs particularly well.
I understand what fiat currency is. I must admit I don't know the term for a currency whose value comes ex nihilo, but I know this is a component of a fiat currency. I tried to temper that with "sure, it's decentralized", which obviously, a fiat currency isn't. Sorry for being less-than-clear.
Bitcoin is a fiat currency. Sure, it's decentralized, but it has no intrinsic value.
People already agree that dollars, Euros, etc. have value. What worth does Bitcoin bring to the table? I use my credit card; it's very convenient and I don't care who knows what I spend at Dunkin' Donuts. But if I was worried about privacy, I'd use cash everywhere. It's easy to exchange between nations, if you need to, and most people don't.
So other than being "distributed!" and "electronic!" and - admittedly - pretty cool, what is it actually good for? Anybody who won't accept cash for identity purposes won't accept Bitcoins, and anybody who might accept Bitcoins will almost certainly accept cash.
And it's really new. As a customer, I'm very nervous about spending "real" (cash) money on worthless bits. As a provider, I'm even more nervous about accepting payment in worthless bits. Not saying they are, but it's my money so the concern is enough to avoid it when cash is a perfectly viable alternative.
In short, why should I use Bitcoins? Why should I accept them for my labor? What assurances do I have that it won't all go belly-up when the fad dies down and people stop caring?
Falsifiability is when you describe an experiment that would show your theory to be false. Falsifiability is a requirement of a valid hypothesis. Gravity would be falsified by showing that objects with mass didn't accelerate towards each other - if you could show that, you disprove gravity. Evolution is falsified by watching a species spring from nothing. Creationism can't be falsified because "it's all God" - anything that happens that you didn't expect, God could've done - which is why creationism isn't science.
It's not about fabrications or hoaxes. The GP's question (I hope) is whether somebody could construct an experiment that shows that the boson *doesn't* exist, at least not as we understand it.
I'd go one further. IT employees who screw up their network infrastructure enough to need to specifically account for a standards-compliant device should be fired.
802.1x, TTLS, PAP, WPA, are *standards*. Any device that supports these standards can connect (this includes Android and iOS devices, and all 10k undergrads, almost as many grad students, a few thousand faculty, another few thousand staff, a hospital, and more), so they can't screw around. They block inbound port 139 and 445 to stop most worms, tell everyone to use a firewall, and simply kick people off (after notice) until you reformat if you get a virus. No magic security tool needed, it's the internet and it's your own damn problem if you get infected so use a FW. IMHO it's better that way.
My school uses 802.1x TTLS-PAP, with the SSO username/password, for authentication and encryption. On wired, there's a (standard HTML) portal that registers your (or an entered, for consoles) MAC address when you enter your password. I do IT support in the dorms; we don't officially support Linux, but it's usually even easier to configure than OSX (which is quite finicky with 802.1x) - on Linux, when you attempt to connect, it guessed the authentication method and just requires your user/pass. Windows needs a supplicant for TTLS - we use a configured SecureW2 installer.
The engineering school's big beefy server (appropriately named Eniac) runs a custom SuSE distro, as well as a few large labs (with home directories mounted over NFS). All my classes have either gone to great pains to be OS-agnostic, or require Linux - never Windows. For credit, all work must compile on the engineering school server (no "it worked at home!", you must check) but it's usually not an issue. For reference, my major coding classes have been a compilers class in OCaml (ugh), a graphics class in Qt/C++, a hardware class in C, and a number of classes with Java. For the most part, I did the work in OSX and tested on their machines before submission. I have an OS class next year that actually requires Linux, because we'll be using direct syscalls and they want to ensure consistency even across different Unixen.
The engineering school is really OSS-friendly, to the point where I think it'd be hard to graduate from it without Linux proficiency (though people sure try...). In fact, I can't think of a single class that's required proprietary software of any sort, even in the liberal-arts school.The networking folks are Linux-heavy as well, so the whole campus feels that. But the business school is a MS shop through and through (Exchange, domains, etc).
RTFS. He's talking about legit mail, not spam. Even automated no-reply boxes notice a bounce, so this is a good answer.
I missed that you have to re-buy the songs that it finds.... my source didn't have that. Where did you read that?