It's not a man made hybrid of any kind. He reproduced a genetic mutation. He didn't modify anything, and as such should not be issued a patent for the tree, as it is a discovery, and not an invention.
Genetic modifications can be patented, not genetics themselves, and certainly not something which existed in nature with no input from man.
Ah, but notice that Google returns snippets that contain the search terms for each page in the search result. If the page contents are not in RAM, then creating these snippets would need to read the page from disk. Google's performance suggests that this is unlikely. (I doubt caching just snippets is worthwhile relative to caching the whole page) You're probably right about the images (keywords only) and mail (subjects only), though.
Given how fast Google is, we expect that they keep all the text of all the web pages that they index in memory. If we estimate 100K machines and 4,285,199,774 web pages, that's 42,852 web pages per machine. Let's guess 1 GB RAM per machine, then that's an allocation of about 25 KB per page (quite a bit larger than the average page size, I suspect). Of course, they've probably replicated the web a few times; let's guess 3 times, so that's about 8 KB per page -- still room to spare, and it's possible that the average memory per machine is greater than 1 GB. Plus, they could compress less popular pages -- the delay of decompression in memory is probably small.
Of course, once you consider that they keep thumbnails of al the images they index, things get tight very quickly. Plus, we can't forget the actual INDEX from words to documents -- that's in memory, too. And Orkut (which is probably pretty small, come to think of it).
GMail is another story altogether. 1 GB per user for 100K users would saturate their cluster. Plus indexes for searching mail. It seems unlikely that we'll have all-memory mail accounts anytime soon.
To decrypt incoming mail or sign outgoing mail, GMail would need access to your private key, which is bad for your security. Even if you trust GMail with your key, it's hard to keep sensitive data private in a large distributed system: a single compromised node could reveal the private keys it stores (keys stored on disk are encrypted with passphrases, but an attacker can copy these keys and try and break their encryption offline; also, keys of users with active sessions may be decrypted in unprotected memory).
Instead, you could run an agent on your local machine that manages your private key. GMail could request decryption and signing from your agent over a secure network connection; the agent in turn could confirm with you before using your private key (so that you don't sign anything you don't mean to). You must still trust GMail to protect your decrypted messages, e.g., to scrub them from its memory when your session expires.
The problem with the agent approach is you can only use GPG from machines that hold your private key. What might be best is a combined approach: keep two private keys, one offline, and another on GMail. Your offline key is the one people trust. Use your offline key to authorize your GMail key for some limited period of time (say, one year). Then, if your GMail key is lost or compromised, you can just create a new one.
Regarding searching encrypted mail, you might allow GMail to index a message when it is first decrypted, but not to store the decrypted message itself. Then, you can still search for that message by the words it contains. An attacker who gains access to your account can use the search determine whether an encrypted message contains a specific word or phrase, but this is probably an acceptable risk for most people (this assumes access to your account does not imply access to your private key, though!). An attacker might be able to reconstruct your message if they gain access to Google's entire index for that message, but this seems unlikely.
research background for anticipatory scheduling
on
The New Linux Speed Trick
·
· Score: 3, Informative
The original research for anticipatory disk scheduling was done at Rice University by Sitaram Iyer and Peter Druschel and is described
here.
While airborne seeding and infertility are necessary to make this work, they might make it difficult to get the right "resolution" of seeds on the field. I assume mines are not too large (2ft radius?), so one needs seeds at least that close together, if not closer. Is possible using airborne seeding?
If the weeds were fertile, then they could increase their density to the maximum the field could sustain. If one could make the weed's fertility "time out" after a few generations or depend on some fertilizer only present in the area of deployment, then one could deploy a fertile weed that could not spread too far.
Of course, "Jurassic Park" showed us that any genetically-engineered technique for controlling a population is doomed to spectacular failure:)
Entering your username or IP address into the subpoena query page seems to be a great way to make sure the RIAA checks out your username or IP address.
People often mistake thirst for hunger. Next time you feel hungry between meals, drink a large glass of water (just keep some at your desk). More often than not, this satisfies the craving. As an added bonus, this forces you to get up every hour or so to pee.
(while beer has the same effect, it carries the penaly of unnecessary calories)
Certainly those of us familiar with the web know how to refine our searches, but novice users may have difficulty with this. Googlehole No. 2 suggests a way that the search engine could help: the engine could offer the keywords most highly correlated with those searched for as refinement terms, e.g., given "apple," the search engine could offer "fruit", "computer", and "Fiona". I believe this has been done in research systems (by clustering the search results using their keyword frequency vectors), but I haven't seen it in deployed search engines.
Byzantine fault tolerance (BFT) is a "traditional" distributed systems technique that enables intrusion resilience. BFT replicates a service such that the service continues to work correctly as long as less than one third of the replicas are comprimised. Combined with proactive recovery (periodically shutting down replicas and restarting them from a read-only disk), this can enable the system to survive an arbitrary number of compromises over its lifetime.
fyi, Bruce Schnier discusses self-destructing DVDs briefly in his latest Crypto-Gram newsletter:
Disney is launching a pilot DVD-rental program that uses self-destructing DVDs. The idea is that the DVD has a coating that oxidizes after a few days, rendering the DVD unreadable.
I think this is a very clever security countermeasure. The threat is regular consumers. Disney wants to be able to rent DVDs to them at a price-point lower than their sale price. By making a DVD that only lasts a few days after being taken out of the package, Disney has solved the problem of needing an infrastructure to process DVD returns.
Of course this doesn't solve the problem of making illegal copies of the DVD, but that's not the problem that Disney is trying to solve. Self-destructing DVDs are a clever solution for a specific security problem, and if it works well it's likely to be a cheap and effective one. (Compare this to Circuit City's superficially similar DIVX format, which also had expiring DVDs, but required a phone line and special player.)
It's eerily appropriate that Microsoft calls the place through which all things pass "the Nexus". The Borg have a Nexus, too: a set of stabalized wormholes through which Borg cubes can reach the entire galaxy (Voyager final episode). Things that make you go "hmmmm..."
Input: 2 cans refried beans 1 cup sour cream (more if desired) 1 cup mayo (more if desired) generic "taco seasoning" 3 large or 4 small tomatoes 1 small can diced green chilies 2 cups grated cheddar cheese 1 bunch of scallions
Process: In a large rectangular pan (16x9?), spread refried beans evenly. In a bowl, mix sour cream, mayo, and taco seasoning to taste (should be pretty spicy). Spread mixture over beans. Dice tomatoes and spread over mixture. Spread green chilies on top of tomatoes. Spread cheese on top of chilies. Dice scallions and spread on top of cheese.
Actually, I've found Fowler's technique for extracting methods pretty useful for clarifying code. Basically, he says that if a block of code is preceded by a comment, extract that block into a method whose name is the same as that comment, and remove the comment.
This works pretty well, and leaves you with two kinds of methods: top-level ones that look like simple lists of tasks (enqueueEvent, sendReply, etc.), and small lower-level methods that do only a specific task. And yes, these small methods usually don't need to be commented, because the method name serves as the comment.
This technique also works well for replacing ugly boolean formulas in if-statements. Compare
// check if message is late, and if so, do blah if (System.currentTimeMillis() > (message.timestamp() + Message.TIMEOUT) { // blah }
to
if (message.isLate()) { // blah }
I'd argute that the latter doesn't really need a comment.
When I first read this, I thought you mean LaTeX (ie. the formatting language), and was very confused. I would have been very impressed to find out that Joss Wheadon could use LaTeX...
Slashdot Mirror
Lots of people are joking about MS using the body as a power supply, which is not what this is claiming.
They want to use the body as a power *conduit*.
One word: bzzzzzzt!
oooh, bad idea:
-> Perfect!
(target blows up)
<--> Perfect!
(two targets blow up)
-> Great!
(target lists to one side)
<- Miss
(civilian casualties)
(standard mythical man-month rant elided)
Bottom line: more people at this stage == bad idea.
Aww, and I was hoping it was brought to me by 3M (TM)!
Genetic modifications can be patented, not genetics themselves, and certainly not something which existed in nature with no input from man.
I assert that I can patent my children:
Ah, but notice that Google returns snippets that contain the search terms for each page in the search result. If the page contents are not in RAM, then creating these snippets would need to read the page from disk. Google's performance suggests that this is unlikely. (I doubt caching just snippets is worthwhile relative to caching the whole page) You're probably right about the images (keywords only) and mail (subjects only), though.
Given how fast Google is, we expect that they keep all the text of all the web pages that they index in memory. If we estimate 100K machines and 4,285,199,774 web pages, that's 42,852 web pages per machine. Let's guess 1 GB RAM per machine, then that's an allocation of about 25 KB per page (quite a bit larger than the average page size, I suspect). Of course, they've probably replicated the web a few times; let's guess 3 times, so that's about 8 KB per page -- still room to spare, and it's possible that the average memory per machine is greater than 1 GB. Plus, they could compress less popular pages -- the delay of decompression in memory is probably small.
Of course, once you consider that they keep thumbnails of al the images they index, things get tight very quickly. Plus, we can't forget the actual INDEX from words to documents -- that's in memory, too. And Orkut (which is probably pretty small, come to think of it).
GMail is another story altogether. 1 GB per user for 100K users would saturate their cluster. Plus indexes for searching mail. It seems unlikely that we'll have all-memory mail accounts anytime soon.
To decrypt incoming mail or sign outgoing mail, GMail would need access to your private key, which is bad for your security. Even if you trust GMail with your key, it's hard to keep sensitive data private in a large distributed system: a single compromised node could reveal the private keys it stores (keys stored on disk are encrypted with passphrases, but an attacker can copy these keys and try and break their encryption offline; also, keys of users with active sessions may be decrypted in unprotected memory).
Instead, you could run an agent on your local machine that manages your private key. GMail could request decryption and signing from your agent over a secure network connection; the agent in turn could confirm with you before using your private key (so that you don't sign anything you don't mean to). You must still trust GMail to protect your decrypted messages, e.g., to scrub them from its memory when your session expires.
The problem with the agent approach is you can only use GPG from machines that hold your private key. What might be best is a combined approach: keep two private keys, one offline, and another on GMail. Your offline key is the one people trust. Use your offline key to authorize your GMail key for some limited period of time (say, one year). Then, if your GMail key is lost or compromised, you can just create a new one.
Regarding searching encrypted mail, you might allow GMail to index a message when it is first decrypted, but not to store the decrypted message itself. Then, you can still search for that message by the words it contains. An attacker who gains access to your account can use the search determine whether an encrypted message contains a specific word or phrase, but this is probably an acceptable risk for most people (this assumes access to your account does not imply access to your private key, though!). An attacker might be able to reconstruct your message if they gain access to Google's entire index for that message, but this seems unlikely.
The original research for anticipatory disk scheduling was done at Rice University by Sitaram Iyer and Peter Druschel and is described here.
While airborne seeding and infertility are necessary to make this work, they might make it difficult to get the right "resolution" of seeds on the field. I assume mines are not too large (2ft radius?), so one needs seeds at least that close together, if not closer. Is possible using airborne seeding?
:)
If the weeds were fertile, then they could increase their density to the maximum the field could sustain. If one could make the weed's fertility "time out" after a few generations or depend on some fertilizer only present in the area of deployment, then one could deploy a fertile weed that could not spread too far.
Of course, "Jurassic Park" showed us that any genetically-engineered technique for controlling a population is doomed to spectacular failure
My bad -- the EFF kindly anonymizes such queries, which is of course, the point :)
Entering your username or IP address into the subpoena query page seems to be a great way to make sure the RIAA checks out your username or IP address.
This also explains bullet-time: it's just lag :)
People often mistake thirst for hunger. Next time you feel hungry between meals, drink a large glass of water (just keep some at your desk). More often than not, this satisfies the craving. As an added bonus, this forces you to get up every hour or so to pee.
(while beer has the same effect, it carries the penaly of unnecessary calories)
Certainly those of us familiar with the web know how to refine our searches, but novice users may have difficulty with this. Googlehole No. 2 suggests a way that the search engine could help: the engine could offer the keywords most highly correlated with those searched for as refinement terms, e.g., given "apple," the search engine could offer "fruit", "computer", and "Fiona". I believe this has been done in research systems (by clustering the search results using their keyword frequency vectors), but I haven't seen it in deployed search engines.
Byzantine fault tolerance (BFT) is a "traditional" distributed systems technique that enables intrusion resilience. BFT replicates a service such that the service continues to work correctly as long as less than one third of the replicas are comprimised. Combined with proactive recovery (periodically shutting down replicas and restarting them from a read-only disk), this can enable the system to survive an arbitrary number of compromises over its lifetime.
Hmm--15 seconds of full page flickering? I can see the news story now: "Web Ad Kills 347 Epileptic Children"
Could someone please provide an intuitive derivation of how they got that distance between parallel universes? I'm curious.
It's eerily appropriate that Microsoft calls the place through which all things pass "the Nexus". The Borg have a Nexus, too: a set of stabalized wormholes through which Borg cubes can reach the entire galaxy (Voyager final episode). Things that make you go "hmmmm..."
It an attempt to look even more like Windows, the next RedHat release will incorporate the new "Bluescreen" theme...
My wife taught me this one. It rocks.
Input:
2 cans refried beans
1 cup sour cream (more if desired)
1 cup mayo (more if desired)
generic "taco seasoning"
3 large or 4 small tomatoes
1 small can diced green chilies
2 cups grated cheddar cheese
1 bunch of scallions
Process:
In a large rectangular pan (16x9?), spread refried beans evenly. In a bowl, mix sour cream, mayo, and taco seasoning to taste (should be pretty spicy). Spread mixture over beans. Dice tomatoes and spread over mixture. Spread green chilies on top of tomatoes. Spread cheese on top of chilies. Dice scallions and spread on top of cheese.
Serve at room temperature with tortilla chips.
This works pretty well, and leaves you with two kinds of methods: top-level ones that look like simple lists of tasks (enqueueEvent, sendReply, etc.), and small lower-level methods that do only a specific task. And yes, these small methods usually don't need to be commented, because the method name serves as the comment.
This technique also works well for replacing ugly boolean formulas in if-statements. Compare
to
I'd argute that the latter doesn't really need a comment.
Batman is a DC Comic, not Marvel.
Marvel: X-Men, Spiderman, Hulk
DC: Batman, Superman, Justice League
When I first read this, I thought you mean LaTeX (ie. the formatting language), and was very confused. I would have been very impressed to find out that Joss Wheadon could use LaTeX...