Subject: General Tech | September 22, 2014 - 05:15 PM | Scott Michaud
Tagged: google, google+
I cannot help but feel like this is a step on the eventual phasing-out of Google's most recent attempt at a standalone social network, Google+. Until just recently, the company was doing all that they could to force it into each of their services; now, they give you a "no thanks" option when creating a Google account (for GMail, Google Docs, and so forth).
Image Credit: Marketing Land
Marketing Land claims to disagree. They expect that Google will "continue making subtle changes to the service" such as enhancements to Hangouts and Hangouts on Air, or even spinning out Google+ Photos. The thing is, these initiatives will not mean that they are supporting Google+; rather, it says that they are supporting the parts of it that worked. The article did not even mention actual Google+, the social network, as something that Google might consider updating -- just Hangouts and other sub-products.
This all depends on what you consider "Google" to be. Not having a profile on a message-sharing service does not really change much, despite how it feels. The real point should be reducing the barrier-to-entry for cross-promotion. A unified login helps in reducing effort to acquire new users without any real risk. Forcing users into your ecosystem could help, if it does not shove them away.
And Google seems to care even less about keeping users in their eco-system with a limited communication and microblogging platform.
Subject: General Tech | September 20, 2014 - 02:33 PM | Scott Michaud
Tagged: chrome os, chrome, google, Android
Last week, we reported on Google's App Runtime for Chrome (ARC) beta release. Its goal is to bring apps from the Google Play Store to ChromeOS through an Android stack built atop Native Client. They are sandboxed, but still hardware-dependent for performance. Since then, vladikoff on GitHub has published ARChon, a project which brings that initiative to desktop OSes.
Image Credit: ARChon Project
To use Archon, you will need to use an x86-64 version of Chrome 37 (or later) on Windows, Mac, or Linux. This project is not limited to the handful of ARC-compatible apps that Google officially supports. The Android apps need to be converted into Chrome extensions using a tool, also available, called chromeos-apk. In fact, the example app is an open source version of the game, 2048, rather than just the four launch apps from Google.
Whether Google intends to offer this, officially, with their Chrome browser is the most interesting part for me. I would prefer that everything just works everywhere but, failing that, having a supported Android platform on the desktop without dual-booting or otherwise displacing the host itself could be interesting. And yes, Bluestacks exists, but it has not been something that I would recommend, at least in my experience of it.
Subject: General Tech, Mobile | September 17, 2014 - 05:03 PM | Scott Michaud
Tagged: google, Android, android one
In much the same way as FirefoxOS is targeting foreign markets with low-cost phones, with the Intex Cloud Fx as the extreme example, Google is pushing for the overseas markets with Android One. Based on Android 4.4 and updated as new versions launch, for up to two years at least, the devices will not be old and outdated.
In terms of hardware, the platform is said to feature front and rear cameras, a quad-core processor, a microSD card slot, and dual SIM slots. Google has several partners involved with the initiative: Acer, Airtel, Alcatel, ASUS, HTC, Intex, Karbonn, LAVA, Lenovo, MediaTek, Cromax, Panasonic, Qualcomm, Spice, and Xolo. Besides a baseline standard, and a bit of marketing, there does not seem to be much to the platform itself.
Of course, delivering a quality standard, at an affordable price, to places which normally cannot obtain smartphones at all is noteworthy.
Subject: General Tech, Systems, Mobile | September 13, 2014 - 05:52 PM | Scott Michaud
Tagged: google, chrome os, Android
To some extent...
This is not the entire Google Play Store; in fact, it is just four Android apps at launch: Duolingo, Evernote, Sight Words, and Vine. According to a Google spokesperson, via Ars Technica, the company built an Android platform on top of Native Client, which is their way of sandboxing (a subset of) native code for use in applications which require strict security (such as a web browser). Android apps can then see and use those platform-dependent Android APIs, but be kept at two arms-lengths away from the host system.
From the app's standpoint, code will not need to be changed or ported. Of course, this is sound in theory, but little bugs can surface in actual practice. In fact, Flipboard was demonstrated at Google I/O under this initiative but is curiously absent from launch. To me, it seems like a few bugs need to be resolved before it is deemed compatible (it is dubbed "Beta" after all). Another possibility is that the app was not yet optimized for a Chromebook's user experience. Claiming either would be pure speculation, so who knows?
Android apps using App Runtime for Chrome (Beta) are available now at the Chrome Web Store.
Subject: Mobile | September 9, 2014 - 01:00 PM | Ryan Shrout
Tagged: tablet, reference design program, Intel, idf 2014, idf, google, aosp, Android
During today's keynote of the Intel Developer Forum, Google and Intel jointly announced a new program aimed to ease the burden of Android deployment and speed up the operating system update adoption rates that have often plagued the ecosystem.
In today's Android market, whether we are talking about x86 or ARM-based SoC designs, the process to release a point update to the operating system is quite complicated. ODMs have to build unique operating system images for each build and each individual SKU has to pass Google Media Services (GMS). This can be cumbersome and time consuming, slowing down or preventing operating system updates from ever making it to the consumer.
With the Intel Reference Design Program, the company will provide it's partners with a single binary that allows them to choose from a pre-qualified set of components or a complete bill of materials specification. Obviously this BOM will include Intel x86 processors like Bay Trail but it should help speed up the development time of new hardware platforms. Even better, OEMs and ODMs won't have to worry about dealing with the process of passing GMS certification leaving the hardware vendor to simply release the hardware to the market.
But, an even bigger step forward, is Intel's commitment on the software side. Everyone knows how fragmented the Android OS market with just 20% of the hardware on the Play Store running Android KitKat. For devices built on the Reference Design Program, Intel is going to guarantee software updates within 2 weeks of AOSP (Android Open Source Project) updates. And, that update support will be given for two years after the release of the launch of the device.
This combination of hardware and software support from Intel to its hardware ODMs should help ignite some innovation and sales in the x86 Android market. There aren't any partners to announce support for this Reference Design Program but hopefully we'll hear about some before the end of IDF. It will be very interesting to see what ARM (and its partners) respond with. There are plenty of roadblocks holding back the quick uptake of x86 Android tablets but those companies would be blind to ignore the weight that Intel can shift when the want to.
Subject: General Tech | August 25, 2014 - 06:49 PM | Scott Michaud
Tagged: amazon, twitch, twitch.tv, google
Well this is a surprise (and I think a pleasant one). We were under the impression that YouTube, the video distribution arm of Google, was planning to purchase Twitch for $1 billion USD (pending regulatory approval). Today, it was made official: Amazon would be purchasing the video streaming platform. Twitch's CEO, Emmett Shear, published an open letter to their community with a message of thanks and a confirmation of Amazon's acquisition.
I guess "eSports" is ready for... Prime time.
Twitch did not mention their value, but don't worry -- Amazon published a press release. The retail and infrastructure giant will pay $970 million in cash. The entire deal is expected to finalize "in the second half of 2014". Since we are already in the second half of 2014, that means any time between now and New Year's (assuming "Calendar 2014").
On the copyright front, I believe this is a major step forward. We originally feared that YouTube, and its parent company, Google, would impose a similar system to their own upon Twitch, to appease copyright owners. This is a problem because YouTube's copyright complaint system is plagued with abuse. I hope that Amazon and Twitch will be more friendly to potential, unproven infringers than YouTube has demonstrated itself to be.
Lastly, Amazon has a big, existing business in web infrastructure and online content delivery. Whether you look from the angle of Prime Video or Amazon Web Services (EC2, CloudFront, etc.), the company can handle sending bits from one place to another. They seem to be a good fit on on that front.
If there was any doubt that Amazon wants to be a big part of the gaming industry, it is gone.
Subject: General Tech, Mobile | July 16, 2014 - 04:11 AM | Scott Michaud
Tagged: google, google play, Android, android l
If you have looked at Google's recent design ideologies, first announced at Google I/O 2014, you will see them revolve around skeuomorphism in its most basic sense. By that, I do not mean that they want to make it look like a folder, a metal slab, or a radio button. Their concept is that objects should look like physical objects which behave with physical accuracy, even though they are just simulations of light.
Image Credit: Android Police (and their source)
Basically, rather than having a panel with a toolbar, buttons, and columns, have a background with a page on it. Interface elements which are affected by that panel are on it, while more global actions are off of it. According to Android Police, who make clear that they do not have leaked builds and readers should not believe anything until/unless it ships, the Google Play Store will be redesigned with this consistent, albeit broad, design metric.
Basically, if you are navigation bar, pack your desk and get out.
If true, when will these land? Anyone's guess. One speculation is that it will be timed with the release of Android "L" in Autumn. Their expectation, however, is that it will be one of many updates Google will make across their products in a rolling pattern. Either way, I think it looks good... albeit similar to many modern websites.
Subject: General Tech, Graphics Cards, Mobile, Shows and Expos | July 7, 2014 - 04:06 AM | Scott Michaud
Tagged: tegra k1, OpenGL ES, opengl, Khronos, google io, google, android extension pack, Android
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."
Image Credit: Blogogist
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.
Would I do anything with the two skipped letters before pie? (N)(O).
Subject: General Tech | July 3, 2014 - 12:39 PM | Jeremy Hellstrom
Tagged: linux, linaro, juno, google, armv8-a, ARMv8, arm, Android
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."
Here is some more Tech News from around the web:
- Running Cisco's VoIP manager? Four words you don't want to hear: 'Backdoor SSH root key @ The Register
- Latest Nexus 9 leak outs tablet's 5GB RAM, 2560x1600 screen @ The Inquirer
- Twitter takes on GOOGLE, swallows wannabe YouTube firm @ The Register
- Samsung will halt plasma TV production before the end of the year @ The Inquirer
- Previously male-only Hearthstone competition now open to all genders @ Polygon
Subject: Mobile | July 2, 2014 - 12:00 PM | Ryan Shrout
Tagged: linux, linaro, juno, google, armv8-a, ARMv8, arm, android l
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.