Sure, this is a little late. Honestly, when I first heard the announcement, I did not see much news in it. The slide from the keynote (below) showed four points: Tesselation, Geometry Shaders, Computer [sic] Shaders, and ASTC Texture Compression. Honestly, I thought tesselation and geometry shaders were part of the OpenGL ES 3.1 spec, like compute shaders. This led to my immediate reaction: "Oh cool. They implemented OpenGL ES 3.1. Nice. Not worth a news post."

Apparently, they were not part of the ES 3.1 spec (although compute shaders are). My mistake. It turns out that Google is cooking their their own vendor-specific extensions. This is quite interesting, as it adds functionality to the API without the developer needing to target a specific GPU vendor (INTEL, NV, ATI, AMD), waiting for approval from the Architecture Review Board (ARB), or using multi-vendor extensions (EXT). In other words, it sounds like developers can target Google's vendor without knowing the actual hardware.

Hiding the GPU vendor from the developer is not the only reason for Google to host their own vendor extension. The added features are mostly from full OpenGL. This makes sense, because it was announced with NVIDIA and their Tegra K1, Kepler-based SoC. Full OpenGL compatibility was NVIDIA's selling point for the K1, due to its heritage as a desktop GPU. But, instead of requiring apps to be programmed with full OpenGL in mind, Google's extension pushes it to OpenGL ES 3.1. If the developer wants to dip their toe into OpenGL, then they could add a few Android Extension Pack features to their existing ES engine.

Epic Games' Unreal Engine 4 "Rivalry" Demo from Google I/O 2014.

The last feature, ASTC Texture Compression, was an interesting one. Apparently the Khronos Group, owners of OpenGL, were looking for a new generation of texture compression technologies. NVIDIA suggested their ZIL technology. ARM and AMD also proposed "Adaptive Scalable Texture Compression". ARM and AMD won, although the Khronos Group stated that the collaboration between ARM and NVIDIA made both proposals better than either in isolation.

Android Extension Pack is set to launch with "Android L". The next release of Android is not currently associated with a snack food. If I was their marketer, I would block out the next three versions as 5.x, and name them (L)emon, then (M)eringue, and finally (P)ie.

By now you should have read Ryan's post or listened to Josh talk about Juno on the PCPer Podcast but if you find yourself hungry for more information you can visit The Tech Report. They discuss how the 64-bit Linaro is already able to take advantage of one of big.LITTLE's power efficiency optimization called Global Task Scheduling. As Linaro releases monthly updates you can expect to see more features and better implementations as their take on the Android Open Source Project evolves. Expect to see more of Juno and ARMv8 on review sites as we work out just how to benchmark these devices.

"ARM has created its own custom SoC and platform for 64-bit development. The folks at Linaro have used this Juno dev platform to port an early version of Android L to the ARMv8 instruction set. Here's a first look at the Juno hardware and the 64-bit software it enables."

Even though Apple has been shipping a 64-bit capable SoC since the release of the A7 part in September of 2013, the Android market has yet to see its first consumer 64-bit SoC release. That is about to change as we progress through the rest of 2014 and ARM is making sure that major software developers have the tools they need to be ready for the architecture shift. That help is will come in the form of the Juno ARM Development Platform (ADP) and 64-bit ready software stack.

Apple's A7 is the first core to implement ARMv8 but companies like Qualcomm, NVIDIA and course ARM have their own cores based on the 64-bit architecture. Much like we saw the with the 64-bit transition in the x86 ecosystem, ARMv8 will improve access to large datasets, will result in gains in performance thanks to increased register sizes, larger virtual address spaces above 4GB and more. ARM also improved performance of NEON (SIMD) and cryptography support while they were in there fixing up the house.

The Juno platform is the first 64-bit development platform to come directly from ARM and combines a host of components to create a reference hardware design for integrators and developers to target moving forward. Featuring a test chip built around Cortex-A57 (dual core), Cortex-A53 (quad core) and Mali-T624 (quad core), Juno allows software to target 64-bit development immediately without waiting for other SoC vendors to have product silicon ready. The hardware configuration implements big.LITTLE, OpenGL ES3.0 support, thermal and power management, Secure OS capability and more. In theory, ARM has built a platform that will be very similar to SoCs built by its partners in the coming months.

ARM isn't quite talking about the specific availability of the Juno platform, but for the target audience ARM should be able to provide the amount of development platforms necessary. Juno enables software development for 64-bit kernels, drivers, and tools and virtual machine hypervisors but it's not necessarily going to help developers writing generic applications. Think of Juno as the development platform for the low level designers and coders, not those that are migrating Facebook or Flappy Bird to your next smartphone.

The Juno platform helps ARM in a couple of specific ways. From a software perspective, it creates common foundation for the ARMv8 ecosystem and allows developer access to silicon before ARM's partners have prepared their own platforms. ARM claims that Juno is a fairly "neutral" platform so software developers won't feel like they are being funneled in one direction. I'd be curious what ARM's partners actually think about that though with the inclusion of Mali graphics, a product that ARM is definitely trying to promote in a competitive market.

Though the primary focus might be software, hardware partners will be able to benefit from Juno. On this board they will find the entire ARMv8 IP portfolio tested up to modern silicon. This should enable hardware vendors to see A57 and A53 working, in action and with the added benefit of a full big.LITTLE implementation. The hope is that this will dramatically accelerate the time to market for future 64-bit ARM designs.

The diagram above shows the full break down of the Juno SoC as well as some of the external connectivity on the board itself. The memory system is built around 8GB of DDR3 running at 12.8 GB/s and the is extensible through the PCI Express slots and the FPGA options.

Of course hardware is only half the story - today Linaro is releasing a 64-bit port of the Android Open Source Project (AOSP) that will run on Juno. That, along with the Linux kernel v3.14 with ARMv8-A support should give developers the tools needed to write the applications, middleware and kernels for future hardware. Also worth noting on June 25th at Google I/O was the announcement of developer access coming for Android L. This build will support ARMv8-A as well.

The switch to 64-bit technology on ARM devices isn't going to happen overnight but ARM and its partners have put together a collective ecosystem that will allow the software and hardware developers to make transition as quick and, most importantly, as painless as possible. With outside pressure pushing on ARM and its low power processor designs, it is taking more of its fate in its own hands, pushing the 64-bit transition forward at an accelerated pace. This helps ARM in the mobile space, the consumer space as well as the enterprise markets, a key market for SoC growth.

If you have been holding off on purchasing Google's Nest thermostat because you didn't like the app that controls it or just were not overly interested in a thermostat that trys to learn your schedule; would you be more interested if you could root it? All it takes is physical access to the thermostat and a minute with it plugged into a USB port on a computer. Not only will this give you complete control over the hardware inside, you can also install an SSH server with a reverse SSH connection to bypass firewalls. It will be interesting to see how these rooted Nest's can interact with other pieces of hardware released by Google with the "Works with Nest" branding. Check out how to do this for yourself at Hack a Day.

"A few months ago, Google bought a $3.2 billion dollar thermostat in the hopes it would pave the way for smart devices in every home. The Nest thermostat itself is actually pretty cool – it’s running Linux with a reasonably capable CPU, and adds WiFi to the mix for some potentially cool applications. It can also be rooted in under a minute."

Docker has put the libcontainer execution engine of their Linux Containerization onto Github, making it much easier to adopt their alternative virtualization technology and modify it for specific usage scenarios. So far Google, Red Hat and Parallels have started adding their own improvements to the Go based libcontainer; adding to the Ubuntu dev team already at work. This collaboration should help containerization become a viable alternative to virtual machines and hopefully be included as a feature in future Linux distros. Read more over at The Register.

"Docker has spun off a key open source component of its Linux Containerization tech, making it possible for Google, Red Hat, Ubuntu, and Parallels to collaborate on its development and make Linux Containerization the successor to traditional hypervisor-based virtualization."

Today, Google announced their "Project Tango" developer kit for tablets with spatial awareness. With a price tag of $1,024 USD, it is definitely aimed at developers. In fact, the form to be notified about the development kit has a required check box that is labeled, "I am a developer". Slightly above the form is another statement, "These development kits are not a consumer device and will be available in limited quantities".

So yes, you can only buy these if you are a developer.

The technology is the unique part. Project Tango is aimed at developers to make apps which understand the 3D world around the tablet. Two examples categories they have already experimented with are robotics and computer vision. Of course, this could also translate to alternate reality games and mapping.

While Google has not been too friendly with OpenCL in its Android platform, it makes sense that they would choose a flexible GPU with a wide (and deep) range of API support. While other SoCs are probably capable enough, the Kepler architecture in the Tegra K1 is about as feature-complete as you can get in a mobile chip, because it is basically a desktop chip.

Google's Project Tango is available to developers, exclusively, for $1,024 and ships later this month.

Google creates two billion Linux containers a week which astute readers will realize implies that they can be created much more quickly than a VM. That is indeed the case, these Linux containers are very similar to Solaris Zones, BSD Jails and other similar ways of sharing parts of an OS across multiple isolated applications as opposed to VMs in which each machine has it's own OS. Even with prebuilt images it is orders of magnitude slower to create a VM than to simply create a new container. With the involvement of a startup called Docker, Google has really changed how they handle their systems; read about the impacts at The Register.

"That tech is called Linux Containerization, and is the latest in a long line of innovations meant to make it easier to package up applications and sling them around data centers. It's not a new approach – see Solaris Zones, BSD Jails, Parallels, and so on – but Google has managed to popularize it enough that a small cottage industry is forming around it."

On Friday, May 16th, Apple and Google (including the remains of its Motorola Mobility division) released a joint statement marking the end of all patent litigation between the two companies. The two companies have been in legal warfare for three-and-a-half years, now. The two companies will also "work together in some areas of patent reform". It is unclear what that actually means.

This decision does not seem to affect Apple's ongoing litigation with Samsung. Those two companies are still in a famous and fierce skirmish over mankind's greatest UX innovations, like slide-to-unlock and the little bounce that happens when you scroll to the end of a list too fast. Those are, honestly, the issues that we are facing. I have a suggestion for an area to reform...

... but that has been beaten to death for years, now. It, at least, shows a willingness to cooperate going forward. It also shows a slight bit more promise for products like Ubuntu on phones, Firefox OS, and even smaller initiatives. You can say what you like about the current litigation, but closing the road for independent developers with great and innovative ideas is terrible and bad for society. Unique smartphones could be made, each with slide-to-unlock, just like unique OSes can use icons and web browsers can use tabs.

Google has an offer for businesses that it hopes will be attractive enough to get them to abandon Windows complete instead of upgrading from WinXP to a new version of a Microsoft OS. They are offering businesses $100 off any managed Chromebook or other ChromeOS device and $200 if it will be running VMWare Desktop as a Service. For those who have to go through major upgrades and software re-writes this might be a reasonable alternative since these companies are less than pleased at the EOL of WinXP and now have an opportunity to try or at least test an alternative OS. It is unlikely that Windows will go the way of "tamagotchis and parachute pants" Google's Amit Singh is quoted as saying by The Inquirer but the demise of WinXP offers a unique opportunity for change to many businesses which has previously been economically unfeasable.

"GOOGLE HAS BEEN QUICK to jump on the demise of Windows XP, and is looking to persuade businesses still running the operating system to buy Google Chromebooks instead."

As time passes, the list of tasks which require native applications is diminishing. Legacy applications, which cannot be reprogrammed for copyright or development reasons, are still on a leash to their intended platform, however. Google knows that their customers want access to those programs and utilities. Virtualization is one of the easiest ways, especially since it is already happening.

Some will prefer native apps on a dedicated machine (and that is okay).

Google also notes that Windows XP is nearing its end of life. They claim that Chromebooks and virtualized Windows instances nullifies security vulnerabilities and compatibility woes. Of course, you are never perfectly secure but at least Google puts their money where their mouth is.