Live data from Hacker News

Google says Nexus One too old for Android 4.0

electronista.com

131–140 of 145 posts

Re: Google says Nexus One too old for Android 4.0

#131

I've got both the Nexus One and an iPhone 4 and I can never understand why anyone would choose the Nexus One over an iPhone, it's such an inferior product both hardware and software wise. The comparatively poor quality as put me off anything but iPhones.

It's cheaper, much cheaper data plans available. It's unlocked and you can take it overseas, pop in a SIM you got in the airport for $10 and have voice and data in your local country. Gmail is better than Apple Mail. Maps app is better. Has wifi hotspot and carriers can't prevent tethering.

Those are the reasons I chose a N1 over the 3gs that was available at the time. Now that Apple is releasing a truly unlocks 4s I'm taking a serious look.

Re: Google says Nexus One too old for Android 4.0

#132
post #128

Earlier quoted context omitted.

And iOS doesn't do that? Let me get this conversation straight.. Someone says that it's strange that android is so large. Someone else says iOS is big too. Then someone comes in to say that they are not large, they just suck at getting the compress/encrypt issue right. No one, other than obtino, thinks that it was simply a mistake that Xuzz put 'then' in his/her post?

It's compressed after encryption, so the effects of the compression is minimal. I believe that my post was correct: due to the effects of the encryption, the compression is almost useless, rendering the large iOS file size essentially equivalent to the size when installed to disk. That's all.

This is correct, and yet at the same time I believe it is incorrect. I am totally willing to believe I'm wrong here, though (as it has been two years since I actually did this process manually). I will explain. ;P

So, it is my understanding that an IPSW file is a ZIP archive containing a number of files, the largest one being where the main filesystem is stored. This file is encrypted, and does not compress very well at all.

However, that file is itself a dmg (Apple disk image) file, which is a compressed file format: a dmg is a compressed HFS+ image. Therefore, the encryption is happening after the compression.

Therefore, I do not believe it is accurate to claim that this is key to the problem. While it is humorous that the files are being compressed, encrypted, and then compressed again, that is not what is causing them to fail to compress: the first compression should work.

Instead, if we go one level deeper, we can ask the question "what is Apple even storing on this filesystem", and the answer is "maybe one or two hundred megabytes of executable code, and a few hundred megabytes of graphics".

The images are stored as PNG and JPEG: file formats that are already compressed. We therefore would not expect the version in the final output file to be much smaller than that on the filesystem. These files are, in essence, being compressed, compressed, encrypted, and compressed. ;P

The executable code, meanwhile, really doesn't compress well with algorithms like deflate: while it has reasonably low entropy, its encoding looks irritatingly random to algorithms that are looking for sequences of bytes (or bits) that are actually identical, especially over small window sizes.

The problem is that you may see "add one, compare, branch if equal" all over the place, but it is "add one (to X), compare (with Y), branch if equal (to Z)", which breaks up the nice sequence. Even just reorganizing the data bits based on the instruction encoder then helps /tremendously/.

However, it is also often the case that X is one of just a few numbers, Z is one of a small range (loops aren't usually that large), etc.: however, normal algorithms look for "exactly this", not "something similar to this with an offset" (or even switching to a general integer encoder); again, minor details, but it breaks deflate.

...and, indeed, there are better compression algorithms out there already that are designed to handle code well. I swear Google even had some cool stuff for this, but I'm not finding it right now :(. Regardless, a quick (silly) citation for validity:

"""While we have not addressed the compression of machine code, others have shown that it is possible to compress machine code by a factor of 3 using a specially tuned version of a conventional compressor [Yu96] and by as much as a factor of 5 using a compressor that understands the instruction set [EEF +97]."""

-- http://www.usenix.org/event/usenix99/full_papers/wilson/wils...

So, yeah: I think the key problem is that Apple is not wasting disk space on the device. And, when you put it that way, it is obvious: why would Apple waste 700MB of flash on a 32GB device, space the user would probably really love to be storing music in, when they only have 100MB of entropy?

The answer is: "they wouldn't", and so (modulo the further compressibility of binaries, an interesting and partially open academic problem) the result is that most of the data on the filesystem is already compressed images/audio, and therefore compressing, encrypting, and even compressing again, doesn't matter to the result.

Re: Google says Nexus One too old for Android 4.0

#133
post #106

Earlier quoted context omitted.

> I found I had to turn off all push notifications and was surprised that apple would put out something that had such inferior usability when the notification dropdown thing that Android has is so clearly better. You may want to note that iOS was released more than a year before Android. The notifications have been essentially untouched between iPhoneOS 1 and iOS 5. > The other thing that really stinks on the iPad co…

The iPad had whatever came with the iPad2 by default, which I assumed was the latest, maybe it wasn't. Anyway, I haven't upgraded to 5 yet since it has seemed wrinkly for a lot of people. Wrt notifications... I just don't understand _why_ they didn't touch it between iOS1 and iOS5. It was so bad :) I'm sure it's much better now.

> I just don't understand _why_ they didn't touch it between iOS1 and iOS5.

My guess is: limited engineering power and other things they considered more critical to user-experience (however misguided their consideration was).

Re: Google says Nexus One too old for Android 4.0

#134

Earlier quoted context omitted.

I bought an Apple 3G new in August 2009, after the 3GS came out and it felt like obsolete junk with the next major iOS upgrade, long before the contract expired. I certainly did not feel like I was treated like a king. I was certainly not the only one: http://appletoolbox.com/2010/06/iphone-3g-slow-after-ios-4-0... None of the suggestions worked. I have a Motorola Atrix now.

This story Sounds like total BS to me coming from a Google employee.

No, it's correct that iOS 4.0 was a huge performance hit on the 3G: it significantly increased iOS memory requirements, on a phone which was already memory constrained It was unusably slow.

iOS 4.2 improved some things and made it usable again, but the phone was still nowhere near as responsive as under iOS 3.1

On the other hand, rsheridan6 had bought a year-old design.

Re: Google says Nexus One too old for Android 4.0

#135
post #116

Earlier quoted context omitted.

Just to clarify what you're saying here: Are you saying that simply because a file is encrypted, that it'd be equivalent to the uncompressed size? There are a fair few modes of encryption (such as CFB, OFB and CTS) out there which ensure that the encrypted data is the same size as the input data. Even if Apple uses a mode which requires padding, the padding should not be so large as to increase the size of the iOS im…

Here is a small test: dd if=/dev/zero of=/tmp/file count=50k bs=100 # create 5MB file of zero aes -e -f file -o file2 -p asdfasdf # create aes encrypted version of the file tar -czf file.tar.gz file # compress file tar -czf file2.tar.gz file2 # compress encrypted file du -sh file* # check size of all files Here is the output I got: 4.9M file 5.0M file2 8.0K file.tar.gz 5.0M file2.tar.gz These results pretty much spea…

Compressing an all-zeros file is not representative of anything. Why not do it with actual text?

Re: Google says Nexus One too old for Android 4.0

#136
post #15

Earlier quoted context omitted.

But the last official update for the 3G turned it into a dog. I don't think any company is blameless, here, but I'm far more disappointed to see Google doing it. Linux still runs on a 386, last time I checked.

I'm not convinced that you could run a 3.0 kernel image on a 386 without running out of RAM pretty soon, even if you cut it down to something pretty minimal. I haven't found any sources where anyone's actually installed modern Linux on one - they all seem to have used ancient distros because support actually vanished some time back (see eg. here: http://hackaday.com/2011/08/12/installing-linux-on-a-386-lap... ).

I stand corrected, but you have my curiosity up. Nevertheless, the "decline" of hardware in the face of software advancement in phones strikes me as awfully rapid. Is the Nexus One really so underpowered that ICS couldn't be made to accommodate it?

Re: Google says Nexus One too old for Android 4.0

#137

Earlier quoted context omitted.

My whole point (which you've carefully elided in your response) was that you didn't need to do any of that to get the new Market, Maps, Youtube etc. on their own update schedules. Most would consider these key features and selling points of the OS and as such Apple bundles them together with OS updates and corresponding yearly(-ish) hardware releases. Even the stuff that you have to seek out, like installing a new la…

My girlfriend is capable of clicking "yes" when iTunes ask her if she wants to update her phone, but that's about the extent of it. She's not going to go out and find third-party repackages of updated features, and she can't download custom ROMs or anything like that. Yet, she likes new features and improvements just as much as anyone else. She might not know what a JIT is, but she'd sure notice if her web browsing g…

I don't see what's so hard to understand about this, apart from the fact that people seem to want to comment on Android based on third-hand talking points rather than their own experience.

Your girlfriend, if she had bought the same phone as me, from the same vendor, would still be on Android 2.1 but without her having to do anything (apart from possibly agree to some updates when prompted on the phone) she would have the latest versions of apps such Google Maps (only requires Android 1.6 and up) which was better than iOS Maps when the phone was sold, and is still better than iOS Maps in the very latest iOS 5. It has many new features like offline maps, Google location integration, 3D vector maps etc. and she can look forward to more being added.

Meanwhile, if she'd bought a 3G (which has near identical hardware) she'd have had to plug her iPhone into a computer, updated iTunes, and then updated the iPhone to get iOS 3 after a year. She'd have had to do this again to get iOS 4, which would have nearly bricked her phone due to it's lack of speed (despite not actually providing many of the actual features of iOS 4). She could then partially fix this by updating iTunes and the iPhone again after a few point updates were released and then would no longer receive any updates to anything Apple considers part of the OS.

Both systems have ups and downs (e.g. I'm surprised that the Android browser isn't something that's updated independently as you'd think that would fit Google's goals very well, but I assume there's technical issues I don't understand). A fixation on the version number of the OS, or false stereotypes about Android and iOS, obscures all of this.

Finally, the point about the JIT (which I realise I wasn't clear about) is that it only provides benefit if the phone has sufficient RAM. Random people on Android forums would naturally assume newer=better and be disappointed that they didn't have the new shiny, but my phone was somewhat unique in having a large amount of RAM (relative to the rest of the hardware specs anyway). It's therefore a good example of people feeling like they're missing out on something, that would actually hurt their performance if they got it.

Re: Google says Nexus One too old for Android 4.0

#138

I've got both the Nexus One and an iPhone 4 and I can never understand why anyone would choose the Nexus One over an iPhone, it's such an inferior product both hardware and software wise. The comparatively poor quality as put me off anything but iPhones.

My Nexus One made my girlfriend jealous enough to give up her 3GS and come over to Android. YMMV.

Re: Google says Nexus One too old for Android 4.0

#139

Earlier quoted context omitted.

Here is a small test: dd if=/dev/zero of=/tmp/file count=50k bs=100 # create 5MB file of zero aes -e -f file -o file2 -p asdfasdf # create aes encrypted version of the file tar -czf file.tar.gz file # compress file tar -czf file2.tar.gz file2 # compress encrypted file du -sh file* # check size of all files Here is the output I got: 4.9M file 5.0M file2 8.0K file.tar.gz 5.0M file2.tar.gz These results pretty much spea…

Compressing an all-zeros file is not representative of anything. Why not do it with actual text?

It depends what you want to show, in this case I was showing the size difference between a file unencrypted and encrypted. An all-zeros file has nearly no randomness, so it compressed very well. Then I show that somehow the encryption process takes away this lack of randomness, and leaves a file almost incompressible. I'm really just increasing the scale to make it more 'dramatic'.

If I happened to be showing how compressed codecs like jpeg, mp3 or h264 weren't compressible, I would definitely pick something more like an actual text file.

Re: Google says Nexus One too old for Android 4.0

#140

Earlier quoted context omitted.

This story Sounds like total BS to me coming from a Google employee.

No, it's correct that iOS 4.0 was a huge performance hit on the 3G: it significantly increased iOS memory requirements, on a phone which was already memory constrained It was unusably slow. iOS 4.2 improved some things and made it usable again, but the phone was still nowhere near as responsive as under iOS 3.1 On the other hand, rsheridan6 had bought a year-old design.

>On the other hand, rsheridan6 had bought a year-old design.

Well, yes, my previous 3G had been stolen, I needed a replacement right away, and I couldn't afford the premium for the 3GS right then. But if the 3G was intended to be obsolete less than a year after I bought it, it was a dick move to sell it with a 2 year contract. I don't think it's too much to ask that a phone not be obsolete before the contract runs out.

But I have learned my lesson. I'm only buying top-of-the-line from now on. I need to switch to Verizon because I moved to an area where they have the only decent network, and I'm holding out for the Rezound or Nexus Prime (Nov 10th).

But this also favors Android over the iPhone. New iPhones only come out every so often. Suppose your iPhone broke/got lost/got stolen at a time when the current iPhone is 8 months into its lifecycle. Your choices are to sign a 2 year contract for a phone that will be likely be obsolete before the contract runs out, pay an exorbitant cash price, go without a phone until the next release, or buy a cheap phone with no contract and wait for the next release. Or you could buy Android. There's always a latest and greatest Android phone that's not more than a month or so old.

Post reply on HN