or Connect
AppleInsider › Forums › Mobile › iCloud › Apple's iCloud disparaged over Core Data sync problems
New Posts  All Forums:Forum Nav:

Apple's iCloud disparaged over Core Data sync problems - Page 3

post #81 of 117
Quote:
Originally Posted by anantksundaram View Post

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
post #82 of 117
Quote:
Originally Posted by jragosta View Post

Quote:
Originally Posted by Crowley View Post

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.

post #83 of 117
Quote:
Originally Posted by MacBook Pro View Post

Quote:
Originally Posted by anantksundaram View Post

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.

post #84 of 117
Quote:
Originally Posted by rcfa View Post

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?
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #85 of 117
Quote:
Originally Posted by Tallest Skil View Post

Originally Posted by rcfa View Post

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.

post #86 of 117
Quote:
Originally Posted by jragosta View Post

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.
post #87 of 117
Quote:
Originally Posted by MacBook Pro View Post

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 way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #88 of 117
Quote:
Originally Posted by jragosta View Post

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.
post #89 of 117
Quote:
Originally Posted by jragosta View Post

Quote:
Originally Posted by rcfa View Post

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.

post #90 of 117
Quote:
Originally Posted by jragosta View Post

All of the syncing problems appear to be on the client side, so the actual data is unlikely to be lost.
And where are your facts and numbers to back up your claim?

censored

Reply

censored

Reply
post #91 of 117
Quote:
Originally Posted by jragosta View Post

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 View Post


And where are your facts and numbers to back up your claim?


The two of you are not even arguing about the right issue.

post #92 of 117
Quote:
Originally Posted by Crowley View Post

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)?
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #93 of 117
Quote:
Originally Posted by rcfa View Post

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'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #94 of 117
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.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #95 of 117

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.

post #96 of 117
Quote:
Originally Posted by jragosta View Post

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.

post #97 of 117
Jesus Christ are you really denying that a problem that even Gruber and DED states exist isn't real?
post #98 of 117
Quote:
Originally Posted by rcfa View Post

OK, to break it down for the mentally challenged:



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.



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?




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".

Quote:
Originally Posted by nht View Post

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.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #99 of 117
Quote:
Originally Posted by stelligent View Post

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.

So asking for people to provide facts to back up their claims is foolish? Maybe you should read a book about debate.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #100 of 117
Quote:
Originally Posted by jragosta View Post

Perhaps you should learn to read.

Perhaps you should learn to pick your battles.

The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.

This is well documented and unless you think these devs quoted by Ars and others are incompetent or anti-Apple then you have to accept that the problem is significant for them in the same way you accept the devs reports that say that Android fragmentation is a significant issue for them.

Both can be worked around but both require a lot more developer effort than it should to the point that many devs simply don't use core data sync or simply punt and target the Android 2.x API and forego the 4.x ones.

Core data sync is a technically hard challenge. More timely Android updates is a politically and economically hard challenge.

Both impact uses and developers in the same way: less able apps.
post #101 of 117
Quote:
Originally Posted by nht View Post

Perhaps you should learn to pick your battles.

The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.

This is well documented and unless you think these devs quoted by Ars and others are incompetent or anti-Apple then you have to accept that the problem is significant for them in the same way you accept the devs reports that say that Android fragmentation is a significant issue for them.

Both can be worked around but both require a lot more developer effort than it should to the point that many devs simply don't use core data sync or simply punt and target the Android 2.x API and forego the 4.x ones.

Core data sync is a technically hard challenge. More timely Android updates is a politically and economically hard challenge.

Both impact uses and developers in the same way: less able apps.

Well put, more or less. But there's no workaround. Anyhow, you're wasting your time. Some people's mission is to drown out ant anti-Apple noise because they believe themselves credible enough to protect the stock. On the other hand, those who jump on this as evidence that iCloud doesn't work are equally off base.
post #102 of 117
Quote:
Originally Posted by nht View Post

Perhaps you should learn to pick your battles.

The fact is that data has been lost and devs do have problems using core data sync via iCloud and it doesn't work as well as advertised to the dev community.
.

Where's the evidence that data was lost due to CoreData?

You seem to think that simply repeating the same made up statement over and over again will make it true.

More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?

Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #103 of 117
Quote:
Originally Posted by jragosta View Post

So asking for people to provide facts to back up their claims is foolish? Maybe you should read a book about debate.

You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.
post #104 of 117
Quote:
Originally Posted by jragosta View Post

Where's the evidence that data was lost due to CoreData?

You seem to think that simply repeating the same made up statement over and over again will make it true.

More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?

Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.

There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself.
https://discussions.apple.com/thread/3382799?start=105&tstart=0
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #105 of 117
Quote:
Originally Posted by ankleskater View Post

You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.

So all the people running around screaming "Apple is evil", "Apple is incompetent", "Horrible problem", "End of the World" are rational adults while the person who says "where is the evidence to support your claim?" is a kid screaming for candy?

Is it opposite day already?

Quote:
Originally Posted by Gatorguy View Post

There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself.
https://discussions.apple.com/thread/3382799?start=105&tstart=0

OK, so someone has finally pointed to a few people who lost data. That does not, however, prove the assertion that CoreData is at fault, nor that it's a serious problem.

There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up. And with hundreds of millions of iDevices, someone will undoubtedly have any problem that you can imagine. Once again, there's no evidence that it's a significant problem, not that the problem is due to deficiencies in CoreData.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #106 of 117
Originally Posted by jragosta View Post
Is it opposite day already?

 

April Fool's Day, at least.


There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up.

 

Bingo. It's just conversion disorder.


Edited by Tallest Skil - 4/1/13 at 8:31am

Originally Posted by Slurpy

There's just a TINY chance that Apple will also be able to figure out payments. Oh wait, they did already… …and you’re already f*ed.

 

Reply

Originally Posted by Slurpy

There's just a TINY chance that Apple will also be able to figure out payments. Oh wait, they did already… …and you’re already f*ed.

 

Reply
post #107 of 117
Quote:
Originally Posted by jragosta View Post

Where's the evidence that data was lost due to CoreData?

You seem to think that simply repeating the same made up statement over and over again will make it true.

More importantly, where is the evidence that it's a significant problem? There are hundreds of millions of iDevices. If it were a serious problem, where are the millions of users picketing Cupertino to complain?

Sure, some developers don't like it. Big deal. Some developers wouldn't like it if Apple created software that would automatically convert their concepts into perfect code. Making every single developer 100% happy is not possible - nor is it Apple's job.

 

If you're going to use this metric then don't be surprised if someone does the same to you the next time you cry Android fragmentation.

 

However:

 

"So, it finally happened. The worst case scenario for any independent iPhone developer occurred. Several users are reporting complete data loss after upgrading my app. iCloud Core Data sync is not working. My users are using this app partially to run their businesses. This is a truly catastrophic failure."

 

(emphasis by the original poster)

 

http://stackoverflow.com/questions/14478517/more-icloud-core-data-synching-woes

 

People don't bitch to apple.  They bitch at app devs and leave them 1 star reviews because from a user perspective it is the app that's failing and losing stuff.

 

In any case, links have been provide to you with the difficulties regarding Core Data synching via iCloud to the point that I believe that the matter is sufficiently supported that the onus is on you to show that this isn't a problem.  Providing links to dev blogs and news articles seems to be producing a LALALALALA I CAN'T HEAR YOU response.

 

And it's not that they don't like it.  It's that it is broken and some developers are removing Core Data iCloud synching from their already approved apps because they don't like 1 star reviews and unhappy users.

post #108 of 117
Quote:
Originally Posted by nht View Post

If you're going to use this metric then don't be surprised if someone does the same to you the next time you cry Android fragmentation.

However:

"So, it finally happened. The worst case scenario for any independent iPhone developer occurred. Several users are reporting complete data loss
 after upgrading my app. iCloud Core Data sync is not working. My users are using this app partially to run their businesses. This is a truly catastrophic failure
."

(emphasis by the original poster)

http://stackoverflow.com/questions/14478517/more-icloud-core-data-synching-woes

People don't bitch to apple.  They bitch at app devs and leave them 1 star reviews because from a user perspective it is the app that's failing and losing stuff.

In any case, links have been provide to you with the difficulties regarding Core Data synching via iCloud to the point that I believe that the matter is sufficiently supported that the onus is on you to show that this isn't a problem.  Providing links to dev blogs and news articles seems to be producing a LALALALALA I CAN'T HEAR YOU response.

And it's not that they don't like it.  It's that it is broken and some developers are removing Core Data iCloud synching from their already approved apps because they don't like 1 star reviews and unhappy users.

Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?

1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".

Not a very convincing argument that Apple's at fault.

If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?
Edited by jragosta - 4/1/13 at 10:37am
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #109 of 117
Quote:
Originally Posted by mstone View Post

The Google solution is that you need to be connected to the Internet or you can't work. That way there is no syncing to be done because there is only one copy of the data, which is the way it should be.

 

If you are going to rely on the cloud then you need always on network connections.

 

That's not correct.  Google sync works even if you are not connected to the cloud.  I can change contact details on my Android phone with no cell coverage or wifi and the next time, the phone connects, it sync the contact to the cloud.  It definitely is a tough problem to solve, but Google has nailed it.  Palm had done  a pretty good job as well with the Palm Desktop as well.  Of course it was on a PC rather than in the cloud and it was one device as opposed to multiple devices.  But if the cloud becomes the master, than the same principle that applies that Palm used except that keeping multiple devices in sync is obviously harder.

 

Now I haven't done really extensive tests where I haven't had connectivity for days and made changes to my phone.  But when I got my G1 (Android 1.0), this was the first thing I tried because this was the single biggest think I missed from my Palm days and no intervening device since I stopped using my Palm pilots ever got it right.

post #110 of 117
Quote:
Originally Posted by jragosta View Post

Still waiting for your evidence that it's Apple's fault. How do you know it's not just crappy coding?

1. App works fine.
2. Developer changes something in app and issues new version.
3. App stops working.
4. Developer says "it's not my fault - blame Apple".

Not a very convincing argument that Apple's at fault.

If CoreData were so bad, why aren't ALL apps failing? Why is it that the number of complaints can be counted on one hand? If it were the massive disaster that you and this developer claim, wouldn't everyone have problems?

 

There's nothing wrong with CoreData.  It's robust.  It's iCloud synching of objects within CoreData that appears problematic. 

 

First, not all apps use CoreData.  Simpler apps might not.  Some apps that need more complex object persistence and retrieval will opt to use a database directly rather than through the Core Data through something like FMDB.  The apps that don't hit the DB directly but have complex object mappings appear to me to be the problematic use cases for Core Data syncing.  You can create your own very complex object models with complex relationships in Core Data.  

 

Second, not all apps that use CoreData needs to sync between devices OR is itself already a local CoreData based copy of an enterprise database that is accessed via the web and sync'd manually by the dev.  CoreData is one option for us if we did an iOS app but most likely we'll use FMDB to our own enterprise server and locally persist data (probably using CoreData) if we did iOS.  Thus the set of apps that would use CoreData sync is a smaller subset of all CoreData apps.

 

Third, synching federated databases correctly is hard and you have to put in careful thought in your database design.  An app designed for local CoreData may or may not be able to maintain integrity in a distributed synching mechanism.  You can blame this on the app developer if you like but remember that CoreData is a data abstraction made by Apple for developers to use in a "it just works" way and for objects to sync across devices as if the backend database were magically federated in an asynchronous environment with global serializability.  Unfortunately the devil is always in the details and for very simple object graphs this might work well but there appear to be commonly used cases where it's doesn't.  App developers that use CoreData in an advanced way have reportedly run into these issues since they are the most demanding CoreData apps with the most complex object graphs.    

 

 

So you're trying to sync complex object trees across multiple devices in a peer to peer fashion across time.  This is hard to do correctly with a known static object structure.  This is insanely hard over arbitrary object trees that joe random developer can create.  This is why everyone went ohh ahh when Steve announced this. 

 

These apps are your money apps and other apps that store and manipulate more than an average amount of data.  These are the apps where losing data or invalid syncs are the most damaging.  There are fewer of these apps but they are of significant importance in the ecosystem.  This is why not "all" apps are failing.  Not all apps are demanding in the same way.  This should be obvious. 

 

I am not a current iOS dev and I'm not up to speed on CoreData (as in I've read about it but written no code) but it's powerful and allows you to very easily build a MVC app with very little code if you use controller classes and widgets provided by Apple.  It's the standard object persistence layer for Cocoa and you get an assload of functionality for free.

 

But based on actual dev reports not bulletproof synching.

 

Tl;DR:

 

The devs I've read seem to think there's a significant issue and they aren't writing trivial apps.  They are not idiots and are well respected in the community and when they explain the issues to the wider dev community other devs nod their heads and get it.  The problem is insanely hard to solve correctly for an arbitrary set of use cases.

 

So who the hell are you to gainsay them?  I wrote all that crap above because I can't prove to you I'm a dev but I can show I understand the issue.  I'm sure you'll just blow that off and ask for more "proof" regardless of what is provided.  

 

Seriously, when devs say this is broken and other devs like Marco Arment and heavyweight tech guys like John Siracusa say "yah, that's pretty borked" WTF other "proof" do you need?

post #111 of 117
Quote:
Originally Posted by ViktorCode View Post


1. Comparing to Drop Box or Google online services is meaningless. Both of those do not sync databases, unless you represent them as a plain file or a simple key-value set. Maybe iCloud is the only db syncing service out there, maybe not. I don’t know. Would be great to see another example that does the same thing.

 

IBM had DB2Sync which would sync a SQL database on the Palm with DB2.  Used to work quite well back in the day.

post #112 of 117
Quote:
Originally Posted by os2baba View Post

 

That's not correct.  Google sync works even if you are not connected to the cloud.  I can change contact details on my Android phone with no cell coverage or wifi and the next time, the phone connects, it sync the contact to the cloud.  It definitely is a tough problem to solve, but Google has nailed it.  Palm had done  a pretty good job as well with the Palm Desktop as well.  Of course it was on a PC rather than in the cloud and it was one device as opposed to multiple devices.  But if the cloud becomes the master, than the same principle that applies that Palm used except that keeping multiple devices in sync is obviously harder.

 

Now I haven't done really extensive tests where I haven't had connectivity for days and made changes to my phone.  But when I got my G1 (Android 1.0), this was the first thing I tried because this was the single biggest think I missed from my Palm days and no intervening device since I stopped using my Palm pilots ever got it right.

 

The problem is harder.  Imagine you have 4 android devices which all make changes to contacts.  1 deletes it.  The other decides to change the addresses.  Another changes the address to a different address.  One renames the contact to something else.  They all happen around the same time offline but now you have 4 object trees with conflicting results in them.

 

Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things.  I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone"  then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party".  Then internet came back on in my home.

 

What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process.  And I'm not sure the App developer has visibility on what the hell happened in the iCloud.

 

And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user.  And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.

post #113 of 117
Quote:
Originally Posted by rcfa View Post

 

Multiple informative posts

 

I'm amazed that there is even a debate on the inviolateness of data.  This is Rule#1, #2 and #3 of enterprise software.  When I first started programming, I was astonished when told that I could yank the power plug on the mainframe and if it was running DB2, no data would be lost.  Relational databases that support ACID jump through hoops, using mechanisms like rewrite logs to ensure that after it returns a successful commit of data, you are 100% certain that the data is not lost.  It adds to the overhead and is much slower than databases that don't provide that or tools to manage backups and restores.  No serious enterprise data is stored without failovers, offsite backup tapes etc. 

 

If anyone is inclined, check out the seminal white paper on DyanamoDB, Amazon's cloud NoSQL database.   http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

post #114 of 117
Quote:
Originally Posted by nht View Post

 

The problem is harder.  Imagine you have 4 android devices which all make changes to contacts.  1 deletes it.  The other decides to change the addresses.  Another changes the address to a different address.  One renames the contact to something else.  They all happen around the same time offline but now you have 4 object trees with conflicting results in them.

 

Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things.  I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone"  then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party".  Then internet came back on in my home.

 

What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process.  And I'm not sure the App developer has visibility on what the hell happened in the iCloud.

 

And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user.  And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.

 

Oh, I totally get the problem.  Palm resolved it by creating conflicted records that you had to manually resolve.  I just did enough testing for the common scenarios that I would typically experience.  Creating a record with the same name on the cloud and a disconnected Android phone.  Changing different fields (address, phone number) on different devices, changing the same field (the last write won - as I'd expect).  But I should try some of these scenarios and see what happens with Contacts.  I never tried deleting a contact and making changes at the same time.  Will be interesting to see what happens.

 

Anyway, this has been a good discussion (barring some unhelpful comments).

post #115 of 117
Quote:
Originally Posted by jragosta View Post

Quote:
Originally Posted by ankleskater View Post

You are not debating. You're a kid screaming for candy while adults are talking politics. You're turning this into a sideshow to make it impossible to have a proper discussion - the ultimate concern troll. Shame on you, troll.

So all the people running around screaming "Apple is evil", "Apple is incompetent", "Horrible problem", "End of the World" are rational adults while the person who says "where is the evidence to support your claim?" is a kid screaming for candy?

 

 

Stop with your conspiratorial rants. Nobody has made the assertions you claim they made. Anyone who legitimately criticizes Apple you call "Apple-basher". Apple is not beyond reproach, it's not a holy entity. Anyone who's too immature to recognize this should be called fanboy (with emphasis on BOY, as in "little, immature, child") or Apple worshiper.

 

You simply chose to ignore evidence presented and then ask for it again. That's like John McCain who wanted hearings on the shooting at the Libyan consulate in Bengasi, while not partaking at that very hearing about the shooting at the Libyan consulate, because he was too busy with a press conference in which he called for a hearing on the shooting on the Libyan embassy (which doesn't exist in Bengasi). Are you a Republican, per chance? That would explain some of your behavior.

 

 

Quote:

Quote:
Originally Posted by Gatorguy View Post

There's a fairly long thread here at Apple Support Communities. Several of the posters claim they lost data. Perhaps there's something in there to indicate how it happens if you really wanted to find out for yourself.
https://discussions.apple.com/thread/3382799?start=105&tstart=0

OK, so someone has finally pointed to a few people who lost data. That does not, however, prove the assertion that CoreData is at fault, nor that it's a serious problem.

There will be 500 posts on the Apple Support forum about any nonsense that someone dreams up. And with hundreds of millions of iDevices, someone will undoubtedly have any problem that you can imagine. Once again, there's no evidence that it's a significant problem, not that the problem is due to deficiencies in CoreData.

 

CoreData likely isn't at fault anyway, this is a matter of the Ubiquity framework, which works in tandem with CoreData to sync over iCloud. CoreData predates iCloud by a fair amount of time and is widely used and reasonably robust, even though it's likely not bug-free. But again, the ability to understand that distinction is beyond your comprehension of Apple's technologies. 

 

That said, if developers have to stop, cancel or massively delay their products, because in the state the frameworks are in, no reliable sync is possible, then that is a serious problem. No, you won't see users losing data, because the users don't get to use these products, because developers don't release them because they don't want their reputation ruined for a bug that's out of their control.

No user will swallow a useless product that keeps losing data and for which they just paid money in the AppStore and then hear from a developer: "Hey, we programmed it by the specs, we have no bug, so call up Apple to fix their frameworks and backend, then our app will magically start working properly. Until then, you're SOL."

 

So your smoke and mirrors argument just won't fly, even more so, the introduction of the word "significant" is a joke. Either something is a problem, or it's not. For something to be a "insignificant" problem, it only means: it's a real problem, but I want to ignore it for whatever reason, so I call it insignificant.

Much like 4000 killed troops are a real problem, but 130'000 killed civilians are an insignificant problem called collateral damage...

 

It's soccer hooligan mentality: usually losers who try to make themselves feel good by attaching themselves to a victorious team so they can say "we won" (even though they were just drinking and screaming and being obnoxious), and who consequently cannot deal with any criticism of the team, regardless of how badly they played and how deservedly they lost, because anything negative is taking away from their self-esteem by proxy. Even funnier to watch though: the stupid fans spend their little hard earned money on sports fan merchandise, while the players swap teams like underwear, and simply play for money, regardless what color jersey they are wearing. The marks are loyal to an artificial brand entity and have their pockets emptied in the process.

post #116 of 117
Quote:
Originally Posted by os2baba View Post

Quote:
Originally Posted by nht View Post

 

The problem is harder.  Imagine you have 4 android devices which all make changes to contacts.  1 deletes it.  The other decides to change the addresses.  Another changes the address to a different address.  One renames the contact to something else.  They all happen around the same time offline but now you have 4 object trees with conflicting results in them.

 

Now sync in a matter that makes sense to the user so they don't "lose" data despite the fact they just told you to do 4 conflicting things.  I'm sure that you can deterministically resolve to a record but probably it wont be the answer the user expects because what the user was thinking is "I renamed Jane C to Jane D because she got married on my iphone"  then "my wife changed her address on the ipad we share to her husbands address" then "I deleted the Jane C contact on my mac because it was old...she's Jane D now" and "then I replaced Jane's old address on my iPod Touch with the work address she gave me while at the party".  Then internet came back on in my home.

 

What the user expects is Jane D with both addresses on all devices even though the user screwed up at least 2 steps in this process.  And I'm not sure the App developer has visibility on what the hell happened in the iCloud.

 

And now imagine it's not an object as easy to understand for a user as a "contact" but an underlying data object the app uses as part of doing things for the user.  And it's not a data object created by Google or Palm but some randomly complex object the developer needed to persist.

 

Oh, I totally get the problem.  Palm resolved it by creating conflicted records that you had to manually resolve.  I just did enough testing for the common scenarios that I would typically experience.  Creating a record with the same name on the cloud and a disconnected Android phone.  Changing different fields (address, phone number) on different devices, changing the same field (the last write won - as I'd expect).  But I should try some of these scenarios and see what happens with Contacts.  I never tried deleting a contact and making changes at the same time.  Will be interesting to see what happens.

 

Anyway, this has been a good discussion (barring some unhelpful comments).

 

First, Contacts are synced with CardDAV, AFAIK, not CoreData.

Second Addresses and generally any record being synced needs a UUID to indentify the indenty of the record, such that a name is not what makes it unique, and multiple Jack Smiths in your address book can be kept apart, because they have different UUIDs

 

Unfortunately iCloud is even screwed up there, where mobileMe was not. 

 

Example: I have several "Chris" in my address book. No last name, because I don't know them or don't care about them. iCloud on more than one occasion has simply merged them into one record without me asking. mobileMe would at least throw a sync error or something that allowed you to intervene before such destructive changes happen. So if I have a Chris (girl) with a mobile phone number and a SkypeID and a Chris with a home phone number and an e-mail address, all of a sudden I notice there's just one Chris with a home phone, mobile phone, e-mail and Skype ID. I was never asked if I wanted these merged, nor would I have approved of such merges.

 

Example 2: You have two AppleIDs, e.g. home@icloud.com and office@icloud.com. So that means you have two address books, which Contacts theoretically can handle just fine. Now you have a contact called Chris in the home account, and add a Chris to the office account. Suddenly Contacts on the Mac shows only one entry, with a little greyed out notice "you have two cards for this contact". Hell, no, I have not. I have two contacts. Never told it to merge, never told it that these are the same Chris. So now I have to make some random exercises like disabling one account, adding a fake last name to the card that's still visible, dragging the vCard to the desktop, deleting the entry, enabling both accounts again, dragging the card into Contacts. Ah, oh magic, now it notices one is called "Chris" and the other is called "Chris X", and they are different people. Now I can rename "Chris X" back to "Chris" and they are recognized as two people. At least until iCloud thinks it has to merge them again...

 

It's that sort of arrogant attitude of "the cloud knows" and "we make it simple" that actually is anything but simple and horribly annoying. If the cloud thinks these might be the same people at the very least I should get an alert like "Two cards with the same name detected: are they the same person? [yes] [no]" but instead that decision is simply made behind the user's back.

 

Anyway, that's not part of the issue this thread is discussing, because Contacts use a different sync mechanism, but that mechanism is broken, too.

post #117 of 117

Yes it is apples fault, quoting an email I received from Apple DTS:

 

"Thanks for mailing to Apple's developer technical support, I am responding your inquiry about Core Data iCloud integration

 

Unfortunately, you are running into a bug. For some reason, the ubiquity importer ignores the update from iPad 2 if both devices are running 6.1.x. And currently I don't see any workaround for this."

 

Using Apple's code from WWDC 2012, you get the SAME bug.

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iCloud
AppleInsider › Forums › Mobile › iCloud › Apple's iCloud disparaged over Core Data sync problems