Yes, or at least the installer can be copied and used without restrictions.

Passwords are not DRM.

I'm sure that will go over really well: Punish people HARDER for picking on someone who's already advantaged compared to the perpetrator, as opposed to picking on someone who's disadvantaged. How about additional punishments for picking on the rich. Or those good at sports. Sorry, but we aren't QUITE yet living in the world of Idiocracy, so no, being smart doesn't make you a vulnerable class.

Good point.

You mean, exactly how many postal services ORIGINALLY operated? In the UK, it was receiver-pays until about 1840. Of course, that doesn't mean that the system wasn't terrible and unfair.

As someone who's been doing Android app development the last few years, this was the approach that we decided upon for a new thin-client application. An HTML5 based app seems like a good choice when the app is mostly consuming multimedia content, but if you need rich interactivity, a native Java application definitely seemed the better fit.

Re the 2nd: You realize the speed of sound in water is more than 4x of that in air, right? We can barely build a craft that can go that speed in the air, let alone water.

If you watch the video, you'll see the answers to each of these questions in detail.

Even assuming that bulk transmutation of elements is a "trivial breakthrough", Osmium is actually much less abundant than gold (citation). You're right that the value is what the market says it is, but wrong in thinking that being able to turn one into the other would cause the price of gold to plummet. Osmium is simply not as _useful_ of an element compared to gold, regardless of its rarity.

Well, technically, since this not a criminal case, nobody has to 'prove' anything. One side just has to have a preponderance of evidence. So far, the analysis of the code shows that only a fraction of a percentage of it is close enough to Sun/Oracle's to warrant looking more closely at it.

And while it offers no direct evidence one way or another, Google's intention from the beginning was to have the source code to Android published and would expect many, many eyeballs on their source code. If nothing else, it's inconceivable to me that the strategy at Google was, "let's clean-room implement 99.5% of this code, but then directly copy this other 0.5% of the code in order to save us time and money." A single engineer being lazy, on the other hand? I could buy that, maybe.

Clean-room reimplementation is not a new or obscure activity in software. It's been done for many decades and the legal hoops to jump through to perform it are well known. Standard practice is to have anyone who contributes as much as a line of code to sign an affidavit stating that they had never so much as glanced at the source code to what is being reimplemented. I suspect that Google has quite a lot of evidence that the clean room implementation was done according to legal standards. The truth is, though, a lot of APIs behave in ways that provide very few reasonable code structures to accomplish its implementation and therefore it is to be expected that even a clean-room implementation will have more than a passing resemblance to the original.

Google (Schmidt, personally) has testified in court that Google did a clean-room implementation of Java.
So far, Oracle's argument that Google did not do a clean-room implementation amounts to, "Uh uh! No they didn't!". Also, to nitpik, you can't "lift code" from an API.

This whole thing seems rather silly. First of all, yes, clearly Google copied the Java API. How can they even begin to deny that? Secondly, there is a crapload of legal precedence that indicates that an API is not legally protected by copyright.

What am I missing here??

Well, if it's 'hard' Real Time, It means that the kernel is designed to give certain guarantees for responsiveness. An example could be that a process that requests it can be certain that it gets a timeslice every certain number of milliseconds either most of the time (for a 'soft' RTOS) or completely deterministically (for a 'hard' RTOS).

As a (former) Blackberry developer, I've decided that I will be doing no more development for their platforms. They pissed away any goodwill I had for them by their crappy tools, crappy support and their ridiculous policies. As an example, in order to become a development partner, which is the ONLY way to get real support from them, you have to sign a license that basically gives RIM rights to use any of your source code that you develop for their platform. Or typically, if you tried to discuss a problem on their support forums, they would allow developers to spend weeks or months trying to figure out a problem before stepping in and say, "Oh, ya, we know about this. It's on our internal bug tracking system," and then close the discussion to new posts. This was often for bugs that had been around for several major API versions, or even from the very FIRST API version.

Fighting through the mess seemed like it was worth it when it seemed like everybody in the market for the software I was developing had a Blackberry, but now that it's dropped down to almost zero, you want me to invest my time and money into a brand new platform? No, thanks. At this point, I'm content to see you slip beneath the waves and to try to forget you exist. Goodbye.

Do you forget that DVD also has DRM? It's functionally equivalent to the one for Blue-Ray: it took a while to crack, and now is essentially completely toothless.

You should probably have checked that before posting... Are you confusing LCD with LED?