3 ms·

Dianne's response to the recent "AOSP is unusable" silliness is pretty solid: http://www.hnwatcher.com/r/734444/Google-s-Dianne-Hackborn-comments-on-Ars-s-Andro

Dianne's response to the recent "AOSP is unusable" silliness is pretty solid: http://www.hnwatcher.com/r/734444/Google-s-Dianne-Hackborn-comments-on-Ars-s-Android-open-sourceness-FUD-piece http://www.hnwatcher.com/r/734444/Google-s-Dianne-Hackborn-c... Regarding drivers, we expended a lot of effort to push things as open as we could. We never shipped any binary kernel drivers for any lead devices, something which most OEMs and silicon vendors seem to have stuck with. We insisted on linux-on-the-metal instead of solutions where it would be virtualized under a closed hypervisor that had the "real" drivers and other such insanity. GPU drivers have been the biggest uphill battle -- getting all the vendors to agree to GPLv2 kernel components to handle resource management and ensure that userspace is not directly poking the hardware, alongside their "secret sauce" in userspace was better than nothing and better than closed binary kernel components, but not ideal. It seems like we're finally seeing some motion in this area. Watching Nokia, Amazon, Barnes & Noble, and others take AOSP from its git repositories and build full products on top of it is, I think, among the best evidence that there's an awfully useful base platform there. If people were to augment that with open source alternatives to various Google (or other) cloud services, that would be cool. And of course folks can take AOSP as a base and extend or modify it however they like in a fully open way -- follow the model of cyanogenmod that's been tracking AOSP and adding their own enhancements, goodies, or platform support on top of it, for example...

pjmlp 13y ago
Except other than a minority, no users will care if they don't get access to Google services.
Spearchucker 13y ago
Your points are noted, and I agree with you. But I'm not convinced by Dianne's post. Big red flag is what on earth you need cloud for to provide a location service? And mail? An MTU is a client app by definition. Open implies supporting popular protocols - that hardly creates a dependency on Gmail. The biggest issue of all though is how most apps are virtually unusable without an internet connection. That, in the real world, happens a hell of a lot more often than people like Dianne care to realise. I call bullshit. Her post is as biased as the posts she's responding to.
- ZeroGravitas 13y ago
  The reason you need tho cloud for location service is because you can save user time and battery by doing a lookup based on nearby wifi points, a database of which is stored in the cloud. Relevantly, Mozilla are trying to build an open one of these. https://blog.mozilla.org/services/2013/10/28/introducing-the-mozilla-location-service/ https://blog.mozilla.org/services/2013/10/28/introducing-the... Though privacy issues make it complicated for people to just download the data, rather than make a call to the cloud. Those who object to the whole idea of this will probably just have to accept slower lookups. I'm not sure what you're saying with your other points, I would have thought a GMail app would be expected to have a dependency on GMail. The Email app (which Ars claimed was abandoned, yet just got a overhaul) is there for communicating over popular protocols to non-Google services.
  - Spearchucker 13y ago
    I use a normal (non-Gmail dependent) MTU for my Gmail. What user need does the Gmail-dependent MTU from Google fulfill that warrants that dependency? As far as I can tell, my non-Google MTU adds more functionality to GMail than GMail has. As for AGPS - great. But we already know that location services function quite well without it. Did you know that you can do AGPS and drastically reduce time to fix just by initializing a GPS receiver using your last known location? AGPS with a location obtained from a WiFi SSID (via a call to the cloud) is only faster when your last known location is drastically different to your current location (another state, or country). I won't believe that Google is incapable of designing a location API that's extensible. There's a non-technical reason, and that reason is in conflict with the openness Google likes to play up.

pjmlp 13y ago

Except other than a minority, no users will care if they don't get access to Google services.

Spearchucker 13y ago

Your points are noted, and I agree with you. But I'm not convinced by Dianne's post. Big red flag is what on earth you need cloud for to provide a location service? And mail? An MTU is a client app by definition. Open implies supporting popular protocols - that hardly creates a dependency on Gmail. The biggest issue of all though is how most apps are virtually unusable without an internet connection. That, in the real world, happens a hell of a lot more often than people like Dianne care to realise. I call bullshit. Her post is as biased as the posts she's responding to.

ZeroGravitas 13y ago
The reason you need tho cloud for location service is because you can save user time and battery by doing a lookup based on nearby wifi points, a database of which is stored in the cloud. Relevantly, Mozilla are trying to build an open one of these. https://blog.mozilla.org/services/2013/10/28/introducing-the-mozilla-location-service/ https://blog.mozilla.org/services/2013/10/28/introducing-the... Though privacy issues make it complicated for people to just download the data, rather than make a call to the cloud. Those who object to the whole idea of this will probably just have to accept slower lookups. I'm not sure what you're saying with your other points, I would have thought a GMail app would be expected to have a dependency on GMail. The Email app (which Ars claimed was abandoned, yet just got a overhaul) is there for communicating over popular protocols to non-Google services.
- Spearchucker 13y ago
  I use a normal (non-Gmail dependent) MTU for my Gmail. What user need does the Gmail-dependent MTU from Google fulfill that warrants that dependency? As far as I can tell, my non-Google MTU adds more functionality to GMail than GMail has. As for AGPS - great. But we already know that location services function quite well without it. Did you know that you can do AGPS and drastically reduce time to fix just by initializing a GPS receiver using your last known location? AGPS with a location obtained from a WiFi SSID (via a call to the cloud) is only faster when your last known location is drastically different to your current location (another state, or country). I won't believe that Google is incapable of designing a location API that's extensible. There's a non-technical reason, and that reason is in conflict with the openness Google likes to play up.