Chrome's Most Important Feature
googlesystem.blogspot.com
googlesystem.blogspot.com
Google, and now Mozilla too, is essentially crowd-sourcing, hopefully throwing a few million extra eyes on the problem.
There are the four Chrome channels: http://www.chromium.org/getting-involved/dev-channel
Chromium snapshots can be pulled from the buildserver: https://factor.cc/chromium.php
Firefox has the Stable, Beta, and Aurora channels: http://www.mozilla.org/en-US/firefox/channel/
Then there is the Firefox Nightly channel: http://nightly.mozilla.org/
Opera and Opera Next: http://www.opera.com/browser/next/
Safari and Webkit: http://www.webkit.org/
I guess IE is here: http://ie.microsoft.com/testdrive/Info/Downloads/Default.htm...
Is that all of them? I keep finding more.
There's some convenience/security tradeoff here anyway. I don't know about you, but I don't inspect the source code of most apps I install or update.
"Stop! Whatever you were going to do, it couldn't possibly be more important than checking if fart-button-xpi has been updated from 1.0.4 to 1.0.5! Now just five more clicks and I'll restart"
Unfortunately, I think years of popup dialog fatigue leads lots of people to just close the window.
In general, the user should extremely rarely be interrupted for anything, especially not anything program-related. Each program having a tray icon, an update alert, update restarts, and flow interruption because it thinks something is important is what has turned windows from a productive computing platform to some kind of cross between a Kafkaesque X-box and a slot machine.
http://stackoverflow.com/questions/3711435/has-anybody-used-...
That "frequently" is every 30 minutes, by the way... I accidentally removed the goog updater from my Lil Snitch rules and noticed that it then started asking permission every 30 minutes, on the dot (I started recording the times for a while).
I don't know why it needs to check so often - except that that kind of data would be very useful for noting how often your users were on 'puters, and if they moved around etc.
Or just an update with a non-malicious bug that breaks the updating mechanism. (This last has happened to companies the size of McAfee and Skype.)
Personally, I don't think we need to worry about a Chrome or FF update suddenly breaking our apps--they don't use cutting edge HTML5/CSS3 features, and I don't suspect that either browser will suddenly change an HTML4 implementation.
Anybody else dealing with this same issue?
Also, I was forced to change our browser checking software to only do lower bound checking. Before, I would explicitly specify which versions were allowed. Now it's more like Firefox 4+, etc.
If you want bleeding edge versions of Chromium (or some other popular program), there are non-standard/third party repositories available. Then you can get nightly builds but still update your system with the package manager.
Joshua
Flash is unfortunately still a requirement for a lot of websites. The 32bit binary chrome has flash bundled, so updates are received as quickly as possible (I know, I should run some flash-blocking plugin, but I don't right now). On 64bit Linux (which is what I need most of the time), you have to maintain the flash plugin separately, and run it through nspluginwrapper, which makes it much less stable in my experience.
You used to be able to run the 32 bit debs on 64bit Ubuntu, but that broke a couple versions ago, and I never had time to see if it could be fixed. You also lose the package manager updates when you do this, since apt isn't multi-arch aware.
Exactly what I dislike about the web app model; I want it even less in my client apps.
http://www.google.co.uk/search?q=update+server+not+available...
So, hilariously, I have to totally remove the app and re-install to update.
I don't think it's a huge advantage for average users, either - %90-percent of iPhone users are on the latest available major OS version, and that (until 5.0) involved a huge non-delta download, physically docking your phone and an onerous, lengthy (well over 30 minute) process, during which you had limited use of your phone.
So it appears there is a bug where the update messes up currently running processes.
For those interested in some of the available options for Windows apps, see here: http://stackoverflow.com/questions/37030/how-to-best-impleme...
In that case have you tried just installing Chrome into ~/Applications instead?
So Google Chrome.app resides in /Applications, but it's installed by the account that gets created when you reinstall OS X (which is by default an account with full privileges). Standard users can read /Applications, so they can launch Google Chrome.app, but the process can't write to /Applications because of its effective UUID. That's why it prompts for an admin password.
In that case, the latest incarnations of Microsoft Windows ought to be doing pretty well for themselves.
It would be pretty neat if someone use only the updater as part of other desktop software packages.
Chrome has eliminated both of these dialogs (that used to be browser standards), and the FF dev team is usually responsive enough to adopt new, good ideas quickly. So what gives?
It is not in the best interest of users to have their plugins disabled automatically as a "feature".
I know that would be easier said than done, but Chrome seems to do a good job of it.
They're starting to offer a separate extension SDK (formerly called Jetpack) that allows extensions to ignore the internal API and build against something more stable. Such add-ons can be installed without requiring a restart, and should be much easier to update, but many important extensions need more power than currently provided. (Ad block is a good example.)
http://groups.google.com/group/mozilla.dev.planning/browse_t...
The work to solve that is mentioned in the thread.
Windows has had binary compatibility for decades. Why not just version the internal browser API? (Extension XYZ was built against FireFox 3.6).
Extensions don't just run on top of Firefox, though; they modify Firefox's UI in arbitrary ways.
>Why not just version the internal browser API?
Firefox already does this, and automatically disables incompatible extensions.
What if it sucks down bandwidth when I'm on 3G? What if an update breaks something, and I'm in the middle of something that can't be updated? What if an update silently breaks the update process? Hrm!
I reference that in your mention of 3G bandwidth usage. Chrome updates should be fairly tiny and bandwidth-friendly. Not always, but more often than not.. Especially on a beta/dev channel.
> What if it sucks down bandwidth when I'm on 3G?
That might happen. What if it does? > What if an update breaks something, and I'm in the middle
> of something that can't be updated?
As per TFA (and experience): The autoupdater never interrupts you. The only UI change is one of the toolbar buttons changes subtly. Most of the time you don't notice that an update is ready to install. More to the point, after the update you usually don't even notice anything different. > What if an update silently breaks the update process?
There's absolutely no precedent for this, but honestly, who cares? This is hardly reason to shun the entire system.Bottom line: The autoupdater makes sure I never care about the version of Chrome I'm running, just like a web app.
Then it risks costing me money, for doing something I've not chosen to do. For a feature described as "not worrying", that can be potentially very worrying.
For the vast majority of people, heading down this rabbit hole isn't worth the effort.
(On the flip-side, it would be nice if there was a magical "undo those updates to point in time X" feature in case something went wrong and you wanted to see if it was because of an update).
It's also really unlikely to break anything you might be doing from one version to the next, unless you're doing really experimental cutting-edge things... And then you probably want the update anyhow.
> What if an update silently breaks the update process? Hrm!
This is part of why Chrome uses a separate application (Google Updater) to do the updating. Even in the worst-case scenario where we update to a version of Chrome that can't even start, the updater still runs and can later update to a fixed version. > What if an update silently breaks the update process? Hrm!
If the updater is self updating an update may break it so that no further updates are possible.Sure, the updater can break itself. But in practice, you rarely update the updater because the majority of the features you might want to update are in the app, not the updater.
So you update the updater very rarely and cautiously, and you update the app quickly and fearlessly. It's not 100% foolproof, but it's a lot better than the alternative: Any crash bug anywhere in the application having the capacity to disable updates.