How will in-place updating work on the Mac and Linux?
To be frank, we haven't solved this problem on Mac.
Right now we're doing an rsync to klobber on update, which is fine for
pre-dogfood. E.g. our normal Mac crash rate far exceeds any possible
crashes caused by version mismatching in the
On Sat, Mar 28, 2009 at 5:35 PM, Dan Kegel daniel.r.ke...@gmail.com wrote:
On Sat, Mar 28, 2009 at 4:59 PM, Erik Kay erik...@chromium.org wrote:
...When you update
in place, resources can be changed, removed, etc. So let's say that
some dll hasn't been loaded yet, but then an autoupdate
On Sun, Mar 29, 2009 at 11:56 AM, Dan Kegel d...@kegel.com wrote:
How will in-place updating work on the Mac and Linux?
For Linux, I was imagining that we'd open handles at
startup to any file we'd need, and then never open
any more handles after that.
We looked into this more at one
On Sun, Mar 29, 2009 at 1:02 PM, Thomas Van Lenten
thoma...@chromium.org wrote:
Most mac apps solve this by having the app exit as part of the upgrade
process, this way a new copy is launched w/ the new resources.
yes, but this is the problem with silent autoupdate. We don't want to
force the
Perhaps we need to think about how to encourage such a restart, without
being the traditional pop-up pain-in-the-er-um-rear.
Can we find real-estate that won't tend to detract from the ui to alert the
user that an update is pending? Perhaps atop a new-tab page? Perhaps an
extra entry ot the
It would be nice to be able to leverage our multi-process architecture and
at least start using the new binaries for any new tabs that are created.
But, that's a different can of worms, I guess.
On Sun, Mar 29, 2009 at 14:31, Jim Roskind j...@chromium.org wrote:
Perhaps we need to think about
This is a very delicate line to walk. We want to silently update... yet not
actually be silent. We want updates to take effect immediately... yet not
require an app restart. You have provided some good ideas but, in practice,
it can be difficult to close on a compromise that doesn't make some
I'm supportive of some UI to let the user know that there is a update
pending. This should be non-model and minimally distracting. We've talked
about a notification area on the NTP. It would also serve as a place that we
could tell people about cool new features. We'll throw this on the queue for
On Wed, Mar 25, 2009 at 6:11 PM, cpu c...@chromium.org wrote:
On windows the exe/dll separation it was meant to simplify upgrade but
in practice the
exe changes frequently enough that we still need to support exe
upgrading in place.
(resending)
While the exe changing issue is annoying, and
On Sat, Mar 28, 2009 at 4:59 PM, Erik Kay erik...@chromium.org wrote:
...When you update
in place, resources can be changed, removed, etc. So let's say that
some dll hasn't been loaded yet, but then an autoupdate happens. Now
you trigger loading the dll, and you crash, because this kind of
On windows the exe/dll separation it was meant to simplify upgrade but
in practice the
exe changes frequently enough that we still need to support exe
upgrading in place.
We always wanted to have a do nothing exe that just loads the chrome
dll but that never
happened, reasons: 1) the sandbox 2)
Something important would be to understand the overhead for a shared
library (fpic, relocation, etc).
On Tue, Mar 24, 2009 at 7:45 PM, Thomas Van Lenten
thoma...@chromium.org wrote:
The Windows product builds a small executable that then loads the main
chromium dll, and hands off control to
Dean McNamee wrote:
Something important would be to understand the overhead for a shared
library (fpic, relocation, etc).
On the Mac, I actually want to link the main executable with -pie so
that it loads at a different address each time anyway. That implies
PIC. It's still wise to
On Tue, Mar 24, 2009 at 4:07 PM, George Djabarov geor...@google.com wrote:
One additional reason to use small executable that loads chrome main
dll is to prevent firewalls warnings each time chrome is updated.
On the Mac, we should be able to avoid these by having a signed executable.
Once
14 matches
Mail list logo
