precious_pony

Nice of him to take the monitor for a walk.

This is hardly a “jury of one’s peers” .

Patent and copyright law should be judged by decided by those with the know-how of how to interpret very complex law and ideally with domain experience.

I’m glad the jury is taking this seriously, but seriously, at this point how does anyone know if the Jury was able to form an opinion based on the evidence or based on their flawed understanding of the evidence?

The article missed out the ultimate set-top-boxes, HTPCs. The Acer Revo’s play all content from everywhere and are not blocked by providers (as its a PC). If you use a remote with them and boot into a good Media Center, you get the best of all worlds and great power efficiency.

The article also did not cover power efficiency. The PS3 and 360 might do a lot, but they (especially the older ones) make a lot of noise and guzzle the juice. The best HTPC will be the android HTPCs on a stick coming up this year. With tweaking they will play everything, take almost no power, and be completely portable.

Fantastic result for Google. Lets hope the judge ultimately agrees with the common sense recent EU decision.

He can’t understand this case, too many big words for him.

I have to agree with you. The only two rulings that Google lost, were the points that they had already conceded. The ruling that they copied the structure of Sun’s APIs is a fact, not something to be ruled upon. The judge will rule if APIs can be copyrighted. It could not have gone better for Google at this point.

The overwhelming evidence demonstrated that Google knew it needed a license and that its unauthorized fork of Java in Android shattered Java’s central write once run anywhere principle.

Complete lies.

Firstly, Android’s implementation of Java was independent. Secondly, the API implementations were independently developed. Thirdly, “Java’s central write once run anywhere principle”, doesn’t apply to Sun/Oracle’s own mobile J2ME, which is completely incompatible with J2SE – so accusing Android of the exact same thing is a little hypocritical – not to mention that Java 5 code may not be compatible with a Java 1.4 JVM. Java’s write-once, run-anywhere only really applies to the J2SE, and backwards compatibility from the current version. Sun was perfectly capable of breaking their own rules.

The ruling does not state that Android was an unauthorized ‘fork’ in the slightest. Lies.

The only real victories for Oracle was that Google was found to have duplicated the structure of APIs and 9 lines of code from a trivial method, the result of an innocent mistake. Google never argues that they did not copy the structure of the 37 APIs. They argues that they did, that it was necessary, and that making their product compatible required engineering to the non-copyrighted standard. I’d say this ruling is about as good as it gets for Google. If the Jury had found that Google had not infringed on the structure of the APIs (given the Judge’s instruction to assume that such APIs were copyrightable) then that would be cause for a mistrial. Their finding is based on the assumption of the copyrightability of APIs. I suspect the Judge realises that to rule in that direction would be madness for the whole software industry.

Groups is the only decent feature on the site. That and the log-out button.

Actually, what does do something to cure cancer is, ironically, science a.k.a. rational thinking.

I refuse to grant any permission to any Facebook app. I have loads of Facebook “Friends” that ask me to give my profile information to one of those sh*tty birthday apps that are basically just user profile farming. I also have friends that constantly send me some sob story viral article about if I hate cancer that I should forward to all my friends, what the F for?

I honestly think that there should be a study done on what kinds of people don’t see a viral message/email for what it really is and realise that clicking a button to reveal yourself as an idiot to all your friends does not in fact do anything to cure cancer.

Lets take the case of a immutable String. The majority of methods on the Java String implementation are obvious. Even the naming of the methods is obvious. So, if I made a new String class (named “StringNotOracle”, and put on a substring method with the same parameters — substring(int beginIndex, int endIndex) — that would be OK due to de-minimis? But then what if I also wanted toUpperCase() or toLowerCase(), now its too similar not to be infringing?

You can see this is a slippery slope. Authors of APIs or classes within APIs, now have to consider that if they choose meaningful method names and meaningful parameter names, there is a chance that they might be infringing on someone who used them before. There is enough to worry about with patent trolls to have the constant threat of somebody suing because your independently developed API has similarities to theirs. Of course a lot of APIs will be similar – as they represent ideas.

Yes, the java APIs are much more involved than a single class, but if Oracle gets its way on this – it makes life a lot more complicated for somebody such as myself.

Moore’s law is not a law (I know you pointed this out). It’s not tried and true either. It’s certainly been tried and has held true up until recently, but in the same way as you can make a law “I always eat cake on my birthday – until you don’t.”

With regard to new tech, I see the next wave of tech being smart devices. Smart heating systems in the home, intelligent robotic workers, contactless toilet sliding doors, driverless vehicles, HUDs, holographic displays. Postal delivery tubes would be a great innovation, using maglev and fast routing of physical packages. Compute performance will enable a brighter future, and especially in the case of intelligent heating systems, all of this extra tech should consume less energy than we are currently spending on dumb tech.

Next gen Kinect like interfaces with holographic displays, voice recognition, intelligent intent prediction are all technologies waiting to hit the big time and to simplify individuals lives.

That said, the world has too many people. The world can’t support as many consumers as we already have so all this tech will end up in the hands of the top 10%, whilst famine, war and nuclear brinkmanship (as a way to acquire water and food) threaten to put a stop to all progress. So, in the future, I guess I’d be happy just to be able to have access to food and water.

But, Google does not want to use ‘Java’ as a brand. It does not even wish to use any of the Sun-developed Java code. It certainly has no use for the frankly awful J2ME (which is still tied to a tiny subset of Java 1.3, originally released in the year 2000).

Google has no use for the crappy implementation of Java, and no intention of carrying with it the design-by-commitee baggage that pervades J2ME. Android was a fresh start.

As a Java programmer, I love Java, but Sun let J2ME stagnate so it was pretty much unusable for the purposes of a smartphone platform. Google created their own ecosystem and class libraries and benefited by designing the APIs around its requirements. Google was never trying to de-value Java, nor to “do-a-Microsoft” and subvert the standard. Part of that is by going their own way and not signing a licensing agreement (which means that hace to stick to the crappy spec). Android’s Java class library is for a single platform only and fit for purpose as opposed to J2ME which is unfit for purpose as it supports archaic use-case paradigms and lowest-common-denominator platforms far below smartphone spec.

APIs are more like the grammar of a language. Words as atomic units are not creative but arguably, grammar itself is a creation. That said, grammar cannot be copyrighted. It is a context in which to tie together units of code, not the core of the creation itself.

APIs might also be tough to develop, but if you are saying that APIs are copyrighted, why stop there, why not be able to copyright the name and arguments of a method? It is a slippery slope indeed to be able to copyright the arguments to functions or bundles of functions.

An API is not code.

I must disagree.

J2ME is a (subjectively) crappy version. I know because I was programming using J2ME for years before Android was announced. There is nothing wrong with J2ME VMs, they are actually really good for the mostpart. It is the J2ME class libraries (and implementations) that are poor. Not enough of the phone is exposed and there is no programmatic method to connect applications together in a coherent way. Java is Java, but the class libraries in J2ME are next to useless lowest common denominator stuff.

J2SE is too big. Much too big, and mostly not applicable to constrained devices. Smartphones are only just getting to the point where J2SE is feasible from a footprint perspective, it was impossible back on the Arm 11 hardware of 2007. Dalvik runs on less than a megabyte of memory allocated, initially fully interpreted. J2SE allocates about 10MB for even a trivial program (although getting better with version 7). The point is, J2SE was a no-go and J2ME was crap. If Google had negotiated with Sun for it to scrap J2ME and go with what it wanted to do itself, then that might have been an option, but that would never have happened.

Google never forked J2ME. It created something that Sun could not create themselves, a useful version.

The standard Java class libraries were not required as they brought with them too much legacy which added to the code overhead, but Java itself and the VM were useful so they went the clean-room approach.

You say that APIs are part of the code. Yes, the same as every word in a copyrighted book is copied one-at-a-tine from a dictionary. APIs don’t do anything themselves, they are the connectors between functional blocks., its like somebody giving you the measurements of a box They are the interface.

The Java APIs were copied in the same way as the measurement of power connector is copied. If you want to perform operations and leverage community implementations, you have to have the same connectors. You could make the connectors a different size, just because you want to be different, but you lose the benefit of the various open source Java libraries if you do that. The back-end to all these API functions were written independently. The vast majority of Java APIs are not rocket science, and in fact, could be improved upon easily. The reason Google kept the API signitures the same is obviously to leverage legal open source code.

With regard to Android code being open. It is – completely. That there are incubation periods where Google creates a new stable version is irrelevant. If users want to fork it – they can. Amazon would never have been able to create the Kindle without the free Android source code.

I would say, that entering the hardware business directly is a risky move as it risks devaluing all brands that are not ‘Google’. Google purchasing Motorola probably made Samsung and HTC nervous, but they are insisting to maintain the Motorola brand and therefore not unfairly leverage the Google name for their own phones.

I’d say that Jelly Bean is the chance for Google to really disrupt the ecosystem in a fair way. If Google can make one final breaking change to the Kernel, and break up the OS into modules, with the manufacturers skins/unique features being overlayed on the top, in a backwards compatible manner, then it owuld be possible for Google to push updates to all handsets without the manufacturers having to rebuild their skins/features every time. Many phones (ironically, probably the cheaper Chinese ones) might actually grant complete update control to aosp itself and therefore will receive new OS updates on close to day-one without driver issues or issues with carrier/vendor features.

All of this is possible with one final major breaking change. I hope that Jelly Bean will make the push toward centralized upgrades of OS without disruption of manufacturer/carrier “value-add” features.

…. then Google Open Sourced the code under a permissive license so that other people could continue development and sell the resultant work:

It seems the acquisition was based upon wanting to gain access to the technology or to avoid patent claims on something similar they were planning to do themselves. In other words, Google did nothing at all wrong, and went the extra mile by releasing the code, free of charge.

If APIs can be copyrighted, why not method signatures?

It is madness to suggest that APIs can be copyrighted. If a computer language cannot be copyrighted, and if certain functions only have a logical set of arguments, then this opens the doors for programmers being sued for having functions with similar function names / parameter types/names.

Imagine a world where I have to call my substring method substring787u8X(pointlessvar1, pointlessvar2, offset, length)… just to be on the safe side of an API copyright claim.

Madness.

Google never forked Java and changed the license. Google’s implementation code is completely independent of Sun’s code and is a (possibly flawed) clean room implementation.

The source code to Android is open. Completely open.

The only code that is not open are proprietory applications within “Google Experience” phones, such as Gmail, YouTube, Maps, etc. These just sit on top of the open stack of the Android OS. If it were not open, then Amazon could not have forked Google and added its own proprietory apps on the open platform.

An open platform does not mean no proprietary apps.

One of the lesser discussed aspects of this trial is that J2SE was not suitable for use on resource constrained devices, and that J2ME was a complete mess, stuck in committee for about 5 years before Android’s introduction. J2ME essentially is a crappy version of Java that shares some of the base classes, removes lots of useful classes, and has really poor class library, completely unsuitable for a modern device.

Android didn’t need J2ME, it couldn’t use J2SE, so Google developed a completely independent stack using an independently developed Java compiler and VM. The question is, is using compatible APIs, copyright theft? If it is, then hundreds, if not thousands of lawsuits are sure to be initiated in the coming months, including many against Oracle I’d wager.

Cool Story Bro

My mother bought my father a Kindle Fire for Christmas. My father loved using my iPad, but had nothing but trouble in his experiences with the Kindle.

My father’s troubles are quickly summarized as:

1. it is slower than the iPad
2. the screen keeps going black (when loading certain webpages)
3. getting lost in the various screens
4. not being easily able to use his gmail account.

My own analysis of the cause of these troubles is as follows:

1. The main screen looks like it was designed in the mid-90s, and scrolling through an app list is just silly compared to having them in a grid or folders.
2. The scrolling through apps or media looks like its not hardware accelerated as it seems to run at around 10-15 fps. Functional, yes, but a touch device should refresh at 60fps to give the user a feeling of control.
   #The Kindle Fire OS can’t access the Play Store (although this is understandable), the volume controls are difficult to access.
3. The Silk browser has caused nothing but trouble for my father. It is sluggish, using software scaling when zooming, and worse still – appears to be compatible with a lot of sites that my father wanted to access (it would just hang).
4. The bookmark system is badly designed. The ‘Web’ tab from the main screen is actually just an app shortcut to the browser. The main screen cannot be customised at all (although the iPad shares this flaw too).
5. The worst of all this is the general feeling of sluggishness. The Kindle Fire has some very capable hardware. Two ARMv7 processors and a PowerVR graphics chip that is faster than in the iPad 1, yet it runs the UI faster than the original iPhone.

Then came ICS ….

The Kindle Fire is like a different tablet. The UI is so clean, I arranged my fathers favourite applications in a grid at the bottom of the screen. I arranged a widget with shortcuts at the top of the home screen. All his bookmarks are synched to his gmail account so when he bookmarks something, it is for good. The software nav buttons are much easier to use, especially the position of the back button at the bottom left, and disappear when playing videos. The browser is super smooth and compatible and runs all the webpages that refused to load in Silk. The font is clean and crisp on the screen, and the home screen feels so comfortable now. My dad is happy like a small child. The Kindle Fire is his first computer, as tech has always intimidated him.

I can honestly say, that ICS is even easier to use for my father than the iPad (the bookmark widget means he doesn’t have to go into sub-screens to find his favourite pages). Not a big deal for experienced computer users, but for someone who is not used to using tech – this is a massive benefit. I was able to limit his number of home screens down to 1 so he can’t accidently scroll off the main page, but that one screen has links to 10 apps, and all his bookmarks, and if he gets lost, the Home button takes him home. Fantastic.

That the Kindle Fire is so popular with such a terrible OS is a tribute to bullet point consumer blindness. Had it not been for ICS on the horizon, I would have immediately returned the KF on my mothers behalf after finding out what she did.

The Kindle Fire is a great little tablet, encumbered with amateurish software. I encourage all those with an hour spare to purge themselves it. Hatred for Kindle Fire OS is not a strong enough word.

DISCLOSURE: I own both an iPad (for iOS ecosystem) and a Galaxy S phone (for Android ecosystem). I love them both.

This should not be posted in head, this was posted in response to DBinSD’s comment elsewhere in this thread.

I’d delete this one or edit if The Verge gave me the option. :-/

I use this ROM:

I use this ROM:

The problem with version 4.0 is that it raises the minimum specs required for the platform and is based upon an incompatible kernel compared with 2.x releases.

This in itself means that, even with the best of intentions, upwards of 40% (finger in the air estimate) of current Android hardware probably couldn’t run it, even if the manufacturers were committed to the ideal.

That in itself does not mean that 4.0+ will never become dominant, it just means that this release in particular was always going to be a lot slower in terms of adoption rates. As old hardware dies, and new capable hardware is sold (even if shipping with 2.x with the intent to upgrade to 4.0+), the numbers will creep upwards.

If I were a lead on Android at this point, I’d be looking at some kernel-level upgrade mechanism themselves (built into all Android phones) and an additional UI layer that is guaranteed to be compatible with future releases. In this way, Google could release the new version independent of manufacturer supplied apps and skins. New OS features might not be exposed by such an upgrade (as system apps would not be pushed as a mandatory requirement), but at least apps would benefit from a less fragmented client base (they could assume existence of newer APIs and OS features).

I think that all these different phone models by manufacturers are currently creating a support nightmare for themselves. The number of phones to support keeps growing and the OS releases never stop. Google needs to manage the driver database and kernel upgrades themselves as an OS feature. I hope that this will be the main thrust of 5.0.