Hacker News new | past | comments | ask | show | jobs | submit login

I've never once been pestered by Chrome. Updates are automatic and invisible.



I was just about to say this.

Shockwave / Flash / nearly every other application in the world tells you your software is old, and asks if you want to update it, and it will keep telling you this until you check the "don't tell me again" box. Which few people do. So instead they get irritated that it always pops up, and get used to clicking "no" because they didn't want to deal with it then, and don't want to deal with it now. A year passes, they get a virus through an old exploit, and they blame the software instead of their habits / their IT department's dogma (which is not always incorrect, but frequently problematic).

Chrome, on the other hand, keeps itself up-to-date in the background, at all times, and doesn't ask you to deal with it. It doesn't even inform you it's doing so, aside from a minuscule little up-arrow on the wrench that disappears on the next launch - no progress bars, no delay, no "restart now", no alerts, nothing. There's no question if someone's using version X or Y; they have the latest of their branch. Period. Or they'll get it in a day or two, and problem solved.

Transparent updates, especially when they're nigh-totally transparent, are in an entirely different world than "do you want to update yes/no/cancel". It's apples and granite, or oranges and wolverines - there's no comparison ("apples are sweeter than wolverines").


> Transparent updates, especially when they're nigh-totally transparent, are in an entirely different world than "do you want to update yes/no/cancel"

Transparent updates are great, until something goes wrong. What happens if someone manages to hijack the DNS entry to make 50 million Chrome installations download an update from a poisoned well? Or Google's quality control misses something and pushes out a buggy update that breaks Chrome's ability to reconnect and obtain a fix for that update? (This has already happened to companies the size of Skype and McAfee.) Or an update simply introduces a behavior that users don't want, like Microsoft using Windows Update to inflict WGA everywhere.

The net benefit of transparent updates is still probably greater than explicit updates, but both ways have costs and we shouldn't pretend that either is zero.


Don't those same problems also exist for explicit updates?

I suppose it's a mitigating factor on the part of requiring user opt-in, should a problem occur, but that's (IMO) only a fortunate side-effect. It's like saying that walking is better than driving, because if you run into something you'll only bruise your shins.


And opt-in updates also mean the ones that did get the faulty update hold onto it for much longer. ie, IE.


The problem with automatic and invisible update is this: say you are using chrome in your company as the interface to an internal tool of some sort. Since the tool is used internally it's messy and one day chrome changes and now, automatically and invisibly, no-one can use it.

I'm not saying chrome's way doesn't have its upsides but there is also a good argument for mantaining older releases.


Actually, Google has Chrome for Enterprise that solves that problem by allowing updates to be disabled.

http://www.google.com/support/installer/bin/answer.py?hl=en&...


Have there been any backwards incompatible changes in the way chrome handles javascript or CSS?


Yes, sure thing. Every single CSS bugfix is a backwards-incompatible change, no?


Point taken, but standard practice is to write correct code for a CSS bug, then write a 'hack' that works for that specific browser version.

On the other hand, if you're doing an intranet site with a company that only has one browser, you might have dispensed with writing correct code and only written the hack.

Its' temporarily practical in a time crunch, but not a good practice since the next update may kill your hack.


All true.

Note that there are also other cases where incompatible changes are made (e.g. ES5 is not exactly compatible with ES3 in various edge cases, CSS2.1 today is not quite compatible with CSS2.1 a year ago in edge cases, etc). The various standards groups an implementors try to minimize the damage from such changes, but it still happens at times.

Heck, Chrome 9 or 10, made major changes to the HTML parser to follow the HTML5 draft. Sites that depended on the old behavior (which different between browsers, so they presumably browser-sniffed and then sent different content to different browsers) likely broke. They certainly did in Firefox when Firefox changed to the HTML5 parsing algorithm.


This happens in the wild with Java updates. We have been burned twice with minor point versions that broke our app, that were pushed out automatically.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: