...but phone batteries are typically a single 3.7V cell lipo. The kind of failure you described from hoverboards shouldn't even be possible, unless the Note7 has a radically different battery.
That said, the charging circuit could still be at fault.
Basically, the TL;DR; version is that the most likely cause for Snapdragon 800/801 phones not getting Nougat is that they likely cannot pass the Android compatibility tests for Nougat for AES performance. They can't pass because the minimum specs are likely higher and they lack the necessary dedicated encryption hardware.
Nobody wanted to point fingers at Google, but the evidence seems to implicate them. Google needs to relax the compatibility specs for upgrading existing devices. Any device which passed the specs at release for a previous Android release should be grandfathered in as much as possible. We have enough problems with Android fragmentation from carriers and manufacturers--Google needs to help, not hurt.
I get better battery life on my Nexus 6 with Android 7 than before. Not much, mind you, but it's a little better.
That said, there are some issues... Cell standby consumed 880 mAh with the radio active for 10s. Somehow, I think that's got to be wrong...
I agree, though--the #1 thing I want is better battery life. And what's crazy is that I disabled the Google location services on my Nexus S and I get 4 DAYS of battery life between charges now (screen off nearly 100%). With Google Location services on, it only lasts ~6 hours. So I suspect Google itself is at fault for a lot of the battery drain.
I use an HP 4600DN. Yeah, it weighs a TON, and I had to have it shipped via pallet, but it's indestructible, Laser (no drying out), has compatible color cartridges, and it prints color.
The color quality for picture is good, but not amazing, and for documents it just works. I've had to buy one toner cartridge in the last 3 years. Works under Linux.
Getting a printer cartridge that didn't smear or leak, though, was an entirely other problem. The official HP ones cost $300 per cartridge, which is way too much, but most of the aftermarket ones leak or smear or have some random problem. I went through 4 cartridges to replace a single one (with the other 3 sent back as defective).
If it's truly this issue, you may be bending your phone or dropping it more than the average.
Are you storing your phone in your back pocket? Are you wearing tight jeans that is putting physical flex on the board? Sitting on the phone? If you are, you might be able to get them to last longer by avoiding those behaviors.
Note: I'm not defending Apple, or justifying their quality/phone/design. I'm just saying that, knowing what the cause is of this failure, a behavioral change could make a huge difference to your device longevity.
Firstly, you're correct. Nvidia was thermal expansion/contraction, while this is due to physical bending.
However, if you look at Louis Rossman's videos, the Nvidia issue was due to internal points WITHIN the chip, not due to the BGA points themselves. This means that simply reflowing the chip (or even resurfacing and resoldering the BGA) won't solve the issue. You NEED a new chip.
Heating the chip might slightly reflow the internal connections which may make the device work for a few days or even weeks, but it's going to fail very rapidly again.
The Apple issue is with the BGA points themselves, not inside the chip, which means that, as long as the points aren't super oxidized (as they were in Jessa's video), a reflow might resolve the issue. Fully resurfacing the BGA as Jessa did should completely resolve the issue, but Jessa replaced the chip anyway--I suspect the chip cost is low enough that putting a new chip on just makes more sense--just to make sure.
As a techie who actually has Google Fiber, it's been amazing. The first couple weeks were really rocky--random internet outages which were unexplainable.
They sent a tech out, who'd never seen anything like it, and he's like "well, I guess I'll replace the network box, because I have no idea what it is." Worked great ever since.
The only major disadvantage is they don't want you running your own router, and have actually hassled me for doing so. They offer just a fiber jack to businesses, but don't offer it for residential customers. Residential customers HAVE to use their "network box" (router). There are actually howtos on the internet of plugging into the fiber jack, if you have a managed switch and set the VLAN tags right.
My speeds:
I get 400 Mbit up/down over wireless (my own router)
I get 900 Mbit up/down wired
Speeds are constant, regardless of time of day, and no weird latency issues at all. I get a reliable 1ms ping to a friend who also has Google Fiber 15mi away, and I get very low pings to the rest of the world. It's hands down the best internet I've ever had. Customer service is friendly, too.
As someone who's done (minor) work on Tomato, I'd highly recommend a ASUS RT-N66U (cheaper) or RT-AC68U (nicer) instead.
At the time, the WRT54G(L) was a great router. I've still got two of them on the desk next to me. Don't buy them now.
1) Range: They don't have the range of more modern hardware like the ASUS routers I listed above
2) Dual-Band: They don't have 5GHZ, which is much faster and has less interference from Neighbors
3) Dropped Packets: The WRT54G has random dropped packet issues. Occasionally, it'll drop a wireless packet regardless of signal strength. With the RT-N66U, the packet loss went to 0%, over an entire night.
4) Stability: The WRT54G is very stable. That said, typically it locked up once every 6-12 months. I've yet to have a lockup on a configured RT-N66U or RT-AC68U running Tomato (shibby), with over 8 deployed for a number of years.
5) Speed: The WRT54G maxed out ~20Mbit (wired) and 6-12Mbit (wireless) running Tomato. The RT-N66U does around 50/225Mbit wireless/wired and the RT-AC68U pushes 400/900.
6) Storage/CPU: The CPU is a 15 year old design, and the storage is 4MB of flash. Modern open routers run CPUs that are massively faster and have 128+ MB flash.
They were wonderful routers, but it's time. Unless you're just doing it for the nostalgia, do yourself a favor and get something that uses the improvements that have been made in the last 14 years.
1) Why is interfering with drone operation below the altitude that manned air travel exists, within state boundaries, even within the purview of the federal government? This is clearly a states issue. The FAA already defined a 400 ft ceiling for drone usage and no-fly zones to prevent interference with manned air travel.
2) Why cannot individuals defend their privacy on their own property? If gun operation is allowed on their property normally, why is firing their gun at an intruder any more "reckless" than clay target practice?
3) Why are we talking about a 5 or 20 year JAIL sentence? Do they realize how much damage incarcerating people does to society and individual's lives? A felony and 5 year jail sentence can wreck entire lives. How is this appropriate for disrupting drone operation, especially over one's own property?
4) Why is someone shooting a drone on their property different than shooting an unoccupied vehicle trespassing on their property? These cases should be simply prosecuted under existing "destruction of property" statutes, which should not be felonies, and should not have multiple-year jail sentences.
Agreed. Apple is way ahead of Qualcomm, and has been for a number of years now. The 2.7 CPU in my Nexus 6 was barely competitive with the iPhone when it came out--with a 145% clockspeed advantage! With that clockspeed advantage, you'd expect the CPU to be way way faster.
There's also something to be said for Safari's performance relative to Android Chrome. The Nexus 6 beats the iPhone 6 in the BaseMark II OS - System benchmark by a good margin, but then loses in Sunspider by a factor of 2. There's obviously some significant room for improvement in either the Android or Chrome software stack (or both).
Did you even read the article I posted? By no means did I cherry pick a single benchmark.
From Anandtech's review, the following benchmarks show the iPhone is faster:
Kraken 1.1 (72%)
Octane v2 (68%)
WebXPRT (55%)
Basemark OS II 2.0 System (47%)
Basemark OS II 2.0 Web (7%)
Basemark OS II 2.0 Overall (3%)
The ONLY benchmark that showed it was slower were these two:
Basemark OS II 2.0 Graphics (14%)
Internal NAND Random Write (41%) -- It fared significantly better than the S7 on all other NAND performance metrics, including all read tests.
I decided to ignore the multicore power of the S7 because for most users, it doesn't matter. Most phone CPU usage is <2 cores, and therefore, it's a pointless statistic. In fact, Anandtech didn't even perform a review that exercised the multi-core CPU capabilities of the S7 compared to the iPhone 6s.
For web browsing, CPU absolutely does matter. Pages load faster with a faster CPU.
For video, your statements are correct. As long as you can render the frames faster than they are displayed, the CPU is fast enough. That's why I focused on web browsing as the metric that really matters, and that's where basically all of the phones fall short.
Okay, so graphics and Multithreaded are faster. But watching videos and web browsing are for more typical usecases for most people, and the Samsung loses heavily.
Look at the browser benchmarks in the page here: http://anandtech.com/show/1012...
The iPhone 6s is almost twice as fast as every other phone out there, and it came out nearly 6 months ago. I don't view the S7 as competitive, let alone faster. Other companies need to prioritize single-core performance as much as Apple. Multi-threaded performance isn't that big of a deal. This is a phone, not a server*.
-Android Fanboi and proud owner of a Nexus 6
*Yes, I know some power users out there utilize >2 cores on a regular basis. But most users (including myself) do not.
This doesn't sound onerous to me at all. It doesn't require anything in public documentation, help pages, or otherwise like the MIT license. It simply requires a single URL in a code comment.
This sounds perfectly fine to me--in general, I and my team already does this because it's helpful to know WHY we chose a course of action, especially when it was complicated enough to require SO's help.
A URL as a comment in your code is reasonable attribution.
There are certainly other forms of reasonable attribution, depending on use, and you are welcome to go above and beyond what’s required and include username, date, and anything else if you like.
You are also welcome to use the MIT License as it is traditionally interpreted: by preserving the full license with relevant fields (copyright year and copyright holder) completed.
Firefox only currently supports DHE with SHA1. Are they going add support for SHA256 DHE when they disable SHA1?
To quote Michael Staruch from the above link:
It looked more like attempts to discredit DHE and push everyone into ECC. And I am not so sure if that's best way to protect our privacy, especially with multiple TLS clients supporting only NSA Suite B curves.
Mozilla, we really need DHE to work with SHA256 and GCM. Sure, fallback to something else (with a second connection, if necessary) if weak dhparams are used by the server.
Firefox only currently supports DHE with SHA1. Are they going add support for SHA256 DHE when they disable SHA1?
To quote Michael Staruch from the above link: It looked more like attempts to discredit DHE and push everyone into ECC. And I am not so sure if that's best way to protect our privacy, especially with multiple TLS clients supporting only NSA Suite B curves.
Mozilla, we really need DHE to work with SHA256 and GCM. Sure, fallback to something else (with a second connection, if necessary) if weak dhparams are used by the server.
TLS does not. All EC curves in TLS are proposed by NIST, and possibly backdoored. You probably don't want to use EC crypto with HTTPS. http://slashdot.org/comments.p...
ECDH is possibly backdoored by the NSA. From what we know, DH is mathematically sound, provided you generate your own, large enough (2048b or larger) prime.
ECDH in TLS only uses curves proposed by NIST. Some cryptographers believe that constants used to pre-compute the curves are in fact backdoored, which would explain how they decrypt most of the traffic. Curve 25519 and a few others are very likely safe, but not available in TLS1.2. ALL available ECDH curves in TLS were proposed by NIST.
I believe that between precomputed ECDH curves and Logjam, the NSA is able to decrypt nearly https traffic.
https://www.schneier.com/blog/...
"I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry." - Bruce Schneier on ECDHE curves in TLS
I trust Bruce.
Ideally, the standards body would introduce curve 25519 to TLS1.2. Until then, server operators need to take this advice, configure their servers to prefer DHE (not EC) with 2k+ keys, and turn off older ciphers including EC*.
Yep. If you buy an object, you have every right to take it apart.
While I agree with the above statement (and some of your others), they didn't buy the devices. It was a developer preview provided to them under NDA. I think iFixit is clearly in the wrong here.
From the article: The developer unit we disassembled was sent to us by Apple. Evidently, they didn’t intend for us to take it apart. But we’re a teardown and repair company; teardowns are in our DNA—and nothing makes us happier than figuring out what makes these gadgets tick. We weighed the risks, blithely tossed those risks over our shoulder, and tore down the Apple TV anyway.
Slashdot Mirror
...but phone batteries are typically a single 3.7V cell lipo. The kind of failure you described from hoverboards shouldn't even be possible, unless the Note7 has a radically different battery.
That said, the charging circuit could still be at fault.
There's actually a pretty good writeup on this: http://www.androidauthority.co...
Basically, the TL;DR; version is that the most likely cause for Snapdragon 800/801 phones not getting Nougat is that they likely cannot pass the Android compatibility tests for Nougat for AES performance. They can't pass because the minimum specs are likely higher and they lack the necessary dedicated encryption hardware.
Nobody wanted to point fingers at Google, but the evidence seems to implicate them. Google needs to relax the compatibility specs for upgrading existing devices. Any device which passed the specs at release for a previous Android release should be grandfathered in as much as possible. We have enough problems with Android fragmentation from carriers and manufacturers--Google needs to help, not hurt.
I get better battery life on my Nexus 6 with Android 7 than before. Not much, mind you, but it's a little better.
That said, there are some issues... Cell standby consumed 880 mAh with the radio active for 10s. Somehow, I think that's got to be wrong...
I agree, though--the #1 thing I want is better battery life. And what's crazy is that I disabled the Google location services on my Nexus S and I get 4 DAYS of battery life between charges now (screen off nearly 100%). With Google Location services on, it only lasts ~6 hours. So I suspect Google itself is at fault for a lot of the battery drain.
I use an HP 4600DN. Yeah, it weighs a TON, and I had to have it shipped via pallet, but it's indestructible, Laser (no drying out), has compatible color cartridges, and it prints color.
The color quality for picture is good, but not amazing, and for documents it just works. I've had to buy one toner cartridge in the last 3 years. Works under Linux.
Getting a printer cartridge that didn't smear or leak, though, was an entirely other problem. The official HP ones cost $300 per cartridge, which is way too much, but most of the aftermarket ones leak or smear or have some random problem. I went through 4 cartridges to replace a single one (with the other 3 sent back as defective).
I'd also strongly recommend Nexus devices over Note devices. You get much better software upgrades and security updates.
If it's truly this issue, you may be bending your phone or dropping it more than the average.
Are you storing your phone in your back pocket? Are you wearing tight jeans that is putting physical flex on the board? Sitting on the phone? If you are, you might be able to get them to last longer by avoiding those behaviors.
Note: I'm not defending Apple, or justifying their quality/phone/design. I'm just saying that, knowing what the cause is of this failure, a behavioral change could make a huge difference to your device longevity.
Firstly, you're correct. Nvidia was thermal expansion/contraction, while this is due to physical bending.
However, if you look at Louis Rossman's videos, the Nvidia issue was due to internal points WITHIN the chip, not due to the BGA points themselves. This means that simply reflowing the chip (or even resurfacing and resoldering the BGA) won't solve the issue. You NEED a new chip.
Heating the chip might slightly reflow the internal connections which may make the device work for a few days or even weeks, but it's going to fail very rapidly again.
The Apple issue is with the BGA points themselves, not inside the chip, which means that, as long as the points aren't super oxidized (as they were in Jessa's video), a reflow might resolve the issue. Fully resurfacing the BGA as Jessa did should completely resolve the issue, but Jessa replaced the chip anyway--I suspect the chip cost is low enough that putting a new chip on just makes more sense--just to make sure.
Source (Louis Rossman):
https://www.youtube.com/watch?...
As a techie who actually has Google Fiber, it's been amazing. The first couple weeks were really rocky--random internet outages which were unexplainable.
They sent a tech out, who'd never seen anything like it, and he's like "well, I guess I'll replace the network box, because I have no idea what it is." Worked great ever since.
The only major disadvantage is they don't want you running your own router, and have actually hassled me for doing so. They offer just a fiber jack to businesses, but don't offer it for residential customers. Residential customers HAVE to use their "network box" (router). There are actually howtos on the internet of plugging into the fiber jack, if you have a managed switch and set the VLAN tags right.
My speeds:
I get 400 Mbit up/down over wireless (my own router)
I get 900 Mbit up/down wired
Speeds are constant, regardless of time of day, and no weird latency issues at all. I get a reliable 1ms ping to a friend who also has Google Fiber 15mi away, and I get very low pings to the rest of the world. It's hands down the best internet I've ever had. Customer service is friendly, too.
Thank you for a clear and descriptive explanation of the actual bug. This is why I've loved Slashdot all of these years.
At the time, the WRT54G(L) was a great router. I've still got two of them on the desk next to me. Don't buy them now.
They were wonderful routers, but it's time. Unless you're just doing it for the nostalgia, do yourself a favor and get something that uses the improvements that have been made in the last 14 years.
Unless you're china airlines flight 006:
https://en.wikipedia.org/wiki/...
Note: It SHOULDN'T cause that, no. But it has happened and could again. Failures during flight could cascade to worse events, and have before.
Ugh. Proofreading fail.
"why is firing their gun at an intruder" should be "why is firing their gun at an intruding drone"
1) Why is interfering with drone operation below the altitude that manned air travel exists, within state boundaries, even within the purview of the federal government? This is clearly a states issue. The FAA already defined a 400 ft ceiling for drone usage and no-fly zones to prevent interference with manned air travel.
2) Why cannot individuals defend their privacy on their own property? If gun operation is allowed on their property normally, why is firing their gun at an intruder any more "reckless" than clay target practice?
3) Why are we talking about a 5 or 20 year JAIL sentence? Do they realize how much damage incarcerating people does to society and individual's lives? A felony and 5 year jail sentence can wreck entire lives. How is this appropriate for disrupting drone operation, especially over one's own property?
4) Why is someone shooting a drone on their property different than shooting an unoccupied vehicle trespassing on their property? These cases should be simply prosecuted under existing "destruction of property" statutes, which should not be felonies, and should not have multiple-year jail sentences.
Note: I fly RC aircraft.
I want 130k ton to LEO!
/pedantic
https://en.wikipedia.org/wiki/...
Put one of those suckers in ORBIT!
Agreed. Apple is way ahead of Qualcomm, and has been for a number of years now. The 2.7 CPU in my Nexus 6 was barely competitive with the iPhone when it came out--with a 145% clockspeed advantage! With that clockspeed advantage, you'd expect the CPU to be way way faster.
There's also something to be said for Safari's performance relative to Android Chrome. The Nexus 6 beats the iPhone 6 in the BaseMark II OS - System benchmark by a good margin, but then loses in Sunspider by a factor of 2. There's obviously some significant room for improvement in either the Android or Chrome software stack (or both).
Did you even read the article I posted? By no means did I cherry pick a single benchmark.
From Anandtech's review, the following benchmarks show the iPhone is faster:
Kraken 1.1 (72%)
Octane v2 (68%)
WebXPRT (55%)
Basemark OS II 2.0 System (47%)
Basemark OS II 2.0 Web (7%)
Basemark OS II 2.0 Overall (3%)
The ONLY benchmark that showed it was slower were these two:
Basemark OS II 2.0 Graphics (14%)
Internal NAND Random Write (41%) -- It fared significantly better than the S7 on all other NAND performance metrics, including all read tests.
I decided to ignore the multicore power of the S7 because for most users, it doesn't matter. Most phone CPU usage is <2 cores, and therefore, it's a pointless statistic. In fact, Anandtech didn't even perform a review that exercised the multi-core CPU capabilities of the S7 compared to the iPhone 6s.
For web browsing, CPU absolutely does matter. Pages load faster with a faster CPU.
For video, your statements are correct. As long as you can render the frames faster than they are displayed, the CPU is fast enough. That's why I focused on web browsing as the metric that really matters, and that's where basically all of the phones fall short.
Okay, so graphics and Multithreaded are faster. But watching videos and web browsing are for more typical usecases for most people, and the Samsung loses heavily.
Look at the browser benchmarks in the page here:
http://anandtech.com/show/1012...
The iPhone 6s is almost twice as fast as every other phone out there, and it came out nearly 6 months ago. I don't view the S7 as competitive, let alone faster. Other companies need to prioritize single-core performance as much as Apple. Multi-threaded performance isn't that big of a deal. This is a phone, not a server*.
-Android Fanboi and proud owner of a Nexus 6
*Yes, I know some power users out there utilize >2 cores on a regular basis. But most users (including myself) do not.
This doesn't sound onerous to me at all. It doesn't require anything in public documentation, help pages, or otherwise like the MIT license. It simply requires a single URL in a code comment.
This sounds perfectly fine to me--in general, I and my team already does this because it's helpful to know WHY we chose a course of action, especially when it was complicated enough to require SO's help.
http://meta.stackexchange.com/...
What is reasonable attribution?
A URL as a comment in your code is reasonable attribution.
There are certainly other forms of reasonable attribution, depending on use, and you are welcome to go above and beyond what’s required and include username, date, and anything else if you like.
You are also welcome to use the MIT License as it is traditionally interpreted: by preserving the full license with relevant fields (copyright year and copyright holder) completed.
https://bugzilla.mozilla.org/s...
Firefox only currently supports DHE with SHA1. Are they going add support for SHA256 DHE when they disable SHA1?
To quote Michael Staruch from the above link: It looked more like attempts to discredit DHE and push everyone into ECC. And I am not so sure if that's best way to protect our privacy, especially with multiple TLS clients supporting only NSA Suite B curves.
Mozilla, we really need DHE to work with SHA256 and GCM. Sure, fallback to something else (with a second connection, if necessary) if weak dhparams are used by the server.
https://bugzilla.mozilla.org/s...
Firefox only currently supports DHE with SHA1. Are they going add support for SHA256 DHE when they disable SHA1?
To quote Michael Staruch from the above link:
It looked more like attempts to discredit DHE and push everyone into ECC. And I am not so sure if that's best way to protect our privacy, especially with multiple TLS clients supporting only NSA Suite B curves.
Mozilla, we really need DHE to work with SHA256 and GCM. Sure, fallback to something else (with a second connection, if necessary) if weak dhparams are used by the server.
SSH has support for 25519 ECDHE, which is great.
TLS does not. All EC curves in TLS are proposed by NIST, and possibly backdoored. You probably don't want to use EC crypto with HTTPS.
http://slashdot.org/comments.p...
ECDH is possibly backdoored by the NSA. From what we know, DH is mathematically sound, provided you generate your own, large enough (2048b or larger) prime.
ECDH in TLS only uses curves proposed by NIST. Some cryptographers believe that constants used to pre-compute the curves are in fact backdoored, which would explain how they decrypt most of the traffic. Curve 25519 and a few others are very likely safe, but not available in TLS1.2. ALL available ECDH curves in TLS were proposed by NIST.
I believe that between precomputed ECDH curves and Logjam, the NSA is able to decrypt nearly https traffic.
https://www.schneier.com/blog/...
"I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry." - Bruce Schneier on ECDHE curves in TLS
I trust Bruce.
Ideally, the standards body would introduce curve 25519 to TLS1.2. Until then, server operators need to take this advice, configure their servers to prefer DHE (not EC) with 2k+ keys, and turn off older ciphers including EC*.
Oh, and get firefox to fix this bug: https://bugzilla.mozilla.org/s...
Yep. If you buy an object, you have every right to take it apart.
While I agree with the above statement (and some of your others), they didn't buy the devices. It was a developer preview provided to them under NDA. I think iFixit is clearly in the wrong here.
From the article:
The developer unit we disassembled was sent to us by Apple. Evidently, they didn’t intend for us to take it apart. But we’re a teardown and repair company; teardowns are in our DNA—and nothing makes us happier than figuring out what makes these gadgets tick. We weighed the risks, blithely tossed those risks over our shoulder, and tore down the Apple TV anyway.
Just to be clear, you're proposing a nearly $6 billion raise to the settlement payout offset by a $.038b reduction in payment to the lawyers.
Regardless if the proposed settlement amount is fair, the lawyer payment reduction basically would have no effect.