Please create an account to participate in the Slashdot moderation system


Forgot your password?
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:A pattern emerges (Score 1) 163

I've been meaning to reply for some time; feel free to e-mail me as I know this discussion will be archived soon.

You're right that Google has relatively little control over Samsung. What they do have is control over the Android trademark, etc., and if Google can require that the Play Store be within one swipe's distance of the home screen when shipped, Google can make other requirements that reflect dedication to ensuring that devices are able to be flashed with AOSP software.

Those requirements are subject to negotiation. Google has some power to push, not based on the Android trademark so much as on the permission to install the Google Apps -- and especially the Play store. The Play store is the big carrot/stick, actually, because an Android phone without the Play store is much, much less useful... at present. It wouldn't be that difficult for Samsung to set up their own app store, and app developers would absolutely upload their apps to it because Samsung is such a huge part of the Android ecosystem. If Samsung were to form an alliance with the top two or three other Android OEMs, their app store would very quickly replace Play as the dominant app store, particularly if they also set out to license all the videos and music they need to reach full parity with the content on Play. Or perhaps they'd take a shorter path: Team up with Amazon which has already done most of this work. If new Samsung, HTC, Motorola and LG phones all shipped with the Amazon store, Amazon would almost immediately match Play.

So Google has to walk a fine line. It has to keep all of the OEMs moving in the same direction, make sure that direction keeps the ecosystem competitive with Apple and Windows (not that Windows has much of the market at the moment) which means making sure the user experience is good and continues to improve, but it also has to allow OEMs enough freedom to innovate and manage their business models so they don't feel like being part of Google's ecosystem is more of a burden than a benefit.

I don't really understand why OEMs seem to feel so strongly that their devices should be locked down, but they do, and they're unwilling to negotiate on this point.

Unless I misunderstand how the Nexus system works, Google *does* have say over how those function, and those have a locked bootloader

So, I think your fundamental error here is that you're thinking locked bootloaders are a bad thing. They're not. They're a good thing.

Locked bootloaders (the way Nexus does them, at least) are there for user security. The purpose of the lock isn't to prevent users from flashing software that does what they want, it's to prevent attackers from flashing software that does what they want -- to give them access to data on the device, bypassing all of the protections built into the stock OS. So, the reason there is an "unlock" step is so that we have an opportunity to forcibly wipe all user data from the device. Someone who finds or steals your locked phone can unlock it (maybe; we made that a little harder in Lollipop), but the unlock process wipes all of your data.

This, BTW, is why I always tell modders that they should re-lock their bootloader after they flash their custom image. Not re-locking it allows anyone who gets hold of their device to flash a new system image that gives them full access to anything on the device (though we're tightening that down in Nougat as well).

That's the main purpose for a locked bootloader, but there are some other benefits as well. They protect devices against inadvertent as well as malicious modification, and they provide a good way to differentiate between a normal device that should implement the full boot chain of trust and those that are in a modifiable state. The vast majority of users never want or need to unlock, and we want to make things very secure for them. Developers (including Android engineers at Google!) and modders do want/need to bypass many of those security protections, so it makes a lot of sense to have a boolean switch that changes between "production device" and "development device" modes.

As for the fuse that the article claims records whether the device has ever been unlocked... that I don't know anything about. I'm sure it's not something that the Nexus team ever asked Qualcomm for. Our requirements to the OEMs who build Nexus devices are that the devices have unlockable bootloaders, and we specify how those should behave. We don't care if a device has been unlocked in the past or not, just about its current state. However, Qualcomm doesn't develop firmware specifically for Nexus devices, and other OEMs do care about whether or not a device has been unlocked. So my guess is that that Qfuse is a Qualcomm feature that has implications on other devices (most likely, unlocking just voids warranties, since flashing bad firmware can damage hardware -- come to think of it, it's possible that if you return a Nexus device for warranty repair/replacement, and the damage is something that could have been cause by bad firmware, and that fuse is blown... maybe you won't get warranty support for your Nexus either).

If Google decides to mandate locked bootloaders or bring an end to the work done by the folks at XDA-Dev, there's just no reason whatsoever for them not to...and that does, in fact scare me.

I do understand your fear. All I can tell you is that the Android engineering team feels quite strongly that users should own their own devices, which means they should be able to install their own software. Probably the best way to see how the Google team feels about it is to look at the Pixel C, which is the first device from Google that uses a Google-provided bootloader. The Pixel C's entire boot sequence is all open source code, and there's a physical switch in the device (modeled very much on the Chromebook "dev mode screw") which allows you to take complete control... after flipping that switch you can flash any part of the system up to and including providing your own implementation of the TrustZone OS. Note, though that your custom trusted OS will not have access to the DRM keys needed to decrypt HD and 4K video from Netflix, etc.

For that matter, if you want to see how Google's engineers look at these things, take a look at how Chromebooks work. Unlike Android, the Chromebook architecture is completely under Google's control. Chromebooks are built by various vendors, but Google's relationship with them is very different, and Google can dictate exactly how they work, within the constraints of the available components.

Comment Re:Cant say i'm surprised (Score 1) 308

I don't understand why people think AVRs need to be programmed in Arduino-C++ dumbed-down. avr-gcc (WinAVR on windows) is extremely nice to use and doesn't hold your hand. True C (or C++, if you like) programming.

I don't think anyone thinks they have to be programmed in Arduino C++, but the tools work well, so why look any further? What do you actually gain with avr-gcc?

Comment Re:As a C programmer (Score 2) 308

If you stick to a C-only subset of C++ you can write your library in C++, but at that point why bother with C++ anyway?

Or you could write your library in C++ but put it behind a C interface. Then you can use all of the expressive power of C++ internally, and provide an API that can be called from any language. And it will still be very close to as portable as if it were written in plain C, because we now have decent C++ compilers on very nearly every platform.

Comment Re: This is an Android Problem (Score 1) 162

I wish that there were more phones running plain Android with fast updates.

This article is exactly what we need to make that happen, though ideally we need it to be on CNN, not just Ars. But Ars is a good step. When consumers demand good update policies, manufacturers will provide them. It's a competitive market.

Actually, I think we're further down that road than it may appear. Stagefright was a big kick in the butt for the Android ecosystem. Not because it actually affected any real users, but because it got a *lot* of press. I think many OEMs have realized they need to fix their update problems, because consumers are beginning to care. The problem is that the OEMs product plans for the last few years have not included plans for monthly updates. Planning for that sort of update cycle requires them to change a lot of things in the way they do business. One is closely related to what you mentioned about carrier-specific builds: The OEMs just have too danged many products. It's not uncommon that what appears to the end user as a single model (e.g. Samsung Note 4) is actually one or two *dozen* different devices... each with its own software build. Not because they actually need that many SKUs and not because all of them actually need different software, it's just been easier to do it that way. Now that the pressure to provide updates is being turned up, I think they're looking at how to streamline their product lines and processes to make it more feasible to deliver them. Oh, and they also have to build the cost of the update-related work into their business plans.

However, building phones is a complex process, and device design and planning cycles often run more than two years, so it takes time for changes in approach to reach the market. I think it'll start getting a lot better in the next 1-2 years.

That's why I'm just sticking with Nexus phones.

Me too. Of course, in my case it helps that I get them for free :-)

Comment Re:Missing a big point (Score 1) 603

Of course you didn't talk at all about "handling the current situation" you talked about "self driving" which isn't actually related at all.

I actually don't agree with that, though that's Tesla's position. I don't think semi-autonomous driving is realistic. Once the car can drive itself sufficiently well that people feel safe looking away to text or whatever, they will. Any system that expects that a human will continue paying attention and be ready to take over at a moment's notice is asking for trouble.

Comment Re:An important thing to note (Score 1) 613

I can't find one either - I moved out of the states ~20 years ago, and I have NEVER paid that much taxes since then, and much nicer (larger) houses.

NJ property taxes are insane, definitely. They've been insane for a long time, though, so I don't think they're evidence of federal taxes being shifted to the state level.

Comment Re:Missing a big point (Score 1) 603

Nice job of focusing on word choice and ignoring the point. The GP claimed that this would be studied and a fix for the current system would be pushed out, making it safer. My point is that I don't think the car has the sensors needed to handle this scenario, so it's not possible to push a fix to the current system.

Comment Re:Location from Wifi? (Score 1) 109

GPS does not work better with WiFi enabled

Actually, your GPS receiver can pinpoint your location more rapidly if it has a good approximate location to start with, which it can get from Wifi location. If your GPS receiver had to start from scratch (no assumption about initial location), it could take multiple minutes to locate you because it has to find and identify multiple satellites, and listen for a full 30-second cycle from each. With a good location estimate plus an already-synchronized clock, the GPS receiver can refine your location in a few seconds.

So GPS does work better with Wifi enabled. And, as you said, location services can use Wifi even when GPS isn't available. In cities Wifi can be much better than GPS because unobstructed views of the sky are hard to come by, and the Wifi AP density is high.

Comment Re:Missing a big point (Score 1) 603

Tesla will make some changes to ensure that this type of accident is avoided in the future, and push at the next update.

I'm not sure that's possible. I think the biggest part of the problem in this case is that the sensor hardware on the Tesla Model S is inadequate for self-driving. The radar doesn't have vertical resolution so it can't determine whether there's enough clear space under an obstacle, and the camera can't resolve differences between a light gray truck and a light gray sky. To fix this you need either dramatically better vision processing software (which may well require better on-board computing hardware), or better sensors -- e.g. LIDAR.

Slashdot Top Deals

Writing software is more fun than working.