Interestingly, medical device manufacturers and healthcare enterprises are generally allowed to establish their own guidelines. Healthcare enterprises in particular are expected to use practical and reasonable resources to ensure the accessibility, confidentiality and integrity of protected health information.
There are numerous medical devices with claims of 99% availability. In fact, very few medical devices provide availability greater than 99.99% availability and none offer 100% availability. Furthermore, healthcare enterprises often can't or won't
A few years ago, I was a member of a team developing next generation medical devices for a multi-national conglomerate. We eventually determined that we would need two or more likely three major releases requiring nearly five years to reach 100% availability.
Most people fail to understand how challenging 100% availability truly is to achieve:
System monitoring including the ability to perform realistic process testing of all components including proprietary components
Stateless components (including proprietary components) with load balancing for automatic failover and fallback
Hot swappable drives of mirrored data with parity at geographically remote locations
Uptime during software updates including re-synchronization of duplicated databases
Data migration tools to move data from node to node in the event of node failure or node replacement
Database replication to local nodes for severability
At the dawning of realisation of a new problem hard facts and figures on a grand scale often aren't available. That doesn't mean there isn't a problem, and it doesn't mean the worry is FUD.
Apologism, it cuts both ways, and a bit of perspective makes all the difference. There are complaints out there, and that they exist is a fact.
I never said that there were no complaints, nor that their existence is a fact.
What I said was that there's no evidence that it's a widespread problem. With hundreds of millions of iDevices, there WILL be problems, no matter how good a job Apple did. So simply saying "there were some problems" is useless. Where's the evidence that it's a significant problem?
What matters isn't how widespread the problems are, but whether they are of a fundamental nature or of an accidental nature. To understand that difference: with hundreds of million iOS devices, there will be a certain number at any given time that develop e.g. flash memory or RAM failure. Such memory failure will corrupt data, which might get synced back and cause trouble. That is an accidental failure, because it's not a fault in the software system (although it might be considered a fundamental failure of iOS devices not to be engineered with parity or ECC RAM and error-detecting/correcting file systems).
On the other hand, if the software frameworks used in iOS and on the server side have bugs, that cause seemingly random, unpredictable and uncontrollable data corruption or loss, as seems to be the case when reading the detailed technical description of what sort of things happen, then it doesn't matter how frequent such bugs or design flaws are causing issues, their very existence renders the framework useless and untrustworthy, particularly since iCloud offers no methods of rolling back to a prior state, or allows the user to intervene before potentially damaging mutations to data occur.
So the number of iOS devices deployed is essentially completely orthogonal to the issue, since we're not talking about accidental failure modes here.
Interestingly, medical device manufacturers and healthcare enterprises are generally allowed to establish their own guidelines. Healthcare enterprises in particular are expected to use practical and reasonable resources to ensure the accessibility, confidentiality and integrity of protected health information.
There are numerous medical devices with claims of 99% availability. In fact, very few medical devices provide availability greater than 99.99% availability and none offer 100% availability. Furthermore, healthcare enterprises often can't or won't
A few years ago, I was a member of a team developing next generation medical devices for a multi-national conglomerate. We eventually determined that we would need two or more likely three major releases requiring nearly five years to reach 100% availability.
Most people fail to understand how challenging 100% availability truly is to achieve:
System monitoring including the ability to perform realistic process testing of all components including proprietary components
Stateless components (including proprietary components) with load balancing for automatic failover and fallback
Hot swappable drives of mirrored data with parity at geographically remote locations
Uptime during software updates including re-synchronization of duplicated databases
Data migration tools to move data from node to node in the event of node failure or node replacement
Database replication to local nodes for severability
While what you write here is all true, it's worth pointing out that I was talking about reliability, not availability. Lack of availability is just an occasional delay in data being pushed and working temporarily with an outdated copy.
If your computer needs to be rebooted due to an OS update, it stops being available, but it better not have lost its data and wiped out the backup when it's done being rebooted.
The problem described by developers however is data corruption and data loss. Quite different from working with good data that's a bit outdated or takes a bit longer to get refreshed.
Look at bit error rates for hard drives, and you realize that these devices' e.g. are 99.99999999999999% or there abouts reliable in reading/writing bits. And that's not good enough, which is why we invented journaling file systems, RAID-5/6, drive mirroring, backup, ZFS. And that's not good enough, which is why there is off-site, geographically diverse online-backup. That's why servers don't just have parity RAM, but ECC-RAM, why there is fail-over and clustering, etc.
The problem is, this is a multiplicative relationship of all components involved.
99.9% or 99.99% reliability in not corrupting or losing data is utterly in acceptable in any environment.
While what you write here is all true, it's worth pointing out that I was talking about reliability, not availability. Lack of availability is just an occasional delay in data being pushed and working temporarily with an outdated copy.
If your computer needs to be rebooted due to an OS update, it stops being available, but it better not have lost its data and wiped out the backup when it's done being rebooted.
The problem described by developers however is data corruption and data loss. Quite different from working with good data that's a bit outdated or takes a bit longer to get refreshed.
Look at bit error rates for hard drives, and you realize that these devices' e.g. are 99.99999999999999% or there abouts reliable in reading/writing bits. And that's not good enough, which is why we invented journaling file systems, RAID-5/6, drive mirroring, backup, ZFS. And that's not good enough, which is why there is off-site, geographically diverse online-backup. That's why servers don't just have parity RAM, but ECC-RAM, why there is fail-over and clustering, etc.
The problem is, this is a multiplicative relationship of all components involved.
99.9% or 99.99% reliability in not corrupting or losing data is utterly in acceptable in any environment.
Still waiting for that evidence on what percentage of data that is lost because of CoreData sync problems.
Note that most of the problems involve loss of data on the client device. It's still possible to wipe the device and restore the data from the server. But even that has never been quantified. Somehow, you Apple-bashers are keen to make the jump from "someone has complained about something" to "Apple is a failure because there's this massive problem out there." Where's the evidence about how often it occurs or how much data is lost?
Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
And just like that, you've proven you know nothing whatsoever about server back end infrastructure.
TS you really should stop that crap. It is unbecoming, unconstructive and counter-productive.
I think rcfa is absolutely on the ball regarding the importance of the issues he cites. I have 30 odd years behind me in managing both network infrastructure and large-scale internationally distributed databases and the points he raises are critical issues. The one thing that is absolutely intolerable for an infrastructure is to corrupt and lose data in a random and unpredictable way.
Failure of a service provider (IBM in this case) to provide the required degree of reliability and control was THE major reason for my company to terminate a long-term contract because we simply could not tolerate key JIT manufacturing control systems going down without warning, backups not being successful, fall-over not working, and a whole range of other issues. For business-critical apps, big data and serious databases, the requirements are orders of magnitude higher than for the "hundreds of millions of users" who think they can live with iCloud with all of its integrity and stability problems.
Still waiting for that evidence on what percentage of data that is lost because of CoreData sync problems.
Note that most of the problems involve loss of data on the client device. It's still possible to wipe the device and restore the data from the server. But even that has never been quantified. Somehow, you Apple-bashers are keen to make the jump from "someone has complained about something" to "Apple is a failure because there's this massive problem out there." Where's the evidence about how often it occurs or how much data is lost?
He doesn't seem to understand that lost data is not available data.
He doesn't seem to understand that lost data is not available data.
I'm not sure what you're saying or who you're referring to as 'he'.
In the end, though, no one has established that any data was lost - much less a significant amount. If your iphone has trouble syncing the data, you can try again later - or if it's corrupted, wipe the phone and sync the phone from scratch. All of the syncing problems appear to be on the client side, so the actual data is unlikely to be lost.
I'm not sure what you're saying or who you're referring to as 'he'.
In the end, though, no one has established that any data was lost - much less a significant amount. If your iphone has trouble syncing the data, you can try again later - or if it's corrupted, wipe the phone and sync the phone from scratch. All of the syncing problems appear to be on the client side, so the actual data is unlikely to be lost.
"He" is the obvious troll to whom you responded.
I agree entirely. I haven't seen a single objective analysis of iCloud other than my own. Until someone presents a rational, reasonable argument there is no need to attend their argument.
While what you write here is all true, it's worth pointing out that I was talking about reliability, not availability. Lack of availability is just an occasional delay in data being pushed and working temporarily with an outdated copy.
If your computer needs to be rebooted due to an OS update, it stops being available, but it better not have lost its data and wiped out the backup when it's done being rebooted.
The problem described by developers however is data corruption and data loss. Quite different from working with good data that's a bit outdated or takes a bit longer to get refreshed.
Look at bit error rates for hard drives, and you realize that these devices' e.g. are 99.99999999999999% or there abouts reliable in reading/writing bits. And that's not good enough, which is why we invented journaling file systems, RAID-5/6, drive mirroring, backup, ZFS. And that's not good enough, which is why there is off-site, geographically diverse online-backup. That's why servers don't just have parity RAM, but ECC-RAM, why there is fail-over and clustering, etc.
The problem is, this is a multiplicative relationship of all components involved.
99.9% or 99.99% reliability in not corrupting or losing data is utterly in acceptable in any environment.
Still waiting for that evidence on what percentage of data that is lost because of CoreData sync problems.
Note that most of the problems involve loss of data on the client device. It's still possible to wipe the device and restore the data from the server. But even that has never been quantified. Somehow, you Apple-bashers are keen to make the jump from "someone has complained about something" to "Apple is a failure because there's this massive problem out there." Where's the evidence about how often it occurs or how much data is lost?
Your answer displays a ridiculous wagenburg mentaility. Apple bashers? Me? Are you kidding? I have about 6 mac, an iPad, two iPhones, three iPads, oh, and a few old NeXTs around. PCs? Zero, except for one that's a hackintosh.
So I'm hardly an Apple basher. But Apple to me isn't a religion. I've as a programmer been through the exercise often enough that Apple releases APIs that are simply not ready for consumption. It's been a Jobsian problem to toss the kid with the bathwater, and get rid of functioning things because something new and superior is on the horizon, even if that new thing isn't ready for prime time.
Just look at FinalCut X. Do I think it's the better paradigm than old-style video editing? Yes. Do I think it was ready for release when it was released? No.
The result is, that people who need to be productive with video/film editing left the platform in droves, and now, after a few years of incremental upgrades Apple is finally at a point where they are trying to relauch the product with a major marketing campagne trying to regain the customers they chased away.
Apple has many strengths, but Apple's corporate culture has also several MAJOR flaws, flaws that they get away with, because they are hidden in the bottom line by big successes elsewhere. The problem however is, eventually these flaws will also hit a user community in Apple's eco system that's not relatively marginal, like iOS app developers or video editing professionals. At some point these corporate character flaws may well hit home with facebook using teenage girls, and then you might see a major drop in iPhone popularity.
Criticizing Apple for what they are actually doing wrong has nothing to do with being an Apple basher. Apple is not a religion, there is no infalible Apple like there is an infalible pope (if your a true catholic).
iCloud is a prime example of something that was rolled out before it was ready, and where the "old" was discarded before a suitable replacement was there, while stranding customers. Just because Apple can cover up such mistakes by selling millions of iPads doesn't mean it's not a mistake. Just because Apple poaches users from an ecosystem where nobody expects a decent user experience doesn't mean that those of us who have been using the products for decades and know how the user experience should and could be are not right pointing out what gets constantly screwed up.
Apple is too much driven by the "always new" mentality, instead first fixing the old, and introducing something new only when it's ready.
As to the percentage of and gravity of these incidents, that's something only Apple may say, who else has access to their server logs?
The only way to get a grip on that would be to create a test app that exercises these APIs and that is specifically designed to report back to the developer that number and kind of errors encountered by comparing a reference data set to what is in the app.
The way that could work is e.g. that updates to the dataset are send in an e-mail attachment a few times per day, the app opens the attachment, and tries to apply the changes. A Mac app, iPad app, etc. would all be active, and then the various liked apps would regularly check what the app developers web site says should be in their data set, and then compare with what's actually in their data set. If enough users would download and use such a test app, one could start getting some real statistics.
In the end, though, no one has established that any data was lost - much less a significant amount. If your iphone has trouble syncing the data, you can try again later - or if it's corrupted, wipe the phone and sync the phone from scratch. All of the syncing problems appear to be on the client side, so the actual data is unlikely to be lost.
Quote:
Originally Posted by Crowley
And where are your facts and numbers to back up your claim?
The two of you are not even arguing about the right issue.
As to the percentage of and gravity of these incidents, that's something only Apple may say, who else has access to their server logs?
OK, so you're bashing Apple and calling them incompetent without having a shred of evidence to support your claims.
Glad we got that cleared up.
I wish there were a nicer way to say this, but you're a certifiable idiot. You cleared up nothing, you try to act as a smart-ass sophist troll. (Look up the meaning, you probably don't know it.)
So that fact is fully sufficient to say that iCloud syncing sucks, which in turn has nothing to do with Apple being incompetent, but it has to to with Apple being irresponsible. Releasing a product before its ready just for the sake of being able to announce new stuff is retarded. Apple probably will get it right in another year or two, but if history is an indication, by then they are probably going to rename and replace iCloud again...
And where are your facts and numbers to back up your claim?
I'm not the one claiming that iCloud syncing stinks. It seems to me that the people making that claim are the ones who need to back it up.
Besides, how would one prove that no one lost data (even if I HAD made that claim)?
The point is, the people making that claim have backed it up, you just choose to ignore the information that people hold in front of your face because it doesn't fit your religion of being an Apple believer.
Of course, simply being an educated Apple user does not force me to view reality through such a distorted optic.
And, yet, in spite of all your whining and name calling, you haven't provided a single shred of evidence to support:
- The contention that this is a wide spread problem - The contention that anyone has lost ANY data - The contention that anyone has lost a significant amount of data - The contention that any other system is any better
Now, you may be happy running around and calling people idiots when they ask for evidence to back up your claims, but that's not particularly rational behavior. And your degree in Computer Science is irrelevant for two reasons: 1. You haven't demonstrated any of the claims above. Having a degree is useless if you refuse to use your brain along with it. 2. Apple has thousands of programmers with Comp Sci degrees, with many of them having even greater credentials than yours. So where's the evidence that you know more than they do?
You're engaging in mindless Apple-bashing and refuse to back up any of your claims with evidence. That's a pretty good definition of a troll.
Someone else already pointed this out but it bears repeating.
There is a really dumb fight going on in this thread. It is dumber than the typical ones in other threads because the participants are calling out each other for not providing facts or misunderstanding the issue. The fact is the participants are all off the mark. You are looking foolish. Really foolish. There have been some funny, silly fights on this site, but this one takes the cake. Please stop. You know who you are.
And, yet, in spite of all your whining and name calling, you haven't provided a single shred of evidence to support:
- The contention that this is a wide spread problem
- The contention that anyone has lost ANY data
- The contention that anyone has lost a significant amount of data
- The contention that any other system is any better
Now, you may be happy running around and calling people idiots when they ask for evidence to back up your claims, but that's not particularly rational behavior. And your degree in Computer Science is irrelevant for two reasons:
1. You haven't demonstrated any of the claims above. Having a degree is useless if you refuse to use your brain along with it.
2. Apple has thousands of programmers with Comp Sci degrees, with many of them having even greater credentials than yours. So where's the evidence that you know more than they do?
You're engaging in mindless Apple-bashing and refuse to back up any of your claims with evidence. That's a pretty good definition of a troll.
OK, to break it down for the mentally challenged:
Quote:
- The contention that this is a wide spread problem'
Things that are fundamentally broken affect 100% of users. Even if it may require certain ill-defined preconditions to trigger a bug, a bug in the code affects everyone who runs the program based on that code, and that would be 100% of iOS users.
To give a comparison: smoking increases the risk of having lung cancer for all smokers. What specific parameters and/or bad luck need to be present to actually trigger the cancer doesn't matter. What matters is, that smoking is a really unhealthy thing.
Same here: the code Apple currently has in production is fundamentally broken. Thus the bugs affect everyone using that code. The precise circumstances in which you get bitten by the bug may not be known, but it's sufficient to know you can't trust the code.
Your little rants are like someone trying to disprove the assertion that smoking is dangerous to people's health by saying that someone's granddad died at age 99 and has been a smoker for all his life.
Quote:
- The contention that anyone has lost ANY data
- The contention that anyone has lost a significant amount of data
That matter is clearly documented in the links provided multiple times. If you don't understand what's discussed there, you're not qualified to discuss this matter at all. When blobs are lost, classes swapped, links are broken, then OBVIOUSLY data is lost. Any data lost is significant. Of course, you don't care if anyone's data is lost, you care about your data. So with your mindset, as long as you didn't lose any data that matters to you, it's not a problem. That sort of thinking spelled trouble in a variety of totalitarian regimes in the last century.
The whole idea of distinguishing between "significant amounts" of data and "insignificant amounts" of data is ridiculous. Assuming you had a numbered bank account in Switzerland with 10 billion dollars on it, and you kept your access password in some iOS app, and now that password is lost. Is it a significant amount of data that's being lost, if a 10 digit string disappeared? Hey, it's only ten bytes, no big deal, is it?
Oh, the banks won't give you access to your ten billion dollars, who cares?
Quote:
- The contention that any other system is any better
That's totally irrelevant if something better is there or not, nor was that ever the question here. If the first plane kept crashing and killing everyone on board, it doesn't matter if there are or aren't better planes. All that matters is that THAT plane isn't working as it should. Get it?
I don't care if there are better sync options or not. What I do care about is that if Apple sells a sync option, it better work, or else Apple debug it until it works, and introduce it to the market when they're done debugging. It's not that hard to grok of a concept.
<span style="background-color:rgb(241,241,241);">Things that are fundamentally broken affect 100% of users. Even if it may require certain ill-defined preconditions to trigger a bug, a bug in the code affects everyone who runs the program based on that code, and that would be 100% of iOS users.
To give a comparison: smoking increases the risk of having lung cancer for all smokers. What specific parameters and/or bad luck need to be present to actually trigger the cancer doesn't matter. What matters is, that smoking is a really unhealthy thing.</span>
<span style="background-color:rgb(241,241,241);">Same here: the code Apple currently has in production is fundamentally broken. Thus the bugs affect everyone using that code. The precise circumstances in which you get bitten by the bug may not be known, but it's sufficient to know you can't trust the code.</span>
<span style="background-color:rgb(241,241,241);">Your little rants are like someone trying to disprove the assertion that smoking is dangerous to people's health by saying that someone's granddad died at age 99 and has been a smoker for all his life.</span>
<span style="background-color:rgb(241,241,241);line-height:1.231;">That matter is clearly documented in the links provided multiple times. If you don't understand what's discussed there, you're not qualified to discuss this matter at all. When blobs are lost, classes swapped, links are broken, then OBVIOUSLY data is lost. Any data lost is significant. Of course, you don't care if anyone's data is lost, you care about your data. So with your mindset, as long as you didn't lose any data that matters to you, it's not a problem. That sort of thinking spelled trouble in a variety of totalitarian regimes in the last century.</span>
<span style="background-color:rgb(241,241,241);line-height:1.231;">The whole idea of distinguishing between "significant amounts" of data and "insignificant amounts" of data is ridiculous. Assuming you had a numbered bank account in Switzerland with 10 billion dollars on it, and you kept your access password in some iOS app, and now that password is lost. Is it a significant amount of data that's being lost, if a 10 digit string disappeared? Hey, it's only ten bytes, no big deal, is it? </span>
<span style="background-color:rgb(241,241,241);line-height:1.231;">Oh, the banks won't give you access to your ten billion dollars, who cares?</span>
That's totally irrelevant if something better is there or not, nor was that ever the question here. If the first plane kept crashing and killing everyone on board, it doesn't matter if there are or aren't better planes. All that matters is that THAT plane isn't working as it should. Get it?
I don't care if there are better sync options or not. What I do care about is that if Apple sells a sync option, it better work, or else Apple debug it until it works, and introduce it to the market when they're done debugging. It's not that hard to grok of a concept.
That's a lot of words to say "I don't really know how serious of a problem it is, nor has anyone demonstrated that it's a serious problem, but I'll continue to rant and bash Apple all the same".
Jesus Christ are you really denying that a problem that even Gruber and DED states exist isn't real?
No one ever denied that it's a problem. Rather, I'm asking all the Apple-bashers to provide evidence that it's a problem that has a significant impact on any significant number of users. Perhaps you should learn to read.
Comments
Interestingly, medical device manufacturers and healthcare enterprises are generally allowed to establish their own guidelines. Healthcare enterprises in particular are expected to use practical and reasonable resources to ensure the accessibility, confidentiality and integrity of protected health information.
There are numerous medical devices with claims of 99% availability. In fact, very few medical devices provide availability greater than 99.99% availability and none offer 100% availability. Furthermore, healthcare enterprises often can't or won't
A few years ago, I was a member of a team developing next generation medical devices for a multi-national conglomerate. We eventually determined that we would need two or more likely three major releases requiring nearly five years to reach 100% availability.
Most people fail to understand how challenging 100% availability truly is to achieve:
Quote:
Originally Posted by jragosta
Quote:
Originally Posted by Crowley
At the dawning of realisation of a new problem hard facts and figures on a grand scale often aren't available. That doesn't mean there isn't a problem, and it doesn't mean the worry is FUD.
Apologism, it cuts both ways, and a bit of perspective makes all the difference. There are complaints out there, and that they exist is a fact.
I never said that there were no complaints, nor that their existence is a fact.
What I said was that there's no evidence that it's a widespread problem. With hundreds of millions of iDevices, there WILL be problems, no matter how good a job Apple did. So simply saying "there were some problems" is useless. Where's the evidence that it's a significant problem?
What matters isn't how widespread the problems are, but whether they are of a fundamental nature or of an accidental nature. To understand that difference: with hundreds of million iOS devices, there will be a certain number at any given time that develop e.g. flash memory or RAM failure. Such memory failure will corrupt data, which might get synced back and cause trouble. That is an accidental failure, because it's not a fault in the software system (although it might be considered a fundamental failure of iOS devices not to be engineered with parity or ECC RAM and error-detecting/correcting file systems).
On the other hand, if the software frameworks used in iOS and on the server side have bugs, that cause seemingly random, unpredictable and uncontrollable data corruption or loss, as seems to be the case when reading the detailed technical description of what sort of things happen, then it doesn't matter how frequent such bugs or design flaws are causing issues, their very existence renders the framework useless and untrustworthy, particularly since iCloud offers no methods of rolling back to a prior state, or allows the user to intervene before potentially damaging mutations to data occur.
So the number of iOS devices deployed is essentially completely orthogonal to the issue, since we're not talking about accidental failure modes here.
Quote:
Originally Posted by MacBook Pro
Quote:
Originally Posted by anantksundaram
What does it expect?
Interestingly, medical device manufacturers and healthcare enterprises are generally allowed to establish their own guidelines. Healthcare enterprises in particular are expected to use practical and reasonable resources to ensure the accessibility, confidentiality and integrity of protected health information.
There are numerous medical devices with claims of 99% availability. In fact, very few medical devices provide availability greater than 99.99% availability and none offer 100% availability. Furthermore, healthcare enterprises often can't or won't
A few years ago, I was a member of a team developing next generation medical devices for a multi-national conglomerate. We eventually determined that we would need two or more likely three major releases requiring nearly five years to reach 100% availability.
Most people fail to understand how challenging 100% availability truly is to achieve:
System monitoring including the ability to perform realistic process testing of all components including proprietary components
Stateless components (including proprietary components) with load balancing for automatic failover and fallback
Hot swappable drives of mirrored data with parity at geographically remote locations
Uptime during software updates including re-synchronization of duplicated databases
Data migration tools to move data from node to node in the event of node failure or node replacement
Database replication to local nodes for severability
While what you write here is all true, it's worth pointing out that I was talking about reliability, not availability. Lack of availability is just an occasional delay in data being pushed and working temporarily with an outdated copy.
If your computer needs to be rebooted due to an OS update, it stops being available, but it better not have lost its data and wiped out the backup when it's done being rebooted.
The problem described by developers however is data corruption and data loss. Quite different from working with good data that's a bit outdated or takes a bit longer to get refreshed.
Look at bit error rates for hard drives, and you realize that these devices' e.g. are 99.99999999999999% or there abouts reliable in reading/writing bits. And that's not good enough, which is why we invented journaling file systems, RAID-5/6, drive mirroring, backup, ZFS. And that's not good enough, which is why there is off-site, geographically diverse online-backup. That's why servers don't just have parity RAM, but ECC-RAM, why there is fail-over and clustering, etc.
The problem is, this is a multiplicative relationship of all components involved.
99.9% or 99.99% reliability in not corrupting or losing data is utterly in acceptable in any environment.
Still waiting for that evidence on what percentage of data that is lost because of CoreData sync problems.
Note that most of the problems involve loss of data on the client device. It's still possible to wipe the device and restore the data from the server. But even that has never been quantified. Somehow, you Apple-bashers are keen to make the jump from "someone has complained about something" to "Apple is a failure because there's this massive problem out there." Where's the evidence about how often it occurs or how much data is lost?
Quote:
Originally Posted by Tallest Skil
Originally Posted by rcfa
Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
And just like that, you've proven you know nothing whatsoever about server back end infrastructure.
TS you really should stop that crap. It is unbecoming, unconstructive and counter-productive.
I think rcfa is absolutely on the ball regarding the importance of the issues he cites. I have 30 odd years behind me in managing both network infrastructure and large-scale internationally distributed databases and the points he raises are critical issues. The one thing that is absolutely intolerable for an infrastructure is to corrupt and lose data in a random and unpredictable way.
Failure of a service provider (IBM in this case) to provide the required degree of reliability and control was THE major reason for my company to terminate a long-term contract because we simply could not tolerate key JIT manufacturing control systems going down without warning, backups not being successful, fall-over not working, and a whole range of other issues. For business-critical apps, big data and serious databases, the requirements are orders of magnitude higher than for the "hundreds of millions of users" who think they can live with iCloud with all of its integrity and stability problems.
He doesn't seem to understand that lost data is not available data.
I'm not sure what you're saying or who you're referring to as 'he'.
In the end, though, no one has established that any data was lost - much less a significant amount. If your iphone has trouble syncing the data, you can try again later - or if it's corrupted, wipe the phone and sync the phone from scratch. All of the syncing problems appear to be on the client side, so the actual data is unlikely to be lost.
"He" is the obvious troll to whom you responded.
I agree entirely. I haven't seen a single objective analysis of iCloud other than my own. Until someone presents a rational, reasonable argument there is no need to attend their argument.
Quote:
Originally Posted by jragosta
Quote:
Originally Posted by rcfa
While what you write here is all true, it's worth pointing out that I was talking about reliability, not availability. Lack of availability is just an occasional delay in data being pushed and working temporarily with an outdated copy.
If your computer needs to be rebooted due to an OS update, it stops being available, but it better not have lost its data and wiped out the backup when it's done being rebooted.
The problem described by developers however is data corruption and data loss. Quite different from working with good data that's a bit outdated or takes a bit longer to get refreshed.
Look at bit error rates for hard drives, and you realize that these devices' e.g. are 99.99999999999999% or there abouts reliable in reading/writing bits. And that's not good enough, which is why we invented journaling file systems, RAID-5/6, drive mirroring, backup, ZFS. And that's not good enough, which is why there is off-site, geographically diverse online-backup. That's why servers don't just have parity RAM, but ECC-RAM, why there is fail-over and clustering, etc.
The problem is, this is a multiplicative relationship of all components involved.
99.9% or 99.99% reliability in not corrupting or losing data is utterly in acceptable in any environment.
Still waiting for that evidence on what percentage of data that is lost because of CoreData sync problems.
Note that most of the problems involve loss of data on the client device. It's still possible to wipe the device and restore the data from the server. But even that has never been quantified. Somehow, you Apple-bashers are keen to make the jump from "someone has complained about something" to "Apple is a failure because there's this massive problem out there." Where's the evidence about how often it occurs or how much data is lost?
Your answer displays a ridiculous wagenburg mentaility. Apple bashers? Me? Are you kidding? I have about 6 mac, an iPad, two iPhones, three iPads, oh, and a few old NeXTs around. PCs? Zero, except for one that's a hackintosh.
So I'm hardly an Apple basher. But Apple to me isn't a religion. I've as a programmer been through the exercise often enough that Apple releases APIs that are simply not ready for consumption. It's been a Jobsian problem to toss the kid with the bathwater, and get rid of functioning things because something new and superior is on the horizon, even if that new thing isn't ready for prime time.
Just look at FinalCut X. Do I think it's the better paradigm than old-style video editing? Yes. Do I think it was ready for release when it was released? No.
The result is, that people who need to be productive with video/film editing left the platform in droves, and now, after a few years of incremental upgrades Apple is finally at a point where they are trying to relauch the product with a major marketing campagne trying to regain the customers they chased away.
Apple has many strengths, but Apple's corporate culture has also several MAJOR flaws, flaws that they get away with, because they are hidden in the bottom line by big successes elsewhere. The problem however is, eventually these flaws will also hit a user community in Apple's eco system that's not relatively marginal, like iOS app developers or video editing professionals. At some point these corporate character flaws may well hit home with facebook using teenage girls, and then you might see a major drop in iPhone popularity.
Criticizing Apple for what they are actually doing wrong has nothing to do with being an Apple basher. Apple is not a religion, there is no infalible Apple like there is an infalible pope (if your a true catholic).
iCloud is a prime example of something that was rolled out before it was ready, and where the "old" was discarded before a suitable replacement was there, while stranding customers. Just because Apple can cover up such mistakes by selling millions of iPads doesn't mean it's not a mistake. Just because Apple poaches users from an ecosystem where nobody expects a decent user experience doesn't mean that those of us who have been using the products for decades and know how the user experience should and could be are not right pointing out what gets constantly screwed up.
Apple is too much driven by the "always new" mentality, instead first fixing the old, and introducing something new only when it's ready.
http://rms2.tumblr.com/post/46505165521/the-gathering-storm-our-travails-with-icloud-sync describes quite well what are the technical issues with this, and what's described there are fundamental issues with how things work.
As to the percentage of and gravity of these incidents, that's something only Apple may say, who else has access to their server logs?
The only way to get a grip on that would be to create a test app that exercises these APIs and that is specifically designed to report back to the developer that number and kind of errors encountered by comparing a reference data set to what is in the app.
The way that could work is e.g. that updates to the dataset are send in an e-mail attachment a few times per day, the app opens the attachment, and tries to apply the changes. A Mac app, iPad app, etc. would all be active, and then the various liked apps would regularly check what the app developers web site says should be in their data set, and then compare with what's actually in their data set. If enough users would download and use such a test app, one could start getting some real statistics.
Quote:
Originally Posted by jragosta
In the end, though, no one has established that any data was lost - much less a significant amount. If your iphone has trouble syncing the data, you can try again later - or if it's corrupted, wipe the phone and sync the phone from scratch. All of the syncing problems appear to be on the client side, so the actual data is unlikely to be lost.
Quote:
Originally Posted by Crowley
And where are your facts and numbers to back up your claim?
The two of you are not even arguing about the right issue.
I'm not the one claiming that iCloud syncing stinks. It seems to me that the people making that claim are the ones who need to back it up.
Besides, how would one prove that no one lost data (even if I HAD made that claim)?
OK, so you're bashing Apple and calling them incompetent without having a shred of evidence to support your claims.
Glad we got that cleared up.
Quote:
Originally Posted by jragosta
Quote:
Originally Posted by rcfa
As to the percentage of and gravity of these incidents, that's something only Apple may say, who else has access to their server logs?
OK, so you're bashing Apple and calling them incompetent without having a shred of evidence to support your claims.
Glad we got that cleared up.
I wish there were a nicer way to say this, but you're a certifiable idiot. You cleared up nothing, you try to act as a smart-ass sophist troll. (Look up the meaning, you probably don't know it.)
The technical issues with syncing are clearly documented (e.g.; http://rms2.tumblr.com/post/46505165521/the-gathering-storm-our-travails-with-icloud-sync and http://lhunath.github.com/UbiquityStoreManager/ ), and anyone with half a background in computing (I may add I have a Sc.M. in Computer Science from an Ivy League university, so I think that qualifies) can tell from that description that the issue here is a half-baked API and infrastructure, which Apple sells as ready for primetime while carefully avoiding using it themselves.
So that fact is fully sufficient to say that iCloud syncing sucks, which in turn has nothing to do with Apple being incompetent, but it has to to with Apple being irresponsible. Releasing a product before its ready just for the sake of being able to announce new stuff is retarded. Apple probably will get it right in another year or two, but if history is an indication, by then they are probably going to rename and replace iCloud again...
Quote:
Originally Posted by jragosta
Quote:
Originally Posted by Crowley
And where are your facts and numbers to back up your claim?
I'm not the one claiming that iCloud syncing stinks. It seems to me that the people making that claim are the ones who need to back it up.
Besides, how would one prove that no one lost data (even if I HAD made that claim)?
The point is, the people making that claim have backed it up, you just choose to ignore the information that people hold in front of your face because it doesn't fit your religion of being an Apple believer.
Of course, simply being an educated Apple user does not force me to view reality through such a distorted optic.
- The contention that this is a wide spread problem
- The contention that anyone has lost ANY data
- The contention that anyone has lost a significant amount of data
- The contention that any other system is any better
Now, you may be happy running around and calling people idiots when they ask for evidence to back up your claims, but that's not particularly rational behavior. And your degree in Computer Science is irrelevant for two reasons:
1. You haven't demonstrated any of the claims above. Having a degree is useless if you refuse to use your brain along with it.
2. Apple has thousands of programmers with Comp Sci degrees, with many of them having even greater credentials than yours. So where's the evidence that you know more than they do?
You're engaging in mindless Apple-bashing and refuse to back up any of your claims with evidence. That's a pretty good definition of a troll.
Someone else already pointed this out but it bears repeating.
There is a really dumb fight going on in this thread. It is dumber than the typical ones in other threads because the participants are calling out each other for not providing facts or misunderstanding the issue. The fact is the participants are all off the mark. You are looking foolish. Really foolish. There have been some funny, silly fights on this site, but this one takes the cake. Please stop. You know who you are.
Quote:
Originally Posted by jragosta
And, yet, in spite of all your whining and name calling, you haven't provided a single shred of evidence to support:
- The contention that this is a wide spread problem
- The contention that anyone has lost ANY data
- The contention that anyone has lost a significant amount of data
- The contention that any other system is any better
Now, you may be happy running around and calling people idiots when they ask for evidence to back up your claims, but that's not particularly rational behavior. And your degree in Computer Science is irrelevant for two reasons:
1. You haven't demonstrated any of the claims above. Having a degree is useless if you refuse to use your brain along with it.
2. Apple has thousands of programmers with Comp Sci degrees, with many of them having even greater credentials than yours. So where's the evidence that you know more than they do?
You're engaging in mindless Apple-bashing and refuse to back up any of your claims with evidence. That's a pretty good definition of a troll.
OK, to break it down for the mentally challenged:
Quote:
- The contention that this is a wide spread problem'
Things that are fundamentally broken affect 100% of users. Even if it may require certain ill-defined preconditions to trigger a bug, a bug in the code affects everyone who runs the program based on that code, and that would be 100% of iOS users.
To give a comparison: smoking increases the risk of having lung cancer for all smokers. What specific parameters and/or bad luck need to be present to actually trigger the cancer doesn't matter. What matters is, that smoking is a really unhealthy thing.
Same here: the code Apple currently has in production is fundamentally broken. Thus the bugs affect everyone using that code. The precise circumstances in which you get bitten by the bug may not be known, but it's sufficient to know you can't trust the code.
Your little rants are like someone trying to disprove the assertion that smoking is dangerous to people's health by saying that someone's granddad died at age 99 and has been a smoker for all his life.
Quote:
- The contention that anyone has lost ANY data
- The contention that anyone has lost a significant amount of data
That matter is clearly documented in the links provided multiple times. If you don't understand what's discussed there, you're not qualified to discuss this matter at all. When blobs are lost, classes swapped, links are broken, then OBVIOUSLY data is lost. Any data lost is significant. Of course, you don't care if anyone's data is lost, you care about your data. So with your mindset, as long as you didn't lose any data that matters to you, it's not a problem. That sort of thinking spelled trouble in a variety of totalitarian regimes in the last century.
The whole idea of distinguishing between "significant amounts" of data and "insignificant amounts" of data is ridiculous. Assuming you had a numbered bank account in Switzerland with 10 billion dollars on it, and you kept your access password in some iOS app, and now that password is lost. Is it a significant amount of data that's being lost, if a 10 digit string disappeared? Hey, it's only ten bytes, no big deal, is it?
Oh, the banks won't give you access to your ten billion dollars, who cares?
Quote:
- The contention that any other system is any better
That's totally irrelevant if something better is there or not, nor was that ever the question here. If the first plane kept crashing and killing everyone on board, it doesn't matter if there are or aren't better planes. All that matters is that THAT plane isn't working as it should. Get it?
I don't care if there are better sync options or not. What I do care about is that if Apple sells a sync option, it better work, or else Apple debug it until it works, and introduce it to the market when they're done debugging. It's not that hard to grok of a concept.
That's a lot of words to say "I don't really know how serious of a problem it is, nor has anyone demonstrated that it's a serious problem, but I'll continue to rant and bash Apple all the same".
No one ever denied that it's a problem. Rather, I'm asking all the Apple-bashers to provide evidence that it's a problem that has a significant impact on any significant number of users. Perhaps you should learn to read.