There's a talk from 1986 by Richard Hamming at Bellcore, about how to do great research, but it also ends up in a short discussion about the conditions there that led to UNIX:
The whole talk is really excellent, and there's this theme in it that the really great things come from some unexpected places, by the compounding of seemingly unrelated character traits, work habits and organization dynamics.
At the end in the Q&A, Hamming gets into a short discussion with the host Alan Chynoweth about the origins of UNIX, evincing from Alan a favorite quote:
"UNIX was never a deliverable!"
expanded:
"Hamming: First let me respond to Alan Chynoweth about computing. I [was in charge of] computing in research and for 10 years I kept telling my management, ``Get that !&@#% machine out of research. We are being forced to run problems all the time. We can't do research because we're too busy operating and running the computing machines.'' Finally the message got through. They were going to move computing out of research to someplace else. I was persona non grata to say the least and I was surprised that people didn't kick my shins because everybody was having their toy taken away from them. I went in to Ed David's office and said, ``Look Ed, you've got to give your researchers a machine. If you give them a great big machine, we'll be back in the same trouble we were before, so busy keeping it going we can't think. Give them the smallest machine you can because they are very able people. They will learn how to do things on a small machine instead of mass computing.'' As far as I'm concerned, that's how UNIX arose. We gave them a moderately small machine and they decided to make it do great things. They had to come up with a system to do it on. It is called UNIX!
A. G. Chynoweth: I just have to pick up on that one. In our present environment, Dick, while we wrestle with some of the red tape attributed to, or required by, the regulators, there is one quote that one exasperated AVP came up with and I've used it over and over again. He growled that, ``UNIX was never a deliverable!''"
If this technique keeps on working after a while, virus writers will have effectively passed the Turing test. Though as predicted, the Turing test will end up saying more about itself (and us) than AI. Perhaps there should be a Turing Test++ that identifies AI as intelligence capable of distinguishing a human from a virus bot soley by communication over IM.
C'mon, wrong answer
on
Why We Fight
·
· Score: 2, Interesting
When resources are scarce, we usually don't attack our own societies, we attack those next to us. Don't look for cover for your fascist ideals in "human" nature. It's just your nature. The rest of us *do* weed people out who assert it, whether it takes a censure or a war.
You're right that disks don't fail together that often, but components do tend to fail when you get them or at the end of their expected lifetimes (just like us!). This is called the bathtub curve. If you buy a bunch of disks at the same time with the same MTBF, you'll get a big spike of failures within the first few days or in say 4 years. If you use RAID5 on lots of disks, you're hosed because it can't tolerate a failure during a recovery. This may sound exotic, but it's a key design consideration on larger disk systems like archive.org's petaboxen (though, I guess those are exotic:).
As usual, variety is the spice of life... just don't buy lots of the same kind of stuff at once.
Anycast allows you to serve the same IP from multiple servers distributed around the net. It's a BGP hack, and some people don't like it because of that, but it's used to keep some of the DNS root servers up. Has the added ability to divide and conquer DDOS attacks. The caveat is that routing changes break stateful connections, so that's why DNS can use it well (single package UDP connections most of the time).
Mosix is a UNIX patch that allows processes to migrate across machines. There's even a neat utility called mtop or something that shows load on all servers in a curses interface.. and you can see them balance out like water pouring between them. This also has issues with maintaining active connections.
If you could migrate statefull connections you could effectively have infinite uptime. Anyone have a patch?
Does anyone know if there's significantly more heat generated by a 110-240V (or 110-220V) PSU when attached to 220/240 voltage as in Europe vs. the 110 power we have here in the States? Most PSUs seem to have this as an automatic capability, though I have seen some that require a small switch be flipped on them.
We've had a bit of a bet going on at the office and while we have found a few theoretical descriptions which say this should be the case, we don't know how much more heat would be expected.
We're thinking the greater heat would come from transforming the higher AC voltage down to the same 3-5v mainboard DC. If there's much more heat, that means we have to plan our racks a bit differently.
Would be really neat to have alternative designs to pick from a la CSS Zen Garden. You could have a design contest for the default and list all submissions as alternates in a sidebar.
When they do ice core samples in the ant/arctic, do they look at all of the layers (top too) and see what the overall correspondence between freeze and melt is? I'm wondering if there's any evidence of fast thaws followed by fast freezes, how far the one goes before the other kicks in, and how often the cycles happen. Does anyone know where to find out more about this?
Actually, glad you brought this up. I turned off duplicate elimination on both sites for my test query and got an exact match between Yahoo's estimated and actual number of results pages. Google's actual number increased but still fell short of actual.
So again, looks like Yahoo has a good handle on what its index size is, but is simply filtering out lots of the results from its index. Perhaps there's not really that much difference between the two after all:)
But even though I said take everything I said with a grain of salt, I would take that claim about estimated vs. actual hits with 2 grains of salt.
Here's my superb rationale why.
Consider that if it was easy or efficient return the exact # of hits, they would probably do it, instead of, for instance, "Results 251 - 259 of about 284". I mean, consider the UI people at Google.. do they want to muddly their otherwise famously precise and clear interface with a guffaw like that? I'd bet Not unless they couldn't do any better or unless there's a good reason to not show the full 284.
My bet is that they tune the results estimate to be basically precise for an average query, and not a junk query.
However, there is a more tantilizing possibility. What if the "of about X" means that X is the total # of pages that *do* match the query, but some repeats or otherwise bogus pages are thrown out.
This would be exactly the evidence needed of their precision/recall tuning. In that case, which of course may be wrong, not only does Yahoo have a huge index, but is leveraging its size to be able to tune for a much higher precision while still returning a large number of results.
That's one possibility it would have been nice to see mentioned in the NCSA study.
Yeah, I agree there are many caveats. Like I said: "However, take this with a grain of salt as it's hard to measure anything without knowing how the sites do Precision/Recall tradeoffs, and there may be substantial structural differences in the way the sites index pages to start with."
What you describe would be to me a "substantial structural difference". Which means I agree.
However, that doesn't change that I do think it's better to accept probable error in a huge population of samples than to choose a miniscule population which is still susceptible to error, as the NCSA study seems to have favored.
The fundamental problem is that if you care about the actual performance of Google and Yahoo, you're left with very little to judge them by.
It's better, as usual, to support open approaches like Apache Nutch.
After criticising the study when I first saw it, I now have some constructive ideas on how to perform a better test of the relative search performance of the two engines.
- Crawler Test
Do a search of "microsoft site:microsoft.com" in Google, Yahoo and MSN search. Assume that Microsoft knows how to crawl its own site completely and judge the relative strength of Google's and Yahoo's crawlers based on how many of those pages they find. Google easily wins.
Unfortunately, his test doesn't work with Yahoo as the reference site since Google returns no hits for "yahoo site:yahoo.com". This is very disappointing, as Yahoo is one of the largest sites on the Web. Neither Yahoo or MSN share this self-censorship policy.
Another test of the same kind is "amazon site:amazon.com", since amazon is a very big site which everyone is presumably very interested in crawling well. Unfortunately, amazon doesn't allow this kind of search on themselves via their A9 engine.
This is an interesting test because it compares the very likely actual size of a site (i.e. Microsoft's reported size for microsoft.com) with the reported size by the second-party search engine. This may be the best 3rd party test of a crawler's Recall on a per-site basis.
- Common Word Test
Surprisingly, Google, Yahoo and MSN all now allow stop-word searching. Stop words are words like "the", "a", "it", etc.. A search for "the" on each show Yahoo significantly in the lead.
This is an interesting test because the word "the" is probably as uniformly distributed in the source webpage population than the random phrases used in the NCSA test (or possibly moreso), plus this word is more likely than any other to occur in every web document (at least with English). These two characteristics mean that finding the most pages with "the" may be the closest approximation of an actual Recall measurement for all sites on the web that can be done without a prior-knowledge testing set.
- Conclusion
Google and MSN seem to have high-quality crawlers, whereas Yahoo makes up with a much larger current index size. However, take this with a grain of salt as it's hard to measure anything without knowing how the sites do Precision/Recall tradeoffs, and there may be substantial structural differences in the way the sites index pages to start with.
Even assuming these results, Yahoo's bigger index isn't necessarily more desirable. A better crawler can yield a bigger and better index with relatively little work (just add more machines to store it on), while there is no easy fix for the meticulous work needed to ensure a crawler is getting to all the nooks and crannies of the Web.
Longer-term, it is these caveats that make an Open-Source approach to crawling shine by comparisson. Take for example the Nutch search engine. Though it is in its early days, there need be no doubt to its cralwing and ranking algorithms as well as its Precision/Recall tradeoff.
The most basic measure of performance in Information Retrieval is precision vs. recall.
Precision is how many of the results that you return are correct. e.g. If Google returns 100 results and 10 of them are correct, then the precision on that query is 10%.
Recall is how many of the correct results you return. e.g. If Yahoo returns 100 results out of a total 1000 correct matches, then the recall on that query is 10%.
Information retrieval systems such as search engines balance these two metrics -- which are fundamentally at odds with each other -- to give the "best balance" in the eyes of the system's designers.
The NCSA study basically misses the effect this decision would have on perceived size of index.
A simple demonstration shows how it works.
First let's say both search engines have the same index size: 10B pages. Second, let's say both search engines have exactly the same apriori capability for precision and recall, but can tune for a preferred performance. Yahoo decides it wants to favor more precise results over more results recalled, at a 2:1 relative ratio compared to Google.
In that case, any given query will show half the hits from Yahoo as compared to Google. Concluding Yahoo's index to be half the size of Google's, given this result, would be incorrect.
Furthermore, without knowing the precision/recall performance of either system, they can only demonstrate a lower-bound on index size, and that certainly doesn't predict average or max index size.
The only thing I'd add to this excellent point about assembly is that it's really a jump-off point for the rest of machine architecture. A real assembly language is pretty hard to teach all by itself and would probably need to be motivated by a deeper architectural course anyways.
Architecture is awesome. What is a CPU anyways?
In college we implemented a CPU, but from two very different perspectives.
The first was in a logic course, where we learned the basic boolean operations and then in one single homework assignment had to put them together into a functional CPU (mux, demux, addr... all the way to registers, cache and ALU).
The second was a hardware course where we started with Radio-Shack gates and a breadboard and worked our way up to Xilinx chips and Verilog.
Now, I still don't understand why a PnP junction works (depsite some excellent attempts by physics friends to describe quantum wells), but I know it exists and I can basically take it from there;) That's a foundation you feel free to experiment on!
BTW, I know you just asked about programming languages, but even in a very limited course, don't set your sights too low. I once did a few week park grass planting project with some city youths. At the beginning of the project the daily conversations were dating, trouble and rap. By the end of the project we were talking about the finer points (for a layman at least) of relativity theory:)
Point being.. it's so easy to dig in with Java *and* get something just like those crazy guys, those C hackers get (check out the Lucene search engine before you dis Java's performance).
I learned C in college. Bleh! Java would have made so many things so much clearer and given me a real way forward.
Ah well. At least you can learn from past mistakes!
Java API Java-API Java API. Java API Java API Java API. "Java API" Java API Java API-Java API. Java API; Java API.Java API Java API. Java API Java API Java-API Java API. Java API Java API Java API. "Java API" Java API Java API-Java API. Java API; Java API.Java API Java API. Java.
A few years ago they probably would have assumed IE and skipped the public comment process. Now there's too many creatives using macs.
Now, asking for 5 copies of a comment letter is like saying "Unless you're a corporate lawyer representing a major publishing house, keep your comments to yourself. You serf."
And no, they don't care about Linux users since it's the office of copyRIGHT, not copyLEFT.. that office is located at creativecommons.org.
"The change is mostly a legal/tax thing to avoid the problems of pursuing revenue-generating avenues while remaining a non-profit."
This is like a zen koan of accounting. The doublespeak that is so familiar to corporate America.
"Uh, yeah Bob, we're gonna have to take our money making discussion off-line because of Sarbanes-Oxley so that we can sort out some of the tax implications of the outstanding revenue from Q3, which we want to preserve for our earnings estimates despite the obvious effects against our write-offs."
which translated means
"Bob. Holy shit, we're rich! Dude, whatever it takes we gotta hide this money from the G-Men so we can take trips down to Jamaica and smoke log-sized joints on the company yacht!"
Don't matter if it's Microsoft or Mozilla foundation;)
I feel like it kind of defeats the purpose of breaking a major public health story to release it in Salon, where you have to decide to be advertised to (by perhaps a major pharma? I'll never know) before you can take up arms against overbearing corporatism.. wtf?
Slashdot Mirror
There's a talk from 1986 by Richard Hamming at Bellcore, about how to do great research, but it also ends up in a short discussion about the conditions there that led to UNIX:
http://www.paulgraham.com/hamming.html
The whole talk is really excellent, and there's this theme in it that the really great things come from some unexpected places, by the compounding of seemingly unrelated character traits, work habits and organization dynamics.
At the end in the Q&A, Hamming gets into a short discussion with the host Alan Chynoweth about the origins of UNIX, evincing from Alan a favorite quote:
"UNIX was never a deliverable!"
expanded:
"Hamming: First let me respond to Alan Chynoweth about computing. I [was in charge of] computing in research and for 10 years I kept telling my management, ``Get that !&@#% machine out of research. We are being forced to run problems all the time. We can't do research because we're too busy operating and running the computing machines.'' Finally the message got through. They were going to move computing out of research to someplace else. I was persona non grata to say the least and I was surprised that people didn't kick my shins because everybody was having their toy taken away from them. I went in to Ed David's office and said, ``Look Ed, you've got to give your researchers a machine. If you give them a great big machine, we'll be back in the same trouble we were before, so busy keeping it going we can't think. Give them the smallest machine you can because they are very able people. They will learn how to do things on a small machine instead of mass computing.'' As far as I'm concerned, that's how UNIX arose. We gave them a moderately small machine and they decided to make it do great things. They had to come up with a system to do it on. It is called UNIX!
A. G. Chynoweth: I just have to pick up on that one. In our present environment, Dick, while we wrestle with some of the red tape attributed to, or required by, the regulators, there is one quote that one exasperated AVP came up with and I've used it over and over again. He growled that, ``UNIX was never a deliverable!''"
If this technique keeps on working after a while, virus writers will have effectively passed the Turing test. Though as predicted, the Turing test will end up saying more about itself (and us) than AI. Perhaps there should be a Turing Test++ that identifies AI as intelligence capable of distinguishing a human from a virus bot soley by communication over IM.
When resources are scarce, we usually don't attack our own societies, we attack those next to us. Don't look for cover for your fascist ideals in "human" nature. It's just your nature. The rest of us *do* weed people out who assert it, whether it takes a censure or a war.
oh whooops, this isn't politics.slashdot.org!
You're right that disks don't fail together that often, but components do tend to fail when you get them or at the end of their expected lifetimes (just like us!). This is called the bathtub curve. If you buy a bunch of disks at the same time with the same MTBF, you'll get a big spike of failures within the first few days or in say 4 years. If you use RAID5 on lots of disks, you're hosed because it can't tolerate a failure during a recovery. This may sound exotic, but it's a key design consideration on larger disk systems like archive.org's petaboxen (though, I guess those are exotic :).
As usual, variety is the spice of life... just don't buy lots of the same kind of stuff at once.
Anycast allows you to serve the same IP from multiple servers distributed around the net. It's a BGP hack, and some people don't like it because of that, but it's used to keep some of the DNS root servers up. Has the added ability to divide and conquer DDOS attacks. The caveat is that routing changes break stateful connections, so that's why DNS can use it well (single package UDP connections most of the time).
Mosix is a UNIX patch that allows processes to migrate across machines. There's even a neat utility called mtop or something that shows load on all servers in a curses interface.. and you can see them balance out like water pouring between them. This also has issues with maintaining active connections.
If you could migrate statefull connections you could effectively have infinite uptime. Anyone have a patch?
Does anyone know if there's significantly more heat generated by a 110-240V (or 110-220V) PSU when attached to 220/240 voltage as in Europe vs. the 110 power we have here in the States? Most PSUs seem to have this as an automatic capability, though I have seen some that require a small switch be flipped on them.
We've had a bit of a bet going on at the office and while we have found a few theoretical descriptions which say this should be the case, we don't know how much more heat would be expected.
We're thinking the greater heat would come from transforming the higher AC voltage down to the same 3-5v mainboard DC. If there's much more heat, that means we have to plan our racks a bit differently.
Would be really neat to have alternative designs to pick from a la CSS Zen Garden. You could have a design contest for the default and list all submissions as alternates in a sidebar.
When they do ice core samples in the ant/arctic, do they look at all of the layers (top too) and see what the overall correspondence between freeze and melt is? I'm wondering if there's any evidence of fast thaws followed by fast freezes, how far the one goes before the other kicks in, and how often the cycles happen. Does anyone know where to find out more about this?
Not nearly as bad as I'd have thought.
Any net vigilanties out there want to "infect" these machines with patches?
ISP Active Hosts Yesterday
yahoo.com 4110
comcast.net 4017
hotmail.com 1567
aol.com 358
rr.com 5256
http://www.trustedsource.org/
Where's the hot new startup?
Actually, glad you brought this up. I turned off duplicate elimination on both sites for my test query and got an exact match between Yahoo's estimated and actual number of results pages. Google's actual number increased but still fell short of actual.
:)
So again, looks like Yahoo has a good handle on what its index size is, but is simply filtering out lots of the results from its index. Perhaps there's not really that much difference between the two after all
Well, yeah.
But even though I said take everything I said with a grain of salt, I would take that claim about estimated vs. actual hits with 2 grains of salt.
Here's my superb rationale why.
Consider that if it was easy or efficient return the exact # of hits, they would probably do it, instead of, for instance, "Results 251 - 259 of about 284". I mean, consider the UI people at Google.. do they want to muddly their otherwise famously precise and clear interface with a guffaw like that? I'd bet Not unless they couldn't do any better or unless there's a good reason to not show the full 284.
My bet is that they tune the results estimate to be basically precise for an average query, and not a junk query.
However, there is a more tantilizing possibility. What if the "of about X" means that X is the total # of pages that *do* match the query, but some repeats or otherwise bogus pages are thrown out.
This would be exactly the evidence needed of their precision/recall tuning. In that case, which of course may be wrong, not only does Yahoo have a huge index, but is leveraging its size to be able to tune for a much higher precision while still returning a large number of results.
That's one possibility it would have been nice to see mentioned in the NCSA study.
Yeah, I agree there are many caveats. Like I said: "However, take this with a grain of salt as it's hard to measure anything without knowing how the sites do Precision/Recall tradeoffs, and there may be substantial structural differences in the way the sites index pages to start with."
What you describe would be to me a "substantial structural difference". Which means I agree.
However, that doesn't change that I do think it's better to accept probable error in a huge population of samples than to choose a miniscule population which is still susceptible to error, as the NCSA study seems to have favored.
The fundamental problem is that if you care about the actual performance of Google and Yahoo, you're left with very little to judge them by.
It's better, as usual, to support open approaches like Apache Nutch.
Yeah, I see that now too. I must have mistyped. My apologies to Google for publicly questioning their editorial policy without merit!
After criticising the study when I first saw it, I now have some constructive ideas on how to perform a better test of the relative search performance of the two engines.
- Crawler Test
Do a search of "microsoft site:microsoft.com" in Google, Yahoo and MSN search. Assume that Microsoft knows how to crawl its own site completely and judge the relative strength of Google's and Yahoo's crawlers based on how many of those pages they find. Google easily wins.
Unfortunately, his test doesn't work with Yahoo as the reference site since Google returns no hits for "yahoo site:yahoo.com". This is very disappointing, as Yahoo is one of the largest sites on the Web. Neither Yahoo or MSN share this self-censorship policy.
Another test of the same kind is "amazon site:amazon.com", since amazon is a very big site which everyone is presumably very interested in crawling well. Unfortunately, amazon doesn't allow this kind of search on themselves via their A9 engine.
This is an interesting test because it compares the very likely actual size of a site (i.e. Microsoft's reported size for microsoft.com) with the reported size by the second-party search engine. This may be the best 3rd party test of a crawler's Recall on a per-site basis.
- Common Word Test
Surprisingly, Google, Yahoo and MSN all now allow stop-word searching. Stop words are words like "the", "a", "it", etc.. A search for "the" on each show Yahoo significantly in the lead.
This is an interesting test because the word "the" is probably as uniformly distributed in the source webpage population than the random phrases used in the NCSA test (or possibly moreso), plus this word is more likely than any other to occur in every web document (at least with English). These two characteristics mean that finding the most pages with "the" may be the closest approximation of an actual Recall measurement for all sites on the web that can be done without a prior-knowledge testing set.
- Conclusion
Google and MSN seem to have high-quality crawlers, whereas Yahoo makes up with a much larger current index size. However, take this with a grain of salt as it's hard to measure anything without knowing how the sites do Precision/Recall tradeoffs, and there may be substantial structural differences in the way the sites index pages to start with.
Even assuming these results, Yahoo's bigger index isn't necessarily more desirable. A better crawler can yield a bigger and better index with relatively little work (just add more machines to store it on), while there is no easy fix for the meticulous work needed to ensure a crawler is getting to all the nooks and crannies of the Web.
Longer-term, it is these caveats that make an Open-Source approach to crawling shine by comparisson. Take for example the Nutch search engine. Though it is in its early days, there need be no doubt to its cralwing and ranking algorithms as well as its Precision/Recall tradeoff.
The most basic measure of performance in Information Retrieval is precision vs. recall.
Precision is how many of the results that you return are correct. e.g. If Google returns 100 results and 10 of them are correct, then the precision on that query is 10%.
Recall is how many of the correct results you return. e.g. If Yahoo returns 100 results out of a total 1000 correct matches, then the recall on that query is 10%.
Information retrieval systems such as search engines balance these two metrics -- which are fundamentally at odds with each other -- to give the "best balance" in the eyes of the system's designers.
The NCSA study basically misses the effect this decision would have on perceived size of index.
A simple demonstration shows how it works.
First let's say both search engines have the same index size: 10B pages. Second, let's say both search engines have exactly the same apriori capability for precision and recall, but can tune for a preferred performance. Yahoo decides it wants to favor more precise results over more results recalled, at a 2:1 relative ratio compared to Google.
In that case, any given query will show half the hits from Yahoo as compared to Google. Concluding Yahoo's index to be half the size of Google's, given this result, would be incorrect.
Furthermore, without knowing the precision/recall performance of either system, they can only demonstrate a lower-bound on index size, and that certainly doesn't predict average or max index size.
The only thing I'd add to this excellent point about assembly is that it's really a jump-off point for the rest of machine architecture. A real assembly language is pretty hard to teach all by itself and would probably need to be motivated by a deeper architectural course anyways.
;) That's a foundation you feel free to experiment on!
:)
Architecture is awesome. What is a CPU anyways?
In college we implemented a CPU, but from two very different perspectives.
The first was in a logic course, where we learned the basic boolean operations and then in one single homework assignment had to put them together into a functional CPU (mux, demux, addr... all the way to registers, cache and ALU).
The second was a hardware course where we started with Radio-Shack gates and a breadboard and worked our way up to Xilinx chips and Verilog.
Now, I still don't understand why a PnP junction works (depsite some excellent attempts by physics friends to describe quantum wells), but I know it exists and I can basically take it from there
BTW, I know you just asked about programming languages, but even in a very limited course, don't set your sights too low. I once did a few week park grass planting project with some city youths. At the beginning of the project the daily conversations were dating, trouble and rap. By the end of the project we were talking about the finer points (for a layman at least) of relativity theory
Java.
:)
Not to brag, but take a look at the things I've written in Java:
- Java Desktop: 1500 lines.
- Solar System Simulator: 2000 lines.
- Backpropagation Neural Net: 130 lines.
And that's just the beginning!
Point being.. it's so easy to dig in with Java *and* get something just like those crazy guys, those C hackers get (check out the Lucene search engine before you dis Java's performance).
I learned C in college. Bleh! Java would have made so many things so much clearer and given me a real way forward.
Ah well. At least you can learn from past mistakes!
Java API Java-API Java API. Java API Java API .Java API Java API. Java API .Java API Java API. Java.
Java API. "Java API" Java API Java API-Java API.
Java API; Java API
Java API Java-API Java API. Java API Java API
Java API. "Java API" Java API Java API-Java API.
Java API; Java API
only foot-licking creatives use macs. the real inspired among us do use linux, hate to say it. ;).
A few years ago they probably would have assumed IE and skipped the public comment process. Now there's too many creatives using macs.
Now, asking for 5 copies of a comment letter is like saying "Unless you're a corporate lawyer representing a major publishing house, keep your comments to yourself. You serf."
And no, they don't care about Linux users since it's the office of copyRIGHT, not copyLEFT.. that office is located at creativecommons.org.
"The change is mostly a legal/tax thing to avoid the problems of pursuing revenue-generating avenues while remaining a non-profit."
;)
This is like a zen koan of accounting. The doublespeak that is so familiar to corporate America.
"Uh, yeah Bob, we're gonna have to take our money making discussion off-line because of Sarbanes-Oxley so that we can sort out some of the tax implications of the outstanding revenue from Q3, which we want to preserve for our earnings estimates despite the obvious effects against our write-offs."
which translated means
"Bob. Holy shit, we're rich! Dude, whatever it takes we gotta hide this money from the G-Men so we can take trips down to Jamaica and smoke log-sized joints on the company yacht!"
Don't matter if it's Microsoft or Mozilla foundation
Either your sense of irony is non-existent or far more developed than average. Given your username, I bet the former ;p
I feel like it kind of defeats the purpose of breaking a major public health story to release it in Salon, where you have to decide to be advertised to (by perhaps a major pharma? I'll never know) before you can take up arms against overbearing corporatism.. wtf?