Nexus 5 v Galaxy S5, Usability v Specs and software's impact
Writing about web page http://www.theinquirer.net/inquirer/review/2343745/galaxy-s5-vs-nexus-5-video-review
Researching some hardware questions on ‘the Inquirer’ website, I spotted their video update of their Samsung Galaxy S5 v Nexus 5 specification comparison.
They rated the S5 better for power and camera auto-focus and the Nexus 5 better for the un-skinned KitKat, Android 4.4.2 OS.
I have seen the clearest advantage of this over the last week or so as one by one the household’s 3 Nexus devices, 2 LG Nexus 5s and an Asus Nexus 7, asked permission to be upgraded to Android 4.4.3. With all the security updates resulting from the heartbleed testing, I upgraded immediately.
The larger battery in the S5 was confirmed to do better in the Inquirer’s video-loop power test. Experience with the Nexus 5 has seen me getting 3 days between charges, with quite heavy Wi-Fi use. I use a couple of mobiles to test websites and have been testing 3 responsive sites recently.
The good power performance was helped by the excellent battery reporting settings screen that came with KitKat. It was easy to spot where power was wasted on features that I did not use.
I seems that 4.4.3 is also triggering power problems on roll-out and Sony among others are blaming Google. Yet the native Nexus platforms have fewer problems as these can be tested right from the start.
Years ago I upgraded Windows 3.1 on an ex-demo HP server. I ran a dream including drivers for the rare EISA bus and other HP specials. HP had donated their whole server range to Microsoft’s bunker of tethered test machines, so all the hardware options were expected.
In those days we were using both Intel x86 and Motorola 68000 processors in 2 variants of embedded single board computers. These ran a remote archive and load facility on the System X telephone exchanges. The benchmarks has the RISC 68000 way ahead for real-time software with a better cache architecture. The applications ran 5 times faster on the Intel initially. The bottleneck was in the Ethernet LAN driver code.
Hardware performance can be as dependent on the software as on the underlying hardware.