I Rode 500 Miles in a Self-Driving Car and Saw the Future - <AUTHOR> http://www.wired.com/2015/01/rode-500-miles-self-driving-car-saw-future-boring/ <comment><USER2> "Damned if it didn't work at the next light, bringing the car to a safe stop two car lengths behind the guy in front of us. "We didn't know it would do that!" Lipinski said with some excitement." Uh, wait, what? Driving down a street in tonnes of steel and you're experimenting with a journalist behind the wheel?</comment>


The Dvorak Simplified Keyboard - <AUTHOR> http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard

<comment><AUTHOR> Hi HN, I noticed that the wikipedia page for Dvorak has been significantly expanded since the last time I read it. I now feel it's pretty comprehensive and makes a compelling case so I thought I'd submit it.

Personally I've been using Dvorak for about 3 years and never looked back. I've been using a TypeMatrix keyboard for about that long and I love it. I immediately changed bindings for all the modifiers so I can press them with my thumbs. Here's my "changes.txt" file, which relocates modifiers:

!mod1 = Alt !mod5 = AltGr remove Shift = Shift_L Shift_R remove Control = Control_L Control_R remove mod1 = Alt_L remove mod5 = ISO_Level3_Shift

keysym Next = Shift_L keysym Shift_L = Control_L keysym Shift_R = F32 keysym Control_L = Control_R keysym Prior = Alt_L keysym Alt_L = ISO_Level3_Shift keysym ISO_Level3_Shift = Prior keysym Control_R = Next

add Shift = Shift_L add Control = Control_L Control_R add mod1 = Alt_L add mod5 = ISO_Level3_Shift

This way I press control with my left thumb, shift and alt with my right thumb. Right-shift is remapped to F32, which I then bind to opening parentheses and putting the cursor inside (lisper here). And other misc stuff.</comment>


Show HN: Meet Baasic – More Than a Back End - <AUTHOR> http://www.baasic.com/ <comment><USER2> Seems interesting. Biggest question that popped up immediately is what happens when my app inevitably outgrows Baaasic's functionality?

</comment><comment><AUTHOR> Baasic is a completely modular, pluggable, scalable, secure and technology- agnostic service for the rapid development of the web and mobile apps.</comment>


100-year-old metal hook could determine whether PG&E guilty of criminal conduct - <AUTHOR> https://www.wsj.com/articles/this-old-metal-hook-could-determine-whether-pg-e-committed-a-crime-11583623059 <comment><AUTHOR> [https://archive.is/F8LPT](https://archive.is/F8LPT)</comment>


Show HN: For all cities over 100k, calculated the farthest and closest cities - <AUTHOR> http://cityextremes.com/ <comment><AUTHOR> How I built this: I pulled the population data from the UN statistics report on cities over 100k and then batch geocoded all of the cities (there was also a fair bit of data cleansing required). I then used a macro in excel to calculate the distance between every city pair (using Vincenty's formula) and uploaded the results to a database. Happy to share more if anyone is curious.

</comment><comment><USER2> This is quite fun actually. I live in Milan (Italy) and my cousin lives in Aukland (NZ). These cities are listed as being the furthest from each other at more than 18,000 km.

Incidentally as a kid I was quite obsessed with the idea of visiting the antipode of my home's exact geographic location, but sadly, when I finally got around to calculating it, I discovered it lay in a nondescript expanse of ocean.

</comment><comment><USER3> Whats the tech stack may I ask? I like the simple design and interactions. easy to noodle around and learn.

<comment><AUTHOR> Just some simple PHP / MySQL

<comment><USER3> ok. was wondering if you used open source data tools etc.

<comment><AUTHOR> I took the list of 4 thousand odd cities from the UN statistics report of cities over 100k and then ran it through the batch geocoding site: [http://www.findlatitudeandlongitude.com/](http://www.findlatitudeandlongitude.com/) ... apart from that just old fashioned excel to calculate

</comment></comment></comment></comment><comment><USER4> This was definitely fun to try.</comment>


For most paywalls, disable JavaScript - <AUTHOR> You can get past most paywalls just by disabling JS. There are browser extensions available to do this. It would also stop some tracking scripts and won't display Ads.<p>An Example I found earlier : https://github.com/dpacassi/disable-javascript <comment><USER2> You don't even need an extension if you don't want. Safari has 'Disable Javascript' as an option in the Develop menu. Firefox and Chrome have the option in the Developer Tools settings.

</comment><comment><AUTHOR> That's a good point

</comment><comment><USER3> You also get past a lot of the GDPR stuff</comment>


What if all guns disappeared? (2018/04) - <AUTHOR> http://www.bbc.com/future/story/20180417-what-would-happen-if-all-guns-disappeared <comment><USER2> We would be in a Simpson's episode</comment>


The Thrill of Losing Money by Investing in a Manhattan Restaurant - <AUTHOR> http://www.newyorker.com/business/currency/the-thrill-of-losing-money-by-investing-in-a-manhattan-restaurant <comment><USER2> Friend of mine runs a tiny and successful to-go cafe. His most unexpected problem was competitor restaurants around him constantly phoning city hall to "complain" about his business in hopes they regulate him off the street. The most common complaint at first was cooking smell, so the tiny cafe is forced to install expensive filtration exhaust.Then the complaints turned to signage. A city inspector showed up numerous times to measure his sign, how far his little sandwich board was placed in the sidewalk out front, the brightness of the lights on his sign, that the artwork on the sandwich board was offensive or violated one of the thousands of regulations regarding public advertising. Then the complaints turned to patio, there was too much noise, chairs were too far into the street, garbage was left too long on tables, ect.

Anybody with a restaurant/cafe startup idea should have some kind of contingency plan to deal with the inevitable use of city hall to try and close you down.

<comment><USER3> Eh. The city passed laws to regulate how much for-profit businesses impinged on the public. Food smells in the air, signs and patio chairs on the public sidewalk. Especially if we're talking about a typical patio that actually impinges on the public sidewalk. Regulating that doesn't seem unreasonable.

And if everybody else has to follow those laws, why should your friend's place be any different? Why should a competing business have to bear the expense of installing a filtration system, then sit idly by while someone sets up shop next door and flouts that regulation?

This is where part of the criticism of cabs is unfair. Cabs aren't allowed to maximize their profits through the perfect price discrimination offered by dynamic pricing. Stuff like Pool and $1 fares are illegal for cab companies to do. So why shouldn't they complain when Uber competes with them without following regulations they have to follow?

Your complaint sounds like those people who get mad when someone rats them out for cheating in class.

<comment><USER4> _> Your complaint sounds like those people who get mad when someone rats them out for cheating in class._

The legal system is so complex that _we are all always cheating_.

People only call for strict enforcement of the rules when they don't like you. It is a wonderful thing to get the government to attack your enemies for you.

<comment><USER3> Yeah, it's so complex: [http://www.nyc.gov/html/nycbe/downloads/pdf/nycchecklist_res...](http://www.nyc.gov/html/nycbe/downloads/pdf/nycchecklist_restaurantsigns.pdf).

OP's examples were not obscure subsection g part 4 item iii-type stuff. They are basic things you'd think about if you were considering the impact of your business on the public.

<comment><USER4> That's a strawman attack. You imply that the entirety of applicable law was contained in that URL, which is false. The actual corpus of law a citizen and business owner must be aware of is the entirety of the law from Federal, State, County, and City, plus all private contracts to which I am bound, covering every activity you do. You're a lawyer sarcastically chastising me with a link to the specific law, and that is poorly done. The very existence of "lawyer" as a _profession_ implies that the law is too complex for individuals to understand.

The computer science version of this would be some poor guy confused about TCP/IP and I could link to the precise part of the RFC that answered his question, with a sarcastic, "Right, that's so complex". I'd be an asshole if I did that.

</comment></comment></comment></comment></comment><comment><USER5> Minimal viable product/lean startup. This is not that. For a restaurant that means:

1\. Have good food, that sells. Nothing else matters. No big up front investments. Have a killer product, which you make in your home kitchen if you have to. I thought Americans knew this, with their food trucks and shared kitchens.

I see this all the time. People thinking about how to name their company, how the logo looks, or in this case which forks to use. These things matter, but only in the long run, when you're able to sell your product successfully already.

Access to money and people like the author make this difficult, you aren't forced to survive.

A restaurant near me has started without a name, no interior decoration and a less than good but not too bad location. After six months they had a line out the door, every night. After a year they had a name. After two years they renovated, but just a little bit. Now it's 5 years later, it looks fancy, they have a logo and it's nicely renovated. But they started with the product.

I think it's a good idea to do everything in reverse, especially when we are worried how we are perceived. We see finished, well working things and think we need to emulate everything they are doing, including the expensive business cards, when it's really the other way around. Product first, being forced to survive, the details come later. Makes for a much more relaxing atmosphere as well, with much less meetings that go nowhere.

<comment><USER6> This sounds like it was written by someone who has no direct experience (side note: selling people food you made in your home kitchen is illegal) and I am pretty sure restaurants, generally, aren't like tech startups, where you experiment to get product-market fit and so on.

People like food, they want to eat it, and chances are high you're making food that's generally recognizable as such and part of a general culinary category and price range. There are acceptable standards for service, wait times, cleanliness, and so on, that you can meet or exceed to provide a certain level of experience.

From what I understand, and being around the business, restaurants almost invariably sink or swim based on how good a real estate deal they've been able to get, and their ability to have a stable staff and be relentless about controlling costs, things like spoilage, advance planning, etc.

Software based startups are all about growth. You fuck around as you describe and when you nail the product it grows like crazy at a very low marginal cost.

Restaurant economics essentially look nothing like that. They aren't about growth, they are about margins, and since they have to be highly price competitive, that means fundamentally the business is about managing expenses.

<comment><USER7> _From what I understand, and being around the business, restaurants almost invariably sink or swim based on how good a real estate deal they 've been able to get, and their ability to have a stable staff and be relentless about controlling costs, things like spoilage, advance planning, etc._

This sounds like it was written by someone who doesn't like food. What I've seen in NYC, over and over again, is that of course you don't want the worst location (or financing terms), and you don't want to shoot yourself in the foot with incompetent operational management or an ever-churning staff. However, those are simply the prerequisites; they're necessary, but not sufficient for success.

If you want to thrive, you absolutely have to have a kick-ass product† (that you also happen to wholeheartedly believe in). If your menu just isn't inspiring (or it's too expensive or otherwise not right for the neighborhood / night-time crowd) -- it doesn't matter what your staff turnover is or much forethought you put into the operations. Inevitably you will fail.

But if your menu is truly awesome, people will make a beeline to your little hole-in-the-wall, wherever it is, and jostle for a spot at your narrow formica sitting counter and a chance to wolf down your product, nevermind the styrofoam bowls, plastic sporks and tissue-thin napkins.

Case in point: [http://xianfoods.com](http://xianfoods.com)

† By product I mean the combination of "menu offering, ambience, staff and cultural vibe." The interplay between these can be quite subtle, and it's tricky to get them right (which is why it's really to believe in what you're doing, and have _taste_ in all things, not just food). The point I'm trying to make is that from what I've observed, it's definitely not primarily a matter of managing your margins and not getting screwed by your lease.

<comment><USER8> If you're in NYC, and you're truly awesome, but have a shitty lease, you'll find yourself with a 5x increase that puts you out of business.

The places that last own the building or have a long lease.

<comment><USER7> I already acknowledged, in my post above, that of course you shouldn't have a "shitty" lease.

My point is that (along with all the other boxes one should tick in starting a restaurant in a cutthroat market like NYC) -- and in particular if your goal is to run a business that's actually thriving, and not just marginally surviving -- it's not _sufficient_.

</comment></comment></comment></comment></comment><comment> cool-RR The problem with investing in something cool, like owning a restaurant or a bar, is that you're competing with a lot of people who are less mature than you. They are less mature than you because they're willing to risk their financial future just so they can feel that they are cool guys who own a restaurant.

It's always dangerous to compete with people who are less mature than you because they are okay with losing the important things in life in order to beat you, so you'll be forced to either go down to their level or lose to them. It's like playing chicken against someone who has suicidal tendencies.

<comment><USER9> This was more or less the point of the article, although the article's author was less slanderous of the competition.

</comment></comment><comment><USER10> The fact of the matter is, this article explains why restaurants are money losing.

It's an intrinsic good to own a restaurant. You get satisfaction from simply owning a restaurant, no matter if you make or lose money.

It feels good to treat your friends, and get preferential treatment at your own place. Making money sometimes is secondary.

It's sort of like programming for the games industry. A lot of people just want to be in the games industry, cause it's "cool". That's why they accept long hours and poor pay.

The ROI for a scrap metal yard or a sewage plant will always be higher than the ROI for a comparably priced restaurant.

</comment><comment><USER11> Spot the guy ho knows what he is doing!

\- Andrew Yang, the principal investor of a successful restaurant [...] who comes from a restaurant family

or

\- Gary Sernovitz is a writer and a managing director of a private-equity firm

<comment><USER12> Everyone who thinks about opening a restaurant should be forced to read 'Kitchen Confidential' half a dozen times, especially the sections about what it actually takes to win in the business.

</comment></comment><comment><USER13> Counterpoint. The Halal Guys going from a single cart to 300+ restaurants: "How Halal Food Became a $20B Hit in America"

[http://www.bloomberg.com/news/articles/2016-09-14/america- lo...](http://www.bloomberg.com/news/articles/2016-09-14/america-loves-muslim- food-so-much-for-a-clash-of-civilizations)

In their case, it was certainly _because_ of the overpowering yet enticing smell of fresh grilled spicy lamb kebobs wafting across the block that drew the "I wouldn't eat meat off the street in a million years" nabobs ;)

</comment><comment><USER14> The only way you can make money in a restaurant is via booze. I know a couple of restaurant owners, and they admit it: if they just sold food, they'd be losing money. The profit margins on alcohol are insane. A $1 bottle of beer can easily go for $5 (a 400% markup). And wine? A decent $12 bottle of wine will easily fill 6 glasses, at $7 a pop.

So if you're planning on opening a restaurant, be sure to get your liquor license. You'll depend on it.

<comment><USER15> The markup is the same on food. It's just that people only order one main dish each but can order several drinks, and it's altogether another additional revenue source that you need.

<comment><USER14> If you read the article, you'll see that the markup on food is nowhere close to alcohol. He claims a < 3% profit.

</comment></comment></comment><comment><USER16> You know those tiny lunch places in downtown San Francisco? Closet-sized and to-go only? That's what people should try as their first restaurant. Unfortunately, people usually try that second.

</comment><comment><USER17> I don't get it. If your gross margin is 3% you can raise your prices by 6% and _triple_ your operating income. Are NYC restaurant-goers really that price- sensitive?

<comment><USER18> the problem is all these stats are lumped together for all types of restaurants all over the spectrum.

yes, a high end place can easily raise prices and make more money. plenty of them do exactly that.

low end places are squeezed both on supply and demand side, and can not easily do this, or the owners are simply afraid.

if you raise your prices by 6% but business drops by 10% because your customers are price sensitive, and the same month you are hit by an unexpected cost, then what?

</comment></comment><comment><USER19> _You can't own one-forty-second of the next Zadie Smith novel._

Really? It seems like you kind of can, these days.

I wonder also whether restaurants are the kind of investment that only works if you can have a portfolio of them.

</comment><comment><USER20> The standard joke: "How do you make a small fortune in the restaurant business?"

"Start with a large fortune".

</comment><comment><USER21> OK, but done better by Anthony Bourdain in his famous book:

"To want to own a restaurant can be a strange and terrible affliction. What causes such a destructive urge in so many otherwise sensible people? Why would anyone who has worked hard, saved money, often been successful in other fields, want to pump their hard-earned cash down a hole that statistically, at least, will almost surely prove dry? Why venture into an industry with enormous fixed expenses (rent, electricity, gas, water, linen, maintenance, insurance, license fees, trash removal, etc.), with a notoriously transient and unstable workforce, and highly perishable inventory of assets? The chances of ever seeing a return on your investment are about one in five. ...

"The easy answer, of course, is ego. The classic example is the retired dentist who was always told he threw a great dinner party. 'You should open a restaurant,' his friends tell him. And our dentist believes them. He wants to get in the business — not to make money, not really, but to swan about the dining room signing dinner checks like Rick in Casablanca."

</comment><comment><USER22> > Manhattan restaurants seem to be the original example of the business model > taken to its extremes by Uber and others in Silicon Valley, of investor > capital subsidizing, semi-permanently, the customer experience.

That's the key take-away (haha). I liken it to poker. If you're at a table with an idiot, you'll get his money. If you're at a table with a bunch of them, they'll get yours.

</comment><comment><USER23> It feels like building owners capture basically all of the excess profit of restaurants, which is to the significant detriment of the quality of a neighborhood.

</comment><comment><USER24> And for anyone dreaming-the-dream, but thinking a hip new food truck is the way to go... a reasonably well equipped truck will run you upwards of $400K+.

<comment><USER25> Or quite a lot less:

[http://prestigefoodtrucks.com/custom-food-trucks-for- sale/](http://prestigefoodtrucks.com/custom-food-trucks-for-sale/)

</comment></comment><comment><USER26> I have always wondered why more people in NYC dont start with food trucks. That would be the most "antifragile" approach to starting a restaurant --

if the food isnt working, change it, if the location isnt working, drive somewhere else

you could approach the restaurant game like you are a/b testing a sign up page until you got it right, then nail down a location etc.

disclaimer: I have never worked in the food industry

<comment><USER27> There's a long wait list for street food vendor permits, so it's not as simple as you think.

But the bigger issue is that's it's glamorous to own a restaurant. You can take your friends there and brag about owning it.

Taking your friends to your poutine truck just doesn't impress them.

<comment><USER28> > There's a long wait list for street food vendor permits

Maybe there shouldn't be?

</comment></comment></comment><comment><USER29> Only restaurants I've known that did well owned the real estate they were in or were super cheap high margin places that were popular with a good location.

Lots of restaurants are just fronts for money laundering.

<comment><USER30> > Lots of restaurants are just fronts for money laundering.

I've heard this before, but I've never been able to find any corroboration.

How does it work? Half your palettes of milk never get delivered?

<comment><USER29> Correct, half of the pallets get delivered and the dairy farm is owned by the launder too via a series of shell companies.

Best way to learn about money laundering (ML) is to study anti-money laundering (AML), since most laundering outfits aren't going to write a book about how they do what they do.

Most interesting thing about ML is that in cooking the books, they've got to keep very good records of what's been done, otherwise they've got no idea what's going on; which is counter intuitive, since you would think they would not keep records.

</comment></comment></comment><comment><USER31> What are some good resources to understand costs of setting up a restaurant in bay area? I know the general concepts involved, but its hard to get specific info like labour rates, rents etc

</comment><comment><USER32> Does this hold true for bars as well?

<comment><USER33> I am in wine business (owner-winemaker of small winery) and it hold true, so I guess it applies to bars as well

<comment><USER32> that's sad, I guess I need a new retirement idea :)

</comment></comment></comment><comment><USER25> Here's the real content, found at the end:

"New restaurants, with too-easy access to financing from people like me, invest too much in design, tableware, food, and service, driving up every customer's expectations of every restaurant in a cyclone of unprofitability.

Landlords, with enough dreamers to fill their spaces, can command nightmare rents."

<comment><USER34> And of course, the explicit connection drawn to the _raison d 'être_ of this site: "Manhattan restaurants seem to be the original example of the business model taken to its extremes by Uber and others in Silicon Valley, of investor capital subsidizing, semi-permanently, the customer experience."

</comment></comment><comment><USER35> > That is, New York City, with all its pastrami-and-pizza-hungry tourists and > residents fleeing their pocket-size kitchens and young people too busy > taking phone pictures of one another to cook, generates enormous demand for > restaurants. There are twenty-four thousand of them in the five boroughs. > That demand should (...)

24,000 restaurants is not demand, it's supply. This is the Mr. Market fallacy.

<comment><USER36> The author understands that. "That demand" is referring to the tourists, residents, young people, etc.

<comment><USER35> I understand that the author understands that "that demand" is tourists. What I meant is that you can't measure the amount of demand (tourists) by looking at the amount of supply (restaurants), which the author does.

<comment><USER6> That's not a sound way of thinking about economics.

Seeing that a certain level of supply remains stable over time tells you a great deal about the amount of demand present.

Of course it does. Much like looking at the skyline allows you to make some basic assumptions about aggregate demand for office space in Manhattan versus Kearney, Nebraska.

<comment><USER37> Except where it doesn't work, such as in the restaurant business, where some non-trivial percentage of the supply is superfluous and will go out of business. Of course, they will be replaced, so there is an argument that it is at least stable, even despite the high turnover - perhaps that's what you're meaning?

</comment></comment></comment></comment></comment><comment><USER35> The author writes as if he was looking for entertainment, not profit. The journey from investing* to losing half of it over 7 years does sound entertaining, so I guess he got what he wanted.

* he says he invested "a car", so $10-40k?

</comment><comment><USER38> thrill is misspelled

(ignore this post)

<comment><USER39> Two posts down from a missing apostrophe as I write this. Am I being trolled?

<comment><USER40> I think "trill" would actually make a better headline. Reminiscent of little birds...

<comment><USER41> or Houston hip hop

</comment></comment></comment></comment><comment><USER42> So you don't think obeying the law is a good thing? Don't you think regulations exist for a reason? In the case of the medical field for example, I'm very happy it is heavily regulated and I would expect everyone in that field to follow those regulations.

Now if you think think some of your industry's regulations are unreasonable, that's a whole other discussion. But it seems like what you are complaining about here is that your business has to follow rules/law/regulations.

<comment><USER43> I don't think that's what he means at all. Nowhere in his statement does he say he shouldn't have to obey the law. Think the complaining is more about the vast amount of regulations that there are. I'm sure you break laws on a daily basis that you have no clue even exist (if you live in the US).

<comment><USER19> There's overly complex regulation, and then there's "this type of business is required to have an air filtration system and yours has been operating without one for months".

My brother just opened a coffee roaster and cafe in suburban Chicago. It's just him, my sister in law, and a couple friends, none of them with any hospitality experience. There were a lot of regulations, and they had to go several rounds with the city during their build-out. But they got through it.

The weird thing about the comment upthread is that they were "forced to install" a filtration system. How did that get past inspection? The dumb little coffee shop --- no food, no cooking smells --- had to have one just to open up.

<comment><USER44> > There were a lot of regulations, and they had to go several rounds with the > city during their build-out. But they got through it.

So far as you know. The problem is that it's entirely possible that there's some little-known codicil of some code which they are in violation of, the rectification of which could at the outside cost as much as they've already invested.

<comment><USER19> I have friends running small food businesses in Chicago --- I was an investor in one of them, a butcher --- and while my friends have run into problems after inspections and suchlike, none of them have been shut down or really jeopardized in any way. The inspection drama I've seen has, I hate to say it, been mostly reasonable.

(The neighborhood complaints, less so.)

Am I just "lucky", and this is a commonplace problem with other people's companies?

<comment><USER45> For a sample size of two, one a painting and repair garage, and another a trucking company, the level of annoyance and apparent post-facto requirements for opening these businesses were right up to the threshold of madness.

</comment></comment></comment></comment></comment></comment><comment><USER46> Bad math edit :)

<comment><USER36> Your math is way off. 2 million annually works out to about 40k a week, so not sure where your 1600 a day comes from.

<comment><USER46> In my head I divided by 52 but then for some reason divided again by 4 thinking that was per month.</comment></comment></comment>


GitHub is down - <AUTHOR> First time seeing a 500 error there. <comment><USER2> [https://twitter.com/githubstatus/status/935296653401247744](https://twitter.com/githubstatus/status/935296653401247744)

"We are investigating reports of elevated error rates."

Anecdotally, it seems to work if not logged in.

</comment><comment><USER3> GitHub is up for me. I'm logged in

</comment><comment><USER4> Is it back up? I saw the 500 page but a minute later I refreshed and it was back up.

</comment><comment><USER5> The day before yesterday I use my personal Github account and it was absolutely okay then. what happens now? :(</comment>


After CEO Carol Bartz's Ouster, What's Next for Yahoo? - <AUTHOR> http://www.reuters.com/article/2011/09/07/idUS55572294320110907

<comment><USER2> Coincidentally, I happened to quit Yahoo! a few weeks ago. From a former insider's perspective, I thought Carol Bartz did a decent job in cutting costs, making org changes, and running the company with no-nonsense attitude. IMO, @blakei the EVP of Products has been doing a great job--he would definitely get my vote of confidence. Just my $0.02</comment>


When Carl Sagan Warned the World About Nuclear Winter (2017) - <AUTHOR> https://www.smithsonianmag.com/science-nature/when-carl-sagan-warned-world-about-nuclear-winter-180967198/ <comment><USER2> By far the most terrifying movie I've seen on nuclear war has been _Threads_.

If you can find a good copy of it, watch it.

Also, many people these days act like the threat of nuclear war went away with the end of the Cold War. But the threat is still very real, and there are still thousands of nuclear weapons that the US and Russia continue to aim at each other, not to mention the rest of the world's nuclear powers, some of which have been at war with each other before and stand a good chance of going to war again.

<comment><USER3> > Also, many people these days act like the threat of nuclear war went away > with the end of the Cold War

Lots of people seem to be convinced that MAD is a sufficient deterrent for nuclear war. Which may be true if your safeguards are perfect and your actors are always rational. But in reality, all it takes is a mistake or a madman to set off nuclear armageddon.

<comment><USER4> That was certainly true during the Cold War, with two implacably opposes factions that have no dependencies on each other and no real understanding of each other either. It was terrifying, and mistakes were made that brought us extremely close to catastrophe.

I think that less of an existential threat now. The works us a lot more interconnected and interdependent. What would Russia be without the west to export its oil and gas to? What would China be without foreign markets? We all need each other. Proliferation means the risk of nuclear terrorise or limited conflict us still significant, but not at the globe killing level we had 40 years ago. A limited or regional nuclear exchange would be catastrophic, but not species killing.

<comment><USER5> >> But in reality, all it takes is a mistake or a madman to set off nuclear armageddon.

> The works us a lot more interconnected and interdependent. What would Russia > be without the west to export its oil and gas to? What would China be > without foreign markets? We all need each other.

The argument was "all it takes is a mistake or a madman." Neither cares about the fact that "we all need each other."

If you worked anywhere in tech long enough, you should be aware how much unexpected errors are indeed possible even in "old and tested" workflows.

And some madman is always somewhere where "everybody thought he's so nice."

> A limited or regional nuclear exchange would be catastrophic, but not > species killing.

Note: "species" and "civilization" aren't the same.

<comment><USER4> OK, what is the scenario where a single madman causes a complete simultaneous nuclear conflagration by the USA and USSR, the only countries with enough bombs to cause a global nuclear holocaust?

Russia and the USA have no interest in destroying each other. All the other nuclear powers are too small fry to cause more than regional damage.

<comment><USER5> > what is the scenario where a single madman causes a complete simultaneous > nuclear conflagration

An actual nuclear war planner wrote a whole book about that:

"The Doomsday Machine Confessions of a Nuclear War Planner"

[https://www.bloomsbury.com/us/the-doomsday- machine-978160819...](https://www.bloomsbury.com/us/the-doomsday- machine-9781608196746/)

P.S. USSR doesn't exist anymore.

</comment></comment></comment></comment></comment></comment><comment><USER6> Another take on the same incident: [https://www.newyorker.com/magazine/2017/01/30/the-atomic- ori...](https://www.newyorker.com/magazine/2017/01/30/the-atomic-origins-of- climate-science)

"The biggest consequence of the nuclear-winter debate, though, has had to do not with nuclear-weapons policy but with the environmental movement. In the short term, the idea of a nuclear winter defeated the idea of deterrence. In the long term, Sagan's haste and exuberance undermined environmental science. More important, the political campaign waged against nuclear winter—against science, and against the press—included erecting a set of structures, arguments, and institutions that have since been repurposed to challenge the science of global warming."

<comment><USER7> Ann Druyan, Sagan's wife, responded to this article with the following:

> Lepore has done history and science, your readers, and my late husband, Carl > Sagan, a great disservice. Her article's central thesis demeans Carl's > scientific acumen and his character, wrongly asserting that, in his > "grandiosity," he harmed the environmental movement by advancing an > exaggerated theory of the long-term consequences of nuclear war.

> From Lepore's account, readers would conclude that Carl's interest in the > greenhouse effect on Venus was something that he picked up from a bright > grad student. In fact, five years earlier, Carl had published his own > dissertation, viewed as the beginning of our modern understanding of Venus, > which included his groundbreaking greenhouse model.

> Lepore also gives the impression that the theory of nuclear winter has been > debunked. If anything, more recent scientific research indicates that Carl > and his colleagues were conservative in their estimates. Tellingly, she > makes no reference to the findings—in peer-reviewed, refereed > publications—that fully support, and expand on, the models created by Carl > and the other nuclear-winter scientists.

> Carl is also faulted for "partisanship," in part for declining an invitation > to dine with the Reagans in the White House—a choice that I made, in > response to the El Mozote massacre and other crimes in Central America for > which I believed Reagan bore some responsibility. Does Lepore find those > public figures and celebrities who refuse to be co-opted by the Trump White > House to be partisan? Or is that an unwillingness to lend your cachet to > policies that you abhor?

> According to Lepore, Sagan "made some poor decisions" and "undermined > environmental science." She leaves the reader to wonder what those bad > decisions were. Fighting for the reduction of tens of thousands of nuclear > weapons? Sounding the alarm on global warming decades before others started > paying attention to it? Mounting the world's most successful campaign for > public scientific literacy? Attracting multitudes to science and reason? > Turning the camera on Voyager 1, which was out by Neptune, to point > homeward, to make us see our true circumstances in the vastness? What better > decisions have other people made?

> Ann Druyan

> Ithaca, N.Y.

—[https://www.newyorker.com/magazine/2017/02/27/letters- from-t...](https://www.newyorker.com/magazine/2017/02/27/letters-from-the- february-27-2017-issue)

<comment><USER8> Wild that Ann Druyan's words would be downvoted here.

</comment></comment></comment><comment><USER9> This article should mention that the original conception of, & strongest warnings about, a global 'nuclear winter' effect haven't really held up with better models & better understanding of how ground fires/explosions might affect the upper atmosphere.

The answers here include a fair summary of the updated case _against_ :

[https://www.quora.com/Is-the-nuclear-winter-a-hoax](https://www.quora.com/Is- the-nuclear-winter-a-hoax)

</comment><comment><USER3> The threat of nuclear war doesn't seem to occupy people's minds the way it used to. It tends to still scare me and keep me awake more than the threat of climate change (although both give me pretty regular existential crises).

There was even an earthquake where I live a few months ago (first I've experienced). It woke me up, and the first thing my mind thought was "nukes" for some reason (despite not living somewhere that would be a likely target). It only took a split second to realize what was really happening, but it was interesting that it was the first thing my mind went to.

</comment><comment><USER10> I went to several of Professor Brian Toon's presentations when I was a student at CU Boulder. The article briefly mentions his current research but if anyone is interested in the effect a nuclear exchange between India and Pakistan would have on the world, this is a sobering read: [https://www.sciencedaily.com/releases/2019/10/191002144251.h...](https://www.sciencedaily.com/releases/2019/10/191002144251.htm)

</comment><comment><USER11> As a kid in the 80s, I was terrified of nuclear winter. Had nightmares about it.

<comment><USER12> Same, well not winter, I assumed I'd die in initial strike living near major targets.

I, and many people of similar age I've talked with since, did not believe they would live into adulthood. Believing nuclear war was imminent and inevitable.

<comment><USER9> I as a teen in the 80s, I never believed nuclear war was _inevitable_ , but it was a constant background fear. In the suburbs of Houston, any nighttime lightning-strike waking me up would trigger the thought: "was that a nuclear detonation over the city?"

Those seeking to learn more about the mindset could check out ABC's 'The Day After' miniseries (1983) or the movie 'Miracle Mile' (1988) – which I'd suggest viewing with no other pre-reading other than this recommendation.

</comment></comment></comment><comment><USER13> > This article marked the public's introduction to a concept that would > drastically change the debate over nuclear war: "nuclear winter." The story > detailed the previously unexpected consequences of nuclear war: prolonged > dust and smoke, a precipitous drop in Earth's temperatures and widespread > failure of crops, leading to deadly famine. "In a nuclear 'exchange,' more > than a billion people would instantly be killed," read the cover. "But the > long-term consequences could be much worse..."

> According to the article, it wouldn't take both major nuclear powers firing > all their weapons to create a nuclear winter. Even a smaller-scale war could > destroy humanity as we know it.

What's the current consensus on the idea of a nuclear winter? I vaguely recall reading that the early papers like these overestimated the effects, and it would take a far larger nuclear exchange than has ever been possible to cause that kind of effect on the climate.

<comment><USER14> > _According to the article, it wouldn't take both major nuclear powers firing > all their weapons to create a nuclear winter. Even a smaller-scale war could > destroy humanity as we know it._

I'm skeptical of this; in the 20th century there were more than 500 atmospheric nuclear tests. Given that, it seems unlikely that a ""small"" nuclear war would necessarily cause such dramatic effects as humanity- destroying nuclear winter. This said, cities getting nuked would probably launch more soot into the atmosphere than the desert or ocean getting nuked, so... maybe?

But I think we should try to avoid finding out for sure. ;)

<comment><USER4> The theory is that the incineration of so many cities, and the subsequent firestorms would put vast amounts of smoke and particulates into the upper atmosphere. It's this rather than the bombs themselves that has the main climatic effect. The fact that all these particulates would be radioactive is an extra dimension to it all.

<comment><USER13> > The theory is that the incineration of so many cities, and the subsequent > firestorms would put vast amounts of smoke and particulates into the upper > atmosphere. It's this rather than the bombs themselves that has the main > climatic effect. The fact that all these particulates would be radioactive > is an extra dimension to it all.

Some later Googling of mine found some stuff about how the nuclear winter theorists's models made predictions that oil well fires would result in a small scale global winter, but the Kuwaiti oil files did not confirm that prediction.

[https://en.wikipedia.org/wiki/Nuclear_winter#Kuwait_wells_in...](https://en.wikipedia.org/wiki/Nuclear_winter#Kuwait_wells_in_the_first_Gulf_War):

> One of the major results of TTAPS' 1990 paper was the re-iteration of the > team's 1983 model that 100 oil refinery fires would be sufficient to bring > about a small scale, but still globally deleterious nuclear winter.[109]...

> In articles printed in the Wilmington Morning Star and the Baltimore Sun > newspapers in January 1991, prominent authors of nuclear winter papers – > Richard P. Turco, John W. Birks, Carl Sagan, Alan Robock and Paul Crutzen – > collectively stated that they expected catastrophic nuclear winter like > effects with continental-sized effects of sub-freezing temperatures as a > result of the Iraqis going through with their threats of igniting 300 to 500 > pressurized oil wells that could subsequently burn for several > months.[110][111][112]

> As threatened, the wells were set on fire by the retreating Iraqis in March > 1991, and the 600 or so burning oil wells were not fully extinguished until > November 6, 1991, eight months after the end of the war,[113] and they > consumed an estimated six million barrels of oil per day at their peak > intensity....

> The atmospheric scientist tasked with studying the atmospheric effect of the > Kuwaiti fires by the National Science Foundation, Peter Hobbs, stated that > the fires' modest impact suggested that "some numbers [used to support the > Nuclear Winter hypothesis]... were probably a little overblown."[119]

> Hobbs found that at the peak of the fires, the smoke absorbed 75 to 80% of > the sun's radiation. The particles rose to a maximum of 20,000 feet (6,100 > m), and when combined with scavenging by clouds the smoke had a short > residency time of a maximum of a few days in the atmosphere.[120][121]

> Pre-war claims of wide scale, long-lasting, and significant global > environmental effects were thus not borne out, and found to be significantly > exaggerated by the media and speculators,[122] with climate models by those > not supporting the nuclear winter hypothesis at the time of the fires > predicting only more localized effects such as a daytime temperature drop of > ~10 °C within 200 km of the source.[123]

</comment></comment></comment></comment><comment><USER15> I'm often amazed that the world didn't encounter a nuclear war yet.

What is so effective preventing it?

<comment><USER16> Luck.

In the short period of time we have had access to nuclear weapons, we have come very close to nuclear war between superpowers:

* Cuban Missile Crisis - Vasili Arkhipov Prevents launching of nuclear torpedo while his Soviet submarine flotilla is being bombarded by depth charges (happened to be signaling depth charges). Turns out the US warships above them just wanted the submarines to surface so they could communicate the end of hostilities.

* Computer Malfunction - Stanislav Petrov Holds off alerting officials of multiple incoming nuclear ICBMs because he "suspected" they were a glitch, preventing a likely nuclear counter-attack.

* Science experiment looks like nuclear attack - Boris Yeltsin correctly decides to wait launching a counter-attack based on an incoming rocket. All the while sitting in front of an activated nuclear briefcase and being pressured by aids to launch within the 12 minute response window. The rocket was meant for atmospheric testing.

There are many, many more.

Proliferation means more and more nation states have access to nuclear weapons. Balancing peace amongst all those nations can be difficult (look at India and Pakistan). Countries with existing nuclear stockpiles can undergo dramatic shifts in leadership and policy (US politics anyone?).

We also have 7.5+ billion people on the planet, consuming more resources than ever, on a planet with a finite amount of things.

Now throw in the further ramifications of climate change like political instability, infrastructure strain, resource scarcity, and refugee migrations into the mix. Or a truly mad guy with a nuke.

There are way too many people out there that are crazy optimistic that we aren't going to have a nuclear war...ever. We have always had warfare, and when the shit hits the fan, armies have always used the biggest weapons they have had.

Nuclear weapons may very well be our great filter.

<comment><USER15> Like, I'm very inclined to think it might happen soon.

But what is making me less inclined is the fact it didn't happen within the last ca. 70 years.

<comment><USER16> We haven't had a global pandemic in over 100 years and yet here we are.

Countries have nuclear weapons and the global community has to get it right every single day to avoid nuclear war.

I'm hoping it doesn't happen, but the lack of precedent doesn't mean nuclear war cannot happen. If we needed precedent for something to occur, we never would have a "first" of anything, and history is littered with firsts.

But here's hoping. Did I mention I'm great at parties?

</comment></comment></comment></comment><comment><USER17> Except that the current consensus on nuclear winter hypothesis is that it was largely politically (as opposed to scientifically) motivated. So comparing it to climate change is rather controversial in its own regard.

</comment><comment><USER18> The valid criticisms of the accuracy of these studies are missing the forest for the trees. A major exchange would utterly cripple the global economy, destroy much of our electrical generation and distribution infrastructure, along with our information storage and processing systems, and our manufacturing capability to rebuild it.

</comment><comment><USER19> I remember the ham-fisted "The Day After" miniseries when I was in highschool. It was the biggest TV event since the miniseries "Roots" in the late 70's (watch that and you'll never look at "Reading Rainbow" or Geordi La Forge the same way again). It was a super cheesy depiction of nuclear war and the days that follow.

I was too young for the "duck and cover" drills of the 50's, but my generation (X) knew that global thermonuclear war (heh) had no chance of survival.

Toward the end of the 80's and early 90's, fear of nuclear war tapered off after The Wall came down. In fact, Sagan was harassed by the GOP and Right- wing pundits for claiming that if Saddam burned the oil fields, we would experience a nuclear-winter around the equator.

The 80's were nuts tho: Reagan & Gorby's nuclear standoff was pretty fucking insane in hindsight: mutually assured destruction is in the DNA of the modern right-wing movement.

Jeez, even Sting wrote a #1 hit about it in 1985 using a melodic theme by Prokofiev.

Those were the days?

</comment><comment><USER20> talk about synchronicity... sam harris recently released a podcast entailing the ever-present threat of nuclear war: [https://open.spotify.com/episode/7DbMBiOYCCr7LRObkqfffe](https://open.spotify.com/episode/7DbMBiOYCCr7LRObkqfffe)</comment>


Android keyboard hits version 5.0, now has fine cursor control - <AUTHOR> http://arstechnica.com/gadgets/2016/05/googles-android-keyboard-updates-with-one-handed-mode-new-gestures-and-more/ <comment><USER2> Seeing different keyboards in Android makes me think of the faith Google had in their developers compared with how little faith Apple had in their developers. The competition among keyboard applications and improvements brought by such a 'simple' application segment is truly boggling.

Before Android, I would have thought Google's way as the Winodws or *nix. I was wrong. Google was able to bring something new in terms of application development and ecosystem freedom that even Apple is forced to adopt.</comment>


Frustrated with iCloud, Apple's developer community speaks up - <AUTHOR> http://arstechnica.com/apple/2013/03/frustrated-with-icloud-apples-developer-community-speaks-up-en-masse/ <comment><USER3> I've worked with iCloud in conjunction with Core Data. It's as broken as the article describes, and in fact has gotten worse over time.

No one really fully knows WTF is going with iCloud - documentation is basically nonexistent, support unavailable, implementation broken in trivial ways, and error messages inscrutable. I was at an Mac/iOS conference recently where the Core Data iCloud talk morphed from a standard talk into a "here's the mic, anybody have any idea what's going on with this thing" affair. Helpful, but indicative of the state of things.

IMO, from having studied this for many, many hours over many moons, is that what Apple is trying to do is fundamentally hard, if not entirely unfeasible. They're trying to replace a smart server with one that's dumb as a doorstop. More specifically, they're trying to emulate a CRUD web service with a file sync engine.

Conflict resolution is left up to individual clients, since the server doesn't do any "thinking". Likewise, there is no canonical, authoritative state of the store, since the server doesn't "think", only the clients do. Apple was hoping that by shoving a bunch of diffs of your database onto the server, that clients can reliably reconstruct a sane database by playing them back - <USER2> that multiple clients are updating the diffs simultaneously and there is no server-side conflict resolution.

Oh, and if stuff fails, there are no regular snapshot states to fall back to, because iCloud is a file store, not a database engine. Your whole store is now corrupt. Enjoy.

Oh, and there's no way to nuke the database and start over - there are metadata files that are undocumented or that we don't even have sandbox access to, that interfere with completely destroying the database.

At this point you might think "Fine! I'll go to my Settings -> iCloud -> Manage Storage menu and delete everything associated with that app and start it off on a clean slate!"

And then you find out that, even today, in iOS 6.1.3 land, there is a bug from iOS 5.0 where if you delete an app's iCloud bucket _it can never be created by that app, on that account, ever again_. I wish I were exaggerating. _In perpetuity_. Presumably some state gets fucked and now this app is forever more unable to store anything on iCloud.

To make even the most trivial experiment on the iCloud API involves _creating a brand new app_.

iCloud (in so far as it relates to Core Data and document storage) isn't just buggy, isn't just poorly implemented - it's _non-functional_.

<comment><USER4> Core Data is barely functional locally, requiring an enormous amount of invasive runtime hooks to create the appearance of a "transparent" (it's anything but) object store on top of Objective-C objects.

The fact that anyone, anywhere (including Apple), actually expected Core Data to work as a _distributed_ object store is totally beyond my comprehension.

<comment><USER5> Never had any issues. I guess what I build is not complex enough.

<comment><USER3> I work on a fairly complex Core Data implementation in a heavily multi- threaded app.

It requires a lot of discipline, and we rely on a lot of learning-through-pain since the documentation beyond the most basic implementation is mostly non- existent.

Core Data is pretty simple if you do all of your work on the main thread, but then your'e also blocking your main execution loop for operations that can take a long time. A large save will _easily_ reach into >200ms land on an iOS device, and your app will feel like crap.

Thread safety in NSManagedObjectContexts is somewhat documented, but has a lot of quirkiness to it. There is some general knowledge around what is and isn't thread-safe, but almost nothing surrounding _how_ to build a multithreaded app and not be murdered by Core Data. Much of this is trial and error and observing what open source projects are doing.

Once you settle into a decent threading scheme that won't kill you (probably with multiple NSManagedObjectContexts) you have to worry about communicating changes across multiple contexts - then you delve into parent-child contexts, where the document gets even more bare. Then you get into propagation delays when crossing context boundaries.

Keeping your code clean through all of this is also a challenge. There are also runtime issues - our implementation in Core Data experiences unbounded growth in memory usage on iOS5, but not in iOS6, forcing us to manually mitigate memory use (which Core Data is _supposed_ to take care of), creating even more thread-safety concerns.

All in all, it's a pain, but it's also the only realistic object store/graph on the platform.

<comment><USER6> > A large save will easily reach into >200ms land on an iOS device, and your > app will feel like crap.

Can you give an order of magnitude at this would happen? I usually only have 50-200 entities in my database in total, saving maybe half of them at the same time. Yet libraries like RestKit insist on a two-context setup to avoid the saving delay you mention. I'm not sure if I should fight the libraries and go back to a single-threaded setup (that I understand) or just go with the parent/child context flow.

<comment><USER7> Fetch and save operations get pretty slow with even just 10,000 entities (if you touch all those entities). It gets a little better if you pre-fetch all the entities rather than one at a time, but the save is still very slow. Breaking that out into a backround thread is feasible, but as the previous commenter mentions, then you risk momentary divergence between the UI and the backend.

<comment><USER5> Index properly. Save in a queue.

<comment><USER7> This is fetching every entity by its indexed key. My understanding of saving in a background queue is that during that 1-2 seconds, the ui will still be using the pre-modification data set, so very briefly the ui may appear incorrect, no? Not a huge deal, but if the ui will be wrong, then for our app that would still force us to pause the ui until the save finishes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I am one of those developers who don't jump on the bandwagon right away. Experience has taught me to be very cautious. It also comes from doing a ton of work on mission-critical systems where you don't do stuff like install the latest software updates without massive testing on off-line systems.

Yes, sometimes I miss out on really neat developments. iCloud is one of those cases where I am glad for being a slow adopter. My mental red flags went up as soon as iCloud came out. Not one of my apps uses it.

On the end-user front iCloud is also an absolute mess. I probably have a dozen i-devices on the same account (testing, etc.). Crap appears and disappears from devices seemingly at random. The worst of it was what is happening with my wive's iPhone and mined. We share an iPad at home. Now contacts are getting deleted from her phone and mine at random and so are notes. It's at the point where she is not using notes any more because --her words-- they disappear within a hour or two of writing them.

Of course, turning off iCloud is the solution. The problem is that this isn't as simple as throwing the switch. If you turn off iCloud on your device it might actually delete things that it shoved into the iCloud service. And then it deletes the info from your other devices. And it does this in some amazingly weird ways. Without telling you what it is about to delete.

For example, I have never explicitly stored contact information on iCloud. Never. I type new or updated contact information into the phone. That's where it belongs. In fact, I never even use my iPad for this. Yet, some contact information for some strange fucking reason is sent over to iCloud. The first time I turned off iCloud piles of contact data evaporated from my phone. I had to turn the damn thing on again to get it back.

I haven't had the time to research how to fully disable iCloud on ALL of my devices while, at the same time, keeping or merging the state of my data on that particular device. As a developer I managed to avoid iCloud. As a user I was not that fortunate, I succumbed to the new shinny thing on the shelf. Now I want nothing to do with it. Thank you Apple.

Any ideas on how to do this?

<comment><USER9> The only thing I can think of is to set up contact, calendar etc. sync to Google (via ActiveSync or otherwise). Calendars won't magically transfer over since they're assigned to a particular calendar, on iCloud in your case, but contacts should get pushed to Google. That'll at least give you a backup of your contacts, and setting up the other devices the same way should sync them all up.

Can anyone else chime in? Does this sound reasonable? I've had everything on my iPhone synced up to Google services for about 4 years now and it's never caused any issues.

<comment><USER8> I might try that.

Frankly, I'm just thinking of writing an app to export everything to a MySQL database on one of my servers and do my own version controlled backup. Not sure Apple would ever approve such an app, but I can certainly write it and use it internally.

A long time ago I learned there is nothing more important than ensuring your data is safe. I learned this the hard way in college when a drive failure evaporated six months of hard coding...and I had zero backups. You don't do something like that twice.

With iCloud Apple has given us a tool that is so badly done it has the potential to evaporate our data. Amazing.

There's a reason Microsoft code runs the IT infrastructures of small, medium and massive corporations. They get it. They don't engage in making petulant adolescent choices for their users. Crap like removing "Save As" from applications and forcing duplication --and even storage-- of files on iCloud from your desktop.

I've been using Apple products since the first Mac. I could not see any way to trust Apple with enterprise data. No way.

I really don't know what Apple is about any more.

<comment><USER9> That's the downside of keeping your data in a service. This is a conceptual problem due to the lack of agreed upon data protocols. Google Reader has highlighted the issue well, and more services are to follow I'm sure. This is an issue that never existed for files since they by definition conform to a specific format.

RSS and CalDAV are examples of web data formats which do work. I'd like to see more formats like that, or perhaps an ability to fall back to export data as files from web services.

</comment></comment></comment></comment><comment><USER10> It's interesting how the iCloud branding plays into this. Because Apple includes so many services under the umbrella term iCloud, it can lead to a very different impression of the service between the users and the developers. All the talk about "iCloud is broken" is about one specific part, Core Data syncing. The rest, like online backup and document syncing and calendars, seems to work most of the time. I actually saw some comments elsewhere along the lines of "iCloud works fine for me as a user, so it's probably just bad developers who can't get it to work, not any issue with Apple."

<comment><USER11> _The rest, like online backup and document syncing and calendars, seems to work most of the time._

Those 3 things are broken as well. Lost all my data _twice_.

<comment><USER12> But only _most_ of the time. Last week, my iPhone inexplicably deleted all the pages in my Notes application that I made in February 2013, around 20 of them. Fortunately, they're still there in my synced e-mail account, but there appears to be no way to sync them "back" onto my iPhone.

And then last month, syncing my iPhone with iTunes inexplicably deleted the 40GB of my music from my iPhone. I hadn't done anything differently from the hundreds (?) of other times I've synced. I just had to go one-by-one and re- check all the playlists I sync, and wait a few hours for all the music to be re-copied. But still.

As easy as Apple products are to use, I'm always afraid something is going to go horribly wrong, in a way I never was with PC's, for example -- they were harder to use, and did less, but you could at least be reasonably sure of what was going on behind the scenes.

</comment></comment></comment><comment><USER13> (Shameless plug) Firebase is an alternative to iCloud for many apps. It's built as a database, rather than a file store, so it's ideal for storing structured data. Conflict resolution is something we've been thinking hard about from day 1, and we think we have a pretty solid story [1].

We launched native iOS support a few weeks ago [2]. You can also access your data from JavaScript or from a REST API. Android and other platforms are in the works. We're a platform-independent service, and since you (the developer) is paying for the storage, we have the right incentives to give you maximum access to your data (unlike iCloud), and a good developer experience.

We've also put a ton of work into making it easy to learn and easy to use. See, for example, our quick tutorial [3].

If you've used Firebase as a substitute for iCloud, we'd appreciate your thoughts in the comments!

1\. <https://www.firebase.com/docs/transactions.html>

2\. [https://www.firebase.com/blog/2013-03-20-new-firebase-ios- sd...](https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sdk.html)

3\. <https://www.firebase.com/tutorial/>

<comment><USER14> Hey, I've been using Firebase for a web client I've been working on for a bit and I like it a lot! Would you consider updating your transactions page with an example of a text change? Such as adding a word in the middle of a paragraph. I'm not quite sure how that would work.

<comment><USER13> Collaborative text editing generally requires a bit more than a simple transaction to work well (Operational Transforms are generally involved). You can use transactions as a basis for this though. We've got some examples coming out soon to show how to to do this. Stay tuned...

</comment></comment></comment><comment><USER15> Frustrated with just iCloud? No I'd go further. I'm frustrated with the whole iOS platform. It's like writing an app in the 1990s. Sure it works. But it's painful as hell. So much so that I've decided this latest project on iOS was probably my last unless something big changes. And just for the record I have a few flagship apps in the app store with millions of active users and I've worked quite extensively with the platform. So it wasn't a case of trying it and then giving up in frustration. It's more like watching your peers blow past you because your toolset is from yesterday and their's is from tomorrow.

<comment><USER16> What is this toolset of tomorrow your peers are using to blow past you, if you don't mind me asking?

<comment><USER3> I'm not OP, but one key complaint I have is that there isn't much in the way of testing. Unit tests are _somewhat_ well-developed, integration testing is a complete mess.

Much of the iOS community still creates software by the seat-of-your-pants model (i.e., write code, boot it up, does it look like it works? ship it). Engineering rigor is still a concept relatively foreign to iOS, and it shows. Apple has little-to-no built in support for anything that smells like TDD.

When you're talking to your server-side peers who have good test coverage, good regression testing, and more generally just _sound engineering processes_ , you can't help but get bit jealous.

<comment><USER6> I was a test zealot all my academic life (it's perfect for building compilers). But in my experience as an iOS contractor, most apps are polished Thin Clients for a remote backend. Which incidentally is the only thing that Objective C is really awesome for. As soon as I write _any_ interesting logic, it is actually a _bug_ , because it should be pushed into the backend. After all, it must behave the same on Android and on the web client.

That leaves us with bug classes like: multithreaded Core Data misuse, "UI can be broken by using three fingers exactly like this", popping a navigation controller as a reaction to a network operation while it is currently being pushed (based on network latency), networking code that does not properly handle session extensions while multiple concurrent threads are in progress, labels use the wrong font, code uses UIKit on the main thread, ...

Good luck writing tests for that _and_ being more cost-effective than code reviews & manual testing.

</comment></comment></comment></comment><comment><USER8> I went to disabled iCloud on one of my Macs and I got this warning:

"If you turn off Documents and Data, all documents stored in iCloud will be deleted from this Mac"

Let's get past the jaw-to-the-floor, how-dare-you, !!!$$%#$## moment. They are morons and don't respect your data.

So, how do you figure out just what is in iCloud? I don't see an easy iCloud viewing option in Finder.

Doing some digging this is what I found:

      - Open Finder
      - Fire-up "Go To Tolder"
      - Enter ~/Library/
      - Go into "Mobile Documents"

That's what's on iCloud. You have to manually dig through it all and figure out what's there.

If you delete anything there it will be deleted from all of your sync'ed devices, including your local Mac. It will also end-up in the trash folder.

You could copy it all to a USB drive, memory stick, or, better yet, Dropbox. Then you can completely disable iCloud knowing your data is safe and iCloud will never cause you further grief.

<comment><USER17> You are not parsing the message correctly. It says nothing about deleting data from your other devices.

<comment><USER18> Yeah, that's just a hidden surprise for you to discover next time you sync, as I unfortunately discovered when it deleted my entire schedule from a corporate Exchange Account. So not only does it apply to your iDevice, it also applies to any accounts that you've linked to the device and conform to the latest generation of CYA extensions for the Enterprise.

</comment></comment></comment><comment><USER19> It might be nice if Apple's legendary attention to detail extended beyond the logo. [1]

1 - [http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the- golde...](http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golden- ratio/)

<comment><USER15> And that's the problem in a nutshell. If it's consumer-facing it's years in development and polished. If it's for us lowly developers, well don't hold your breath.

<comment><USER20> The in-joke we had as Mac developers many years ago was that Macs are very user friendly. The problem is that developers aren't users.

</comment></comment></comment><comment><USER21> My trust of iCloud disappeared when a restore from backup lost all important data (passwords, Google Authenticator keys, etc.) with no indication. The backup was listed as successful, the restore was listed as successful and yet the only data I needed it to restore was lost.

This was also when I learned that Google's process for restoring lost two- factor credentials ultimately ends in an email form which sends to higgins- firstname.lastname@example.com which been bouncing since _2011_. Thank FSM I had some some backup codes printed…

<comment><USER22> Google explicitly opted out of backing up authenticator keys.

iCloud would be worse if apps /couldn't/ opt out.

<comment><USER10> I don't think that's right. Secure things in iOS are in the Keychain, and the Keychain is only backed up if you do an encrypted backup via iTunes. Other backup methods (iCloud and non-encrypted iTunes) just leave it out of the backup.

The scary thing is that you hope your apps can handle the case where they have local data but no authenticated user for it. Some of them just treat no authenticated user the same as a first start and reinit the local data.

<comment><USER23> The backup, encrypted or otherwise, doesn't contain the actual keychain file itself, but rather a plist export of a subset of the keychain.

Things that are marked as kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly are never included in this backup file. Google's GTMOAuth library uses this value for its keychain records.

<comment><USER10> Interesting.

</comment></comment></comment></comment></comment><comment><USER24> When ever this topic comes up, including at iPhone conferences I attend, no one seems to have ever heard about Simperium, which pretty much has as their mission statement to solve this problem and seems to have actually done so quite well (yet people are mentioning, quite often, only tangentially-related companies like Dropbox); I believe they are even a Y Combinator funded company... I would be fascinated by an explanation of "what they could be doing differently so that people would use them".

<comment><USER25> I've talked to folks from Simperium before and think that they have a good idea but I remain skeptical of their approach . In particular their Core Data syncing strategy.

As I understand it Simperium observes changes to the Core Data models you specify, maps those changes to operation transforms, and distributes the transforms across whichever clients have subscribed to the service. That's great if all your app needs is simple data replication to multiple clients. Unfortunately operational transforms are not necessarily snapshots of database transactions and conflict resolution strategies do not guarantee a valid database.

Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients. Conflict resolution is then performed between operations rather than transactions. Simperium can probably take steps to minimize that case but as long as I can construct transactions which cannot be expressed as a single operation this will happen.

Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules. For example two clients can each add a child object to a "has one" association. Both "create" operations can be applied without conflict but the parent object no longer passes the application's validation rules.

This doesn't make operational transform based synchronization untenable but it does imply a new set of constraints on how applications should model their data in order to successfully apply operations from other clients. That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail. Otherwise I fear such a service is another iCloud like trap which will eventually (though perhaps less frequently) hit catastrophic edge cases from which there is little hope of recovery.

<comment><USER24> > Saving a Core Data transaction on one client may generate multiple > operations which are replayed interleaved with operations from other > clients.

Interesting; I've implemented OT myself, and this is not a fundamental failing of the concept: in fact, even fairly simple implementations like ShareJS do not succumb to this fate (the easy way to model it is that you end up with larger macro-operations that are capable of transforming eachother's components, while still having to be played back one macro-op at a time; you also just stop playback while a transaction is in progress). I am totally willing to believe that Simperium's implementation (which I believe thinks about the separate objects as separately transformable documents) may have issues here, though.

> Worse a client can apply operations without conflicts only to find that its > models no longer pass its own validation rules.

This is certainly true, but is endemic to the entire idea of offline synchronization and has nothing to do with operational transforms: you simply can't do this without accepting "a new set of constraints on how applications should model their data in order to successfully apply operations from other clients"; this is clear from CAP (as rather than become unavailable when the network is offline/partitioned, we have to lose some consistency).

> That may not be a popular sales pitch but I'm reluctant to feed structured > data through a service that doesn't at least discuss the model and its > constraints in some detail.

This is totally fair. (I can entirely appreciate it as well, as it reminds me of all of my complaints regarding how seldom you would hear companies like Parse and StackMob attempt to drill in how important security should be while using their services, at best leaving it as an appendix in their documentation. I believe they have at least been getting somewhat better about this since my talk on the subject at last year's 360|iDev.)

</comment></comment></comment><comment><USER26> There's been quite a few articles from people far smarter than I about it, and most of them agree that whilst doing a server backed database synch service is hard, it shouldn't be _this_ buggy at this stage.

It's like Game Center, Apple doesn't bother with any apps that really use it so there's many, many problems reported on a consistent basis, and they don't seem to use iCloud for anything involving Core Data so they're not dog fooding and having engineers swear at code. No swearing means no one is motivated to go back and try improve it.

</comment><comment><USER27> I tried to add iCloud features to an app as part of a contract gig. It was disastrous. The paying customer knew we were capable, but began to wonder what was going on with us -- it was frustrating to have our client lose a bit of respect for us when the cause was the brokenness of iCloud.

They, understandably, thought there was no way that something so heavily promoted by Apple could be such a lemon. And in spite of having heard mumblings of iCloud bugs, we wrote it off as amateur iOS developers.

We ultimately abandoned iCloud prior to release (going with simple Python based server for data storage) -- reading the other posts I'm glad we didn't try to convince ourselves that the 'almost stable' behavior was just a quirk of our devices having been used in development mode.

</comment><comment><USER16> Anyone care to speculate as to why apple can't seem to do web services with even a modicum of success? (Remember ping?)

<comment><USER28> For the same reasons Microsoft hasn't been terribly successful online?

It's a different game played by different rules.

Interestingly, I'd like to watch and see how Google does moving into the physical goods space.

<comment><USER29> Erm, excuse me?

For one, Windows Azure is a pretty big deal. Secondly, XBox Live is a pretty big deal. Third, Bing might be struggling to gain traction but it most certainly works.

So can you point me to a Microsoft web property or service that is as wonky as iCloud at all?

<comment><USER28> I'm not saying they've found zero success. XBox live is probably the biggest.

At Microsoft's size they aren't really looking for "pretty big deal" successes.

Bing is probably around 15% market share. A home run for most but not (yet) for MS.

I can't really comment on Windows Azure. I'll take your word for it but I think Amazon is eating Google and Microsoft's lunch here.

This isn't a fight for second place.....

<comment><USER29> Apologies, I was assuming we were talking about the technical chops of the two companies when it comes to building web scale services.

<comment><USER28> Apologies not needed. That raises a question though.

I was implying that Apple and Microsoft don't do as well building web services. I wouldn't argue that Azure can't scale but the overall approach seems to be a little bit "unfinished".

Let me explain, the only true cloud computing environment that really solves 90% of any companies needs is AWS. Somehow Amazon understands what the developer community needs. I'm really perplexed by Google not getting this right.

Apple doesn't and I don't believe Microsoft does either.

I don't think this is about technical chops. It's something else that I can't put my finger on.

Similar to how I don't understand how Amazon crushed Best Buy so quickly.

</comment></comment></comment></comment></comment></comment><comment><USER30> As an Apple user, I have often consulted discussions.apple.com to find fixes for problems. A lot of times there were thousand post long threads with no official answer. It is a wasteland. I know they don't answer questions, but they could make an exception for the most important common issues. It's as if they put their fingers in their ears and sing "la la la" while we try to communicate bugs.

How can the richest computing company not answer questions put by thousands of users who have banged their head in the same bug? It's insulting to have this circus happening on their doorstop.

</comment><comment><USER31> The unexpected appleID problem is, in my opinion, a world stopping bug...the kind that would cause a code red meltdown if it wasn't fixed 24 hours. This bug has been reported for years, with no resolution. The apple stores pretend the problem doesnt exist or they give you the runaround because their product that "Just Works" doesnt have a fix for it yet. My wife, who was a hopeless apple junkie, has decided that her current iPhone5 will be her last apple product...with her continued frustration with AppleId authentication being the straw that broke the camels back.

<comment><USER32> If trying to juggle more than one apple ID in the same storefront is breaking the camel's back, she's in for a world of soul crushing disappointment with any less UX polished product -- which is pretty much all the rest of them.

<comment><USER31> With my much less polished Android UI, at least I can use my phone.

<comment><USER32> Someone can't use an iPhone because they're juggling Apple IDs?

First, it supports multiple IDs, the limit is one ID per storefront or sync.

Second, if this isn't about multiple IDs but about multiple addresses for a single ID, and if you don't like it supporting the old addresses, go to <http://appleid.apple.com> and manage them. You can update, edit, and remove old email addresses, decide what your primary one is, etc. I find it helpful to ensure 100% of all services across all devices are using the same exact ID aka email address; one way to enforce this is to be sure your appleID account only has one listed.

On the other hand, if she has inadvertently created multiple IDs over the years, she needs to either settle on one ID per service (my wife has one for music, one for apps, one for iCloud), or she needs to ditch the extra ones and standardize on a single one.

To tell if they're the same or multiple accounts, again, go to <http://appleid.apple.com/> and log in with the one you think is the master, be sure the others are listed. If not, they're separate IDs.

None of this stops her from using her phone. Conveniently, all these phones fine with or without the ID.

FWIW, on my Galaxy Nexus I find managing multiple Google Accounts and cloud data sync more precarious. Sure, there's an easy radio button to pick accounts in the Google Play store, for example, but once I made sure I'm using the same ID across devices I've never had a bookmarks, contacts, calendar, or messages sync issue with iCloud, while I am having to go in and reset sync settings for bookmarks, contacts, etc., every couple weeks on Jellybean. And I usually don't know the sync is broken again until I notice something's missing, check sync settings, and see the broken sync alert.

<comment><USER31> She doesn't use multiple IDs. She only uses one. But in order to make things work, she has tried everything in the book, including trying to sign into her old account when this stupid bug pops up.

And no, she can't use the phone as it was advertised. She has multiple apps that use iCloud for storage, and every time this happens, she just stops using the apps, as it can literally take hours of trying before she can successfully sign into iCloud.

<comment><USER32> > _She doesn't use multiple IDs. But... trying to sign into her old > account..._

Sounds like more than one. She needs to quit using the phone with "old" IDs, she's confusing herself and the device.

Get logged into <https://appleid.apple.com/> and get it sorted out there. If you can't log into that, get on phone with Apple support until you can. As long as you didn't two step auth it, the phone support can and will help.

I'm not trying to debate, btw, I'm trying to legitimately help. Like most of us here, we end up being the support person for our family's devices, and I have seen people get themselves in a jam w/ the ID before. Clearly defining the Primary Apple ID won't be resolved until it's clearly resolved in the web interface.

</comment></comment></comment></comment></comment></comment><comment><USER33> I have been surprised at the relative lack of interest from developers about first class syncing support, when mobile blew up I expected a flurry if libraries and tools that I could use to have my app work offline and sync data wherever I am.

Sometime last year I gave up waiting and started working on PouchDB (<http://pouchdb.com/>), its based on CouchDB's syncing model (and syncs with CouchDB) and works anywhere that Javascript runs (the browser + node), there is an iOS / OSX equivalent (<https://github.com/couchbaselabs/TouchDB-iOS>).

PouchDB isnt quite ready for production but its getting close, I would love any feedback on it, although I expect most people commenting on this would be more interested in TouchDB

<comment><USER34> I'm very interested in this, in fact I'm planning on rolling an iOS based couchDB solution for a company sometime this summer. Could you comment on some key differences between pouchDB and touchDB? Did you also try to simply run ARM compiled couchDB on iOS? If yes, how was the performance there? I've read that initializing takes about 10 seconds - I'd be willing to swallow that if the subsequent interactions are smooth.

How about the initial replication of larger databases? Do you roll out an initial version directly in your app or do you have some file based download of a snapshot?

<comment><USER33> The key differences between touchDB and pouchDB is that touch is written for ios and pouch is written for web browsers, if you are building for ios and not using phonegap then I suggest using touchdb. It is also the more mature of the 2 but hopefully we arent too far behind with pouch.

I used to work for Couchbase on the arm compiled couchdb mobile versions, mainly android but either way I wouldnt hugely recommend using them, they always worked against the grain of the platform, never had great performance and due to those reasons they didnt really get widely adopted and therefore I wouldnt trust their stability across a variety of platforms and use cases.

The problems with arm compiled couchdb is the reason TouchDB was made, and similiarly with PouchDB / TouchDB for android and CouchDB I hope we get to the point were there is an out of the box sync solution that works great on every platform, it doesnt feel too far away.

For large initial datasets I have tried taking a dump of the database and importing it on first load, it worked however replication has been more than sufficient for my use cases right now. Once pouch has stabilised and released there are a lot of low hanging fruit that can be done to optimise replication (and in particular for first load).

<comment><USER35> The TouchDB project was started at Couchbase, and since then we have ramped up our investment in mobile sync. The key thing about this project is that its designed to be tiny and boot fast. So it is written in Objective-C (and Java for Android.)

We are renaming TouchDB to Couchbase Lite (still 100% open source), and have a bunch more tools for it:

Couchbase Lite container for PhoneGap: <https://github.com/couchbaselabs/LiteGap>

Couchbase Lite for iOS: <https://github.com/couchbase/couchbase-lite-ios>

Community mailing list: <https://groups.google.com/forum/#!forum/mobile- couchbase>

We are 100% serious about building the best damn database for mobile. Bonus points that it will seamlessly interact with other projects like PouchDB and friends via the sync protocol originally written as part of Apache CouchDB.

</comment></comment></comment></comment><comment><USER36> I don't mean to be flip but how could you think a company that has to take down their store to change the product inventory would be a good bet to build solid web services?

<comment><USER10> OTOH, the number of leaks via prematurely updated store pages that you see on other manufacturers indicate that it's not as easy as you would think.

<comment><USER37> It's called staging and scripts.

<comment><USER10> I just wonder what the practical effect of Apple's online store being down is... it looks bad, but does it actually cost them any sales?

<comment><USER6> When I still had Mac blogs in my RSS reader, the store closing down for a few minutes would actually cause wide coverage with a follow-up post on what how their inventory has changed.

</comment></comment></comment></comment></comment><comment><USER38> Anyone using TouchDB as an alternative to iCloud core data syncing?

<https://github.com/couchbaselabs/TouchDB-iOS>

Of course, you would need to support some form of CouchDB server for this to work, deal with authentication, etc.

<comment><USER39> In my last startup, I used TouchDB and found that 95% of the time, it worked great, and 5% of the time, the app would grind to a screeching halt.

Reading documents from the local TouchDB store would block the main thread until the upstream CouchDB server would reply with the document's current revision, even if the local store already has an existing version of the document. Using GCD to wrap around these document transactions was still clunky at best and resulted in a poor overall UX.

YMMV, perhaps these issues could have been worked around if I had had a more realistic deadline and stayed in touch with the community. The maintainer, Jens Alfke, is very active.

<comment><USER35> Thanks for the heads-up. We are very responsive to issues filed via the Github issue trackers, or brought up on the mailing list. My guess is this has been fixed since then (we've rewritten a lot of that code path), but if it isn't fixed, you can find a link to all of the relevant bug trackers on our Google Group splash page: <https://groups.google.com/forum/#!forum/mobile-couchbase>

</comment></comment></comment><comment><USER40> Core Data now provides NSIncremental store, which lets you use any web API as your persistent data store. It's possible to roll your own alternative to iCloud in this way, if you choose.

<comment><USER41> Core Data + NSIncremental store with a web api backend does not solve the problem of offline sync. It is possible to roll your own, its hard to get it right. It is complicated by iOS restriction of not able to run your own daemon. But then if I have the resource to roll my own then I would not complain about Apple.

Dropbox does not come close as alternative. Dropbox as of now is file-based sync. Core Data iCloud sync is trying to sync an always opened SQLite3 database file, they do it through database log files. Possible alternatives are TouchDB, Simperium, Firebase but then you have to change your app from not using Core Data. Or rewrite your app to use file based storage as what 1password did. The key is offline sync. File based cloud sync is solved problem. So maybe the way to go is persistent store of client app has to use files.

<comment><USER40> Very true. The pain point seems to be largely the database merges; it's possible to roll your own db while using iCloud mainly as a key/value store for synching user preferences and status between devices. This is particularly useful if you support more than just apple devices...

Edit: regarding offline sync (which I didn't address) something like AFIncremental store is a good example of how a local persistent store can be maintained in tandem with the online store.

(But, as you say, non- trivial and hard to get right.)

</comment></comment></comment><comment><USER42> If I'm not mistaken, there seem to be better cross platform options in Parse and Dropbox. A case can be made for the "walled garden", iCloud doesn't seem to be one of them.

<comment><USER3> There is indeed an opportunity here for other cloud providers - but "better" is fuzzy. The nice thing about iCloud is that once you set it up on a device, there is no need to configure it or authenticate ever again.

It "just works" (if it actually worked).

With Dropbox, either you are storing everything for all of your users (and paying for it), or you integrate into the user's Dropbox account - which would necessitate a fancy ol' login/authentication system. Far from seamless, and relies on your users subscribing to something that is popular but far from ubiquitous.

So... either pay through the nose for _all_ your users' storage, or force them to jump through some circus hoops on their own. Neither are great.

<comment><USER27> The biggest reason we wanted to use iCloud is: background syncing (i.e. not just when the app is in the background, when the app isn't even running).

For apps that get a fair bit of off-line data creation this is a nice feature.

There's no way for a third party library to do this (at least not through iOS 6.1.3 SDK).

</comment></comment></comment><comment><USER43> Tuesday's article on The Verge [1] was a lot clearer about the distinction between the various components that fall under the iCloud brand and what the problems are with the Core Data synchronization piece.

[1][http://www.theverge.com/2013/3/26/4148628/why-doesnt- icloud-...](http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-just- work)

</comment><comment><USER44> I feel like I'm the only person that has had zero trouble with iCloud. My phone backs up to it regularly (without my having to do anything whatsoever) and I've transferred my entire phone settings (and my wife's) more than once to brand new devices via iCloud.

In my experience, it truly does "just work".

<comment><USER45> Right. So as a consumer, it's mostly painless.

For developers, it's fundamentally broken as potatolicious describes <https://news.ycombinator.com/item?id=5454729>

<comment><USER44> Gotcha. I guess I just don't see what all the fuss is since it works flawlessly for me.

<comment><USER46> Lots of things fall under the iCloud umbrella. A lot of them DO work. Just as you only think about the parts that work, ios developers think about the parts that do not work- so to you iCloud works and to them it doesn't even though you're talking about different things in the system.

</comment></comment></comment></comment><comment><USER47> I think the reason developers (myself included) try, and re-try to make it work (Coredata + iCloud), despite all the bad experiences and bad stories is that everybody would like badly that it worked. Because if it worked it would be awesome, when I test it and that it works it's really really nice, but I lost confidence in the overall reliability so in the end I never take the risk to ship it.

<comment><USER48> That's like staying with an abusive spouse because he bought you a nice dinner once.

<comment><USER49> Except that fixing abusive spouse is nearly impossible, but fixing buggy service is possible (though it may be hard in this case).

<comment><USER6> Not only that - for Game Center it seems that this has actually happened.

</comment></comment></comment></comment><comment><USER50> The document storage of iCloud is broken from a design viewpoint: I don't want to store/find things based on app, but rather by date/time created, content type, name, etc.

If I have many apps that do the same thing, I'd have to go through each one to remember where I saved something. No, just no.

</comment><comment><USER51> Expect Parse to be bought soon..

</comment><comment><USER52> Sounds like an opportunity for Dropbox. Go Dropbox!

<comment><USER53> No, the article covers this. Dropbox is great, but it is based on document syncing. Apple has document syncing working just fine. Like database synching, Apple and Dropbox both have issues. To get a hint of the problem, you can read this post about why git+Dropbox is problematic: <http://www.unityisplural.com/2012/02/git-dropbox-bad.html> (I've used git+Dropbox and have gotten corruption issues in my git repo).

Further, by pushing an app relying on Dropbox, you're telling your users to sign up for an extra service to use your app. That's bad.

<comment><USER54> It's true that git+Dropbox isn't resilient in the face of multiple simultaneous writes, but I think the problem is overstated. You might see an inconsistent state, but you'll never get corrupted data because of it. You might corrupt the repository on Dropbox (has happened to me a couple of times), but this is trivially fixed by deleting and recreating it.

I'd never use it for a large team, but for a couple of collaborators, or syncing a repository between multiple computers for a single developer, it's a nice and easy solution.

</comment></comment></comment><comment><USER55> Apple's dalek lawyers will emerge chanting litigate! Litigate! Litigate!

Serious Apple have always done a crappy job of online services - why would you expect any more.</comment>