Similar, but Fermat's Last Theorem states that no integers x,y,z can satisfy the equation x^n + y^n = z^n where n is an integer > 2 This one allows every exponent to vary separately as well as the bases and is trying to make a guarantee rather than proving an impossibility (and, contrary to popular belief, proving a negative is not only possible but trivial to prove )
It does not take talent to waste power. It takes talent to build a fusor from scratch. It takes talent to build scintillators, or even use existing one, to get a spectrum from your reaction to know the exact reactions that are occurring and in what proportions. It takes talent to keep yourself safe using such a device. It take drive and motivation and a damn side more vision than most people have to attempt such endeavors. This is the Hello World for a nuclear physicist and I encourage such behavior.
If all you can see is someone "wasting" electricity I think you've missed out on a much larger picture.
ugh, sorry. forgot some words, was focused on making the numbers correct: (5% of schizophrenics * 1% of the population) = 0.05% *of the general population* are violent schizophrenics vs
3.025253% of the general population are violent non-schizophrenics (This would be the overall rate after discounting both violent and non violent schizophrenics)
I just went on a mini wiki binge based on that refutation. Thanks.
It would seem that although femtosecond pulses are not on the scale of the state of the art (attoseconds) they are still considered "ultra-short" by the optics community. The real news would seem to be the range of frequencies that can be produced (both the breadth of frequencies and, specifically, some frequencies that are difficult to work with) and little more.
Only one paper wasn't behind a paywall, and I'm not a trained scientist, (So if I make a mistake someone PLEASE CORRECT ME) but from what I can glean graphene will happily absorb nearly any wavelength of light because of the lack of a bandgap between free electrons and bound electrons (this is the opposite of what you find in, e.g. semiconductors where there is a meaningful power gap). Electrons in graphene can be exited to any quantum level within a wide and useful range. In fact it seems that it absorbs so much of the energy that they had to dope the graphene to reduce its absorption. It is also notable that the graphene wasn't hard to produce. They produced flakes between one and three layers in solution, filtered out the water, cooked for a bit, and the resultant jumble of flakes was A-OK and only ~1/3 graphene by volume. Far easier than producing something more pure or large scale.
The graphene is pumped in a "lossy" mode to bump electrons up in energy (this is the "low Q" or "low quality" resonator mode) and then the resonant cavity is bumped to "high Q" mode. Since the graphene absorbed so much of the pumping light, and did so over the entire bandwidth of the pumping laser, when the mode is switched it lases brightly and all at once. (This is, in short, "how to build a Q-swtiched laser")
The key difference with graphene is that it absorbs practically any frequency of light without any modification. This is the special property, the lack of tuning required for a "saturable absorber". As far as I can tell this means that the material can store a certain amount of energy from the laser pump with low losses until it becomes saturated. I interpret this as a sort of optical capacitor (low loss energy storage) where as more traditional absorbers are leaky capacitors at frequencies that they are not tuned for.
Not sure how significant the optics community will find this, but it does seem to be a meaningful technology rather than a "trick" or some "in 5 years" promise.
Does AMD support VDPAU these days? Because VA-API support is mighty poor in my experience. Broke down and bought a card when I had a perfectly find integrated one for my TV box because I can't get VA-API to work with mplayer. There is a source version that supports it, I couldn't get it to compile cleanly, though.
I also had a ton of trouble with the "legacy" vs new ATI drivers (the computer was low end, but only a few months old when this nonsense happened). Not sure what caused that split, but it was hell to get working on Ubuntu. Left a bad taste in my mouth all around. Think they resolved it, but it was just yet another barrier between me and what is normally a flawless experience.
The protocol will migrate to the new primitives, the bitcoins will still be bitcoins. Old bitcoins will remain in the pulbic, well documented, chain (meaning that even if the primitives are hopelessly broken the chain itself won't be ruined because of its vast public record). New blocks and new bitcoins will use the newer primitives.
IANABP (I am not a Bitcoin Proponent, I own exactly 0BC and will not in the forseeable future), but I am interested in the idea and mechanisms involved.
If a break is ever found, suspected, or even slightly likely an orderly migration to better cryptographic primitives can be performed. If you are interested in knowing more the wiki enumerates all the known possible attacks.
Pointer chasing is the cannonical example. Trees, linked lists of every flavor, maps, many many more.
Even if your memory accesses are aligned you will still start to stream cache misses as soon as you are operating beyond the limits of cache, or start bouncing between cores and/or threads (snooping is cheap, but it isn't free and by the time you get there another thread might have kicked out your data).
Then there is synchronization between threads. Fences aren't free (far far from it, though some can be cheaper than others)
Some practical examples are rays tracers (objects scattered all around memory), XML parsers (relatively huge objects and more. Love or hate it XML is everywhere), precise garbage collection scatters certain objects around memory, and compression. That is just off the top of my head, but you get the idea. Not everything is contigious. Even when it is you can easily stream misses a rate collosally higher than they can be served.
The power of a modern processor to get work done is dominated by cache misses. I mean by a factor of a hundred or more to one unless every bit you are computing lives in cache and nothing ever kicks your code or data's cache line out (including another line of code or data that you need. Because of the way that cache works you can't map every address to every line in cache).
It doesn't matter. Laser. Radio. Gama ray.Doesn't matter. At these distance the systems are, no matter how well focused, diffraction limited. Just like we can't build a mircoscope to see infinitely deep into the smal we cannot build a laser com with perfect focus. Diffraction wins. We can cheat a little, but not over these distances.
We could see laser flashes just as easily as hear radio waves from parabolic dishes.
A call for violence or discrimination against a people based on their race, gender, religious beliefs, sexual orientation, parental status, or marital status (and perhaps more, but that covers the major bases) is hate speech. Perhaps it lacks rigor, but that is my own internal definition.
Of course it is censorship, I don't think anyone can credibly deny that, but that doesn't mean that a slippery slope applies to it. Look at some of the hate speech laws around the world for more details. There are good and bad ways to do it, but it can be done right.
If we want to make America better then we need to do something to combat the irrational and damaging hatred that spreads like as much kudzu through a forest, choking the ecosystem litterally from the roots up. Perhaps hate speech laws aren't the right tool, but they are a tool to consider to combat a very real problem.
The best way to stop any want or need for hate speech laws is to be intolerant of intolerance, but many people would never question their grandmother's racism, or an in-laws calls to cast all Muslims out of the nation. This low level of negativity and subtle hatred feeds the whole food chain, culminating in some rather terrible things across every spectrum of society.
How can you change that? What can be done? How do you raise the morality level of an entire society? How to do all this without robbing society of other rights? I don't know, but it is worth talking about.
I understand the fear of hate speech laws. Our government can sometimes use tools made for good purpose to accomplish evil ends, but let's speak as rational people about it instead of becoming polarized so much against the means itself that the original of it intent is lost. Most of us really want to make the world better.
That isn't exactly how rainbow tables work. In fact colliding chains is undesireable for rainbow tables. While it is true that you might end up on another "chain" the odds of that are exceedingly low with even 128bits of hash space and any decent salt.
The reason for itterating a password hash it to slow it down, to try and thwart brute force, however it doesn't work that well against GPUs since they have so many cores to work with and VERY efficient implementations of the algorithms. Some password hashing algorithms (I believe bcrypt is of this sort) can be tuned to take more memory and, this, keep GPUs from working much if any faster than a normal CPU. This, really, needs more research but the principals are simple: make memory access patterns impossible to predict so you can't stream in cache lines and make the space required "large" (lare isn't HUGE, I think a few megs is large enough. You won't find this in a normal cryptographic hash as they are *designed* to be fast, and that is a good thing for every use aside from this)
Rainbow tables work in chains, as you said, but what they do is they generate a hash from a "seed" for each chain THEN they "map" that hash back into the password space, and then hash that, map, hash, map, hash, da da da. Once you do this for a good long ways you store the final hash and the seed for this chain. You have MANY chains. To find a password from the hash you pick up right in the middle of that. Lets go step by step: You have a hash to reverse 1) check the hash against your "end of chain" hashes 2) If the hash has no match you do the same "mapping" that you did while creating the rainbow table into the password space 3) repeat until you find an "end hash" and therefore the chain, or you find that this password isn't in your table by mapping-hashing more times than you used for the chains 4) assuming you found the end hash you then take the "seed" for that chain and start hashing and mapping it over and over until you find your original hash 5) the password that you hashed to get there will be the correct one
So, yeah. Lots going on and many subtle problems that can creep in, but the chances of a collision due to itterated hashing aren't large. Smaller than anything you'll ever need to worry about. Like I said, too, itterated hashing doesn't help much against GPUs
I write in Java, most days, so I depend on compilers to do a lot of work for me. I don't depend on them [compilers] to pick the correct algorithm for me.
Simple problems get library functions. Simple streams of instuctions get optiomized futher by the processor. It still requires an awareness of how to optimize the problem to get good results.
Can't sort a linear list like you sort a random access list, an't sort a directed cylic graph at all (lest you peer inside and find a wayto break the loops) at all, and you can't provide consistency, patition tollerence, and availability at the same time. Some things *are* written in stone, but not as many as I let on, but CERTAINLY more than I'd like!
That is because of knowledge of processor details, memory details, comple operations, and, well, they [compilers] are better than us. Except that the ability to optimise depends on pure logic, of some form. As the state gets large optimization gets more complex.
Just like quicksort(3) is far faster than bubblesort so too is a highly threadable code faster than non-threadble code. Languages do not, contrary to belief, express intent, the provide a strict set of instructions that the computer MUST respect. In the end a good algorithm with no compiler help will beat optimized "dumb" code in all cases larger than "toy" (say, a few dozen "n" in Big-O notation)
Good thought about opimizing compilers, but it doesn't bear out.
It is possible to prove a multi-threaded program correct.
First you might start at the memory model, and all the guarantees that one can make based on that (and, by association, all the guarantees in terms of the memory model that locking / atomic calls make), then one can move on to he library structures and routines (objects and methods to put it in another paradigm).
Once you have hard guarantees using primitives and low level constructs it might be easy to construct a state-based proof. One example is Cliff Click's lock free hashtable (don't know ifhe has a formal proof, but nearly so if not)
Correctness in multithreaded environments takes a different form than in a single thread, but it is nothing that cannot be managed. Generally there are only a few "tough locks" to crack and the majority of the speedup can be had. Some problems are harder than others, and some problems don't have great parallelism, but that is just a generalization of programming, really. "Some things are harder than others, but nothing doable is impossible"
I wrote up a very long comment that ranted and raved and didn't come close to this comment right here. Some threading problems are hard, really hard. They aren't that common.
IANAA but I can tell you that they have automated those tasks. The things that astronomers do these days is more programing and math heavy. They are taking the absoloute raw data and turning it into useful figures, new theories, proving old theories or debunking them and coming up with new ones, and every so often making a pretty picture that we can enjoy.
The amount of data collected is VAST, and there are so many telescopes and more projects viing for telescope time. The amount of prep work and post work pales in comparison to the actual observations.
So you are right in that sense: Automate!... but many things still require a solid chunk of grey matter, in the end.
Re:Don't waste your time with GNOME 3.6
on
GNOME 3.6 Released
·
· Score: 2
I came here to say this. Instead I'll second.
Add nautilus back in to get my prefered file manager back (1 apt-get), change the keybinds so I've got my 4 virtual destops on my normal keybind (I like CTRL+ALT+(left|up|down|right) for desktops 1,2,3,4 and + shift to move with window, but that is just my preference. I use the virtual desktops a LOT), and... really that is it. Install my dev suite (same old same old, do it anywhere, Xubuntu to debian) and... happy me! Got my productivity back. I like it even better than compiz (though it DOEs have compositiing!). I've even heard of some folk running compiz on top of it, but I grew tired of that.
Completely honest question, what bits does the Oracle version include that Hotspot does not?
G1GC, some very nice optimizations across the board, and some (I think) rather efficient native segments where needed (I/O and the like) are all a part of Hotspot.
I'll guess that the Oracle binary bits are to serve Oracle, but it would be interesting to see some improvements to aspire towards in Hotspot that are already in Oracle Java. Let me know.
Bananatree3 likely wasn't being ignorant, but rather stating the situation simply. The economics are driven by... economics. Just because they know where more is and are getting at it faster does not mean that it is the cheap stuff that used to spring out of the ground and soak the plains of Texas and Texans alike. This oil is deeper, dirtier, and more spread out.
We are really good at getting at oil, because we need it for every piece of modern life, or at least it is the only feasible way to do it. So we get the oil, however we can.
It would have been more accurate to say, "the CHEAP shit is running out". Other than that I think it is a fine comment.
Albedo actually, but that is one HELL of an amusing mixup! I think that if we could calculate libido accurately via simple observation we'd be able to put dating websites out of business;)
Similar, but Fermat's Last Theorem states that no integers x,y,z can satisfy the equation x^n + y^n = z^n where n is an integer > 2
This one allows every exponent to vary separately as well as the bases and is trying to make a guarantee rather than proving an impossibility (and, contrary to popular belief, proving a negative is not only possible but trivial to prove )
It does not take talent to waste power.
It takes talent to build a fusor from scratch.
It takes talent to build scintillators, or even use existing one, to get a spectrum from your reaction to know the exact reactions that are occurring and in what proportions.
It takes talent to keep yourself safe using such a device.
It take drive and motivation and a damn side more vision than most people have to attempt such endeavors. This is the Hello World for a nuclear physicist and I encourage such behavior.
If all you can see is someone "wasting" electricity I think you've missed out on a much larger picture.
ugh, sorry. forgot some words, was focused on making the numbers correct:
(5% of schizophrenics * 1% of the population) = 0.05% *of the general population* are violent schizophrenics
vs
3.025253% of the general population are violent non-schizophrenics (This would be the overall rate after discounting both violent and non violent schizophrenics)
I just went on a mini wiki binge based on that refutation. Thanks.
It would seem that although femtosecond pulses are not on the scale of the state of the art (attoseconds) they are still considered "ultra-short" by the optics community. The real news would seem to be the range of frequencies that can be produced (both the breadth of frequencies and, specifically, some frequencies that are difficult to work with) and little more.
Only one paper wasn't behind a paywall, and I'm not a trained scientist, (So if I make a mistake someone PLEASE CORRECT ME) but from what I can glean graphene will happily absorb nearly any wavelength of light because of the lack of a bandgap between free electrons and bound electrons (this is the opposite of what you find in, e.g. semiconductors where there is a meaningful power gap). Electrons in graphene can be exited to any quantum level within a wide and useful range. In fact it seems that it absorbs so much of the energy that they had to dope the graphene to reduce its absorption. It is also notable that the graphene wasn't hard to produce. They produced flakes between one and three layers in solution, filtered out the water, cooked for a bit, and the resultant jumble of flakes was A-OK and only ~1/3 graphene by volume. Far easier than producing something more pure or large scale.
The graphene is pumped in a "lossy" mode to bump electrons up in energy (this is the "low Q" or "low quality" resonator mode) and then the resonant cavity is bumped to "high Q" mode. Since the graphene absorbed so much of the pumping light, and did so over the entire bandwidth of the pumping laser, when the mode is switched it lases brightly and all at once. (This is, in short, "how to build a Q-swtiched laser")
The key difference with graphene is that it absorbs practically any frequency of light without any modification. This is the special property, the lack of tuning required for a "saturable absorber". As far as I can tell this means that the material can store a certain amount of energy from the laser pump with low losses until it becomes saturated. I interpret this as a sort of optical capacitor (low loss energy storage) where as more traditional absorbers are leaky capacitors at frequencies that they are not tuned for.
Not sure how significant the optics community will find this, but it does seem to be a meaningful technology rather than a "trick" or some "in 5 years" promise.
Does AMD support VDPAU these days? Because VA-API support is mighty poor in my experience. Broke down and bought a card when I had a perfectly find integrated one for my TV box because I can't get VA-API to work with mplayer. There is a source version that supports it, I couldn't get it to compile cleanly, though.
I also had a ton of trouble with the "legacy" vs new ATI drivers (the computer was low end, but only a few months old when this nonsense happened). Not sure what caused that split, but it was hell to get working on Ubuntu. Left a bad taste in my mouth all around. Think they resolved it, but it was just yet another barrier between me and what is normally a flawless experience.
The protocol will migrate to the new primitives, the bitcoins will still be bitcoins. Old bitcoins will remain in the pulbic, well documented, chain (meaning that even if the primitives are hopelessly broken the chain itself won't be ruined because of its vast public record). New blocks and new bitcoins will use the newer primitives.
An understandable misunderstanding.
IANABP (I am not a Bitcoin Proponent, I own exactly 0BC and will not in the forseeable future), but I am interested in the idea and mechanisms involved.
If a break is ever found, suspected, or even slightly likely an orderly migration to better cryptographic primitives can be performed. If you are interested in knowing more the wiki enumerates all the known possible attacks.
Pointer chasing is the cannonical example. Trees, linked lists of every flavor, maps, many many more.
Even if your memory accesses are aligned you will still start to stream cache misses as soon as you are operating beyond the limits of cache, or start bouncing between cores and/or threads (snooping is cheap, but it isn't free and by the time you get there another thread might have kicked out your data).
Then there is synchronization between threads. Fences aren't free (far far from it, though some can be cheaper than others)
Some practical examples are rays tracers (objects scattered all around memory), XML parsers (relatively huge objects and more. Love or hate it XML is everywhere), precise garbage collection scatters certain objects around memory, and compression.
That is just off the top of my head, but you get the idea. Not everything is contigious. Even when it is you can easily stream misses a rate collosally higher than they can be served.
The power of a modern processor to get work done is dominated by cache misses. I mean by a factor of a hundred or more to one unless every bit you are computing lives in cache and nothing ever kicks your code or data's cache line out (including another line of code or data that you need. Because of the way that cache works you can't map every address to every line in cache).
Don't take my word for it though, take Cliff Click's: http://www.infoq.com/presentations/click-crash-course-modern-hardware
You mean the moon stage? https://www.youtube.com/watch?v=ofbWiDdkHuQ
Amazon Elastic Compute.
No excuses.
https://en.wikipedia.org/wiki/Diffraction-limited_system
It doesn't matter. Laser. Radio. Gama ray.Doesn't matter. At these distance the systems are, no matter how well focused, diffraction limited. Just like we can't build a mircoscope to see infinitely deep into the smal we cannot build a laser com with perfect focus. Diffraction wins. We can cheat a little, but not over these distances.
We could see laser flashes just as easily as hear radio waves from parabolic dishes.
A call for violence or discrimination against a people based on their race, gender, religious beliefs, sexual orientation, parental status, or marital status (and perhaps more, but that covers the major bases) is hate speech. Perhaps it lacks rigor, but that is my own internal definition.
Of course it is censorship, I don't think anyone can credibly deny that, but that doesn't mean that a slippery slope applies to it. Look at some of the hate speech laws around the world for more details. There are good and bad ways to do it, but it can be done right.
If we want to make America better then we need to do something to combat the irrational and damaging hatred that spreads like as much kudzu through a forest, choking the ecosystem litterally from the roots up. Perhaps hate speech laws aren't the right tool, but they are a tool to consider to combat a very real problem.
The best way to stop any want or need for hate speech laws is to be intolerant of intolerance, but many people would never question their grandmother's racism, or an in-laws calls to cast all Muslims out of the nation. This low level of negativity and subtle hatred feeds the whole food chain, culminating in some rather terrible things across every spectrum of society.
How can you change that? What can be done? How do you raise the morality level of an entire society? How to do all this without robbing society of other rights? I don't know, but it is worth talking about.
I understand the fear of hate speech laws. Our government can sometimes use tools made for good purpose to accomplish evil ends, but let's speak as rational people about it instead of becoming polarized so much against the means itself that the original of it intent is lost. Most of us really want to make the world better.
That isn't exactly how rainbow tables work. In fact colliding chains is undesireable for rainbow tables. While it is true that you might end up on another "chain" the odds of that are exceedingly low with even 128bits of hash space and any decent salt.
The reason for itterating a password hash it to slow it down, to try and thwart brute force, however it doesn't work that well against GPUs since they have so many cores to work with and VERY efficient implementations of the algorithms. Some password hashing algorithms (I believe bcrypt is of this sort) can be tuned to take more memory and, this, keep GPUs from working much if any faster than a normal CPU. This, really, needs more research but the principals are simple: make memory access patterns impossible to predict so you can't stream in cache lines and make the space required "large" (lare isn't HUGE, I think a few megs is large enough. You won't find this in a normal cryptographic hash as they are *designed* to be fast, and that is a good thing for every use aside from this)
Rainbow tables work in chains, as you said, but what they do is they generate a hash from a "seed" for each chain THEN they "map" that hash back into the password space, and then hash that, map, hash, map, hash, da da da. Once you do this for a good long ways you store the final hash and the seed for this chain. You have MANY chains.
To find a password from the hash you pick up right in the middle of that. Lets go step by step:
You have a hash to reverse
1) check the hash against your "end of chain" hashes
2) If the hash has no match you do the same "mapping" that you did while creating the rainbow table into the password space
3) repeat until you find an "end hash" and therefore the chain, or you find that this password isn't in your table by mapping-hashing more times than you used for the chains
4) assuming you found the end hash you then take the "seed" for that chain and start hashing and mapping it over and over until you find your original hash
5) the password that you hashed to get there will be the correct one
So, yeah. Lots going on and many subtle problems that can creep in, but the chances of a collision due to itterated hashing aren't large. Smaller than anything you'll ever need to worry about. Like I said, too, itterated hashing doesn't help much against GPUs
I write in Java, most days, so I depend on compilers to do a lot of work for me. I don't depend on them [compilers] to pick the correct algorithm for me.
Simple problems get library functions. Simple streams of instuctions get optiomized futher by the processor. It still requires an awareness of how to optimize the problem to get good results.
Can't sort a linear list like you sort a random access list, an't sort a directed cylic graph at all (lest you peer inside and find a wayto break the loops) at all, and you can't provide consistency, patition tollerence, and availability at the same time. Some things *are* written in stone, but not as many as I let on, but CERTAINLY more than I'd like!
Laziness need not apply.
That is because of knowledge of processor details, memory details, comple operations, and, well, they [compilers] are better than us. Except that the ability to optimise depends on pure logic, of some form. As the state gets large optimization gets more complex.
Just like quicksort(3) is far faster than bubblesort so too is a highly threadable code faster than non-threadble code. Languages do not, contrary to belief, express intent, the provide a strict set of instructions that the computer MUST respect. In the end a good algorithm with no compiler help will beat optimized "dumb" code in all cases larger than "toy" (say, a few dozen "n" in Big-O notation)
Good thought about opimizing compilers, but it doesn't bear out.
It is possible to prove a multi-threaded program correct.
First you might start at the memory model, and all the guarantees that one can make based on that (and, by association, all the guarantees in terms of the memory model that locking / atomic calls make), then one can move on to he library structures and routines (objects and methods to put it in another paradigm).
Once you have hard guarantees using primitives and low level constructs it might be easy to construct a state-based proof. One example is Cliff Click's lock free hashtable (don't know ifhe has a formal proof, but nearly so if not)
Correctness in multithreaded environments takes a different form than in a single thread, but it is nothing that cannot be managed. Generally there are only a few "tough locks" to crack and the majority of the speedup can be had. Some problems are harder than others, and some problems don't have great parallelism, but that is just a generalization of programming, really. "Some things are harder than others, but nothing doable is impossible"
I wrote up a very long comment that ranted and raved and didn't come close to this comment right here. Some threading problems are hard, really hard. They aren't that common.
Man up and learn. I like it.
What about XFCE stifles your productivity? I rarely hear a remark against it so I'm interested to know.
IANAA but I can tell you that they have automated those tasks. The things that astronomers do these days is more programing and math heavy. They are taking the absoloute raw data and turning it into useful figures, new theories, proving old theories or debunking them and coming up with new ones, and every so often making a pretty picture that we can enjoy.
The amount of data collected is VAST, and there are so many telescopes and more projects viing for telescope time. The amount of prep work and post work pales in comparison to the actual observations.
So you are right in that sense: Automate!... but many things still require a solid chunk of grey matter, in the end.
I came here to say this. Instead I'll second.
Add nautilus back in to get my prefered file manager back (1 apt-get), change the keybinds so I've got my 4 virtual destops on my normal keybind (I like CTRL+ALT+(left|up|down|right) for desktops 1,2,3,4 and + shift to move with window, but that is just my preference. I use the virtual desktops a LOT), and... really that is it. Install my dev suite (same old same old, do it anywhere, Xubuntu to debian) and... happy me! Got my productivity back. I like it even better than compiz (though it DOEs have compositiing!). I've even heard of some folk running compiz on top of it, but I grew tired of that.
XFCE all the way.
Which country would that be?
Completely honest question, what bits does the Oracle version include that Hotspot does not?
G1GC, some very nice optimizations across the board, and some (I think) rather efficient native segments where needed (I/O and the like) are all a part of Hotspot.
I'll guess that the Oracle binary bits are to serve Oracle, but it would be interesting to see some improvements to aspire towards in Hotspot that are already in Oracle Java.
Let me know.
Bananatree3 likely wasn't being ignorant, but rather stating the situation simply. The economics are driven by... economics. Just because they know where more is and are getting at it faster does not mean that it is the cheap stuff that used to spring out of the ground and soak the plains of Texas and Texans alike. This oil is deeper, dirtier, and more spread out.
We are really good at getting at oil, because we need it for every piece of modern life, or at least it is the only feasible way to do it. So we get the oil, however we can.
It would have been more accurate to say, "the CHEAP shit is running out". Other than that I think it is a fine comment.
Albedo actually, but that is one HELL of an amusing mixup! I think that if we could calculate libido accurately via simple observation we'd be able to put dating websites out of business ;)