Google Checkout will be retired, transition to Google Wallet - <AUTHOR> http://googlecommerce.blogspot.com/ <comment><USER2> Google is making the same mistakes Microsoft made. Trying to enter into every industry it can thinking it can use it's monopoly power to take over the world. Reality: Doing 20 things mediocrely is not as profitable of doing 2 things very very well.

Result:

1) Constant experiments and dropped products (just like Microsoft).

2) Consumers no longer trust your services to stick around and no longer even invest in your platforms (*see most of Microsoft's offerings).

3) The services you do have aren't the highest quality and your brand takes a hit as being "giant mediocre corporation" like Microsoft instead of "high quality company" like Apple.

The more things change the more they stay the same.

<comment><USER3> Completely agree. I'm so disappointed in Google for having Checkout for _years_ and not doing anything serious with it. I really wanted it to become a serious alternative to Paypal. But it's like they never even tried.

And it turned out to be _huge_ mistake for them because they could've _really_ used Checkout accounts from day one of Android, to get people to pay for Android apps. I still believe this has been one of the biggest obstacles on Android, because you need Google Wallet (which is brand new service, I guess) account to pay for apps, and obviously the vast majority of people didn't have one, and didn't bother to make one either, and they'd rather look for the free alternative of the app.

It's been getting a bit better since Android 4.0, since they are asking everyone to make an account at the set-up, but they are still behind, and it could've been much better early on if Checkout was popular.

<comment><USER4> As someone who used to recruit for Google, and watched the team recruit THOUSANDS of developers only to discontinue product after product, wtf are these guys all doing?

</comment></comment></comment><comment><USER5> Earlier today I received a phone call from a number in Mountain View CA. It was Google letting me know in advance that Google Checkout was to be shut down (and asking to keep the call quiet). This was, to say the least, very surprising considering I have very little correspondence with Google Checkout and was actually thinking there was a huge problem with my account. Thankfully not but this is still bad news for myself and I presume the industry at large.

Google Checkout was _very_ good with their fraud protection to the point that I did not have to think about it. In fact, over the years I have been growing my business Google have been my rock---never a real issue with them.

PayPal was a similar story but it also seemed to attract the sort of customer that would open a dispute at almost any issue (or just threaten it). You can also count me in one of their horror stories that indirectly cost me £5k and even got to the point where they just flat out refused refunds for my customers who wanted them.

I have a Stripe and GoCardless account as well and I've been trying to make it work but their fraud protection is just not up to scratch compared to Google and PayPal, which is a real shame. I'm not sure if I'll ever be able to see enough data to get quite the same fraud protection. Stripe do look fun though.

Another perspective from a merchant: roll on Bitcoin. With exchanges offering guaranteed payouts in another currency (for me, GBP) I take on zero risk by accepting it and it solves so many problems. There's no wonder more and more websites are starting to accept it.

<comment><USER6> Someone suggested Bitcoin today, as a merchant, what would you recommend to start accepting it? a third party service?

<comment><USER5> Definitely a third party service. Then place the bumper sticker "No Bitcoins on our servers" somewhere :)

I integrated MtGox and BitPay. Compared to Google Checkout (XML mania) and PayPal (documentation drama) they take about 5 seconds to implement (test is another thing entirely).

I went with MtGox in the end since it was cheaper. I was then happy to offer a 3% discount to make up for the fees users got stung with purchasing BTC. However MtGox has a number of bugs that make it a show stopper for some customers.

If you ask the right questions they will acknowledge the bugs and tell you they are working on it and need plenty of time. I would probably not use MtGox if I had known about the bugs prior to integrating.

<comment><USER7> Just wanted to public thank you for detailing your experience as a merchant, setting up with MtGox and BitPay.

Just curious, would you give BitPay a second look?

Obligatory: I'm currently using MtGox and haven't really had the time to try BitPay, but the MtGox legal issues could be a reason to need a second option.

<comment><USER5> Yes I would, I'd probably jump back to them. I've just not had time to sit down this year!

</comment></comment></comment></comment></comment><comment><USER8> Although Google Checkouts is shutting down, Google Wallet for Digital Goods still lives on (<https://support.google.com/checkout/sell/answer/3080449>). It offers pretty much the best pricing on the net (most favorable of 5% or 1.9% + 30c (USD) per transaction is automatically applied.) and works in way more countries and currencies than Google Checkout ever did (<https://developers.google.com/commerce/wallet/digital/faq>).

<comment><USER9> I feel like no one actually read the submission. Google Checkout and Google Wallet overlapped too much, and Wallet won out. If your website uses Checkout, just replace it with Wallet, and move on with your life.

<comment><USER10> Wallet doesn't have payment processing except for items on Google Play.

</comment></comment></comment><comment><USER11> I don't trust Google any longer. Google (usually) brings out fantastic products only to neglect and abandon them like a bored toddler.

This wave of product discontinuations is making me extremely hesitant to use anything new Google brings out. If Google brought out Gmail today I'd sign up and explore what it's about, but I wouldn't ever give out the email address for fear that it would be snatched back with no or little notice.

I'm not going to pretend to know Google's business better than they do, but to me it appears as though they're really dropping the ball here and losing a lot of credibility and trust.

<comment><USER12> I wonder how we would have reacted if rather than spacing all these out, they batched them up an did one big announcement with plans for all lines being discontinued. Quick and clean sort of deal.

</comment></comment><comment><USER13> Anyone have any idea if this effectively terminates any existing recurring Google Checkout subscription payments (on November 20)? If so, that's kind of a big deal. Cutting off merchants from their revenue stream is a great way to get people really angry and could easily destroy a business.

<comment><USER14> My understanding is that merchants would need to ask their users to re- subscribe through different payment provider. It seems very unlikely that Google Checkout would allow any way of importing users' credit card information.

After such treatment I'm very unlikely to use any future Google's payment systems (such as Google Wallet).

</comment></comment><comment>===

<https://support.google.com/checkout/sell/answer/3098725>

The ability to process recurring charges or subscriptions using the subscription beta feature will be shut down on November 20th.

</comment><comment>===

<comment><USER13> Wow, so it _is_ true, that's the confirmation I was looking for. Really hard to believe. I knew if they did shut them off they would point to the fact it's still "beta". The subscription feature has been labeled beta since it was released in March 2009. This is sick.

<comment><USER14> I was confused about that "beta" part, because I didn't know that Google Checkout Subscriptions was still in beta. Now it all comes together.

It looks like Google is exercising in Doublespeak. I received email from Google Checkout today. After skimming headers I could not understand what they wanted to say.

How do you like email's subject: "An update to Google Checkout"

"An update"!

Thanks to Hacker News it's getting all clear now.

Anyway here's full email:

</comment></comment></comment><comment>===

[Google Wallet]

Safe & Secure

An update to Google Checkout

Hello,

A key focus of Google Wallet is to simplify and improve the commerce experience for merchants and shoppers. Just last week, we announced two enhancements to the Google Wallet platform. The Instant Buy API enables merchants to offer a fast buying experience to Google Wallet shoppers on their Android apps and websites, while processing their own payments. In addition, the new Wallet Objects API enables merchants to engage their customers with loyalty, offers, and more.

As we continue to build the Wallet platform, we must focus our priorities. That is why we are announcing today that we will retire Google Checkout. We remain heavily invested in building a platform that enables merchants to meet the demands of a multi-screen world where consumers shop in-store, at their desk and on their mobile devices.

I sell goods or services using Google Checkout. What does this mean for me?

Merchants can continue to accept payments using Google Checkout until November 20, 2013. We have partnered with a few best-in-class companies to provide you with discounted migration options, so you can continue to run your business with as little disruption as possible.

[Braintree] provides everything merchants need to accept payments, and powers many of the fastest-growing online and mobile businesses around the world.

[Shopify] offers a fully hosted online shopping cart so you can quickly and easily accept payments with top payment providers.

[FreshBooks] is an easy to use online invoicing solution.

If you are a U.S. merchant that does have payment processing, you can apply for Google Wallet Instant Buy, which offers a fast buying experience to Google Wallet shoppers.

I am an Google Play Apps or digital goods merchant. What does this mean for me?

Sellers of digital goods on Google (Google Play, Chrome Web Store, Offers Marketplace and Google Wallet for digital goods) will automatically transition to Google Wallet and will not be impacted. Learn more »

If you are a user of the above products, but use the Google Checkout APIs for notifications or reporting, stay tuned. We will be announcing replacement APIs shortly and recommend you stop using the Checkout APIs as soon as possible.

Learn more about integration types, the best migration solution for your business and next steps on closing your Checkout account. What this means for shoppers There are no changes. Shoppers can continue to use Google Wallet to purchase goods wherever they see the "Buy with Google" button.

More details

• We will continue to process Checkout transactions until November 20, 2013. The last date for refunds will be December 20, 2013.

• After November 20, 2013, all order reports and history will be available for download.

• In order to help us disburse all funds to you and file your tax forms properly, please verify that your Tax ID and business name match what is shown on your income tax return.

• You will see slight changes to the Merchant Center as we go through this process with you.

More help

To learn more about this change, we invite you to join us for our live webinar on May 23, 2013, at 10AM PST. As always, feel free to contact us at any time. We look forward to working with you as we explore new payment methods.

Sincerely, The Google Checkout Team

Google Wallet | Help Center | Call support © 2013 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043

You have received this mandatory email service announcement to update you about important changes to your Google Checkout account.

</comment><comment>===

</comment><comment><USER15> This is a real shame. My business was one of the very first to integrate Google Checkout into a website shopping cart after the general release. I did a marathon coding session the first week it came out because I knew that it would be worth some free publicity if I got it working.

All of our payments come through either Google Checkout or PayPal. And some people really hate PayPal, so we will be looking for alternatives (Amazon Payments springs to mind).

I could see the writing on the wall for Google Checkout a couple years back, though. They failed to add any new features in recent times in order to try to match PayPal. The reporting was weak. E-mail notifications didn't always work right. Declined charges were a hassle. E-mail payment requests couldn't be formatted and were too short. Those were my main complaints, I'm sure there were many more problems faced by people who had different requirements.

Checkout had huge potential to integrate into Google's other services. For example, it let Google see directly who the best and most reliable merchants were. In fact, I believe you can still have Adwords show stars on your text ad based upon Checkout customer feedback.

Another useful integration is with Analytics. They did attempt some information sharing there. Tying Analytics directly to sales information is fantastic, and I wish they had made them work together better.

</comment><comment><USER6> It's a real shame that Google Checkout never really was what was promised, we've integrated it into our shop and we have more GoCardless payments than Google Checkout, it was a horrible system to deal with and I won't miss it when it goes (and if I ever get a response about the Stripe UK beta I'll be swapping that quick sharpish)

We've had more declined transactions on Google Checkout than PayPal + GoCardless put together.

<comment><USER16> (I work at Stripe.)

Sorry you haven't gotten one yet! I just sent an invite your way.

<comment><USER17> Is this for e-commerce? I just suspected you guys didn't seriously consider e-commerce since you don't do pre-auth and settlement. It being illegal to charge the customer before shipping in some countries and such.

<comment><USER18> They do: [https://support.stripe.com/questions/can-i-authorize-a- charg...](https://support.stripe.com/questions/can-i-authorize-a-charge-and- then-wait-to-settle-it-later)

<comment><USER17> This is a very recent change, if I am not mistaken. Seven days is a very short window.

</comment></comment></comment></comment></comment><comment><USER19> Retiring a payment system is really the ultimate insult to those that invest in your platforms.

Imagine the bank that you use for your business transactions, especially recurring billing, to one day walk in and say: so sorry, you won't be able to process your old payments any more, but here is a new and shiny service that we think is better that you'll have to use from now on.

Never mind the integration overhead, possible loss of business, customer service issues and all the other headaches that can come from a thing like this.

I'm scared just to change bank accounts given how far those bits of information have propagated, losing a billing platform is a nightmare for businesses that rely on it.

Why would anyone switch to another service by the same provider that just chose to shut you down or that chose to saddle you up with a bunch of overhead on this years calendar?

Google partnering with braintree, shopify and freshbooks is the saving grace here.

In payment systems only two things matter: fraud control and continuity. Google excels at the first, drops the ball on the second.

</comment><comment><USER20> I am surprised that they will no longer offer processing. The whole reason I even used them was to prevent the need to deal with a payment processor (my current store options for customers are google and paypal).

I checked out amazon's offer again and will likely add them as a replacement. They have a lot of existing customers, the charge is reasonable, and I will be able to integrate it in a fairly painless manner.

</comment><comment><USER21> I'm a bit uninformed about the capabilities of Google Wallet and Checkout. Anyone care to elucidate the differences? Do they perform the same functions?

</comment><comment><USER22> I think the problem was Google's Api was very ill written compared to Paypal's. This may be an old implementation, but I think the Api didn't allow subscription services easily, and also notified it's sellers of an order immediately (regardless if the transaction was successful or not).

Beside, I think Google is investing the proper resources in building Waller to be a formidable product against Paypal, Amazon, and other 3rd Party checkouts.

Side Note: For the Google Checkout devs that read this, I'm sorry for what I did (Michael Largent).

<comment><USER23> Shoddy API's are not unique to Checkout. Most, if not all, of Google's API's are actually pretty terrible. When they DO update their API's it's pretty rare that they tell anyone, and they never update their documentation. So, a workflow that worked fine last week will suddenly fail disgracefully and you'll have no idea unless you find the right version of the docs.

<comment><USER24> maps has a great API.

</comment></comment></comment><comment><USER25> I figured this was going to happen when they announced Wallet, :/. <https://news.ycombinator.com/item?id=5714531>

<comment><USER26> This is the real story. They're not shutting down at all, they're pivoting their focus within payments to mobile/physical presence. Getting rid of 'card not present' situations means cheaper and more reliable processing, and the physical focus that goes with mobile payments gives additional reasons for Android users to leave their credit card details with Google. Google's fastest growth right now must be in Android-driven Google account signups. I can see why they're focusing on that area, rather than some old, first financial world only, pre-monopolized, credit card not present delayed payments reverse charges web based fraud rule quagmire.

</comment></comment><comment><USER27> Good thing I'm not using Google Checkout anymore. It's still a shame though. I actually like it more than Paypal but having done some experiments with my ecommerce businesses (e.g. <http://www.wellingtonstravel.com/>) I found people trust the Paypal payment option more or are more familiar with it, leading to more conversions. So that's why I went with Paypal over Google Checkout.

</comment><comment><USER28> Ugh, this is terrible. The one service I actually used with Google, and they shut it down. In their defense, its been dead for a while, they made the UI horrifying to use and a giant PITA. Glad I got my one last payment in.

Time to move to stripe.

<comment><USER29> Looks like Google partnered(?) with Braintree, Shopify and Freshbooks-- like you can get a discount for transitioning. Considering how many people mention just moving to Stripe on this thread, I wonder what sort of hoops those three had to jump through to get their names on the page. Also I wonder what part of the process led Google to choose those three over their competitors.

It seems like Stripe would have been a natural choice. Anyone know anything about the vetting process and want to comment? It would be interesting if there was a hangup or concern that led to the decision.

<comment><USER30> Stripe is only available in North America, and probably lacks the headcount to handle thousands or more new merchants in a short time. Braintree's more than twice as old, more than twice as big, and operates in US/UK/AU/CA/EU. Recommending Stripe would mean sending many of Google Checkout's merchants somewhere that can't help them. Google Checkout, like many third-party processors, is heavily used by merchants outside the US where a traditional merchant account is much more difficult to acquire and integrate.

<comment><USER10> Google Checkout was US/UK only.

</comment></comment></comment></comment><comment><USER31> Wait, so what's the difference between this and Google Wallet?

<comment><USER32> > Wait, so what's the difference between this and Google Wallet?

With Checkout, Google is a credit card processor.

With Wallet, Google isn't a credit card processor, they are partnered with Bankcorp Bank who is issuing virtual cards which are funded either by transferring funds from the users bank account or by charging credit cards.

</comment></comment><comment><USER33> This is bizarre considering that the Gmail money thing just launched so Google is remaining in the payment processing business (different from Play in that Checkout and Google Gmail Money are much more accessible to recipients).

<comment><USER32> > This is bizarre considering that the Gmail money thing just launched so > Google is remaining in the payment processing business

The "Gmail money" thing is a Google Wallet feature, as Google Wallet doesn't include credit card processing on the merchant side, I suspect that for things where Google is, effectively, the "merchant" (like sending money through Gmail), they are paying a third party for processing services.

</comment></comment><comment><USER34> Uh... calling it a "shutdown" isn't all that close to the truth. They're transitioning from Checkout to Wallet.

<comment><USER35> It may be a transition for Checkout users, but it's a shutdown for merchants.

* Shutting down payment processing which was a pretty fundamental part of the offering

* they're requiring you to reapply to get an instant buy account

* They're killing off the APIs

It's not a transition if you lose a core feature, don't transition the accounts in any meaningful way, and have to implement a new system - at that point it's about like switching to PayPal (except you get to keep payment processing if you switch).

</comment></comment><comment><USER36> anyone taking bets... ehm willing to speculate on what big is next dying at google? I'm thinking about google tv, or is that Q already gone? music? books? I'm happy to see G staying on the marketing garden

<comment><USER37> I'm going with FeedBurner. Although you could argue it's already 90% dead.

<comment><USER38> We're betting the same, and have put our money where our mouth is: <http://feedsnap.com/>

<comment><USER39> Go bold. Love it.

</comment></comment></comment></comment><comment><USER40> At some point I thought the master plan behind Google Checkout was to tie the adword payments to actual purchases behavior. So instead of paying per click an advertisers could have paid "per purchase".

With enough sites on board Google would probably have been in quite good position in trying to figure out if the user is really going to make the purchase or not. If user is likely to purchase, then show him "pay per purchase" ads otherwise just regular "pay per click".

</comment><comment><USER41> If you are interested, I have been keeping score: <http://jensenbox.github.io/timeline/>

</comment><comment><USER42> Could this mean that could expand the number of countries that were supported by checkout?

I really hope so, not being able to sell in the Play Store/Chrome Web Store is something we've been looking for a while.

</comment><comment><USER43> This title is inaccurate. Google Checkout is being upgraded to Google Wallet, which provides the _exact_ same functionality with more features.

<comment><USER10> No, they are getting rid of the payment processing.

</comment></comment><comment><USER33> I wonder if anyone besides Braintree will step in with a copy of Google's APIs and try to win some easy business?

</comment><comment><USER44> I reason google shoud bring labs from the dea, and use it to test the waters with products like this.

</comment><comment><USER45> Amazon is still a viable alternative to PayPal.

I used it to buy the latest Humble Bundle.

</comment><comment><USER46> I just hope they don't toss Scholar. That thing is salvation.

</comment><comment><USER47> The post says they are transitioning over to Wallet in the very first sentence. It's amazing how many people are commenting without even getting that far into the link.

</comment><comment><USER48> does anyone have any idea what happens to the google drive subscription, if you're paying via google checkout?</comment>


Launching the Kindle Fire was a mistake - <AUTHOR> https://plus.google.com/100838276097451809262/posts/EvstFnKynKf <comment><USER3> I read the first few sentences of this and stopped when he said it was downright terrible. Having just received one for Christmas myself, I really have no idea where all the Fire hate is coming from. Sure, it's not an iPad, but it is absolutely a gap between my phone and my MacBook that I am now happy to have filled. Laying in bed watching Arrested Development, playing Angry Birds on a slightly larger screen, or browsing the web all work just fine. It also was neat that all the apps I got on the Amazon Appstore already sync'd directly to the device.

I'm also really impressed with how Amazon took the physical buttons (menu, back, and home) off the actual device and made them part of the UI by tapping a little arrow at the bottom of the screen.

Yes, the power button is misplaced, but overall I am very satisfied with this $199 tablet that I am finding myself using pretty often so far.

<comment><USER4> I've played around with most companies' flagship tablets, to include the iPad. With the exception of my windows 7 tablet, the kindle fire was the first tablet that I actually purchased. Overall I love it, but there are a couple of things that really hurt the experience.

The biggest issue for me would be that the kindle fire often doesn't respond to input very well. I often find myself having to press a button 2-5 times in order for it to register. I know I am hitting the button because the button animation seems to be working correctly. I hope that they finally manage to fix this issue with another update. This alone brings the device from 4.5 stars down to 3.5 in my opinion.

The only other issue I have is that magazine/comic books are being sold for the kindle fire as if they are actually readable. This is more of a complaint against magazine and comic book publishers who should have started optimizing their content for digital display years ago. I shouldn't have to manually zoom in every time I turn a page and then pan around. The print magazine industry is rapidly becoming unprofitable, so why aren't these companies busting their asses to create e-reader friendly versions of their products?

</comment></comment><comment><USER5> Many of his main points are vacuous at best. "Adding insult to injury, it's an extremely simple and ugly unlock-gesture, just the sweep of a mono-color bar from right to left." Since when is a function being simple a problem? And he's comparing it to a Windows phone, where the entire interface is based on "mono- color" tiles.

The Fire is a $200 tablet, and aside from a misplaced On/Off button (not sure how that got passed QA), the hardware you get for $200 is incredible. The software could use some work, there's no doubt about that. But here's the thing:

 _They can improve the software._

I don't love my Fire, but you can hardly say it is "downright terrible", especially when you consider the price tag.

<comment><USER6> My mother or any other normal non-geeky people in my family doesn't care whether the problem lies in software or hardware. They care about the experience.

The Kindle Fire experience is terrible right now. That terrible experience is what they'll remember and associate the brand with.

<comment><USER5> "Terrible" is hyperbole at best. And while they may not care, my point is, Amazon can (and, I hope, will) improve it.

All of these complaints about a $200 tablet remind me of Louis CK's bit on airplanes and cellphones, "Everything's amazing, and nobody's happy."

<comment><USER7> You have a right to bitch if you're told you'll be flying a DC-10 and they seat you in a single engine Cessna.

<comment><USER8> Where did you get the idea that the the Fire is a top of the line type device?

The Cessna costs a fraction of the price of the DC-10. The Fire is a fraction of the cost of an iPad...

Even if you have no idea how to compare tech specs, or if you are brain-dead to marketing tactics, anyone should be able to look at the price tag and think to themselves, _Well, the Fire costs a lot less than the competition. It's probably not going to have all the bells and whistles, but it is going to get the job done._

<comment><USER7> Honestly, I didn't even include the iPad in the analogy. I would say the iPad is the 767.

The Nook Tablet is borderline DC-10. Of course, I'm looking at these devices with a rooting perspective as well. The screen quality, RAM, and extra storage space giving the Nook the edge. I have no desire to listen to music on a tablet, so I really only care about web browsing and video. The e-ink devices are still superior for regular text IMO. Unfortunately, since the publishers adopted the agency pricing model, these devices won't decrease in cost as quickly as they would have under regular retail pricing that would've allowed the razor blade model to defer the costs.

</comment></comment></comment></comment></comment></comment><comment><USER9> I bought one. I love it. I CANNOT wait for a 8, 9 or 10 inch one because I will be the first one to get it (assuming it's still cheaper than the Ipad).

I have no idea what people are talking about when they say they are disappointed. Seriously how much hardware + software do you want for $199.

Last time I read a book and finished it was a few years ago. I just finished a 500 page book on the fire, and it has certainly helped a lot with note taking, going back to highlights etc...

Browsing the internet is just fine, although the video audio seems to be off sync for Youtube videos. Movies through Prime were just ok.

Sometimes it hangs, but it's not all that bad. You just turn it off, then on (really, you just press the button back to back. like 1.5 seconds).

I think most people were expecting a smaller Ipad. Well, come on.

<comment><USER10> How is it with reading PDFs? I read a lot of books on my iPhone without any problem, but PDFs just don't scale right. I'm starting think about getting some sort of tablet and good PDF handling is high on my requirements.

<comment><USER11> With the caveat that I don't have a lot of experience with the iPad's pdf support I'd say the Fire's support is solid. I recently read an entire e-book in pdf format on it. The main limitation is that there isn't a lot of screen real estate so if you want to read it on a full page scale you need to tolerate a very small font (this was not a problem for me). A cool upside is that when you get a Fire, Amazon creates an email address that you can send emails with attached pdfs and documents which will then automatically be downloaded onto your Kindle.

Overall nothing mind blowing but if you like e-readers I think you'll be satisfied with the pdf support.

</comment></comment></comment><comment><USER12> Funny that anybody can think there is a first mover advantage in this market when tablets have been shipping and failing for about 30 years now, the idea itself is over 50 years old, and some directly related patents are over 100 years old!

The secret to Apple's success is obviously their zen-like patience and restraint.

<http://en.wikipedia.org/wiki/History_of_tablet_computers>

<comment><USER13> Tablets could hardly be considered consumer appliances before the iPad. They're not even in the same league, and this is coming from someone who owns zero Apple hardware.

<comment><USER12> I think tablets before the iPad would have taken whatever they could get, but they couldn't make it in any market. Apple had to wait for many planets to align before they could make their move:

\- It wasn't until the web that any new consumer computing platform was viable whatsoever.

\- Even then, the new platform had to start as a phone, so people had an excuse to buy it (well, I need a phone anyway...) and so the carriers could subsidize it.

\- All the technology needed to be there, and cheap: a responsive multitouch sensor, a GPU for smooth interface animation, a backlit color screen, gigs of solid state storage, hardware video codecs, batteries that last for days, durable glass/metal enclosure, and probably all sorts of little things that we don't even notice.

My point is that the iPad's success wasn't about being first. It was essentially about being _last_.

</comment></comment></comment><comment><USER14> I almost hate the Fire. I have a Kindle Touch and I thought the interface between the two devices would at least be consistent.

In the Fire to bring up the menu when reading a book you tap the bottom of the screen. In the Touch you tap the top of the screen. In the Touch you can look up the definition of a word the same way you do on the Fire. However, on the Touch when the definition of a word comes up you can look up the definition of a word used in the definition of the word you just looked up the same way the original word's definition was obtained. You can't do that in the Fire.

Why don't both devices automatically sync? When I first turn on a device I sync. Sometimes when I open a book I have to sync again to get to the furthest read page. Why do I have to sync after syncing?

Why does the browser icon show up on the main page of the Fire every time I use the browser? I keep removing the icon from the main page. Shouldn't I only have to do this once?

Turning pages is a great pain in the Fire and the Touch. You tap the screen and a page turns. This is horrible because sometimes while holding the device I accidentally tap the screen without meaning to turn a page. The iPad has the swipe interface for turning a page. Apple got this spot on. Amazon should copy Apple in this regard.

The web browser on the Fire is horrible. It's slow and I can't get web base email to work properly on it. This is pathetic.

I could go on but the point is made. The Fire is an unpolished device. It's almost entirely pathetic. This is all just my opinion and others will have a different opinion but I would highly recommend getting an iPad instead of a Fire. Don't be lured by the low price of the Fire.

</comment><comment><USER15> _The return rate will be high and Amazon will suffer for it._

The Fire currently has over 8000 reviews on Amazon with an average rating of 3.9. Over 5500 of those reviews give the device 4 or 5 stars. Something tells me the average Fire customer does not have such high expectations.

<comment><USER4> While they must be included for accuracy, I found that well over half of the 1-star reviews were written by people who knew that they wouldn't like the Kindle Fire, yet ordered one anyways. There were an awful lot of people who complained that it wasn't as nice as the iPad 2 that they explicitly stated they also own. What logical person buys a low-end tablet when they already have what is arguably the best tablet ever made?

<comment><USER16> sometimes reviews at amazon are annoying. I was reading reviews for a _men's_ gps watch. somebody gave it 4 stars and mentioned that (s)he would've given 5 stars, if "the product had women's model too". It doesn't make any sense. it is clearly mentioned that the model is for men - why write the review at all? people have weird expectations

<comment><USER17> What's more infuriating is when people give 1 star reviews to products they've never purchased for bogus reasons like "the price is too high" or "this is not out in my country".

<comment><USER16> ha, that is funny. I can't afford a ferrari, so it must be a bad car, super logic !!

I've also noticed this - complaining about a product "not being waterproof" when the product makes no mention of being water proof, drivers not available for Mac when the product clearly mentions windows only etc.

Amazon should allow reviews _only_ from people who _actually_ bought the product, that will reduce at least a bit of stupid reviews.

</comment></comment></comment></comment></comment><comment><USER18> Companies need to stop copying Apple, because if they don't, every review will be tainted by why Apple did X better than they did. Apple might not have actually done X better, but they did it first, and people like what they already know. The comment about the unlock gesture is especially relevant; there is no need to stipe something across the screen to unlock a tablet. If people copy that, though, the reviews will inevitably compare it to Apple's implementation, and will like Apple's better. (Be it less lag, better color scheme, better font for "Slide to unlock", etc.) If they do something completely different, like a hardware switch, then everyone will be happy because it's the first time they've ever seen anything like that and the idea will be allowed to stand on its own merits.

The Fire is flawed from the start because it uses out of date software. If you are going to advertise something as Android, then people expect it to be good at Android. Look at Archos' Android tablets; dead because they kept it on 1.6 forever. (I will certainly never buy an Archos product again.) The solution is to not advertise it as having Android, even if you use Android behind the scenes. There are many Linux devices that don't claim to be Linux, and as a result, nobody ever cares that GHC 7.4 doesn't run on it; it's just a box that runs software that does stuff rather than being "a Linux box". (Hell, the original Kindle is a good example of this. Do you want an xterm on your Kindle? Nope! So you don't care that it doesn't have X11.)

Anyway, I guess I'm saying that the key to hardware design is expectation management. Be different so that you aren't compared to Apple. Underpromise so that you aren't compared to something you aren't.

<comment><USER19> If you look at Amazon's own page for Kindle Fire, it does not list Android OS as a feature (with the exception of the Appstore but that predates Fire).

<comment><USER18> Fair enough. But they obviously used Android, so people (including me) expect the tablet to compete with other Android tablets. That's the reason why I don't have one, even if I would only use the Amazon features. (I do own a Kindle, though, because it doesn't promise anything other than "buy books from Amazon.com and read them on an e-ink screen", and that's exactly what I want.)

</comment></comment></comment><comment><USER20> I have a Kindle Fire. I actually like the fact that it is an imperfect product - lags in switching tabs, occasional lags so long in loading websites that you wonder if your wifi has gone dialup, the dang "Carousel". I do like the reading experience and pocket-ability - it fits into a winter jacket easily - though you need to weigh down your opposite pocket to avoid lopsided-ness.

The Kindle Fire is the first credible competitor to the iPad. Android tablets running Honeycomb - it hurts my head - the UI - it is like a Klingon control panel. Definitely not intuitive. The Kindle Fire - it is a compromise - <USER2> custom, dumbed-down ("The Carousel") UI on the iceberg of Android 2.x.

For me, it is a tangible reminder that products aren't all perfect like the iPad. There is no such thing as immaculate conception - the Kindle Fire will get better over time. Comparing it to the iPad is like comparing NYC to... any other city except London[1]. It's a different metro, not as sophisticated - it's for those who just want a tablet device that is relatively affordable.

The iPad has set the bar - it is the _first computer_ for many under the age of six. The Kindle Fire is no such thing - it is, as a review said best, a Kindle with benefits.

[1] <http://en.wikipedia.org/wiki/Global_city>

<comment><USER21> For the record, in terms of metros for ease of use I'd have to say Paris > NYC > London (having lived in all three cities).

</comment></comment><comment><USER22> I couldn't agree with this more. My grandma recently bought one and I spend all of Christmas getting it set up for her and teaching her. She's gotten really frustrated and would probably return it if it hadn't been free from her company.

This part especially is what I agree with:

"Yet, the drive to quickly release a product in a hot field is almost irresistible. Amazon believes growing marketshare is more important than the reputation of their tablet. This is wrong. I believe consumer tolerance for poor products is at an all time low, thanks to ten years of amazing Apple products. Unfortunately, the idea that first movers win is widely believed across the tech industry."

Version 1.0 should be magical.

I do need to correct the author on one point though - I did find a native email client on it.

<comment><USER23> > _"I do need to correct the author on one point though - I did find a native > email client on it."_

Which is nigh unusable. I set up my email account on it and went to bed with it at 70% charge. I woke up with the Kindle Fire at 20%. It drained 50% in about 8-9 hours doing nothing more than email.

Yes, idle email checking uses power, but I have never seen it _that_ bad on _any_ device. The battery is no slouch either based on normal reading/video drain rates.

My Fire's battery has been dry for 4 weeks and counting now. I have no felt even the slightest urge to recharge it and use it. Considering this is a low- margin device designed to hook people onto Amazon's profitable content pipeline, this is an utter and abject failure. Others I know who got the Fire at launch have all either returned it, or their Fires have a fate similar to mine - forgotten in a drawer.

<comment><USER22> Yea I didn't say it was good, but it's there. I had a similarly terrible experience with their mail client.

</comment></comment></comment><comment><USER24> I'm starting to think there must be 2 products on the market right now called the 'Amazon Kindle Fire' - this very enjoyable one I picked up and this other one that all these blog posts are complaining about.

<comment><USER25> Having just received one for Christmas I too find the Kindle Fire quite enjoyable. Yes it could use some polishing, could possibly be the fact that it's running an older version of Android.

</comment></comment><comment><USER26> It's cheap and pretty much does the job from what I hear. Obviously the author's and his family's experience was a bit worse than most people report. But honestely, returning something is a huge pain in the ass. It requires work and backing out of a decision. Very few people ever bother returning things. Just like some percentage of people never mail in rebates.

With apps, you can offer a 100% satisfaction guarantee, it will increase conversion, and few people will ever take you up on it. It sucks that it means a business doesn't have to please everyone completely, but the business is in it for the money anyway, not pleasing everyone. I think, from a business perspective, it was right to launch and capture the holiday sales. Subsequent versions will get better. I have a first generation Kindle and later versions blow it away. My version has freaking black text on a dark gray background, worse than cheap newspaper.

</comment><comment><USER27> I believe that their has been an update to the Fire that seems to have alleviated most of this guys problems.

The kindle that I received for Christmas has been a joy to use :)

</comment><comment><USER28> My problem with this post is the assumption that the Kindle Fire would have blown away the iPad with a few more months' development time.

Lots have companies have tried to beat the iPhone/iPad. Nobody has even come close. This guy's whole worldview centers around the fact that since he worked at Amazon, all their engineers are clearly the best. And if that engineering team releases a bad product it's clearly a reflection on someone other than the engineering team.

What is far more likely is that Amazon's engineers weren't going to approach the iPad no matter how hard they tried or how long they worked. It's nothing to be ashamed of - they have lots of great company in this regard.

</comment><comment><USER29> Some people think "I didn't like it" means nobody should like it. I like my kindle fire, although I think I'd prefer a Ice Cream tablet next year. I like widgets and power and awesomeness. But just because I think I might like something else better doesn't mean I'm going to jump on a soap box.

</comment><comment><USER30> I personally love the Kindle Fire. I'm an iPad user, but I bought a Fire to check it out. It's surprisingly powerful--and the 7 inch form factor is great for games.

But yeah--the interface is fiddly. I think the only reason why I get so much use out of my Fire is because I'm used to dealing with buggy products. I'd never give one to my parents. Maybe 2.0.

Oh--and the browser is HORRIBLE. Despite Amazon's crowing about their new tech --it seems like Skyfire repackaged. And super hard to use.

</comment><comment><USER31> _Consumers are snapping the Fire up because it's $200, but they expect a_ tablet _. Not a black brick that plays movies._

Some do. But a lot expect an e-reader that also plays movies. That's how Amazon is marketing it: just one of their many kindle devices. My mother-in- law has a Kindle and reads a lot of books, and I keep trying to tell her that it's more similar to an iPad than her Kindle, but I don't think it sinks in because, well, it's a Kindle.

<comment><USER32> I'm curious as to how this positioning will play out. On the one hand, its a better Kindle because it can play movies, etc, but its also the most expensive, heaviest Kindle with the shortest battery life and a worse screen for reading.

</comment></comment><comment><USER33> I have a Fire and like it a lot. I use it every day for reading books in low light conditions. I'd buy it again tomorrow.

</comment><comment><USER34> Would be nice if HN could resolve the (google.com) bit in the list to a Google+ user account.

</comment><comment><USER35> "I tell her it's less than half the price of an iPad, but the software will be almost as polished because it's made by Amazon."

LOL. Because Amazon are known for quality consumer software, right?

<comment><USER36> Well, all the kindles before the fire were pretty damn polished.

<comment><USER37> The first one wasn't. Odd form factor, thick, no PDF support. A great start, but "polished" it wasn't.

<comment><USER36> The form factor was a little funky, yes. It was thinner than anything else at the time. And PDF support was an omission that increased the polish, not detracted from it. Reading PDF on a e-ink screen is a horrible experience, adding it was a compromise.

</comment></comment></comment></comment><comment><USER38> Okay, you've convinced me. It was the lack of privacy that gave me pause. And the well executed Nook.

</comment><comment><USER39> One of the arguments I'm seeing here is that people shouldn't have such high expectations because it's a $200 device. You don't really want the reputation of releasing a device that's cheap because it's crappy, rather than cheap because it's limited.

From a customer's point of view, for $200 they expect a smaller screen, less storage, less features, less ability to run the latest games. They do not expect less fit and finish. See the car industry for an example. You expect less bells and whistles from a Toyota Corolla than you do from a Lexus, less power and less luxurious materials, etc, but you don't expect that the dash will have large gaps in it, the steering will be unreliable, etc.

</comment><comment><USER40> This is not a mistake. For me, $200 and low expectations make this a great value. Amazon's not building an iPad competitor, and failing to meet that expectation isn't an excuse not to build the Kindle Fire.

</comment><comment><USER41> My wife loves her kindle. She has purchased a few books, uses it for web browsing and a few games.

</comment><comment><USER42> The only thing that killed the Fire for me (and sadly I now own one, got it as a gift), is they reneged on their 1 year of Amazon Prime free deal. Now, you only get a month.

Screw that, the tablet is next to useless without Prime unless you like buying movies/tv shows that are DRMed up.

Also, why the hell does it have stereo speakers that are only on the left side of the device in landscape orientation? What use is stereo in portrait?

And on top of that, mine was shipped from Amazon with a defective LCD and now I have to deal with that.

Honestly, I am not impressed.

<comment><USER43> When did Amazon ever claim to offer one year? The initial announcement of it was one month of free prime (<http://www.wired.com/epicenter/2011/09/amazon/>).

If your LCD is defective, contact Amazon and they will take care of it - that's what the warranty is for :)

<comment><USER42> Yes, I have contacted Amazon. However, the device does not look like it was damaged in shipping, it looks like it is a manufacturing error.

Amazon is not gaining any points from this, at any rate.

</comment></comment></comment><comment><USER44> I read the criticisms of the Fire's OS and think, "why wouldn't the next version run Windows 8?" It is not as if Amazon has much shared interest with Google or a bunch of reasons to love Android and certainly Android doesn't give their tablets a marketing advantage.

<comment><USER45> Why wouldn't the next version of the Fire run Windows 8? Here's three reasons:

1\. Microsoft's not likely to let Amazon put Amazon put Windows 8 on the next Fire for free.

2\. Microsoft will be running the app store for Windows 8 tablets, not Amazon (BTW, do we even know what the in-app purchase rules will be for Windows 8? If they're at all Apple-like, that's a dealbreaker by itself).

3\. Windows 8 is likely to have more demanding/expensive hardware requirements than Android

</comment></comment><comment><USER46> I wonder if Amazon will do a trade-in program when the Kindle Fire 2 comes out for unhappy Fire owners. It's just the kind of crazy customer experience turn- around I could see Amazon doing.

</comment><comment><USER47> not this guy again. this is the former Google intern who completely mischaracterized Android's UI rendering

<comment><USER48> This sort of comment is harmful to healthy discourse. It is okay to be wrong sometimes, and his previous potential wrongness has little bearing on this discussion.

</comment></comment><comment><USER49> I was contemplating on buying the Kindle Fire, but now I just have to buy it ... The voices "pro" and "contra" have split into almost precise 50/50 - now I just need to have the device so I can make a decision myself. I don't have any book reader yet at all - I have to start somewhere.

<comment><USER50> If you mainly want an e-reader, I recommend one of the other Kindles that has an E Ink display, which is wonderful. The Fire doesn't have an E Ink display.

<comment><USER51> e-ink is wonderful, until you turn the page or you turn off the lamp that's next to you.

Everyone tells me you get used to the e-ink flash, and I hear it's gotten much better, but it still kinda stinks. Most of my reading is done in bed or on my couch, neither of which has great reading light. The LCD is perfect for this.

Maybe it's the years I've spent in front of a computer, but staring at a screen in the dark doesn't bother me at all. Maybe I'll regret it someday.

</comment></comment></comment><comment><USER22> The newsyc iPhone app does this. It's nice.

</comment><comment><USER52> tl;dr

his mom didn't like the kindle fire and over the holidays complained to him about it.</comment>


Ask HN: Books about running a software development contracting / consulting biz? - <AUTHOR>

We're running a software development consulting business and want to improve how we work. There's lots about startups, but not so much about running a contract / consulting development company. What resources / books have you found? <comment><USER2> Secrets of Consulting & More Secrets of Consulting - Gerald Weinberg.

Getting Started in Consulting - Alan Weiss

Your Marketing Sucks - Mark Stevens

Listen First, Sell Later - Bob Poole

E-Myth Revisited - Mark Gerber

</comment><comment><USER3> We've been doing that in parallel to our startup for the last year or so. I don't know of any books on the subject, though. Any particular topic you'd like to discuss?</comment>


Why I find IOTA alarming - <AUTHOR> https://medium.com/@thedrbits/why-i-also-find-iota-deeply-alarming-99d4f2da3282 <comment><USER2> I feel like I'm missing one side of the story. I don't know much about IOTA but from what I learned reading articles linked on HN today IOTA:

\- Uses custom "ternary" crypto which has been shown to have vulnerabilities in the past.

\- Has software that doesn't include the basic function of generating wallet addresses, instead having some users rely on shady 3rd party websites and getting their coins stolen.

\- Does away with much of what made other cryptocurrencies like Bitcoin work in the first place in order to remove transaction limitations.

\- Except that the changes required to make this work, at least in theory, are for the most part not actually implemented yet and there appears to be a lot of doubts that it can work at all. See for instance this comment on the article: [https://medium.com/@comefrombeyond/thank- you-269640e794e7](https://medium.com/@comefrombeyond/thank-you-269640e794e7) ("in the future", "temporarily", "will be using",...). Also note that many replies in this comment actually deflect the original criticism without actually addressing it. I don't even understand what that person means by "You describe the internet", and how that has anything to do with the argument of TFA.

So basically you have a highly experimental technology (even by cryptocurrency standards) which is very much unproven (even by cryptocurrency standards) and yet apparently it has a market cap of $6 billions: [https://coinmarketcap.com/currencies/iota/](https://coinmarketcap.com/currencies/iota/)

So what's the other side of the story? Can a IOTA enthusiast explain what's missing from this picture?

<comment><USER3> 1\. There have been no vulnerabilities in the past. Please read: [https://blog.iota.org/official-iota-foundation-response- to-t...](https://blog.iota.org/official-iota-foundation-response-to-the- digital-currency-initiative-at-the-mit-media-lab-part-1-72434583a2)

2\. If people are unable to generate a simple seed (password) on their own. How can they even begin to understand cryptocurrency or even new tech based on IoT? Still, yes it should be in the wallet and it will be added, but only for investors, I guess?!

3\. Please read the following from their AMA: [https://www.reddit.com/r/Iota/comments/7goul4/iota_founders_...](https://www.reddit.com/r/Iota/comments/7goul4/iota_founders_ama_summary_of_important_questions/) and [https://www.reddit.com/r/Iota/comments/7tltz2/live_interview...](https://www.reddit.com/r/Iota/comments/7tltz2/live_interview_with_david_s%C3%B8nsteb%C3%B8_founder_of/)

Is their market cap justified? Is the entire crypto market cap justified? The whole idea is to invest in tech that can change the future. Who knows which party will be the winner. It's a dare to believe in something magical, like IOTA. Or put your luck into something more real like Bitcoin, for example. Alas, it's good to have doubts, but this blogpost is alarming and not IOTA.

PS: A small portion of my crypto investments are in IOTA, but never press your luck on a single coin.

<comment><USER4> > 1\. There have no vulnerabilities in the past.

I don't know man, the MIT Digital Currency Initiative found a pretty bad one last August:

[https://medium.com/@neha/cryptographic-vulnerabilities-in- io...](https://medium.com/@neha/cryptographic-vulnerabilities-in- iota-9a6a9ddc4367)

> the IOTA developers had written their own hash function, Curl, and it > produced collisions (when different inputs hash to the same output). Once we > developed our attack, we could find collisions using commodity hardware > within just a few minutes, and forge signatures on IOTA payments. We > informed the IOTA developers, they patched their system, and we wrote a > vulnerability report

<comment><USER3> You should really read my first link and [https://twitter.com/c___f___b/status/956445618381246464](https://twitter.com/c___f___b/status/956445618381246464)

The MIT-DCI are not credible..

<comment><USER4> I value the MIT Media Lab and its DCI group pretty highly. There is nothing about the Media Lab or the DCI in that first link of yours. [1]

So what were you trying to say?

What I did find in that first link of yours [1] is this gem though:

> The IOTA hash function, Curl-P, was designed to allow for practical > collisions. The IOTA protocol's security depends solely upon the one-wayness > of the function, not its collision resistance. The rationale behind the > design of Curl-P is a much more complicated question which we explain in > detail.

This statement is alarming on so many levels.

[1] [https://blog.iota.org/official-iota-foundation-response- to-t...](https://blog.iota.org/official-iota-foundation-response-to-the- digital-currency-initiative-at-the-mit-media-lab-part-1-72434583a2)

// edit: oops, I see now that it's a multipart post, so I'll have a look there.

// edit: yeah okay, nothing of substance in the other parts either.

<comment><USER5> Part 4 explains the Curl-P part in more detail, and it doesn't inspire any confidence. They are claiming that they intentionally inserted a known bad hash function in the open source part of the code, so that anyone "fraudulent" clones would be useless. The closed source coordinator is claimed to avoid this problem by some way, so they claim that the IOTA network is not affected.

I'm having a very hard time believing that explanation, but even if I do, it's still something that shows bad judgement in my opinion.

</comment></comment></comment></comment></comment></comment><comment><USER6> Oh man, this article reminded me I should sell what little IOTA I have, so I tried to. Here's what happened:

I launched my wallet and saw a zero balance and zero transactions. I looked around and heard from some friends that I need to convert my funds or something, because there was a "snapshot" yesterday.

I clicked the "re-attach" button and waited for a few minutes. It failed, so I did it again and again and again. After half an hour and five times or so, it succeeded and I could see my balance.

I tried to send funds, the wallet said "sending" for around ten minutes, and then it finally said "success". I waited for the funds to confirm (there were three transactions, two of which were zero for some reasons), but 70 minutes later it still hadn't.

A friend told me I should "re-attach" the transaction and "promote" it. Apparently, "promoting" sends five transactions that reference yours, to confirm it. I imagine the transactions are zero-fund transactions that just spam the network to self-confirm your own one. Who confirms the confirmers?

This is absolutely _insane_ and I can't believe this thing ever got traction. It feels like hacks upon hacks upon hacks. It doesn't even work right! Did _any_ of the people who bought these coins try to ever use them for anything?

<comment><USER7> No offense but your comment is unintentionally humorous because you're asking all these sane questions blaming the mindless people who bought into IOTA, but you happen to be one of them as you describe yourself.

> This is absolutely insane and I can't believe this thing ever got traction.

It got traction because people--including yourself--bought into it without thinking much.

> It feels like hacks upon hacks upon hacks. It doesn't even work right! Did > any of the people who bought these coins try to ever use them for anything?

Yeah, like yourself. You never actually tried to use the coins for anything until this point when you are now finally trying to "cash out".

<comment><USER6> > You never actually tried to use the coins for anything until this point when > you are now finally trying to "cash out".

An alternate (and correct) interpretation is that I bought IOTA as I thought I may end up using it in my IoT projects. I didn't (probably because nobody working for IOTA actually cares about IoT), and now I want to sell them for a more useful currency.

Not everyone wants coins for speculation, but you're forgiven for thinking otherwise.

<comment><USER8> The other possibility (not just you and IOTA, but for others) is that a lot of coins have free offerings at their launch to get things off the ground. Stellar is an example.

So yeah, just because someone owns coins doesn't mean they are/were mindless speculators.

<comment><USER6> Oh, true, they did give out some coins (me included).

Yet another possibility (which is how... a friend of mine... uses coins) is buying weed from the dark web. That's a big use case right now.

<comment><USER9> I bought my first legal weed in California yesterday and it was a very interesting experience. I don't usually smoke but I wanted to see what the store was like. It was strictly cash only. They had several ATM's installed in the building. Security was tight for this reason. It's hard to process that it's now legal.

<comment><USER6> Is it completely legal now? Do you no longer even need a prescription?

<comment><USER9> It is completely legal now and I didn't need a prescription card. They asked me if I had a prescription card, for what reason I don't know, because I've never had one and they don't require it anymore. I think perhaps medical clients get discounts or special deals?

<comment><USER10> Probably asked so they don't charge some kind tax or something...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I have been on HN for 3 years now but I have never seen anything like this thread. There are sheer amount of sockpuppet accounts being created to defend IOTA.

<comment><USER12> You know how people can get irrationally invested in defending gaming consoles because they've bought one for $500?

Imagine what it feels like when you have tens of thousands of dollars invested in something where the flamewars might actually have a real effect on whether you ten-double your investment or not

I think it's gonna get much uglier than this down the road

</comment></comment><comment><USER13> It's fascinating how some cryptocurrencies are starting to generally move towards centralization and away from the core principles of Bitcoin.

</comment><comment><USER14> I just copy paste from CfB's response, in case you missed it:

Thank you. This article was useful for me, it showed what details of IOTA haven't been highlighted yet. Below I list incorrect things from the article, if you find time it would be great if you paid more attention to them and shared your thoughts:

"IOTA has no limit on transactions and therefore, it has no limit on bandwidth requirements or disk space." — In the future the majority of the nodes will be swarm nodes forming clusters and using Swarm Intelligence. A swarm can process more transactions than a single full node.

"This means, if you run a full IOTA node, anyone on the IOTA network can write data to your hard drive with just a small, extremely low cost proof-of-work." — IOTA was created for the Internet-of-Things with network-bound PoW in mind, the current state of things is temporary.

"Over time, the IOTA transaction set size can grow unbounded, leaving only storage farms with the resources required to host the data." — This is incorrect even for Bitcoin because of pruning techniques.

"My past experience working at companies that develop hardware products tells me this does not make sense in any other way but a marketing bullet." — While this thing is likely correct I decided to list it here. IOTA team has experience working at companies developing hardware products too. Even more, I bet your smartphone contains a chip developed by one of our advisors.

"IOTA claims their Ternary-based Proof-of-Work function will work with IOT because it uses minimal power, but I contend that any power usage more significant than signing a transaction is too much because there is another alternative approach." — As I already said, IOTA will be using network-bound PoW, which will be consuming less energy than required for a transaction signing.

"Contacting a central server run by the company that built the IOT device, announcing the need to submit a transaction at which point the centralized server will submit the transaction on the device's behalf." — You described the Internet, not the IoT. Please, refer to "Connectivity" section of [https://iot.ieee.org/newsletter/march-2017/three-major- chall...](https://iot.ieee.org/newsletter/march-2017/three-major-challenges- facing-iot), it explains why you are very wrong.

"In the case of IOTA the client software design intends to kick nodes off the network that do not participate enough, so being even just a passive listener is not an option." — And again you talk about the Internet, not about the IoT. Googling for reasons of not using IP(v4/v6) should show you the mistake.

I don't mention insignificant mistakes in your reasoning, all those seem to be caused by the lack of information about IOTA. This is an issue that the IOTA team is working on.

<comment><USER15> This is a very.. immature and amateurish response at best, purposely deceptive at worst.

OP talks about what IOTA _is_. The response is: "You are wrong because we _hope that IOTA will be different in the future_". How does this response make any sense at all?</comment></comment>


Dismissing Python Garbage Collection at Instagram - <AUTHOR> https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172 <comment><USER2> This is a great post. I like how they walked through all the steps and especially the "perf" tool.

Ruby has a patch to do the same thing -- increase sharing by moving reference counts out of the object itself:

Index here:

[http://www.rubyenterpriseedition.com/faq.html#what_is_this](http://www.rubyenterpriseedition.com/faq.html#what_is_this)

First post in a long series:

[http://izumi.plan99.net/blog/index.php/2007/07/25/making- rub...](http://izumi.plan99.net/blog/index.php/2007/07/25/making-rubys- garbage-collector-copy-on-write-friendly/)

I think these patches or something similar may have made it into Ruby 2.0:

[http://patshaughnessy.net/2012/3/23/why-you-should-be- excite...](http://patshaughnessy.net/2012/3/23/why-you-should-be-excited- about-garbage-collection-in-ruby-2-0)

[https://medium.com/@rcdexta/whats-the-deal-with-ruby-gc- and-...](https://medium.com/@rcdexta/whats-the-deal-with-ruby-gc-and-copy-on- write-f5eddef21485#.10aa2bnnw)

The Dalvik VM (now replaced by ART) also did this to run on phones with 64 MiB of memory:

[https://www.youtube.com/watch?v=ptjedOZEXPM](https://www.youtube.com/watch?v=ptjedOZEXPM)

I think PHP might do it too. It feels like Python should be doing this as well.

</comment><comment><USER3> It's basically "cheating" at GC by exploiting a very narrow use case. I saw a trick like this at Smalltalk Solutions in 2000 with a 3D game debugging tool. The "GC" actually simply threw everything away for each frame tick.

Someone needs to come up with something like a functional language based on a trick like this. Or maybe a meta-language akin to RPython, so people can write domain specific little languages for doing things like serving web requests, combined with domain specific "cheating" GC that can get away with doing much less work than a full general purpose GC.

Couldn't a pure functional programming environment be structured to allow for such GC "cheating?"

<comment><USER4> ErlangVM's GC does exactly this. Memory is scoped in a closure around a process, and any time the process goes down all its memory its thrown away.

Also anytime a functions scope terminates, all its memory immediately goes away.

This can be done because its a functional language with immutable data structures.

<comment><USER5> I work in VBScript inside of classic ASP and the statement, _" Also anytime a functions scope terminates, all its memory immediately goes away."_, is true there. I doubt anyone would suggest that VBScript is a functional language with immutable data structures.

Additionally, all memory used by a page is cleaned up when the page is finished processing. This has to do with "Memory is scoped" more than immutable data structures.

<comment><USER6> I think you mean memory usage is lexically scoped because no pointers to blocks are saved or returned? I think, and didn't really want to think harder, just thought in the same sense that functional brings some useful baggage with it, so does lexical scope.

</comment></comment></comment></comment><comment><USER7> I find Instragram's engineering blog to be really awesome (I especially like their content on PostgreSQL). As well, it seems like they managed to implement a solid solution to a problem they were facing.

That being said, I wonder if their team considered implementing a different language that was meant to work without GC overhead. I'm all for working with something you're familiar with, but this seems like they've hit the point where they know enough of the problem surface area that they should be able to start optimizing for more than just 10% efficiency by turning off a selling point of safer languages.

<comment><USER8> > That being said, I wonder if their team considered implementing a different > language that was meant to work without GC overhead.

Er, hold on there. As discussed in the article, python only uses GC to cope with cases which the refcount can't handle. Which turns out in some situations to be a relatively small amount. The performance problem here didn't actually come from any "fundamental overhead" of GC, just an incidental implementation detail.

Deciding to jump languages just because of a 10% performance gain which pointed them in that direction (which, as I've discussed above, it didn't) would be ill advised.

> by turning off a selling point of safer languages

I don't know if I'd say GC is a _selling point_ of a safer language, it doesn't really have a lot to do with safety in itself and the authors certainly didn't manage to remove any language safety in disabling the GC.

</comment></comment><comment><USER9> Nice. I worked on something like this at an internship. I wrote a Unicorn-like preload-fork multiprocess server in Ruby (for other reasons).

I realized that the workload (which involved a large amount of long-lived static data on the heap) would have seen enormous memory savings, if only we weren't running with Ruby 1.9's mark-and-sweep GC algorithm that marked every object during the mark phase.

I briefly experimented with turning off GC and periodically killing workers. Thankfully, in _that_ situation, all we actually had to do was upgrade to Ruby 2.2, which does have a proper CoW-friendly incremental GC algorithm.

`fork` is awesome.

</comment><comment><USER10> One of their issues was that Python runs a final GC call before process exit. Why _does_ Python run that final GC call if the process is exiting anyway?

<comment><USER11> Perhaps it's to make sure all the objects' finalizers are run also, making sure to release everything, not just memory and file descriptors? The finalizers are user-defined, so could include side effects that the GC would not know about.

<comment><USER12> Does Python guarantee that finalizers are called at all? Most languages don't, I thought.

<comment><USER13> PEP 442 describes the situation with good detail, including how it was in Python 2 and how Python 3 improves on it:

[https://www.python.org/dev/peps/pep-0442/](https://www.python.org/dev/peps/pep-0442/)

</comment></comment></comment></comment><comment><USER14> > Instagram can run 10% more efficiently

Seems quite risky/costly for a mere 10% computational efficiency gain. If you're going to change the memory model of a programming language, might as well shoot for __10x __improvement instead of 10%.

<comment><USER15> At scales like Instagram/FB, 10% is a big improvement.

<comment><USER16> Then 10x such be even better for their users! It would be a noticeable difference at that point.

<comment><USER17> At their scale, it's not about making it faster for the users. It's already fast enough. It's about making the clusters more efficient to save money. At this scale, they have already made things a lot fast for their users by throwing money at it.

</comment></comment></comment></comment><comment><USER18> Is it just me, or does it look like the typical example of short term hack that will blow up in your face pretty quickly, and turn your life in a constant stream of low-level tinkering ?

I suppose people at instagram didn't just stop there, but are also planning for more long term solution to optimizing their stack ( aka migration to a more performant language).

<comment><USER19> > turn your life in a constant stream of low-level tinkering

It appears to me this is the fate of anyone that has to make garbage collection scale. [1] I guess it's all worth it; build fast, win big and then struggle with the GC as an exercise in technical debt once you can afford enough staff to focus on the problem. Dreary.

The insight that due to reference counting GC turns reads into writes is interesting; I think I've encountered that before but can't remember where. As the gap between CPU throughput and RAM latency grows this becomes an ever greater point of pain.

> aka migration to a more performant language

That happens occasionally with small systems, and it usually works. But big operations with complex code bases don't do that very often. Facebook has re- implemented PHP at least twice now to improve run time performance without changing their language. Just one anecdote in a long list of heroic anecdotes about those who will do any number of backflips and somersaults to avoid replacing their chosen language.

[1] [https://news.ycombinator.com/item?id=12043271](https://news.ycombinator.com/item?id=12043271)

</comment></comment><comment><USER20> Fun fact: Lisp originally had no GC. It just allocated and allocated memory till there was none left, and then it died, after which the user dumped their working heap to tape, restarted Lisp, and loaded the heap back from tape. Since only the "live" objects were actually written, the heap took up less memory than before and the user could keep going.

</comment><comment><USER21> _Instagram's web server runs on Django in a multi-process mode with a master process that forks itself to create dozens of worker processes that take incoming user requests._

So this is all a workaround for Python's inability to use threads effectively. Instead of one process with lots of threads, they have many processes with shared memory.

<comment><USER22> Just a small nit pick, it's not shared memory it's Copy on Write memory that comes from forking. It would be interesting to see an explanation of the tradeoffs between threading and multiprocessing in their app servers too!

<comment><USER21> Right, they're not using shared memory for interprocess communication. The article used the term "shared memory", but they just mean read-only sharing.

</comment></comment></comment><comment><USER23> Noting that some other library might call `gc.enable()` is correct. But, then ignoring the fact that another library can simply call `gc.set_threshold(n > 0)` seems like an obvious bug in the waiting, and the same issue as something calling `gc.enable()`

</comment><comment><USER24> This is called out of band GC. We've been doing it for years in Ruby with Unicorn [https://blog.newrelic.com/2013/05/28/unicorn-rawk-kick-gc- ou...](https://blog.newrelic.com/2013/05/28/unicorn-rawk-kick-gc-out-of-the- band/)

However when the ruby community moved to Puma which is based on both processes and threads it was needed less. Not that this is rocket science (it's still far behind the JVM and .NET), I assume a hybrid process/thread model is something that hadn't reached a critical mass in the Python/Django/Flask/Bottle community?

<comment><USER25> uWSGI can definitively run in an hybrid process/thread model.

</comment></comment><comment><USER26> They mentioned msgpack was calling gc.enable(), but it looks like that issue was fixed quite a while ago in version 0.2.2:

[https://github.com/msgpack/msgpack- python/blob/2481c64cf162d...](https://github.com/msgpack/msgpack- python/blob/2481c64cf162d765bfb84bf8e85f0e9861059cbc/ChangeLog.rst#bugs- fixed-10)

</comment><comment><USER27> This writing feels a little sloppy

> At Instagram, we do the simple thing first. [...] Lesson learned: prove your > theory before going for it.

So do they no longer do the simple thing first?

More on topic: this seems like they optimized something in a way that might really constrain them down the road. Now if anyone creates an object that isn't covered by ref-counting they will get OOMs.

</comment><comment><USER28> Carl Myer, a Django core dev, presented at Django under the hood on using Django at instagram. It was a really good talk that goes through how they scaled and what metrics they use for measuring performance. [https://youtu.be/lx5WQjXLlq8](https://youtu.be/lx5WQjXLlq8)

</comment><comment><USER29> I actually didn't know that CPython had a way of breaking reference cycles. I seem to remember reading that reference counting was the only form of garbage collection that CPython did. Maybe this was the case in the past?

<comment><USER30> It was introduced in Python 2.0. You're not alone ... I still think of 2.0 as kinda new myself. :)

Look in this doc for "Optional Collection of Cyclical Garbage": [https://www.python.org/download/releases/2.0/](https://www.python.org/download/releases/2.0/)

<comment><USER29> Released in October 2000... yeah, that's probably around the last time I paid any attention to the implementation details of GC in Python.

</comment></comment></comment><comment><USER31> > Each CoW triggers a page fault in the process.

Maybe I misunderstood how page faults work, but I thought this process was reversed. I.e. Each page fault triggers a CoW, not the other way around?

</comment><comment><USER32> It could help to colocate all the refcounts in a contiguous block of memory, column store style. You would nly get a page fault per 1024 objects.

</comment><comment><USER33> I'm confused - doesn't a worker run out of memory if GC is disabled?

<comment><USER34> Python is also reference counted, and this does the bulk of the work - the GC is just for things that were missed. Instagram has the process that spins up the Python works kill and replace any that eventually use of the allowed threshold of memory.

<comment><USER35> Question, but as someone who doesn't do this sort of work...is this typical? That things would balloon that requires you to periodically kill things sounds like fuzzy logic somewhere to me.

I get that software is complex and people have simple deadlines...

<comment><USER36> This is pretty common for a forked server model. You already need to handle the case where the worker process dies, so it's simple to also occasionally kill it on purpose. Memory thresholding is nice, but you also have things like MaxRequestsPerChild from Apache. Restarting the worker after say 100,000 requests is cheaper than profiling / tracking down slow memory leaks. OTOH, when you get down to MaxRequestsPerChild 10, you have clear problems that should be easy to track down; you can also do CPU usage thresholding to limit damage from infinite loops that are hard to reproduce.

</comment></comment></comment></comment><comment><USER37> This is actually very clever, and really solves their problem pretty neat!

</comment><comment><USER38> Using threading to handle user requests with Python seems very wrong to me. They might see solid improvement by ditching WSGI and employing a non-blocking solution (like Tornado, aiohttp or Sanic), running on PyPy as multiple instances behind a load balancer.

<comment><USER39> It's not multi-threaded, it's multi-processed. Non-blocking IO is also not a magical fix to any of their relevant problems.

</comment></comment><comment><USER40> I didn't know about atop or perf profiling. Cool write up.

</comment><comment><USER41> Instead of a bunch of hacks that are obviously going to blow up in someone's face one day why not just use a more suitable platform?

Forking threads for web pages is so old school...And Python is a terrible choice for something at their scale.

Just redo the hosting bit in Java or golang and call it a day. If their UI code is sufficiently isolated from the back end it's not a huge deal.

Instagram is a pretty small application feature-wise, a few devs could probably do it in a couple months

<comment><USER42> Instagram is a living example for when you have big scaling problems you just scale. You are probably right with your arguments... the question is: Is it worth to choose a good scaling architecture when it slows your initial development down? Instagram is python, many Youtube parts are python, FB is even worse and is PHP at many parts.

So what? Sure they would scale better when using Erlang, Java or Go... but sometimes it is wiser to finish building something than making the best ultrascalable system. If you are really successful you will find ways to scale.

<comment><USER41> I've heard this so many times but I always wonder how the unicorn effect skew this. Do a majority of companies with such scaling issues fail? I've seen products go down in flames firsthand because performance was so bad. Never at a start-up but I assume it happens there too.

Facebook is a good example because of all the money they've thrown at a problem they shouldn't have. First was a custom PHP interpretor then a compiler and now hack. If they didn't have nearly unlimited money to throw at it would things have ended differently?

Language choice is one of the easiest choices to make. Pick a fast one out of the box if you plan to get big. It's not like the faster languages take orders of magnitude longer to write code in, the effect is minimal at best.

</comment></comment></comment><comment><USER43> If you think about it, this approach is actually very similar to the FaaS/Lambda/Serverless model. Each request lives in its own little container which gets thrown away after every execution. This approach means you reduce the amount of shared state and lots of problems like garbage collection either get easier or go away.

<comment><USER28> Not really. Where they recovered the 10% memory was by keeping shared state shared, and reducing the amount of memory that was copied into each process.

With something like Django, there's quite a big startup tax you have to pay, so at the scale of Instagram they would need quite a lot more servers to handle the same load if every request was served lambda style.

<comment><USER43> I think you're both right and wrong. You're right in that if you did run Django inside Lambda it would be inefficienct. But you're wrong because that's not how you should adopt Lambda. This is a similar situation to everybody re- architecting all their single-point-of-failure on-premise apps to the cloud in the first place.

The point of Lambda is that you don't startup Django with each request. You can think of the fixed/shared part of Django being replaced by API Gateway. Lambda then replaces the non-shared threads that get started for each request.

<comment><USER28> I see where you're coming from, but not all state that _could_ have been shared can be pushed into the API Gateway, like Code Objects and settings. To adopt lambda as you suggest would require a re-architecture (not Django), and at that point you're probably better off going for something more efficient. They even mention that memory cache hit ratio improved giving more CPU throughput, which totally disappears if you're starting a new process for every request.</comment></comment></comment></comment>


Why the QR code is failing - <AUTHOR> http://www.imediaconnection.com/article_full.aspx?id=30267 <comment><USER2> Somewhere I have a 30 page report from an executive in a media company on why QR codes are the next big thing, because they are big in Japan.

If there was any red flag for me it was the fact that those that didn't know consumer habits, technology or why the milieu of both would effect the adoption of a new mode of doing things were saying these things.

QR codes were pushed because they hit the marketing sweet spot of engagement and measurability, without any acknowledgment of the dissonance imposed.

As I said once: "QR codes: like using a megaphone to seduce someone. The ugliest, stupidest, most useless (and used less) tech in a while."

<comment><USER3> 40% of people surveyed in this not-so-scientific survey knew what it was. Despite there not being any real reason _why_ they should know (there has been no effort into marketing them beyond the tech circles, as far as I can tell, unlike a hashtag which is used by nearly every television show, and explained by said television show). And despite the second most used mobile OS not having a default implementation. I don't know what you define as successful, but to me this qualifies.

I was hoping this article would be able how marketers don't generally do anything useful with the barcodes. Sending you to their website (probably designed for desktops) is not the way to go. He touched on this, but then focused on QR code's lack of ubiquity.

<comment><USER2> I quantify successful is we used it as the backbone of a campaign for one of the biggest bands and the world and saw very little usage.

</comment></comment></comment><comment><USER4> The QR code is only failing in advertising contexts. Printed out your boarding pass for a flight lately? It probably had QR code, but the beauty is you barely needed to know about it. All you had to do was print your boarding pass and then stick under the scanner.

In advertising contexts, you need to recognize the QR code, know what the hell it is, know how to search for an app in your phone's app store that will read it, download that app, open that app, and scan the QR code. All to be sent to an advertiser's website.

For any consumer to do that, regardless of how interested they are in the ad, is a massive ask.

</comment><comment><USER5> Key insight here is right at the middle: "People will not adopt a technical solution that serves to replace a manual task, if that solution is less efficient than the manual task it replaces. How could we think that QR codes for marketing would work any better than CueCat? Did we not learn the first time?"

No matter how great technically, no matter what the reward is at the end, if you can't get people to use the product it's not useful.

<comment><USER6> As I saw it, the CueCat's problem was needing to be tethered to a computer with web access, which nobody at the time habitually carried in their pocket.

<comment><USER7> Also, it required a very specific hardware device.

</comment></comment></comment><comment><USER8> Sensational title aside, the key issue is identified a number of times in the article itself - creativity. They're not being exploited properly and as has been said, what's the point in having a scannable code that does nothing more than redirect to a website?

Firstly, it seems to be hard for these agencies to appreciate that someone scanning a code will want to see a mobile optimised site, not the standard one.

Secondly, they need to add value, so make them do something the user will find useful (which most of the time isn't loading a URL). Eg. as contact codes on the side of taxis and on their posters; as SMS ones that prepare a text for you to sign up to a service or enter a competition, etc. Even those are basic but are a convenience.

There are lots of things to do, but none of this means QR codes are failing (there's no solid evidence in the article to support that claim). Just that there's no imagination or actual thinking going on.

</comment><comment><USER9> I don't think the qr code is failing, but actually just becoming mainstream.

Seems to be trending up pretty well. <http://www.google.com/trends?q=qr+code>

Whether it is due to marketers putting the codes everywhere or actual value is yet to be said, but certainly don't think the technology itself is failing.

</comment><comment><USER10> I saw one use of the QR code that impressed me: in my city (Lyon, France), on bus stops, there are QR codes. Following them leads to a web page where you get the waiting time for the next buses. This is a quick and cheap way to display the waiting time without adding hardware to the bus stops.

The only good point I see for the QR code is that it makes it easier to get to a webpage. That made perfect use of it.

<comment><USER11> It would be faster and easier for a Short URL in place of a QR code in most cases.

For example - at the bus stop with a QR code I would have:

\- locate an app I rarely use in the Menu

\- open app

\- depending on app, hit button to go to camera

\- snap photo

\- processing time

\- opens web browser... (sometimes I'd get a confirmation page prior to the action)

With a Short URL:

\- open browser thats prominently placed on my phone

\- tap in Short URL (bit.ly/xYz123XyZ)

Manually typing a Short URL is a very low pain point in comparison to QR codes these days.

<comment><USER12> Or even text messaging. Text "M15 AT 53" to "311411" and you find out when the next bus is going to be at your stop. That'd work.

<comment><USER13> Melbourne uses a four digit number for tram stops (for use via text, automated voice, web and apps) and it works quite well. <http://tramtracker.yarratrams.com.au/phone/>

</comment></comment></comment></comment><comment><USER14> The problem is that QR codes are used to replace simple (static/generic) URLs. If you have a usage where there is potentially a wide range of values, they become more useful, but since they're being used in mass printing / advertising, they're going to be the same all over and in that case you might as well just use an easy URL.

QR codes work great when being used in items where there is a large (think 100,000) number of potential unique values. That scale means they shouldn't be used for a product SKU, for example - they should be used for a specific object like a SKU/serial # combo. Never enter a serial number again to register a product, for example.

</comment><comment><USER15> Here in Europe I have seen lots of smart use of QR codes in advertising lately:

\- Scan the QR code to receive a rebate coupon for the product advertised \- Scan the QR code to receive a two for one deal on tickets for what ever event advertised \- Places like 7-eleven offering you a free soda with your hot dog if you scan the QR code on the poster in the window before entering \- Scan the QR code for an exclusive trailer for the movie advertised \- An ice cream company introduced a new ice cream and you could scan the QR code on the advertisement to get a free ice cream \- Adverisements for universities where scanning the QR code would let you order their information brochures sent home to you \- Scan the QR code to be informed when the advertised service is available in your location

And several other uses I can't remember at the moment.

My point is that it is, like the author of the article indicates, quite possible to make great use of QR codes in advertisements.

Many of the mentioned campaigns I also know worked great. For example during the free ice cream campaign, the local 7-eleven was filled with teenagers with smartphones getting their free ice cream every time I went there.

I've also noticed that most of the campaigns that succeed don't "just slap a QR code in their", they give you information about it: "Scan the QR code to get a free ice cream using your cell phone. If you have an iPhone go to xxx to get a scanner, if you have an Android xxx, if you have a Nokia xxx" or similar solutions. It's kind of a chicken and egg problem. Nobody will use QR codes if they don't know what they are, or how they work. And nobody will known what they are and how they work, unless somebody tells them.

</comment><comment><USER16> About the only ad that would get me to scan a QR code would be the promise of an explicit coupon code/discount.

My memory fogged up since so much time has passed, but last time I scanned a QR code I ended up on some fast food company's home page. What exactly did they expect me to do at that point? A coupon for a free softie/mcflurry whatever dessert product would have at least encouraged me to go visit the restaurant.

</comment><comment><USER17> The one place I've used QR codes successfully is when friends visit and want to use my wireless on their phones. I've got a QR code for the SSID and another for the password. For laptops, I can hand out a little USB drive with a text file they can open and copy/paste.

</comment><comment><USER18> I guess I was living in a fantasy world where I thought I could just take a picture of one with my iphone's camera app and something would happen. I tried a couple times and nothing happend.

So, how _does_ it work?

<comment><USER19> For the iPhone, you'd need an app that can read it. Google's app is probably the best for it, since it provides so much functionality otherwise as well. Considering android's marketshare, though, I think these do have the potential to take off. Well, as long as people take this guys advice and make them point to coupons, or an actual campaign, rather than the URL on the billboard.

Meanwhile, I'm thinking of using them in a print book/brochure as an easy way to get to multimedia. A photo book, for example, with a QR code pointing to a relevant video. Turns a book into an app!

<comment><USER18> The whole needing an app kills it. If its built into the native camera to recognize these codes I can really see it taking off. No more needing to type long landing page urls when you see a billboard or needing an exclusive short url when you can just point your camera and see the intended page open up on your iphone browser.

<comment><USER20> On Android that's how it is.

<comment><USER21> I just got an Android phone, and it's not. Just now, I went to this website on my computer: <http://en.wikipedia.org/wiki/QR_code>

I took a photo of QR picture with the built in camera. Nothing.

I have to use google goggles or something to interpret the QR code.

<comment><USER22> <http://code.google.com/p/zxing/wiki/GetTheReader>

<comment><USER21> That's not the point. I already have an app to do it. That's not built into the os. That's definitely an extra download.

<comment><USER22> I wasn't disagreeing.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> QR codes are useful/useless depending on the way you engineer it, and the action that follows once when its read. We have integrated QR codes in our app, and the app comes with a QR scanner. It makes it so much easier to do several actions, and when we did our soft sales and customer feedback everyone loved the ease of use and the results. Actions like on reading a QR code taking you to a static website is rather useless. But, if upon reading a QR code you can initiate an action its pretty powerful.

</comment><comment><USER24> I'm pretty sure it's because it's a solution looking for a problem as far as advertising goes. Much better served putting a "www.wheretofindus.com" on your ad instead.

</comment><comment><USER25> It would be much more interesting to see stats about the use of QR codes in an actual campaign. If they generate even a few hits, and create a few new customers, it could be worth the inches on the ad. After all, they don't loose anything by using a QR code.

</comment><comment><USER26> This is what we been saying for long time now, and with "our" solution there's no need for barcodes - we rely 100% on "the image". No names as that will only lead to bashing, so we'll just simply add on to this chorus: Barcodes are dying.

Demo coming soon.

</comment><comment><USER27> I would argue the QR code is failing because my phone can't read them without downloading an app.

</comment><comment><USER28> It's ugly and people want to use where they are also spending millions of dollars to make things _not_ ugly. End of story.

Oh, and in the interest of making the future happen just a little bit faster, please fire anyone who thought otherwise on the way out.</comment>