If you follow Benedict Evans on Twitter then you know that he is something of an Apple fan boy, so it's hard to read such a piece without noting that there is already considerable bias in it.
I'd like to address the first list though, "There are a bunch of reasons why someone would buy a high-end Android rather than an iPhone".
That list does not include the two reasons that myself and people I know use Android:
1. We wish to have control over our devices
2. We have not invested heavily in either Apple or Google and we avoid making choices that will force us to be invested in one over the other
On the first point, control may be about privacy (using something like XPrivacy), personalisation (perhaps CyanogenMod), adblock (AdAway), or simply having more control over what runs to be able to extend the battery of a Nexus 5 to a few days of heavy use rather than a single day (kill all the background services but still have the apps available for us to use).
On the second point, myself and my friends do not use Google as an ecosystem or as a range of permanent services and virtual assistants. We invariably are using different launchers (Nova is most common), perhaps Duck Duck Go... and our Google footprint is really just to use some Google apps as standalone apps (Gmail, calendar, drive). We tend to get media from Kindle, or Spotify... so we're not even hooked on Google Play.
What this means is that we've avoided deep lock-in with Google, and we make choices that avoid being locked in to Microsoft or Apple too.
When I think of what most of my friends use, it's a mix of technologies. Apple and Lenovo laptops, the latter running Windows or Linux. iPods and Cowon music players. Mostly Android phones.
The biggest reasons not to go for an iPhone are the same reasons we haven't gone for an iPhone to date: It feels like an all or nothing decision that would be hard to change in the future.
The value of an iPhone seems to be of the entire Apple ecosystem, it makes sense if you've bought into it already, or are choosing to buy into it, but not if you do not choose to be locked in.
The value, to us, of an Android device is that you can get the benefits of this technology without having to be part of any ecosystem, Google's or Samsung's or that of anyone else (Amazon?).
I'm not sure it's possible for Benedict to see this any more... he's personally so deep into the Apple world that his perspective is skewed by that reality. The question of why anyone would choose not to be a part of an ecosystem isn't even asked. He's made it an Apple vs Google question, when the people I know using Android are not even considering that question.
PS: If I think of what entices people to consider an Apple iPhone more than anything else, it's the camera (usually noted as the software ecosystem around the camera). Photography on an iPhone bests every Android device there is. This is the single reason that some of my friends have an iPhone.
One of my main reason for using Android is I hate being forced to use iTunes to update and sync.
One, it has one of the worst UI for device managers (was designed manage music), and it's a very unpleasant experience for me every time I am forced to use it to manage my idevices.
Two, it had wiped out everything in my iphone one time I try to sync it to a new computer. To me, the word "sync" means to update devices so that the data missing from the other device gets synced. No way would I have second guessed it would wipe out data from the device. So every time I use iTunes to sync, I get super nervous.
With Android, I can just navigate my device as if it's just an external drive when I plug it into my computer(a Mac).
iTunes is just the opposite of Apple's "it just works" motto.
I copy a lot of music to my phone - but it just kind of automatically appears playable there when I buy it - and I can "download" it onto the iPhone by clicking on the cloud icon. Presumably some combination of iCloud / iTunes match takes care of that for me in the background.
I just realized the one thing that I am missing, that I've heard can be done with iTunes, is the ability to delete an album. iPhone only lets you delete one song at a time - which is painful if you have a lower capacity iPhone.
Good reason to buy a 128 GB iPhone and just never worry about it again.
I have hard time seeing iPhone last more than 3 years. That is 36 months, or $360 of spotify subscription. Now price difference between 16GB and 128GB for iPhone 6 is $200 before tax. This comes roughly just under two years and is about average interval tech savvy people update their phones at.
This is just putting things in perspective, unless you have very specific needs of your phone I do not think 16GB is enough anymore, 64GB is definitely way to go.
I use my iPhone a lot - blowing through 64 GB is pretty trivial. It's not even clear to me that 128 GB will get me through the full two years, but, at least I won't have to spend all my time deleting / re-downloading music. And, might be able to keep a few videos (I've had to delete them all off my iPhone to make space).
I spend a lot of time traveling overseas, and have been hit by more than a few >$500 phone bills, even with the international data plan and lots of use of WiFi Dongles+Local SIMs. The more data, maps, podcasts, music I can store locally, the less use of data required.
I probably won't be happy until we get a 256 GB iPhone, which, on current trends, probably won't be for another 3-4 years unfortunately.
To put it another way - 128 GB isn't enough for me to stop worrying about saving space on my iPhone, but it is enough that there is little value in me shuffling music on/off it.
If you pay for iTunes Match, import all of your non-iTunes music into iTunes, Apple will store a DRM-free AAC file (256 kbit/s) in the "cloud" which you can play/import directly onto your mobile devices (without sync/tether).
You only have to pay for iTunes Match when you have new music to import. Once imported it is available "forever."
PS - I ironically used this to escape the Apple ecosystem. You can use it to strip DRM from old Apple DRM-ed music. You import it using match, and it converts it from an AAC-DRM track to an AAC DRM-free one and ups the quality from 128 to 256 Kbit/s.
It gives you the highest quality Apple has for the song, if it's matched. I had a ton of terribly transcoded files that got replaced with 256kbps AAC files. In my reading and own personal testing the difference between 256kbps AAC and 320MP3 is negligible. The only issue I ran into was some stuff didn't full match an album. I would get 10 out of 12 tracks matched, or 5 out of 12. Still for 18K songs I think I only had 100-200 that didn't end up being matched.
Amazon does offer this too but I have no idea how well it works in comparison.
A lot has changed in the last few years. Spotify gives me all the music I could ever want, and if something is missing you can sync music from Spotify on your computer to your phone, and everything is wireless. For video it's almost the same thing, YouTube and Netflix provides we with all the content I need to have on my phone.
"Cache" implies they're only temporarily on your device. This is false: the files are downloaded and encrypted on your device, and do not go away unless you explicitly tell Spotify/Rdio to remove them.
Spotify/Rdio will remove those files at any time if they lose the license to play them. This is not the case with media files you own, and have complete control over (lacking DRM).
Caching it on the device is enough for me. I'm fine with knowing that I don't really own my music, as long as I can still listen to it while I'm on the subway without cell signal.
iTunes Match + iCloud syncs your music automatically. Kind of like Photostream for music.
Photostream, after a rocky few initial months, has been awesome for the last year+ I hope it works as well with the new Photos apps as it has with Aperture.
Not a fan of iTunes myself and its all-or-nothing sync behavior does ask for more. Fortunately, it has been possible to update the device or download purchased content directly on the device for a couple of years now.
But not pictures on the device, which was really what I care most. Maybe iCloud is better now, but it's an extra layer of blackbox I will need to worry about.
One of my main reason for using Android is I hate being forced to use iTunes to update and sync.
I was always amazed when a friend that had an iPhone said all his (music|photos) were wiped by iTunes when he plugged in his phone, again. It seems like such an easy thing to get right, but if you can't get it right, toss up a dialog "do you want to reset this device's (photo|music) store?"
I fire up iTunes about once a year or so to make a backup. If you're syncing your mail/addresses/calendar/music (eg Spotify)/photos/etc via other services, there's really not much to sync otherwise. Not to mention that iOS updates over the air now, and does not require a computer to activate.
In which way superior? The file transfer to/from Android uses the native OS interface ( Linux, Windows, etc ) and users are accustomed to this, no need to learn a second interface a la iTunes.
While a Chrome extension is not such a bad idea, is rather unnecessary.
I find iTunes to be very useful. One place to manage all of the content on my device, back it up, and restore it (if necessary). Android file transfer is buggy and exposes too much to the user. While it is cool to look inside of DCIM or wdh_update, it isn't helpful or even understood.
android leverages MTP standards and in a lot of cases emulates USB media storage. On Windows, Linux and OSX - this has resulted in a drag and drop interface for Android.
Samsung devices don't have the proper drivers on Mac for transferring files with Finder. I'm stuck using the Android File Transfer or the Samsung proprietary app, both of which suck.
You can get Servers Ultimate and just set your phone up as an FTP server or some other file transfer server.
Droid NAS also works brilliantly on Android devices and Macs. On Macs they'll just show up on your local network as a network drive you can drag and drop files to in finder. You just need to have your phone on the same wifi as your computer.
> To me, the word "sync" means to update devices so that the data missing from the other device gets synced.
But that's not what sync means. True sync has a source and a target, and the target's file collection is always made to match the source. If you confuse the source and the target and the "source" is empty, you get the outcome you describe -- the empty device's file collection is "duplicated" (i.e. erased) on the other device that's been mistakenly chosen as the target.
This is a surprisingly common outcome among people who don't fully understand the meaning of sync. If your interpretation were the default meaning, it would be impossible to delete any tracks from your music collection. If you deleted some tracks from the source device, the source would have those tracks restored from the target instead of being deleted from it -- but that's not what sync means.
EDIT: People, don't downvote posts just because you don't understand the topic under discussion. The above description is absolutely, incontrovertibly correct in every detail. Therefore, in a depressing trend, it's been downvoted because it's annoyingly, infuriatingly right.
Sync has always meant merging semantic changes in state between two or more devices. If I buy an app on my desktop and take 4 photos on my phone, when I sync the two devices, I expect the new app on my phone and 4 new photos in my iPhoto.
As version control has taught us, merging changesets can lead to a menagerie of pathological cases and there's no universally correct automatic merging tool. iTunes in the grandfather's case, chose to merge incorrectly and lose data.
You either need to read more carefully, or you do not understand what "sync" means. Please do not add to public confusion about this.
1. Synchronization means making two directory trees identical -- same files, same count, no more, no less.
2. If tree B (destination) has more files than tree A (source), sync deletes files from B so it agrees with A.
3. If tree B has fewer files than A, files are added to B so it agrees with A.
4. If tree B has the same number of files, but different contents or dates, the sync program replaces them with files from tree A.
5. THEREFORE, ERGO, the operator MUST say which is the source, and which is the destination.
For the life of me I can't understand why people find this so confusing.
> Sync has always meant merging semantic changes in state between two or more devices.
YES, as clearly explained above. And that means if the user chooses the wrong source, for example a device with no music tracks, then the program will dutifully erase all the music tracks from the destination device.
> iTunes in the grandfather's case, chose to merge incorrectly and lose data.
Yes, but that outcome resulted, not from an error in iTunes, but from the user misidentifying the source device, and that, in turn, resulted from his not understanding sync, a misunderstanding that he revealed in his post by attempting to rely on an incorrect dictionary definition of the word.
EDIT: consider this hypothetical example.
1. Directory tree A has 9 files.
2. Directory tree B has 10 files.
3. In your description, the user doesn't have to say which is the source -- no user intervention is required.
4. If so, without user intervention, how does the sync program know what to do? Does it add a file to tree A, or delete a file from tree B?
Think before answering.
EDIT: Readers, do not downvote posts simply because you're confused. Ignorance is not a justification to cast a downvote.
> Sync has always meant merging semantic changes in state between two or more devices.
That is a definition of file synchronization [1]. Usually the aim of "syncing" is to input two directories and the outcome is that the contents of both directories are the same.
What you are describing below point 1. is an algorithm to achieve this goal.
The algorithm you describe needs a source and destination folder and this may be Apple's algorithm and implementation (I have no idea) but this is by no means the only way to do so (see two-way file synchronization [1]).
In that case, there are two strategies for synchronizing file systems -- either:
1. The operator tells the program what to do.
-- or --
2. The program gets it wrong at least some of the time.
In the case of contact list synchronization, like Google Contacts, the system assumes that the device the operator is editing at the moment is the source, and acts accordingly. Notice that a positive determination is made as to what the source and destination are, based on the operator's activity and its timing.
In all other cases where two directory trees are synchronized, are made to have the same content, and in which files may be deleted as well as added, the operator has to tell the program which is the source and which is the destination. End, full stop.
I agree that you need some user input or the program will get it wrong in some cases.
But the distinction between source and destination is relevant with some algorithms (one-way sync) and irrelevant in others.
Let say you have two directories A and B to sync and both contain a file f but the one in B is more recent than the one i A. A consistent strategy would be to always favor the most recent file and end up with A and B containing the same f file that was the one being in B at the beginning of the syncing. At no point I asked the user to define a source nor a destination but still the two directories are synced.
Note that it is your choice to continue or not the discussion as much as it was mine (not yours, shockingly) to answer your post.
So please keep your "End, full stop" and "Think before answering" to yourself, they are quiet annoying.
> But the distinction between source and destination is relevant with some algorithms (one-way sync) and irrelevant in others.
True, but the decisions made by the operator are critical to any desirable outcome, in all cases, without exception. Your example proves the point:
> Let say you have two directories A and B to sync and both contain a file f but the one in B is more recent than the one i A. A consistent strategy would be to always favor the most recent file and end up with A and B containing the same f file that was the one being in B at the beginning of the syncing.
Yes, unless that's not what the operator wants. Suppose the operator has edited a file as part of a programming project, but introduces a bug and simply wants to restore the system's original state with a minimum number of file operations. In that case, the operator wants older dated files to be copied over newer ones.
How shall the algorithm proceed? The operator tells it what to do.
> So please keep your "End, full stop" and "Think before answering" to yourself, they are quiet annoying.
If people understood the meaning of file synchronization, I wouldn't have to. All the replies suffer from naive assumptions contradicted by real-life experience, such as the OP losing his music collection as just one example, or the example I just gave -- things that happen to real people in the real world.
You're right, synchronization means making two directory trees identical. Nothing about that definition refers to or relies on the concept of a canonical source and a target to be wiped. That's cloning, which is a special case of synchronization.
Where does this meaning for "sync" come from? Rsync does work this way, but sync is abbreviated from synchronization and that doesn't - to my knowledge - imply any directionality in it, and dictionary definition [1] seems to agree.
Indeed it does, and that is the true meaning of sync. Consider this example:
$ rsync -a --delete (A) (B)
If (A) is empty, watch (B) become empty too. The point I'm making is that the use of the "--delete" option causes rsync to agree with the true technical meaning of "sync". Without it, the two directory trees (A) and (B) cannot be guaranteed identical at the end of the process (the real meaning of sync).
> ... and that doesn't - to my knowledge - imply any directionality in it ...
Of course it does. How else can you make two directory trees identical if your intention is to delete some files from both trees?
> and dictionary definition [1] seems to agree.
Never rely on a dictionary in a technical discussion. Contrary to popular belief, dictionaries do not list word definitions, they list what people think words mean. This is why "literally" and "figuratively" are listed as synonyms.
> Contrary to popular belief, dictionaries do not list word definitions, they list what people think words mean.
I have no idea what you think the definition of a word is, besides what people think it means. Are you imagining a platonic Word floating in the ether somewhere that we see in a mirror, dimly? Is there some official "This Is What Words Mean" tome somewhere that all true definitions flow from? Was there some secret international treaty wherein all word definitions were all agreed upon?
1 : in a literal sense or manner : actually <took the remark literally> <was literally insane>
2 : in effect : virtually <will literally turn the world upside down to combat cruelty or injustice — Norman Cousins>
This is what people think "literally" means. But it is not what "literally" actually means. The common perception is false.
> Is there some official "This Is What Words Mean" tome somewhere that all true definitions flow from?
1. Only for certain terms. There are plenty of examples.
2. On the topic of words, you need to learn the meaning of deconstructive postmodernism, the fascinating idea that there are no shared ideas, that everything is a matter of opinion.
> Was there some secret international treaty wherein all word definitions were all agreed upon?
You missed my point, which is that, no matter which definition one chooses, a word cannot simultaneously mean what people think it means, and the opposite of what people think it means, at the same time. Even given the fluid nature of word definitions, that's not rational. That's why I choose this example over and over again, not because of what "literally" means, but because it cannot possibly mean A and not-A at the same time.
And some words have technical meanings that are contradicted by popular usage, like "theory" in science. Many people think "theory" means "hunch" -- "but it's just a theory, you know?" In science, theory has a specific meaning contradicted by the everyday understanding.
In the present case, file synchronization has a specific meaning that many people don't know. This misunderstanding causes them to lose their music collections.
> it cannot possibly mean A and not-A at the same time.
Here's an old joke:
A linguistics professor was lecturing to his English class one day. 'In English,'
he said, 'A double negative forms a positive. In some languages, though, such as
Russian, a double negative is still a negative. However, there is no language
wherein a double positive can form a negative.'
A voice from the back of the room piped up, 'Yeah, right.'
> no matter which definition one chooses, a word cannot simultaneously mean what people think it means, and the opposite of what people think it means, at the same time.
A word can have multiple meanings, and those meanings can be related, or unrelated, or contradictory, or anything in between. When a person uses a word, usually they intend one of those meanings, but you can also intend multiple meanings at the same time—thus double entendres. You can also say something, but mean something different, or even the opposite—thus irony and sarcasm.
> And some words have technical meanings that are contradicted by popular usage, like "theory" in science. Many people think "theory" means "hunch" -- "but it's just a theory, you know?" In science, theory has a specific meaning contradicted by the everyday understanding.
"Theory" has multiple meanings, some of which people are unfamiliar with. But their understanding isn't wrong, they just don't know the meaning that the speaker intends.
> synchronization has a specific meaning that many people don't know.
Synchronization has multiple meanings—thus why we have post after post arguing about which is correct.
> This misunderstanding causes them to lose their music collections.
If you think about the parent's case, unidirectional syncing ended up causing empty dataset to be synced from the computer to the iPhone. That doesn't seem right. Compare this to Dropbox's model of syncing: intentional changes (yes, deletes as well) are synchronized and this is done multidirectionally between all the participating devices. This is what seems to me like a better definition of sync.
Or consider your mobile device calendar. You add an appointment on your phone, it doesn't disappear when you sync with your PC (or with cloud, as is common today).
I didn't mean to imply that dictionary defines the meaning, but it does seem to agree with what I mean with "sync". Where does this "true technical meaning of sync" come from?
> If you think about the parent's case, unidirectional syncing ended up causing empty dataset to be synced from the computer to the iPhone.
Not if the user selected the new iPhone as the source. In fact, that's the only way the described outcome could happen -- assuming the desktop machine originally had a full collection of music and the iPhone was empty.
> That doesn't seem right.
True, it doesn't seem right. But the customer is always right.
> Or consider your mobile device calendar. You add an appointment on your phone, it doesn't disappear when you sync with your PC (or with cloud, as is common today).
A perfect example. What if your phone is the source of most of your appointments and contacts? Wouldn't it seem logical to make the phone the source for a sync transaction?
Let's take the next step -- what if your phone is the source of your music collection? What if you add music to your phone while on the road and want to add those tracks to your desktop machine's archive? To do this, the sync program must accept your instructions about which device is the source and which the destination. So you must not get it wrong. In other words, in order to get the expected outcome, you must know how sync works.
To repeat your earlier point:
> Or consider your mobile device calendar. You add an appointment on your phone, it doesn't disappear when you sync with your PC (or with cloud, as is common today).
Yes, that's right, but you're not taking that example to its logical conclusion -- the smaller, more peripheral device, the phone, is the source for the sync. If that device has no music on it, the desktop machine will have its music collection erased.
> I didn't mean to imply that dictionary defines the meaning, but it does seem to agree with what I mean with "sync".
Yes, true, which explains why I've been hearing so many accounts like yours -- people rely on dictionaries to define technical terms and end up erasing their music collections.
> Where does this "true technical meaning of sync" come from?
Logical thinking:
1. "Sync" means that two directory trees end up with the same content -- exactly the same number of files, same names, same everything.
2. For (1) to be true, the program performing the sync must sometimes delete files as well as add files.
3. For (2) to be true, the program must know which directory tree is the source. Therefore the user must know this too. But users, reliant on dictionaries, may not understand what sync actually means.
Suppose I create appointment A on my phone's calendar, and appointment B on my laptop's calendar. After syncing, B shows up on my phone, and A shows up on my laptop (as I would expect). Who is the source and who is the target in this case?
According to your definition, this is not 'syncing'. But for most people, it is.
All synchronization depends on either the user, or a program, deciding which is the source and which is the destination. Such a choice is always made.
Consider this example:
1. Device A has a list of 9 contacts.
2. Device B has a list of 10 contacts.
3. According to your thesis, the sync program doesn't need to be told which is the source and which the target.
4. If so, and if the user intentionally deleted a contact from device A, shall the sync program:
x. Restore the contact missing from device A from device B, or
y. Delete the contact missing from device A from device B?
The answer is that the sync program cannot know what to do without being told which is the source and which is the destination.
This is how iTunes decides what to do -- the user tells it which is the source and which is the destination.
> According to your definition, this is not 'syncing'. But for most people, it is.
Yes, and to prove this point, and of the ascendancy of human instinct over logic, the OP lost his music collection.
This is a classic example of people's inability to think logically. How on earth could a computer program know what to do in the above example without being told what to do by the operator?
There's one exception, which ironically proves the point. In the example of real-time contact list synchronization, a sophisticated system would automatically assume that the device the operator is using at the moment, that he is editing, is the de facto source, and make other synchronized devices have the same content (this is how Google Contacts works). But in this example, as in all examples, the sync process cannot proceed until a decision is made about the meaning of "source" and "destination". In this example, the decision is automatic, but it has to be made.
In the case of syncing two music collections, the operator has to specifically identify which is the source and which the destination. I cannot tell you how often I've heard stories of people buying a new iPhone, then running iTunes, then erasing their music collection by misidentifying the source for the transaction.
4. If so, and if the user intentionally deleted a contact from device A, shall the sync program:
x. Restore the contact missing from device A from device B, or
y. Delete the contact missing from device A from device B?
Stop thinking in files and start thinking in actions, and the answer is obvious. The delete action is being synced, therefore the contact should be deleted from B. If the file is merely missing (e.g. due to filesystem corruption), it should be created from B, since you are syncing the create action.
There's no directionality needed or implied, it's a merge of two trees.
> The delete action is being synced, therefore the contact should be deleted from B.
Yes, and that is exactly what I said in my post, the one that got downvoted -- there are special cases where the context can be used to decide which is the source and which the destination. But a source and a destination must always be selected.
> There's no directionality needed or implied, it's a merge of two trees.
Not in the general case, because there is no general case. How do you merge two directory trees having different file sets without knowing the operator's wishes? Does he want files missing from one tree to be deleted from the other, or does he want files missing from one tree to be restored from the other? The answer is that you ask him -- the operation cannot proceed automatically.
And for this obvious, technically correct insight, my posts get downvoted with perfect reliability.
Yes, and that is exactly what I said in my post, the one that got downvoted -- there are special cases where the context can be used to decide which is the source and which the destination. But a source and a destination must always be selected.
There is no source nor destination, it's a merge of two equivalent trees. When I do "git merge <remote>", I'm not saying I want to replace the local branch with contents of the remote, nor vice versa. There's no source nor destination, they're both equal.
How do you merge two directory trees having different file sets without knowing the operator's wishes? Does he want files missing from one tree to be deleted from the other, or does he want files missing from one tree to be restored from the other?
You're still thinking in files. There are no files, just actions. The files are a byproduct, not the things being synced.
> There is no source nor destination, it's a merge of two equivalent trees.
Let's say I have two systems in a programming project. On one of the systems, I have edited some files, but now realize I have created a bug I can't locate and I don't want to try to undo what I have done -- I just want system B to be returned to its original state, a state represented by system A, but with a minimum of file operations.
So I run a synchronization operation, and I tell the algorithm how to proceed. If I follow your philosophy --
"You're still thinking in files. There are no files, just actions. The files are a byproduct, not the things being synced."
-- then (using the default rules of two-way file synchronization), the edited files, the files I have ruined, files having newer dates than the originals, will be copied onto the original source tree, tree A, and I will lose the only remaining copies of the files' original states. If instead I delete the edited copies to avoid this, the originals will be deleted too.
So much for automatic file synchronization without the operator understanding and overseeing the process.
Your reply doesn't analyze file synchronization operations with enough depth to avoid such disasters.
You've moved your argument from "synchronization always must have a source and destination" to "certain synchronization models are not well suited to some use cases".
I certainly agree with the latter, even if it has no bearing on the former.
> You've moved your argument from "synchronization always must have a source and destination" to "certain synchronization models are not well suited to some use cases".
No, I have moved from specific examples to general examples, and general rules. The most general rule is that synchronization cannot be automatic and have a desirable outcome.
If it happens that often then iTunes isn't communicating clearly enough to the user what is about to happen. I'm reminded of this advice:
> The principle is simple: it's not your fault. (Side note: if you don't understand this reference, then do yourself a favor and watch this video[1].)
It's not your fault. It's not the user's fault. It's not the designer's fault. In fact, it's nobody's fault. What's crystal clear to you might be confusing to me, and no one is to blame for that. It's just something we have to work with. — Source: http://moz.com/blog/5-lessons-learned-from-100000-usability-...
> If it happens that often then iTunes isn't communicating clearly enough to the user what is about to happen.
Yes, I agree completely. But given that, I have to say I hear regularly from people who (a) buy a new iPhone, and then (b) wipe their music collections later on the same day.
Many people assume that an apparently sophisticated, polished program like ITunes will "do the right thing." But no.
3. For (2) to be true, the program must know which directory tree is the source.
Nope. Both are the source of their own actions, and both are the destination of each other's. You're inventing restrictions that haven't applied since at least the first DVCSs.
Please do not contribute to public ignorance. You clearly haven't tried to use rsync, which has its name for a reason -- it's a synchronization utility. All synchronization operations must know which is the source and which the destination. Something this is arrived at automatically, but in the case of rsync and iTunes, you must tell it.
Quote: "rsync is a file synchronization and file transfer program"
SO which word is confusing?
> Both are the source of their own actions, and both are the destination of each other's.
Of course. But let's return to planet Earth. Consider this example. Two systems have directories with independent collections of files. System A has 9 files. System B has 10 files. The operator tries to sync the two systems. But to do so, the operator has to tell his synchronization program, which is the source and which is the destination.
The outcome depends on the operator's decision, it cannot depend on the contents of the directory trees.
Read the original post, the one I replied to -- the OP lost his music collection by choosing the wrong source for a file synchronization operation using iTunes. I replied to explain what "synchronization" means in that context.
You clearly haven't tried to use rsync, which has its name for a reason -- it's a synchronization utility.
Like many others, e.g. Dropbox, Unison, Git-annex. Just because "rsync" has sync in it's name doesn't mean it's the only syncing model possible.
All synchronization operations must know which is the source and which the destination.
In rsync, yes. In others, no.
SO which word is confusing?
No confusing word. The only confusion is in the assumption that sync == rsync. It's like saying that all cars work like the Model T.
Two systems have directories with independent collections of files. System A has 9 files. System B has 10 files. The operator tries to sync the two systems. But to do so, the operator has to tell his synchronization program, which is the source and which is the destination.
Nope. You never have to tell Dropbox, Unison or git-annex which is the source and destination. In the latter, I just do "git-annex sync", and both are synced with each other.
>> All synchronization operations must know which is the source and which the destination.
> In rsync, yes. In others, no.
False. In a two-way synchronization, if the operator wants to restore an older version of a file because of a bad edit, he must tell the algorithm what to do. In no case can the operator use such an algorithm without understanding what rules it intends to apply.
> In the latter, I just do "git-annex sync", and both are synced with each other.
Read the above example. These programs must be told what to do by the operator, and there is no safe, automatic algorithm that always gets it right.
In a two-way synchronization, if the operator wants to restore an older version of a file because of a bad edit, he must tell the algorithm what to do.
I have no idea why are you bringing versioning into this conversation.
These programs must be told what to do by the operator, and there is no safe, automatic algorithm that always gets it right.
I don't know what do you mean by "get it right". That's a subjective concept.
All I'm saying it, syncing does not have to involve a "source" and a "destination", nothing else.
> I have no idea why are you bringing versioning into this conversation.
I can see that. Okay, let's say that someone has a corrupted music track on his iPhone, the track won't play, and even though it has a newer date than the original on his desktop archive, he needs to overwrite the new-date bad track with the old-date original.
> All I'm saying it, syncing does not have to involve a "source" and a "destination", nothing else.
All I am saying is you're not thinking about this with enough depth. In the above example, a modern, sophisticated two-way synchronization algorithm will overwrite the old-date good track with the new-date defective track unless the operator understands how synchronization works and prevents this default outcome.
> I don't know what do you mean by "get it right". That's a subjective concept.
No, it is not -- unless you think everything is a matter of opinion and there are no shared objective truths. And if you believe that, why do you even bother to post in public forums, forums that exist on the premise of the reality and utility of objective, shared truths?
By this definition, "unison" isn't sync. It's also possible to handle not reinstantiating deleted items, although it takes more bookkeeping (usually "tombstone" records).
> So, if I start with two devices holding lists, and I place the union of those lists on each device, what is that called?
Not enough information. Naive set theory isn't adequate to cover file operations. Files have sizes and dates, but members of sets don't normally have these properties.
File synchronization isn't necessarily a simple and blind union of two sets. Some synchronization operations require that files be deleted, others require that files be restored or provided if absent. Which is true is left to the operator -- he must decide.
Consider this example. Two directory trees, A and B, contain the same number of files, but some of the files have sizes different than the other. Does the synchronization operation copy files from B to A, or A to B? The answer is that the operator must decide.
Rsync, a popular file synchronization utility, can delete files, or not, depending on what options the operator selects. It also much be told which is the source and which the destination.
> Do you have a reference for the technical definition of sync that this fails to meet?
A quote: "File synchronization (or syncing) in computing is the process of ensuring that computer files in two or more locations are updated via certain rules.
In one-way file synchronization, also called mirroring, updated files are copied from a 'source' location to one or more 'target' locations, but no files are copied back to the source location. In two-way file synchronization, updated files are copied in both directions, usually with the purpose of keeping the two locations identical to each other."
In the first case, algorithm must be told which is the source and which the destination. The operator must decide. In the second, the algorithm must know how to proceed -- are newer files overwritten, or are older files overwritten? The operator must decide.
Most people don't understand this -- in all synchronization operations, the role of the operator is key to getting any desirable result.
In answer to your question above, the online definition I quoted above doesn't allow for a simple union of two file trees, because there is no such thing -- the algorithm requires additional information, information provided by the operator.
In a two-way synchronization, if the algorithm encounters a file that is (a) not present on both systems, or (b) one copy is larger, or (c) one copy has a newer date, the algorithm cannot proceed unless and until the operator expresses a preference -- establishes the rules.
In short, there is no automatic file synchronization -- all examples require the conscious participation of a decision-maker.
Let's say I have edited some files in a large, complex programming project. The outcome is successful. I want to synchronize two file trees to reflect the successful outcome, but with a minimum of file operations. Therefore I tell the synchronization program to copy newer and/or newly created files from B to A.
Next example. I have edited and changed a complex software project, but the changes are a disaster and I want to recover the original state, but with a minimum of file operations. So I tell the sync program to restore older files from A to B, and delete new files from B not present on A.
Neither of the above operations can proceed to a desirable outcome unless I give the sync program explicit rules.
Conclusion: There is no such thing as a union of file systems that doesn't need to be told how to accomplish that end.
Any platform you buy into includes lock-in. Buying an Android phone locks you into the world of Android apps just as much as an iOS device locks you into iOS apps. Music on iTunes is DRM free. eBooks are an issue, but there's a Kindle app for iOS and plenty of other options just as on Android.
Even when it comes to browsers and search engines, now that iOS 8 has robust XPC, the optimised browser engine is available to third party browser apps. These will let you set whatever default search provider you like, without any performance compromises.
Sure there are some areas where Android devices retain more customisability, but iOS 8 closes the gap considerably, and without fundamentally compromising security and privacy in the way many of these features do on Android.
> Any platform you buy into includes lock-in. Buying an Android phone locks you into the world of Android apps just as much as an iOS device locks you into iOS apps.
Yet I can build an android app,deploy it, share it with my friends and co-workers without having to put it on google play,owning a specific computer with a specific os, or paying a fee.
There is a common theme amongst my friends that whilst they are not technical (I am the only programmer or person working in tech), they are all geeks for one thing or another; be it cameras, watches, coffee, cycling gear and so on.
They like to tinker and play with things, have some control over them. Adults with toys.
It's probably a selection bias, but it reaches out to so many people that ignoring it entirely is also a bias.
I think you're largely correct, but I'd add another point, which is that even if Evans was on the money about why people bought a Galaxy Note a year or two ago, it far from follows that the decision process is exactly the same today.
Someone might have chosen a Macbook in 2006 because they really liked the white plastic, but that doesn't mean that eight years later, they'd be at all likely to buy a new white plastic Lenovo running Windows. In the meantime, they will have acclimated themselves to the platform, gotten used to how it works, come to rely on features that aren't on another platform, or simply not want to deal with the hassle of starting over from scratch with a blank slate device.
Personally, I see Apple's product integration as a liability. It's fantastic for many users, it simplifies things and makes devices work well together. But, mostly for business reasons I'd guess, they define that integration to be best or only on Apple made devices.
But for me I feel like I'm putting all my eggs in one basket.
I know the app ecosystem is improving a bit and mediating lots of that, but there's still a long legacy there and I'm concerned about hard corners that will lock me in.
I used to feel that way. However, now that I am mostly retired, owning both iOS and Android devices does not seem necessary, and giving up some freedoms and jumping with both feet into Apple's little walled garden seems like a reasonable decision. I am almost certain to trade in my beautiful Samsung phone for an iPhone 6+. I have been running the beta of Yosemite for a long while and the new iOS 8 integrations with OS X, look good. I feel like making my life simpler.
I almost went in the opposite direction. I have been a Linux fan since 1992, and I still have several Linux servers I use for hosting my web apps. I thought of getting a FSF 'free' style phone, etc. and have fun with that.
But, I feel like a simpler life style now and I am willing to give up flexibility and, I hate admitting, some FSF style freedoms. #sellout
That 'simpler lifestyle' only works until they force something that you can't abide by, and by that point it's too late. Personally I can't even tolerate that there's only one hardware manufacturer and one source of software. That never ends well for consumers.
I feel like I am not really trapping myself in the Apple ecosystem because the things that I use (web browser, emacs, IDEs for Java, Clojure, Ruby) are available on Linux. I just don't use my Linux laptop very much since the Apple experience is more polished.
I do agree with your comment in general. That is, for non-tech computer users, moving off Apple's platforms would be difficult after years of use.
Thanks for the comment. I think what you've missed is that the attitude you describe is shared by a very, very small proportion of the user base - perhaps a few tens of millions out of the 1bn+ Android users. I had a go at estimating this last year: http://ben-evans.com/benedictevans/2013/6/5/counting-geeks-w... I tried to capture it in the 'people who don't like Apple' bucket, but as you say its a little more nuanced than that.
Fundamentally, the question is not 'why does a HN reader buy Android?' but 'what motivated the multiple hundreds of millions of people who bought a $600+ Android?' and as I'm sure you know, they're not using Cyanogen (though as investors in it we hope that changes;) Screen size is a huge factor.
Even for non-technical people iPhone has worse "lock in" because Apple tries as hard as they can to enforce lock in. For example, if you buy content within an app on the iPhone, the developer cannot let you access that content on a non-apple device or Apple will remove their app from the app store. The same is not true of Android.
I am the only HN/technical person on another large forum (not this), and the common thing amongst those members and the many real-world friends I have via that is that they are geeks for other things: cars, bicycles, watches, cameras, coffee, etc. This geek tendency carries to other areas, including smart phones.
I've definitely got a selection bias by having friends who are geeks (in the non-technical meaning), but there is still a bias in selecting arguments that excludes the existence of people who are geeks.
I agree with much of what you've said (and have said) and what motivates one way or the other... but I do think that your arguments don't acknowledge people who buy top-end Android, and do so without intending to buy into Google, or Samsung. With Apple and Amazon it's somewhat harder, buying their devices is to buy into their ecosystem.
The decisions I see them make is very much based on their desire to control their own things... the definition of control varies on a person to person basis, but it is the common factor.
On Cyanogen I personally do not run it, most of the benefits people seek can be obtained by rooting but keeping the stock ROM. This hasn't stopped friends from blundering through online guides though. That is the thing that surprises me, they're not technical, most work in offices doing admin/marketing/sales stuff, and they want top-end devices with the status that comes with it, but they really want to assert control over their devices.
Whomever allows those people to have control (officially or not) wins them, for that is one of their biggest triggers when choosing new devices and accessories.
I say this as an Android user who prefers Android over iOS for various reasons (Firefox and its Addons, mainly), but when you say that you wish to have control over your device, you're forgetting that one can jailbreak an iOS device if they so desire which gives one vastly more "control" over it, so to speak.
Granted, a reason (aside from vastly cheaper hardware prices) I choose Android over iOS is the fact that I don't even have to root my device to get more customizations and options (I use SwiftKey, for example) than an iOS device that's non-jailbroken, but I do pay a price for that in regards to less functionality, security and performance compared to iOS devices (in certain circumstances) because of Android fragmentation, etc. - Just ask most musicians why they prefer iOS over Android, if you want just one case scenario.
But, all in all, I wouldn't paint all iOS users with one brush that says they don't want "control" over their devices. "Control" comes in many forms and methodologies and is often in the eye of the beholder anyway.
>On the second point, myself and my friends do not use Google as an ecosystem
But, you must admit that takes time and time is money. Finding third party alternatives (you can trust and work well) isn't free once you consider the time it takes to do so.
>The value of an iPhone seems to be of the entire Apple ecosystem, it makes sense if you've bought into it already, or are choosing to buy into it, but not if you do not choose to be locked in.
Agreed, but there's workarounds. Also, I feel that way about Android considering its fragmentation limitations. I'm locked into some apps on Android I really don't prefer and iOS has better, more competitive choices of related apps that vastly suit me better.
It's all give and take, really. In the end, I choose Android (overall) but since I also have iOS devices I use for testing purposes, etc. I have no allusions that there's sacrifices I make by choosing Android over iOS.
>he's personally so deep into the Apple world that his perspective is skewed by that reality.
I'd focus less on ad hominem and more on the facts.
Your reasons are those of someone deeply involved in technology, which is not the case for the mass market. For them, just looking and feeling good is far more important.
I'd like to address the first list though, "There are a bunch of reasons why someone would buy a high-end Android rather than an iPhone".
That list does not include the two reasons that myself and people I know use Android:
1. We wish to have control over our devices
2. We have not invested heavily in either Apple or Google and we avoid making choices that will force us to be invested in one over the other
On the first point, control may be about privacy (using something like XPrivacy), personalisation (perhaps CyanogenMod), adblock (AdAway), or simply having more control over what runs to be able to extend the battery of a Nexus 5 to a few days of heavy use rather than a single day (kill all the background services but still have the apps available for us to use).
On the second point, myself and my friends do not use Google as an ecosystem or as a range of permanent services and virtual assistants. We invariably are using different launchers (Nova is most common), perhaps Duck Duck Go... and our Google footprint is really just to use some Google apps as standalone apps (Gmail, calendar, drive). We tend to get media from Kindle, or Spotify... so we're not even hooked on Google Play.
What this means is that we've avoided deep lock-in with Google, and we make choices that avoid being locked in to Microsoft or Apple too.
When I think of what most of my friends use, it's a mix of technologies. Apple and Lenovo laptops, the latter running Windows or Linux. iPods and Cowon music players. Mostly Android phones.
The biggest reasons not to go for an iPhone are the same reasons we haven't gone for an iPhone to date: It feels like an all or nothing decision that would be hard to change in the future.
The value of an iPhone seems to be of the entire Apple ecosystem, it makes sense if you've bought into it already, or are choosing to buy into it, but not if you do not choose to be locked in.
The value, to us, of an Android device is that you can get the benefits of this technology without having to be part of any ecosystem, Google's or Samsung's or that of anyone else (Amazon?).
I'm not sure it's possible for Benedict to see this any more... he's personally so deep into the Apple world that his perspective is skewed by that reality. The question of why anyone would choose not to be a part of an ecosystem isn't even asked. He's made it an Apple vs Google question, when the people I know using Android are not even considering that question.
PS: If I think of what entices people to consider an Apple iPhone more than anything else, it's the camera (usually noted as the software ecosystem around the camera). Photography on an iPhone bests every Android device there is. This is the single reason that some of my friends have an iPhone.