| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 10:10 UTC (Wed) by drag (subscriber, #31333)In reply to: Day: GNOME OS by krake Parent article: Day: GNOME OS
The author's intent was to describe why they have to use a zygote process on Linux to watch over spawning new processes and why they don't need to jump through all the same hoops do that in Windows or OS X.
Another way to put it, more or less:
Due to Windows habit of locking files it has forced people to use a model of installing that avoids file clobbering issues present in Linux. Something else magically happens on OS X.
It seems to do the same thing in Linux with a system-wide package manager you would need a package manager that is aware of the processes that users are running, installs the software update to a alternate directory, sends a notification to users to shut down the application, and when they do that then rename the new directory over the old one.
Or something like that.
I am very interested in how iOS/OS X handles application updates through the app store. The blog posted hinted at versioning directories in the app bundle, but I have no clue what happens with iOS and such.
(Log in to post comments)
Day: GNOME OS Posted Aug 8, 2012 11:36 UTC (Wed) by krake (subscriber, #55996) [Link]
"The author's intent was to describe why they have to use a zygote process on Linux to watch over spawning new processes and why they don't need to jump through all the same hoops do that in Windows or OS X."
Well, he clearly failed on the second part, since the posting does not contain enough information why that is not a problem on Windows and OS X.
For example it is missing the information krakensden added, i.e. that Windows can schedule a rename to the next reboot, allowing the app store to schedule replacement of files but on the downside also requiring system restart.
As I said it I don't want to assume the worst but it smelled a lot like comparing different types of upgrade mechanisms
Day: GNOME OS Posted Aug 8, 2012 14:19 UTC (Wed) by drag (subscriber, #31333) [Link]
Well the guy doesn't know how they really do it on OS X.
And yes it is comparing update methods. They need to do what they do in order to deal with some of the bad aspects of how Linux installs packages.
They could ignore that completely and have each user install Chrome in their home directory, but apparently it is easier to write a bunch of code to work around rpm/deb-style package management then to try to convince Linux users to not depend on rpm/deb for installing and updating Chrome/Chromium.
He also seems to indicate that it's not going to be a issue with them on Chromium OS.
Day: GNOME OS Posted Aug 8, 2012 14:40 UTC (Wed) by krake (subscriber, #55996) [Link]
"And yes it is comparing update methods."
Well, than the blog posting is without merrit.
Like complaining that parallel processing with child processes needs extra work when accessing shared data and stating that multi threading would make that way easier.
"They could ignore that completely and have each user install Chrome in their home directory..."
Or globally.
"...but apparently it is easier to write a bunch of code to work around rpm/deb-style package management then to try to convince Linux users to not depend on rpm/deb for installing and updating Chrome/Chromium."
Well, if it is easier to deal with app store limitations than not to be in the app store than that is a conscient choice. Complaining on how easy it would have been not to be in the app store is just whining.
So marketing (or managment) decided that being in the app store outweights extra engineering effort. Deal with it!
Day: GNOME OS Posted Aug 8, 2012 16:19 UTC (Wed) by cmccabe (guest, #60281) [Link]
The issue is that they don't want to have to restart Chrome/ium after an update. And they don't want to deal with version skew between different files. Their solution seems reasonable to me overall.
Day: GNOME OS Posted Aug 8, 2012 16:24 UTC (Wed) by drag (subscriber, #31333) [Link]
Seems that he thinks it's much easier task to accomplish if they didn't have to deal with Linux apt/rpm style updates.
Day: GNOME OS Posted Aug 9, 2012 8:31 UTC (Thu) by krake (subscriber, #55996) [Link]
True, but they decided that getting into the app stores made the additional engineering costs acceptable.
They could have avoided the issues by going the route of a stand-alone installer but obviously found it more viable to do it the other way.
Day: GNOME OS Posted Aug 8, 2012 12:40 UTC (Wed) by Mog (subscriber, #29529) [Link]
Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Windows gave us the expectation of a reboot after IE updates (I know, this may not be mandatory nowadays but old habits die slowly). On my Linux boxes, I close all applications, especially browsers, before running 'yum update'.
Day: GNOME OS Posted Aug 8, 2012 13:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Really? That sounds terribly disruptive. I never close a thing before doing updates (unless the update is huge, e.g. pushing all of KDE from 4.7 to 4.8 or something like that, in which case I generally log in again afterwards), and have never had trouble.
Day: GNOME OS Posted Aug 8, 2012 14:10 UTC (Wed) by drag (subscriber, #31333) [Link]
> Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Well the application or user is given no notification that a update was performed for most (if not all) Linux systems unless the user is the one that did the update itself.
If it's a single user environment then it's not that big of deal, but I suppose it can cause headaches unless the administrator makes sure to upgrade the system while everybody is logged out.
Day: GNOME OS Posted Aug 8, 2012 14:43 UTC (Wed) by krake (subscriber, #55996) [Link]
If the software depends on anything not changing after startup, it could monitor those files.
I believe that this is possible nowadays. Might even be possible to monitor the application's installation directory as a whole
Day: GNOME OS Posted Aug 8, 2012 16:22 UTC (Wed) by drag (subscriber, #31333) [Link]
yeah. Inotify and such. I believe that sort of thing is what they Zygote process for (as mentioned in the blog post), which is extra steps that they don't have to do on other systems.
The code used to do such things is suppose to be rather ugly, but unfortunately Google has terminated it's code search stuff and thus the links from his post showing what Chrome does is broken. I don't have time to hunt down the details myself right now.
Day: GNOME OS Posted Aug 8, 2012 20:08 UTC (Wed) by nix (subscriber, #2304) [Link]
Nah, the Zygote process does nothing as crazy as inotify. It's just a run mode of the chrome binary where it does nothing but listen for requests to fork off children to do other work. Thus, it ensures that those children are all the same instance of the same binary, so are guaranteed to be able to engage in IPC with each other (and with the master browser process) smoothly.
The thing is, a forking architecture like this is a good architecture for other reasons, compared to a plain exec() architecture. Among other things, it means that relocation happens only once, so it saves memory because pages dirtied by relocations are dirtied only once, and it saves time because relocation happens just once, at Chrome startup (an important consideration when the binary is 110Mb). KDE 3 used exactly this architecture just to minimize relocation overhead.
Again, this thing is *five hundred lines*. It's *trivial*. I've written similar things in under a day. And people are proposing massive invasive changes to every program storing state in /etc, and massive invasive changes to the way updates are carried out, to save on the terrible overhead of writing something tiny like this. Why? I am baffled.
Day: GNOME OS Posted Aug 8, 2012 22:26 UTC (Wed) by walters (subscriber, #7396) [Link]
<p>Why don't you go out and patch every application to do it then? I think you'll quickly find that it's <b>insanely tedious</b> for application authors to have to keep a file descriptor open on every file they use.</p>
<p>What's even better - it's <b>still racy</b>. If the user launches an application while an update is happening, the app can get half of the old files, and half of the new. There is no way to solve this without coordination at every layer of the stack.</p>
Day: GNOME OS Posted Aug 8, 2012 23:00 UTC (Wed) by nix (subscriber, #2304) [Link]
Have you responded to the wrong comment? There's nothing in the zygote model requiring file descriptors to be kept open to anything at all, and it's not racy if you keep each application in its own root (as nixos does: I'd agree this is one of the things it gets right), because the binaries and non-shared datafiles for a given package are never overwritten.
In fact with only a few exceptions (e.g. Perl if you want to use CPAN), you can mark such subtrees immutable and nothing whatsoever breaks. (I've been doing this for years.)
Yet again, this seems like a massive invasive change for very nearly undetectable benefit -- and it still doesn't solve the only instance of this problem that I can ever recall encountering, the 'updated application state in your home directory breaking downgrade' problem.
It's a shame I'll not be at LPC or we could have a good argument over this :)))
Day: GNOME OS Posted Aug 9, 2012 15:41 UTC (Thu) by arafel (subscriber, #18557) [Link] I think you might have misread the blog post: This process opens every file we might use and then waits for commands from the main process. When it's time to make a new subprocess we ask the helper, which forks itself again as the new child. By virtue of always forking from the same initial process, we guarantee that we are always running the same code; even if the files we opened are replaced by a system update our handle on them is the handle for the previous file.
Day: GNOME OS Posted Aug 10, 2012 8:16 UTC (Fri) by nix (subscriber, #2304) [Link]
Oh yes, true enough. Of course the most important part of this is the 'always running the same code' part. You don't have to hold the files open: if there are lots of little ones you might prefer to suck them into memory instead.
(Obviously this model will not apply to everything, but it does in fact apply to a lot. You need an abstraction around file I/O to do it, but Chrome already *has* that, and thanks to libio and open_memstream() anything can get it quite easily, without major rewrites.)
Day: GNOME OS Posted Aug 8, 2012 16:48 UTC (Wed) by endecotp (guest, #36428) [Link]
> I am very interested in how iOS/OS X handles application
> updates through the app store.
On iOS, if you install an update to an app from the store, then any currently-running instance of the app is killed first.
Only one app is "foreground" at any time on iOS, so when the App Store app is in the foreground, the app being upgraded cannot be. When an app is backgrounded, it is told that it is going in to the background and it is expected to save its state. It might eventually be resumed but it could be terminated without any further notice due to power-off, low memory, etc. So the case of an update is not special.
I don't know how it works on the Mac, where presumably the app being upgraded might still have windows visible. My guess is that it is killed with some notice first.
Day: GNOME OS Posted Aug 9, 2012 8:39 UTC (Thu) by krake (subscriber, #55996) [Link]
"I don't know how it works on the Mac, where presumably the app being upgraded might still have windows visible. My guess is that it is killed with some notice first."
I wouldn't be so sure. The blog indicated that Chrome wants to be running during and after the upgrade and it said Linux makes that difficult and Windows and OS X don't.
Therefore we msut assume that the Mac store update process allows applications to continue to run. There is just no confirmation on that yet and not details how it does it.
Day: GNOME OS Posted Aug 9, 2012 9:30 UTC (Thu) by hummassa (subscriber, #307) [Link]
this is probably because the Mac upgrade process changes the whole /Applications/Google\ Chrome directory and the old application + the old shared objects is running from the old directory, so you don't have the problem you usually have *during* an apt-get dist-upgrade that if your running applications dlopen(), they do that with the *new* libraries (possibly inconsistently with what they are expecting).
|
|||||||||||||