Google's Chrome OS is a Commitment Mechanism | Hacker News Reader

Google's Chrome OS is a Commitment Mechanism

hellosorld.com

34 pointsstanleydrew20 comments

The big problem with the cloud is that it moves power from the user of the software , to the cloud vendor.

so google chrome might be a bad commitment.

I believe we as users need to find a better way to get the benefits of the cloud(in maintenance and availability) ,without losing control of our software.

I don't see this as a big problem. There are bound to be many cloud vendors competing for our business, so we as consumers can demand data portability. And we can still have control of our software if we host it ourselves. There's nothing stopping anyone from writing an open-source gmail clone that we can all run on our own servers.

Odd, b/c what we have now is a string of failures (cough rackspace cough) (cough DNS failures cough) (cough rackspace again cough), connected to quite a few companies that don't have good guidance on data protection or privacy control (facebook, microsoft/danger), bound up by an internet that isn't nearly as ubiquitous or reliable as we want (AT&T). Access to those services is still in question: net neutrality is still under debate, and I'm seeing services blocked at the employer (can't let corporate secrets get out via google docs!) and ISP (long story) level.

For what? 99% of what we want out of the cloud is solved by a good laptop and a reasonable backup system.

Ask me again in 5 years (and it'll actually be 5, not 1 or 3), but right now, the cloud isn't worth it.

I don't disagree that there are a lot of hurdles to overcome. I also don't disagree that 99% of what the cloud offers is solved by a good laptop with regular backups. But that's kind of like saying 99% of what twitter offers can be solved with public mailing lists and a character limit. That doesn't mean twitter isn't worth using or creating. (OK maybe not the best example since I don't use twitter myself but you get the idea.)

And what about this scenario, which isn't too far fetched in my opinion: your ISP provides you with private cloud storage, a software stack, and your own dns name for you to host your own private web-accessible applications, each installable with one click.

There is still the problem of reliable internet access, but in time I think we all know internet access will be as ubiquitous as electric power and we will trust our ISP just like we trust our power company: we completely ignore them until the power goes out for a day, we get really mad, wait for them to fix it, and then forget it ever happened.

So where do I store my tax return, Google Docs? Amazon? MS? I think not. Hard drives are not going away, "listen to me now and believe me later."

The problem with this is the great deal of uncertainty about when (if ever) the 'optimal' outcome of the commitment will occur. It's not just a matter of application availability as the author seems to imply.

Even if CloudPhotoShop and CloudEmacs materialized tomorrow, until there is ubiquitous high-bandwidth connectivity, most users will want to continue to make lots of fine-grained choices about what particular bits of their data they want stored locally, remotely, remotely-with-local-cache, etc. There's no way for my CloudApps to know in advance that tomorrow I'll be on a 15 hour flight so I'd like to have these 2 movies, 10 playlists and the latest versions of a couple of Cloudocuments I last edited from a different machine in my local storage before I lose connectivity.

Exactly. I reject the entire premise that web apps are fundamentally "better for you". Yes, they have zero installation, and that's great. There are also a number of drawbacks that the author ignores or glosses over, such as requiring ubiquitous high speed (and often low latency) connections, having all your data in the hands of a third party, and apps being written for the lowest common denominator of HTML/CSS/Javascript rather than taking advantage of advanced OS functionality. Both web and local apps have their place, and there's no need for one type to dominate.

I reject the entire premise that web apps are fundamentally "better for you".

You're inserting the word "fundamentally", but the author is not claiming they are fundamentally better than native applications at all. Not every article is "X vs Y".

His premise for talking about commitment mechanisms is that you've already decided that web applications are the long-term optimal choice for you. If it isn't the optimal choice for you, the commitment mechanism is meaningless.

The lack of "ubiquitous high-bandwidth connectivity" is likewise a short-term cost, and may already be negligible depending on how ubiquitous you need it to be and how much bandwidth. It's already good enough for many if not most people, and the gaps are shrinking.

My point was users will always want the option of explicit storage control (which ChromeOS lacks) until local-to-cloud syncing is essentially transparent. This takes a a lot more bandwidth and ubiquity than is currently available.

A reasonable technical analogy is the use of overlays (user controlled) vs virtual memory (automatic) by programmers - until hardware support, memory and disk sizes and speeds were available, overlays were the practical and desired memory management technique. Similarly, the cloud has to be much closer in availability and access speed to local storage before users don't have to bother with much explicit control of data storage location. I think that's a lot further off than the author and you assume.

Storage is cheap though, so this only becomes an issue when you want to cache gigabyte sized movies. Why not cache your whole photo and music collection now? In 10 years you won't even worry about huge videos. You'll be carting around terabyte sized flash in your phone and more on your cloudbook SSD.

Because there is no user-controlled local storage under ChromeOS, at least as described now. But even if there was, no matter how much local storage you have (and the assumption is that you'll have more on the cloud and your cloud dataset size will be larger than local storage) you'll still want to make explicit storage decisions based on the availability of bandwidth and connectivity.

Say today at the office I worked on a few documents, shot a gig of video at the office holiday party, bought a couple of mp3s. All were stored on the cloud. Tomorrow morning I, before I leave for a disconnected mountain cabin, I fire up my netbook and tell it to sync. I don't have time to wait around for the video but I specifically want the docs and the mp3s. Additionally, I want an explicit sync of a group of documents from two years ago. They're in the cloud but I have no idea whether they are in the netbook cache so I want an explicit check. The only way you'd stop doing this sort of thing is if you're more-or-less always connected.

The uncertainty will surely mean that Chrome OS will remain a secondary OS for many people (including me) for awhile. But over time as you realize that 80%, then 90%, then 95% of what you actually use is available as a hosted app, Chrome OS (or the MS or Apple equivalent) becomes your primary OS.

Don't be too short sighted! Cloud hosted version of Grand Theft Auto running in your Webbrowser on Chrome OS coming within the next 5 years!

It's in beta: http://www.onlive.com/

The most useful piece of information in this article, to me, was the concept of 'commitment mechanism'.

http://www.itvt.com/story/5733/cloud-based-games-company-onl...

Is anyone actually willing to make that commitment right now?

A few bloggers have already done the "use only Web apps for a month" thing and written about it.

"Let's use only web applications so that we don't waste time on desktop application !"

Really ?

Reply on news.ycombinator.com