That would be correct if the meltwater had the same salinity (density) as the ocean water it's floating in and melting into. Being less dense, it doesn't displace its own equivalent volume of ocean water- and the remaining volume is pure contribution to sea level. But the differences in density are small and the contribution to sea level is only a few percent of what it would be if the ice were on land and not already floating. So they just stick to truisms about floating ice cubes.
You ever try Gnome or KDE, or to a lesser extent WindowMaker or Eazel?
Yeah, I have. You ever try KDE 4.0/4.1? Or to a lesser extent, 4.2?
GP is correct in this: part of the purpose of a patent is to fully reveal the invention, the idea being that someone skilled in the field can build the invention using only the information given in the patent. So a patent must give complete instructions to actually build the invention patented.
After all patents are to promote innovation, partly by revealing it. Other people can build the invention (that is fully allowed, you are just not allowed to sell/distribute a product based on the invention), and improve on it: this is how innovation is promoted.
Furthermore the protection is not only for a limited time frame, it is also limited by geographic region. So unless a patent has been applied for in all countries of the world (e.g. via the PCT), it may simply not exist for example in China. Which would mean that the Chinese could build the invention, and sell it within China, but they may not export it to say the USA where the patent is valid.
It is a strategic decision on the side of the patent holder where the holder may or may not want to cover the world (cost is an issue). As another poster indicated already, China is also part of PCT so Google may apply for the same patent in China as well and get their IP protection (admittedly enforcement is an issue in China but that is not the point here).
Because the article doesn't have any technical detail either. I would assume that the new features allow them to connect through some sort of peering mechanism, but the article doesn't go into detail.
Well, I thought there was some useful detail in the article, particularly this:
Overall, the modifications to Conficker B++ appear relatively minor as compared to the significant upgrade in functionality, performance, and reliability, that occurred from Conficker A to B. These smaller and more surgical changes to B appear to address some of the realities that are currently impacting Conficker's binary update strategy. In particular, in Conficker A and B, there appeared only one method to submit Win32 binaries to the digitial signature validation path, and ultimately to the CreateProcess API call. This path required the use of the Internet rendezvous point to download the binary through an HTTP transaction. Under Conficker B++, two new paths to binary validation and execution have been introduced to Conficker drones, both of which bypass the use of Internet Rendezvous points: an extension to the netapi32.dll patch and the new named pipe backdoor. These changes suggest a desire by the Conficker's authors to move away from a reliance on Internet rendezvous points to support binary update, and toward a more direct flash approach.
However, Conficker A and B did support through the previous netapi32.dll patch an ability to accept new DLLs, as long as the shell code submitted through the RPC buffer overflow matched the original Conficker infection shell code. This approach was limiting both in the requirement that direct flashing required an easily identifiable shellcode string and a single DLL method loading procedure, both of which are now subject to detection by security software. Conficker B++ dramatically increases the flexibilty of the direct flash mechanisms, offering an ability to load digitally signed Win32 executables directly to a Conficker host.
There has been a lot of good advice posted already, but I'll add what I can from my own experience. I was a computer science professor at a larger (~15,000) university for 20 years, and we used open source for virtually everything, but it was like pulling teeth to get the university to switch, mostly because of attitudes of people in the Data Center. The first thing, back in the 80's, was to get them to connect to the Internet. They thought their IBM Bitnet connectivity was all anyone would ever need. It was a very painful process, and people actually got fired
The fact that you asked about how to find out what the licenses cost suggest that you feel you can't just ask the people in your Data Center. If that is true, be prepared for a long guerilla war, but you will be able to make progress. As far as finding out what those things cost, you can't just get a standard price. Every contract is negotiated individually, with all sorts of mini-grants and bundling going on to help close the deal. If you can't get the information from the Data Center, try the Purchasing office. They may be more helpful.
In my experience, one department going its own way isn't real effective. I think that the Data Center spread the word that we were "different" and what worked for us "wouldn't work" for anyone else. Some people were puzzled as to why we never seemed to be bothered by viruses and worms, but they kept getting new stuff and it kept them happy.
One place where we managed to get a little purchase was when money got tight, and we pointed out that dropping some licenses might be preferable to laying people off. The good thing about that is that then they had to get some people with some open-source expertise, and that's how you really make progress, when there are some open-source advoctes inside the belly of the beast.
The most important thing is not to be impatient, and not to give up. When you get an opportunity, show the deans and vice presidents your $300 netbook, or whatever else, or show how effectively you can use open office and create documents that everyone else can use. They will start asking questions, and eventually the Data Center will have to come up with some real reasons why they go with proprietary products.
Good luck
First off, does this kind of approach work against any rationally designed secure software? All that would seem to be needed to defeat this is for the the login procedure to have a few seconds of delay before it responds yes or no, and no speedup in the guessing will help. This is why we have shadow password files, right? Or have I just been using *nix too long?
Also, I've seen people using GPUs in all sorts of non-graphics computation environments for some time now. When push comes to shove, is this just about money, and that CPUs have extra features that makes it easier to run an operating system, but aren't needed for pure computation? I'm not a hardware guy, so this is probably a stupid question, but I just don't get it.
We gave you an atomic bomb, what do you want, mermaids? -- I. I. Rabi to the Atomic Energy Commission
