[ReggieX]

chalk up another "BFD/quit whining" response.

I'm already rebooting regularly because BitTorrent creates swapfiles that don't clear after a log out. Set Software Update to manual and only update on your own schedule.

[yukon]

This isn't true, there are lots of kexts which cannot be safely unloaded at runtime....you can unload something into an immediate panic...a lot of the IOKit provider nubs for miscellaneous hardware buses are deeply unhappy about runtime unloading.

Disclaimer:I haven't worked on Darwin's source, and I don't work for Apple, I only know what I read about it and what I see in OS X.

iChat isn't updating the IOKit, Safari damn well better not be installing kernel extensions (it's updating of the webcore framework is questionable as well). The security updates don't always update really low level, OpenSSH updates, help.app fixes, and such things don't need to take down anything else. Right now, I have 6 updates needing restarts - one updates libpng and requires the restart, there's the iChat update, the AirPort software....I've got 50kbps going to the G4 at the moment, that doesn't really stop ever, taking down the G4 means the network goes down (and yes, I'm the only "client" of my OS).

I realize you were contradicting the "only XNU updates need restarts" quotes, but "Apple really should be better about this". Perhaps a push to stop requiring restarts for updates would make it so that certain kernel extensions could be unloaded that can't now (obviously, unloading very core ones that handle IO etc, unloading those isn't smart, unless they can be immediatly reloaded some way I don't know).

Ugh, I thought the whole argument being made was that restarts cause the user to lose "state" information? Why is forcing the user to quit any better? Because its 30-90 seconds faster than a restart?

webcore goes down, quit safari. no need to quit xcode and appleworks. window manager or even cocoa frameworks are updated, fine, quit everything GUI, but services like ssh and apache stay up, the GUI reloads. All networking goes down, fine, it reloads and the network is back up in five seconds instead of 3 minutes. There's a benefit to this. If OS X Server is the same way, more than a few xserve admins will be pissed off when Apple updates samba and apache goes down.

Apple resources that might be used to solve the problem are likely best used on other projects that have more important impacts on user experience....dedicate engineers to....improving ________ performance.

If iChat requires a restart, obviously no real time has been spent to go past the code that Apple inherited to stop requiring restarting. Some work to make installer.app see levels of "restarting" (quit to console, quit to loginwindow, quit teachtext and relaunch it) would make it so that Apple could stop most of it's updates from rebooting the OS. More work, diminishing returns, but same with performance. Computers get faster, performance increases that way too, but a requirement to restart all the time ("every few weeks") sticks with an OS.


One of the measures of an OS is it's uptime - not necessarily how long it's been up, but how long it can keep critical applications up (through application crashes, through security updates). And no one should compare OS X to Windows, that's been left behind long ago, better to compare it to the best and ask why it isn't.

[Person Man]

Originally posted by yukon:
Safari... (it's updating of the webcore framework is questionable as well).

Why? Many of the security issues in Safari are actually part of WebCore, but not Safari, which relies on WebCore. The reason Apple calls it a Safari update is that many security sites mistakenly report the security issues as being "Safari" problems. Not to mention that the average (nontechnical) user most likely won't know what "WebCore" is, but can easily understand that a security hole in Safari has been fixed.

[Basilisk]

iChat isn't updating the IOKit

No its not, and as I said InstantMessenger.framework is probably a case where the dependencies are light enough that if one wanted to do a clean shutdown of the affected apps its possible though non-trivial. I suspect that many would be surprised how much "state" could be lost this way. It would include Mail, Address Book, and lots of related stuff. That's a hell of a lot of state to lose. Nevertheless I grant you that its one case where a restart probably wasn't required if Apple wanted to throw the engineering effort at it.

Safari damn well better not be installing kernel extensions (it's updating of the webcore framework is questionable as well).

Safari is nothing but a thin wrapper around WebCore. This has been clear to technical users since its introduction. Non-technical users who do not understand that these are intimately tied are unlikely to be upset at the notion that Safari updates the framework.

The security updates don't always update really low level, OpenSSH updates, help.app fixes, and such things don't need to take down anything else.

The one-line blurb about the security update patches isn't always a very complete picture of the actual update dependencies. There hasn't been an OpenSSH-only update this year, that's a complete red herring.

Look at the info at http://docs.info.apple.com/article.html?artnum=61798. The following 2 updates in 2004 could have potentially skipped a restart by shutting down a (potentially manageable) number of dependent apps:

20040916 (iChat, InstantMessage.framework)
20040524 (HelpViewer)

Security updates in 2004 that would have required a full quit of every GUI app (many would also affect service deamons):

20040907v1.1 (CoreFoundation, etc.)
20040907 (CoreFoundation, etc.)
20040809 (libpng which is used by CoreGraphics)
20040607 (LaunchServices)
20040503 (CoreFoundation, etc.)
QuickTime 6.5.1 (Used for image decoding in Cocoa and Carbon)
20040405 (libxml2 which is a dependency of Foundation)
20040223 (CoreFoundation, etc.)

By my count that means that Apple has had two "questionable" reboots in the last year for security updates.

So what precisely is all the noise about? Are folks seriously arguing that 2 extra reboots in the last year is too much? Is fixing this really so much more important that engineering time should be spent on this rather than making the OS more productive in other ways?

Perhaps a push to stop requiring restarts for updates would make it so that certain kernel extensions could be unloaded that can't now (obviously, unloading very core ones that handle IO etc, unloading those isn't smart, unless they can be immediatly reloaded some way I don't know).

I think you're missing the point of my post. A whole bunch of the kernel can't be unloaded precisely because its either core or IO-related. In a very real sense the entire kernel fits into that category.

webcore goes down, quit safari. no need to quit xcode and appleworks.

Again, the dependencies are more complex than you portray. Replacing WebCore requires XCode to quit (it uses it internally). The current version of AppleWorks doesn't need to go down but I'd be willing to bet that the next version links WebCore too.

window manager or even cocoa frameworks are updated, fine, quit everything GUI, but services like ssh and apache stay up, the GUI reloads. All networking goes down, fine, it reloads and the network is back up in five seconds instead of 3 minutes.

Thats a complete strawman. As I already established, very few real updates are at the high level. CoreFoundation updates have the potential to impact almost everything in the process tree below mach_init. At the very least its going to take down many of the controller services (configd, etc.) and authentication. And that's going kill (you guessed it) both OpenSSH and Apache.

If iChat requires a restart, obviously no real time has been spent to go past the code that Apple inherited to stop requiring restarting.

No, it means that Apple has optimized for the common case (8 of the 10 updates mentioned above) and decided that the extra engineering effort can be spent elsewhere more productively.

More work, diminishing returns, but same with performance. Computers get faster, performance increases that way too, but a requirement to restart all the time ("every few weeks") sticks with an OS.

Its disingenuous to equate the two. Not all areas of potential improvement have equal impact on the userbase.

Its also silly to focus on the timing of those restarts as they are essentially arbitrary and uncontrollable. Apple has no foreknowledge of where the next vulnerability will be so sometimes security updates appear tightly spaced (like recent history) and sometimes the windows are longer.

The upgrades to the install process you propose would have saved two restarts in 2004. The portion of the userbase that cares about this still would have had to shut down your apps and services 8 other times. Thats a 20% win for you and a percentage of users, and completely wasted effort for the rest of us.

Spending the same amount of effort improving IO performance, CoreGraphics performance, etc. all have measurable impact for 100% of the userbase. I know where I'd rather they spend their time.

One of the measures of an OS is it's uptime - not necessarily how long it's been up, but how long it can keep critical applications up (through application crashes, through security updates).

Uptime is only a valuable measure if that's your primary design goal and you are unable to create service reliability through other means (rotating service frontend, hot failover, etc.). OS X is not intended to be the be-all-end-all OS for all users and uses. If you are deploying a five-nines service environment on a single machine there are undoubtably better choices. If your goals are less extreme and you can afford reasonable maintenance windows then the occasional reboot is a total non-issue and is likely lost in the noise compared to other service availability issues.

Alex

[Gavin]

Wow, that was well thought out and stated.

And it's still just an excuse.


The only time I have to take my linux box down is when I upgrade the kernel itself. Free BSD is the same, which OSX is based on.

I pay money for my OS and I want it to be the best.

[Basilisk]

Wow, that was well thought out and stated.

And it's still just an excuse.

"Excuse" by what standard? That Apple has other priorities isn't an excuse, its a resources decision. They get made all the time.

The only time I have to take my linux box down is when I upgrade the kernel itself. Free BSD is the same, which OSX is based on.

Here's a common of a misconception. OS X's userland is based on FreeBSD. The kernel and a great deal of what would actually be involved in rebootless security updates are different.

Look at the security table I supplied. Anytime you see "CoreFoundation" in the list realize that BSD has no equivalent. Also realize that its called "Core" and "Foundation" for a reason. Apple has a more narrowly rooted dependency tree than Linux or FreeBSD. This is a design decision that has specific advantages and disadvantages. The main advantage is that CoreFoundation includes a lot of good stuff that everyone can leverage. Fixes there improve lots of things. The disadvantage is that when it has to be updated more processes are impacted.

And finally, understand that while I'm very pleased for you that your home Linux box doesn't reboot as often, its not because the Linux folks have solved this problem, its because they've ignored it. They've taken the 90/10 rule to heart and not solved it in the general case. Most users don't have to reboot, and those who actually live in the corner cases of the update get to find out the hard way.

At my last datacenter we used to get burned by this, and ended up setting a policy that rebooted our Linux boxes after any low level updates (libc, nfs, etc.). This is a farily typical response. When you're managing lots of Linux boxes you often freeze out your Linux installs and never update unless the security patch is so serious you don't think you can skip it. Then you spend a day to a week testing it on a canary box to find out if you live in one of the corner cases. In particular, you reboot to make sure that the box comes back up. Sometimes, especially on libc/libc++ updates, it doesn't. Then you waste more time figuring out why.

You have your anecdotal evidence about how Linux and BSD work, and I have mine. But the picture over there isn't all roses. Apple's approach is differnt than Linux, its more conservative, but its also guaranteed to be correct in all cases.

Alex

[TETENAL]

Originally posted by yukon:
help.app fixes, and such things don't need to take down anything else.

The Help.app update did not require a restart.

webcore goes down, quit safari. no need to quit xcode and appleworks.

Xcode uses WebCore.

[yukon]

Why? Many of the security issues in Safari are actually part of WebCore, but not Safari, which relies on WebCore.

An application update shouldn't change the system. That's part of dll hell. An OS update fixes parts of the OS that have problems, an application update fixes the application. Webcore really is not part of Safari or anything, it's development was announced at the same time, but the relationship is reversed. Safari depends on Webcore, as do other applications now. If Apple fixes webcore in a way that breaks 3rd party applications, and calls it a Safari update, the average user updating Safari will see their other applications suddenly go down for no reason. My application example before was Omniweb since it's high profile and uses webcore, but Omni sends omniweb with it's own copy of webcore.

It would include Mail, Address Book, and lots of related stuff. That's a hell of a lot of state to lose.....(webcore/safari) Non-technical users who do not understand that these are intimately tied are unlikely to be upset at the notion that Safari updates the framework

I don't have Mail open, nor Address Book, nor even iChat. Taking down the OS for this is odd.

As I said above, I know what Webcore is, and I know that it and Safari are strongly related, but Safari =! Webcore. They've shipped Webcore and the instant messaging framework as part of the OS, available for other parties to use. If Webcore is supposed to be part of Safari, it should be a service Safari offers. If webcore is a Safari application, update it with safari (and start calling it libsafari), if it's a system framework, then update it with the system. This is a bit of a tangent from the restarting issue, but I think it's also valid (should an iTunes update change your CDRW drivers? It broke support for my SCSI burner in one "update" a while ago).

Replacing WebCore requires XCode to quit (it uses it internally). The current version of AppleWorks doesn't need to go down but I'd be willing to bet that the next version links WebCore too.

Yeah, to be honest, I wasn't certain about XCode not needing webcore, but it was just an example, I can make up a few thousand ;-). How about "Updating webcore does not require Camino to go down", or terminal.app, or toast, or just plain the majority of OS X applications. If the next version of AppleWorks (steve willing uses Webcore, then it should be restarted too, but don't kill MPlayer.

Checking to see if any open applications use a framework shouldn't be too hard to implement, giving a list of "The current applications would need to be quit to be updated : Safari, Help, XCode, AppleWorks7. Do you wish to quit these applications? or Restart?", not a horrible thing to do.

By my count that means that Apple has had two "questionable" reboots in the last year for security updates.

And that's security updates. I was just mentioning that there was an OpenSSH update that took down the system (ISTR it was the trojaned one, quite a while ago I guess), the recent one I mentioned was help.app which I thought took down the OS, others have in the past. It's a "questionable" reboot, and if I don't have anything open that uses instantmessage.framework, it's unnecessary. Thanks ;-)

A whole bunch of the kernel can't be unloaded precisely because its either core or IO-related. In a very real sense the entire kernel fits into that category.

Sure, restart for the kernel extension changes that the kernel needs to do anything useful like IO, or needs in order to load new or the updated extensions. The point is that _even when_ a kernel extension is updated, a restart isn't always necessary, not "Kernel extension updates shouldn't require restarts" (though someone might want to try and argue that one).

Thats a complete strawman....very few real updates are at the high level. CoreFoundation updates...its going to take down many of the controller services (configd, etc.) and authentication. And that's going kill (you guessed it) both OpenSSH and Apache.

So? Kill the services, and restart them. For updates that aren't at the low level (the "few"), don't restart the entire OS. Just a little work there would mean "a few" restarts would be avoided. At the point where you start updating very important stuff, working to avoid restarting would require more work, still very do-able, but at that point your update is a full OS update anyway, isn't it?

Its disingenuous to equate the two. Not all areas of potential improvement have equal impact on the userbase. Its also silly to focus on the timing of those restarts as they are essentially arbitrary and uncontrollable.

But then, not all problems require the same amount of work to get the improvement. Comparing working on code optimization with allowing the user to avoid restarting on updates that the OS is built to avoid restarting on, it's also not the same.

Timing, I was just saying that every few weeks, there's going to be a new update, and with the way it's set up now, it's going to require a restart regardless of necessity.

The upgrades to the install process you propose would have saved two restarts in 2004.

How many in 2003? 2002? How many users would have to restart for those updates? How about in 2005, can you tell? Maybe in 2006 there'll be an update to iChat every week that'll take Adium* down (*adium may require instantmessage.framework, it's an example. You can use VNCThing as the example if it does) along with with the entire OS.

Uptime is only a valuable measure if that's your primary design goal and you are unable to create service reliability through other means (rotating service frontend, hot failover, etc.). OS X is not intended to be the be-all-end-all OS for all users and uses.

Yeah, it's for shmucks, uptime means nothing since it's not the primary design goal, users can just keep the machines off. ;-D (I'm joking of course, but uptime is a valuable measure, even outside enterprises that can afford and configure multiple machines as a backup for a main one).

OS X is supposed to modern. It's supposed to be the be-all-end-all OS for the desktop. OS X is supposed to replace other server operating systems with the XServe. When OS X needs to go down for the majority of updates (6 of 10 in my SU window right now) while Linux and the BSDs (the current three major, don't give me 4.4), well, they don't really go down unless you recompile and install a different kernel or update something the OS needs to run. This isn't the way OS X was designed, this isn't what we were told we were upgrading to.

By Gavin-
Wow, that was well thought out and stated. And it's still just an excuse. The only time I have to take my linux box down is when I upgrade the kernel itself...I pay money {for OS X}...I want the best.

Absolutely, had trouble replying to that well at all . Harder than arguing against APE this time ;-)

[Basilisk]

If Apple fixes webcore in a way that breaks 3rd party applications, and calls it a Safari update, the average user updating Safari will see their other applications suddenly go down for no reason.

You're arguing pure semantics. If Apple called the update "Webcore" the update implementation would be the same. And, of course, my mother in law would have no idea what it was since she uses "Safari" not "WebCore".

I don't have Mail open, nor Address Book, nor even iChat. Taking down the OS for this is odd.

And as I have said, time and time again, its one (one!) example of a uneccessary restart. The way you talk about this problem I'd swear you were having unneeded reboots every day.

This is a bit of a tangent from the restarting issue, but I think it's also valid (should an iTunes update change your CDRW drivers? It broke support for my SCSI burner in one "update" a while ago).

It is tangental to the restart issue. If you're arguing for more fine-grained updates that's fine but its a seperate conversation. If Apple wants to update your CDRW drivers its going to require a restart. You can make a case that those shouldn't be bundled with iTunes (I suspect they do this for simplicity), but its not saving a restart.

Checking to see if any open applications use a framework shouldn't be too hard to implement, giving a list of "The current applications would need to be quit to be updated : Safari, Help, XCode, AppleWorks7. Do you wish to quit these applications? or Restart?", not a horrible thing to do.

Except, of course, the reality is that the breakdown of updates I've listed would require a logout anyway (change CoreFoundation means kill the entire GUI).

But hey, if you think its easy please implement it. Its not like Software Update is some supersecret magic. The URLs for download are well known and the installer can be driven from user apps. If doing the right, correct thing for the transitive closure of all dependencies in all cases on user machines is easy I encourage you to try. I've had quite some experience with this, I think you'll be surprised.

And that's security updates. I was just mentioning that there was an OpenSSH update that took down the system (ISTR it was the trojaned one, quite a while ago I guess), the recent one I mentioned was help.app which I thought took down the OS, others have in the past.

As TETENAL mentioned I was wrong (so were you). The HelpViewer update didn't require a restart (check for yourself). So are we really just talking about InstantMessanger now?

You keep talking about updates that maybe didn't require restarts as if there are a lot of them. I suggest we stop talking about them in the hypothetical because I can't escape the feeling that you're inflating the number in your mind. All of the update history is available on Apple's site, please get a list for 2004 (and 2003 if you like) of updates that by your standard shouldn't have required a restart. Then we can user real numbers instead of hypotheticals.

And, yes, as already rehashed many times, you can include InstantMessage on your list

So? Kill the services, and restart them.

Again, its not just network services. CoreFoundation touches almost everything under mach_init and updating it is a big deal. Restarting the full process chain under mach_init is tantamount to a reboot (in terms of time and net effect). The init startup is the bulk of the reboot sequence. This isn't 5secs vs 3min.

But again, if you think its easy, that's great. Rather than asserting that I suggest you detail a viable strategy for an in-place update of CoreFoundation. If you come up with one (in detail), I promise I'll go away .

How many in 2003? 2002? How many users would have to restart for those updates? How about in 2005, can you tell?

Neither of us can predict the future, so its pointless to speculate. I was frustrated at the number of reboots in early versions of OS X and I think they've gotten a whole lot better over subsequent releases.

You apparently have a different impression, but excepting InstantMessage, I haven't actually seen you come up specific examples. There are 6 updates in your SU right now that require restarts. How many would your strategy "fix"?

uptime is a valuable measure, even outside enterprises that can afford and configure multiple machines as a backup for a main one).

OS X is supposed to modern. It's supposed to be the be-all-end-all OS for the desktop. OS X is supposed to replace other server operating systems with the XServe.

Earlier in this thread someone maintained that the reason folks are resistent to this is that we think that Apple can do no wrong. I think the evidence of my software development for OS X pretty clearly indicates my postiion isn't blind worship of Apple.

The problem you describe is harder than you think, and all I see in this thread is handwaving over how easy the problem is.

while Linux and the BSDs (the current three major, don't give me 4.4), well, they don't really go down unless you recompile and install a different kernel or update something the OS needs to run. This isn't the way OS X was designed, this isn't what we were told we were upgrading to.

As I replied to Gavin your assertions about Linux aren't true in my experience. Linux's update process cuts corners that I don't think are acceptable in all cases (clearly they are in some cases). I'm happy that Apple hasn't chosen this route.

Alex

[CharlesS]

Originally posted by Angus_D:
Apple could and should improve the behaviour of this, perhaps even by walking the process table and examining the mach images loaded into each running thing, then prompting the user to OK before automatically quitting them and marking them as temporarily disabled while it does the update... Or something. However, it'd be non-trivial to implement something like this, let alone implement it in a user-friendly way.

Am I missing something? To my simple mind, it seems like it'd just be:

1. Wait until update finishes (since currently you don't have to reboot until the update is done)

2. List running processes (ps -aux)

3. For each process, list dependencies (otool -L)

4. For each library/framework linked to, check its dependencies (otool -L)

5. Repeat recursively, being sure not to check a library/framework that's already been checked, until all dependencies and dependencies of dependencies have been checked.

6. Put up a dialog box that says "The following applications need to be quit and restarted:" followed by a list of apps that depend on the framework you updated.

7. Boom.

Obviously the ps and otool tasks wouldn't need to be fork/execed, as Apple could put code to list processes and check dependencies inside the Software Update mechanism if they wished. It's just an example to show how it can be done currently.

Yes, for CoreFoundation, you'd probably be best off with a restart. However, for something like WebCore, the algorithm above should work, I think.

[Basilisk]

Yes, for CoreFoundation, you'd probably be best off with a restart. However, for something like WebCore, the algorithm above should work, I think.

I agree that there are cases where the strightforward strategy works. My point is that the bulk of the frequent updates are security updates and for whatever reason CoreFoundation gets touched a lot.

Even still, the simple strategy isn't all its cracked up to be in all cases. It accounts only for direct dependencies, not indirect dependencies. A lot of the system is completely dependent on the proper behavior of a group of long-running core processes (init, mach_init, configd, and SecurityAgent to name a few). Updates to their dependencies require them to restart. In some cases those dependencies are surprising in high-level scope (SecurityAgent needs Cocoa and Carbon for example).

Those processes publish lots of important core services over IPC to processes that do not necessarily have the same direct framework dependencies. However, that doesn't make the dependency less real. If you restart configd then apps that use it need to be shutdown and restarted (or at least signalled). In configd's case you can probe (otool -L) other processes for the use of its related framework (SystemConfiguration) but its not always clear how to execute a clean restart of those dependent proceses because they may in turn have other implicit IPC dependencies. Its especially hairy if those IPC dependencies are within third party apps. My own SideTrack depends on configd, how is Apple to know that killing configd means killing sidetrackd which in turn requires them to quit any open copy of System Preferences with the SideTrack prefpane loaded?

In graph theory terms a complete provably correct all cases service restart requires you to be able to define a total order on the closure of all dependencies. Thats very hard, and Apple can't do it alone because third party apps create their own. Its a lot of data to manage and it has to be correct, and Apple has to get some of it from third parties using a mechanism that they would need to define and validate. And even then a bad data block from a third party could make it do the wrong thing.

This is why I get frustrated when people talk about how easy the problem is. In my real job I do release engineering and once you step beyond the trivial case of one framework with only leaf dependencies (WebCore -> Safari) its not nearly as easy as it sounds. And, as an unfortunate fact of life, the trivial case is not the common case (as demonstrated by my analysis of the actual Security Updates above).

Alex

[ManOfSteal]

Wow, this thread is still going?

[Basilisk]

Wow, this thread is still going?

Well... Yukon, Charles and I have all stepped in. If history is any indication we're just getting warmed up

Alex

[Gavin]

Originally posted by Basilisk:
"Excuse" by what standard?

By it's very definition. To forgive or explain away. I'm not trying to belittle it here because it's all technically correct, but your post picks at the little details and dodges the point which is simply "it could be better".

That Apple has other priorities isn't an excuse, its a resources decision. They get made all the time.

Which seems to imply that you agree with the basic premiss here. The rest is an excuse, an apology. Not meant as a criticism of you or your ideas but just an observation of the overall thread.

Here's a common of a misconception. OS X's userland is based on FreeBSD. The kernel and a great deal of what would actually be involved in rebootless security updates are different.

I have no misconceptions about the OS. I would like to measure OSX by other UNIX variants which it deserves. Not "it's OK cause it's a little better than windows" which some people are suggesting here.

And finally, understand that while I'm very pleased for you that your home Linux box doesn't reboot as often ...

Actually several servers, but thanks for the attempt at belittling my knowledge

... This is a farily typical response. When you're managing lots of Linux boxes you often freeze out your Linux installs and never update unless the security patch is so serious you don't think you can skip it. ...

You have your anecdotal evidence about how Linux and BSD work, and I have mine. But the picture over there isn't all roses. Apple's approach is differnt than Linux, its more conservative, but its also guaranteed to be correct in all cases.

You know I basically agree with you here. What you are saying is all very true, it's just that it's beside the point, which is you shouldn't have to restart unless you have to restart. And to require a restart when it's unneeded is annoying. Not a problem, just annoying. Of course there are times when it's necessary but it's not out of line to ask a technology company for a more sophisticated approach.

[Gavin]

yukon
If Apple fixes webcore in a way that breaks 3rd party applications, and calls it a Safari update, the average user updating Safari will see their other applications suddenly go down for no reason.

Basilisk:
You're arguing pure semantics. If Apple called the update "Webcore" the update implementation would be the same. And, of course, my mother in law would have no idea what it was since she uses "Safari" not "WebCore".

Jeez, my response to this was almost word for word except I was gonna use gramma instead of mother in law.

I know people who won't click the install button because they are afraid they will break something. Calling it "webcore" or application frameworks" would scare the hell out of them.

As I replied to Gavin your assertions about Linux aren't true in my experience. Linux's update process cuts corners that I don't think are acceptable in all cases (clearly they are in some cases). I'm happy that Apple hasn't chosen this route.

RPMs are definitely more of a pain in the butt, but I don't have to take email or file serving down when I upgrade apache. This is more of an issue in a small office with a single server running an intranet. You have to do the upgrades during business hours but you hear about it when any service is unavailable for 2 minutes. The xserve falls into this niche.

I wonder if a restart later button would solve everybody's problem. The upgrade panel gets out of your face and the machine reboots overnight. You'd still run into occasional library mismatch problems with running programs.

[CharlesS]

Originally posted by Basilisk:
I agree that there are cases where the strightforward strategy works. My point is that the bulk of the frequent updates are security updates and for whatever reason CoreFoundation gets touched a lot.

Even still, the simple strategy isn't all its cracked up to be in all cases. It accounts only for direct dependencies, not indirect dependencies. A lot of the system is completely dependent on the proper behavior of a group of long-running core processes (init, mach_init, configd, and SecurityAgent to name a few). Updates to their dependencies require them to restart. In some cases those dependencies are surprising in high-level scope (SecurityAgent needs Cocoa and Carbon for example).

So if you have to update something required by configd, restart. For something that only affects high-level GUI stuff, like WebCore, restart the appropriate processes. For something like ftpd or sshd that might not even be on, restart the appropriate processes.

I don't see why it's necessary to take a hard-line absolute stance either way. That's why I said reboot for something like CoreFoundation, restart apps for something like WebCore.

[Basilisk]

By it's very definition. To forgive or explain away. I'm not trying to belittle it here because it's all technically correct, but your post picks at the little details and dodges the point which is simply "it could be better".

I'm arguing that with few exceptions (InstantMessage, maybe WebCore) it can't be "better" and still be reliable and correct. My premise is the old saw, "For every complex problem, there is a solution that is simple, neat, and wrong." Thus far the presented solutions are all simple, neat, and provably incorrect.

Can Apple do better in some cases? Yes. Are those bugs? Yes. But that's not what the discussion seems to be about. Yukon argues that many of the updates that required restarts didn't have to, and thus far except for InstantMessage no one has stepped up to the plate with an actual example of one for which that was actually true.

Actually several servers, but thanks for the attempt at belittling my knowledge

It really wasn't meant that way. My point was that they are "home" servers and so you fall into the category of folks for whom the cut corners in the Linux upgrade model don't have a serious impact. Its not a universal truth that their upgrade model works for all cases, and I personally have dealt with the fallout in a production environment.

You know I basically agree with you here. What you are saying is all very true, it's just that it's beside the point, which is you shouldn't have to restart unless you have to restart. And to require a restart when it's unneeded is annoying.

I don't disagree, my point has been that there's not a flood of updates which fall into the category of "restarted but didn't have to restart". For the most part we seem to get nothing but anecdotal evidence and faulty memory. HelpViewer didn't need a restart. There hasn't been an OpenSSH-only update (which could be restarted as a service only) in the entire history of Security Updates for Panther.

Look at it another way, I'm asking for someone to explain not _why_ they are complaining about unnecessary restarts, I'm asking for someone to step up with more than one or two examples of where its actually happened often enough to be worried about it (much less spawn a thread this long).

I don't see why it's necessary to take a hard-line absolute stance either way. That's why I said reboot for something like CoreFoundation, restart apps for something like WebCore.

Its hard line because if Apple wants to be taken seriously they need to have their release engineering be correct. Otherwise we'd be sitting here in the other type of update thread "Update X broke my Y!"

But that's not really the point. I'm not debating that for the absolute simple leaf node cases (like a pure WebCore update) that it couldn't be done. My point is that as far as I know there hasn't been a WebCore-only update _ever_. The entire argument about Webcore is nonsensical because its totally angels on the head of a pin. It never happened.

Looking at the update history for Panther (not just security updates, the whole thing). In the last year I find about 4 WebCore updates. Not a single one of those was WebCore-only. All Safari/Webcore related security updates included CoreFoundation. Even the Safari 1.2 release included an update to Foundation.

Alex

[Gavin]

Actually several servers, but thanks for the attempt at belittling my knowledge

Basilisk:
It really wasn't meant that way.

Actually I was just being flippant.

My point was that they are "home" servers and so you fall into the category of folks for whom the cut corners in the Linux upgrade model don't have a serious impact. Its not a universal truth that their upgrade model works for all cases, and I personally have dealt with the fallout in a production environment.

I tend to roll my own on the linux server end. I think OSX's updater is mostly great for my desktop but it would driver me nuts with a server. I haven't used X server but I imagine the updater works the same. I'd need it to be more granular. I want the new ssh but not the ftp server, the system libs but don't touch apache, etc. Having all or nothing in a big bundle wouldn't work.

I don't disagree, my point has been that there's not a flood of updates which fall into the category of "restarted but didn't have to restart". For the most part we seem to get nothing but anecdotal evidence and faulty memory. ...

I'm asking for someone to step up with more than one or two examples of where its actually happened often enough to be worried about it (much less spawn a thread this long).

I don't honestly pay it that much attention so I can't give you examples better than...
Once upon a time there was an update and the people thought "hey, in linux I'd just restart the network for that!"

As to the long thread. It's the annoyance factor. This whole board is basically one big bitch-fest
There was a lot of talk, especially around the time of the beta, about how unix reliability is measured in uptime, uptime of months if not years. People feel ripped off. The system updates just take all the fun out of the 'post your uptime' threads.

[goMac]

In theory there is no reason why SU should have to restart the machine. I heard a rumor at one point Apple was working on addressing this issue.

However, from what I hear, Apple engineers are easily distracted... I think they kinda lost track of that feature.

[drainyoo]

Dude is it really that serious? You cant wait 30 seconds for the system to restart? I find that ridiculous.

[Randman]

Go to any Windows forum and try and complain about this. Gee, what a whinger.

[CharlesS]

Originally posted by drainyoo:
Dude is it really that serious? You cant wait 30 seconds for the system to restart? I find that ridiculous.

What about people who run servers on their machines? 30 seconds of downtime is a big deal in that case.

[Randman]

Originally posted by CharlesS:
What about people who run servers on their machines? 30 seconds of downtime is a big deal in that case.

If people run servers, they should also budget time for maintainance. Honestly, it's not trouble to restart a computer and any of those complaining about it should really rethink their priorities in life.

[drainyoo]

Originally posted by CharlesS:
What about people who run servers on their machines? 30 seconds of downtime is a big deal in that case.

I dont think hes running a server.

[drainyoo]

Originally posted by Randman:
If people run servers, they should also budget time for maintainance. Honestly, it's not trouble to restart a computer and any of those complaining about it should really rethink their priorities in life.

I agree. The last thing I worry about in life is restarting when I update software.

[curmudgeon]

You are right. I am sorry.

[Geobunny]

Originally posted by curmudgeon:
jesus christ, just shut the **** up.

Having only 9 posts in 10 months of membership makes me think you're someone who choses their posts carefully - this one confuses me. Why take the time out of your day to make such a useless contribution to an otherwise useful and mature discussion?

If you don't agree, voice your opinion eloquently (as others have already done so) or pass by and say nothing at all. Please don't waste anyone's time by posting something which is neither constructive nor original.

PS. My apologies to those following this thread for rising to the bait.

[goMac]

Originally posted by CharlesS:
What about people who run servers on their machines? 30 seconds of downtime is a big deal in that case.

We ran XServe's at my old work. Every few months we'd apply the software updates and restart around midnight. It wasn't a huge deal.

[ReggieX]

Originally posted by CharlesS:
What about people who run servers on their machines? 30 seconds of downtime is a big deal in that case.

In that case they should have more than 1 machine anyway, mirrored for backup and/or have scheduled maintenance. Heck, I'm on standby for a routine systems implementation tonight. We put up a notice saying the server's down for maintenance and to come back in a few minutes.

[TETENAL]

Originally posted by goMac:
We ran XServe's at my old work. Every few months we'd apply the software updates and restart around midnight. It wasn't a huge deal.

How did you resist the temptation � when Software Update popped up � how did you resist the temptation to install it right away? I usually install the same minute I hear about the update. Having to wait months would be hell.

[siflippant]

Originally posted by manofsteal:
Wow, this thread is still going?

yep, it's amazing how much time and effort some people put into these topics... I could restart my PB at least 20 times on the spin during the same time it takes to write a length reply...

[Xtraz]

Originally posted by TETENAL:
How did you resist the temptation � when Software Update popped up � how did you resist the temptation to install it right away? I usually install the same minute I hear about the update. Having to wait months would be hell.

On the other hand, I wait a few days to make sure the update isn't pulled or a major bug surfaces because of it. Unless that update contains an improvement that had been making my life miserable, that is. (though I don't remember any instances of this recently)

I've been following this conversation not because I'm particularly passionate about the issue (my server serves at most 5 people and is non-critical), but because the depth and civility of this thread in general exceeds that of the general argument that goes on in these forums.

As I understand the situation (keep in mind my lack of knowledge of OS structures), Linux and OS X are OSes that are built with different goals in mind. Linux and FreeBSD chose simplicity and OS X one of relative complexity, with an assortment of core services that provide to all applications. Apple chose this so nice features, such as system-wide access of addresses, passwords (the most visible examples), can be implemented and hence improve the overall usability of the OS (for most users). OS X is built with ease-of-use in mind from the very beginning. Linux, on the other hand, was not. Its GUI and ease-of-useness was added on later.

The tree of interdependences that OS X's services can get very complicated when third-party software are introduced into the mix, as they can implicitly link otherwise unlinked applications and services. And therefore the safest way to handle all cases (make sure 99.9% of the computers don't break) is to force a reboot.

Though based on what I've read I'm agreeing with Alex, I'm curious as to how subtantial these changes are if they were to be implemented. To change the way CoreFoundation and other low-level pieces of software are loaded (ie to allow piecewise dynamic loading), would that require some clever strapping of software? Or would that require a complete rewrite of how pieces of the OS communicate with each other?

As for non-low-level (are two dashes allowed in a word?) framworks such as the InstantMessaging example, would that be much work to work out all dependances?

[Xtraz]

Originally posted by ReggieX:
I'm already rebooting regularly because BitTorrent creates swapfiles that don't clear after a log out. Set Software Update to manual and only update on your own schedule.

Interesting, I didn't know this. Does finding the swapfiles and deleting them manually work?

[goMac]

Originally posted by TETENAL:
How did you resist the temptation � when Software Update popped up � how did you resist the temptation to install it right away? I usually install the same minute I hear about the update. Having to wait months would be hell.

If we're running, say, a mail server its not a big deal to have it on 10.3.2 Server instead of 10.3.5 Server. It's already working just fine, why fix what's not broken?

[Basilisk]

Linux and OS X are OSes that are built with different goals in mind. Linux and FreeBSD chose simplicity and OS X one of relative complexity, with an assortment of core services that provide to all applications.

That's essentially correct. OS X's dependency tree is narrowly rooted because a few shared frameworks and services provide a great deal of functionality. That has advantages for users and developers because it makes it possible for core data types to be passed amongst applications at many different levels easily. For users this gives us things like complex clipboard datatypes. For developers it means that data can be passed between OS layers without translation (or with automatic translation) which means they are more likely to do the "Mac-like" thing and support better integration.

To change the way CoreFoundation and other low-level pieces of software are loaded (ie to allow piecewise dynamic loading), would that require some clever strapping of software? Or would that require a complete rewrite of how pieces of the OS communicate with each other?

Probably one or the other. If one can update the running library dependencies without stopping the process you don't have to shut the service down. This is possible, in fact that sort of dynamic loader trickery is how XCode's "Fix and Continue" feature works. However, it is very complex to get right in all cases, and I believe the current XCode implementation has a performance impact.

Alternately you can implement a system where running apps express their dependencies (both library and implicit IPC dependencies). Third parties would have to support this for it to really work.

Alex