Or, assuming they control the site (implied by your use of new pagename/asset/etc) send cache control headers so that no caching is done of some of the assets.

> why does the government get to have my name, contact info, salary history, and God knows what else?

IANAA, but I assume your government already knows your name, address, phone number, salary history, etc. Isn't that how they tax you?
The other stuff, I think, is things like promotions, which they *could* infer from salary, but that's probably not as accurate as they want it to be.

Citation needed?

Find a common app written for iOS and Android (hmm... like GeekBench?) and the results will show the difference.
JIT compilers are pretty darn good these days... they even use them for the web.

No, I don't think so.
Common applications are multi-thread. Even at a basic level, one core driving the UI another driving the business logic.

Single thread might make a difference for games, but a well written game in 2016 won't be single threaded either.

P.S. My Note 7 reported 5499 multi-core, so it's like taking a flame thrower to the iPhone 7 plus number.

No, it's a really low percentage (0.1%).
Might be a large quantity of devices, but still a small percentage.

I've been using a Mac... including being an early adopter of Clusters.

HFS+ compression isn't designed for user files, which is why there are no native tools to use it *for end users*.
There are some hacky command line things you can do, but it's messy, can break, and is totally useless for anything that modifies the file (so, VMs, databases, and the like).

If you're going to use that, you may as well just zip the file and unzip it before you use it.

> That's common wisdom, but I don't think it stands up in the modern world. Here's my bonnie results on a softraid-5 partition with a 10GB test file:

Below is proof of that RLaager is accurate.

root@ViStAr:/fast/temp # bonnie -s 10000 -m zfs
File './Bonnie.29377', size: 10485760000
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
zfs 10000 382297 99.0 1219601 95.8 716616 97.7 349655 99.9 1859572 99.5 19018.9 44.7

Another aside Gzip is terrible. Below is proof, but basically, as a benchmark tool it's about the worst thing you can use.

$ sudo dd if=/dev/random of=test.raw bs=555745280 count=1
1+0 records in
1+0 records out
555745280 bytes transferred in 12.883350 secs (43136706 bytes/sec)
$ du -hs test.raw
531M test.raw
$ sudo /usr/bin/time gzip -1 test.raw
      18.18 real 17.69 user 0.47 sys
$ ls -la test.raw.gz
-rw-r--r-- 1 root wheel 555914267 Jun 14 16:45 test.raw.gz

I can write to a compressed ZFS disk faster substantially faster than you were able to write uncompressed.
the filesystem being used is ZFS, with compression on.

Same filesystem with a highly compressable file shows this result:

$ sudo dd if=/dev/zero of=test.raw bs=555745280 count=1
1+0 records in
1+0 records out
555745280 bytes transferred in 0.493310 secs (1126564044 bytes/sec)
$ du -hs test.raw
512B test.raw
$ ls -la test.raw
-rw-r--r-- 1 root wheel 555745280 Jun 14 16:50 test.raw
$ sudo /usr/bin/time gzip -1 test.raw
test.raw.gz already exists -- do you wish to overwrite (y or n)? y
        3.79 real 2.02 user 0.20 sys
$ ls -lart test.raw.gz
-rw-r--r-- 1 root wheel 2425121 Jun 14 16:50 test.raw.gz

I was able to create the original dataset much faster than gzip was able to recreate it, and compress to a much greater level.
You can also do a similar thing with an all-ones file and get similar results though you won't get the whole punching effect that was seen with /dev/zero.

I disagree, as ZFS demonstrates >500MB/sec to a compressed filesystem is very achievable, including random I/O access.

FIle compression utilities don't work well with virtual machines. You can't just start the VM in a zip file...

a) Implication that it's complex to add compression.

Other common filesystems have it, NTFS, ZFS, BTRFS. Given the amount of money Apple have, I doubt it's that complex.

b) Disks are cheap.

Looking at apple.com/uk pricing, the difference between the 512GB SSD and 1TB SSD is £400. And if you choose incorrectly, you can't just open the case up and change it.
You could then use an external USB, as I do, but sleep/wake doesn't work properly, and endurance on USB keys isn't exactly ideal.
Or you could hang a whole powered drive off it, but then why have a laptop.

c) Nobody needs compression

I've got a couple of hundred GB of virtual machines. I save about 1/3 of the space by just compressing/uncompressing them all the time, but it's a waste.
I imagine a lot of developers would also find it useful; I'm playing around with 70GB text file I generated as part of some stuff I'm doing, and that compresses down to about 5GB when on my server on ZFS, but then I can't carry it with me (e.g. use on a train).

I could spin up a VM with ZFS in it, but then I'd need to hard-allocate a bunch of space to a fileserver... and back to square one.

You may have a different bunch of concerns. SSDs might be plenty big enough for you.

C'mon, it's 2016. Where is compression?

scandalgate or controversygate... so hard to choose...

He's on to something.
But rather than a simple 'hate checker' that could suggest alernatives, why not go the whole hog.

CLIPPY: "I notice you are talking hate on the internet. Do you need help? [Yes] [Obviously]"

How does it fly?

Except this isn't the case. The G3 uses the same technique (only buttons for power/volume on the back, no buttons on the front).
For games and apps where you want the extra real estate, go into Settings->Display->Home touch buttons.
Then click on 'Hide Home touch buttons'. A list of all your apps will appear, just tick away.

Then when you're in an app you've done this with the bottom buttons will vanish but will re-appear when you slide your finger from the bottom/side of the screen where they normally are. For me, it's intuitive.

> Oh? Have you factored in the cost of ensuring that you always have an offsite and fully up to date copy, not to mention secondary and tertiary copies for transit time in case your primary datacenter/server happens to kick the bucket/get stolen/evaporate?

Assumption: They guarantee that your backups/archives are safe.
Reality: "You are responsible for properly configuring and using the Service Offerings and taking your own steps to maintain appropriate security, protection and backup of Your Content, " Notice the words "and backup". If they lose your data it's your problem, not theirs. http://aws.amazon.com/agreemen...

> It's easy to compare the cost of an offered service to what you can pick up seeming similar equipment for from Amazon or Newegg... the realities though are far more complex.

Not to those who are 'skilled in the art'. For example. a copy of CrashPlan, two 3TB drives locally, one 3TB drive at a parent/friends house. For the paranoid, two 3TB drives at two peoples houses. Assumption: network bandwidth is sufficient and/or not much data change rate and/or happy to shuttle drives backward and forward.

Or, if you don't want to use crashplan, use rsync or other such replication technique. Set up md5sum scanning to run every few weeks at each location, takes a day or so to run and you're 100% certain that bitrot hasn't set in.

Advantages:
* I can touch each physical box.
* It's massively cheaper.
* Recovery is much quicker since I can just grab the physical copy.
* I know how the backup infrastructure is designed. If something goes wrong it's my fault, I can't rail uselessly against the sky gods if suddenly all my data goes away.

Disadvantages:
* You have to maintain it. You can't trust the sky gods to maintain it for you - a drive fails, you have to buy&replace. Forget to configure something/validate something is done correctly then it's your own fault.