Yes, I remember that article. I must admit I was a bit disappointed with it. But it made sense. How the threading in the Mach kernel is higher level than some other linux kernels. At least it made sense to me, but not knowing a ton about Mach, I pleasantly went along with it. Is this untrue or still up in the air? That is why I was hoping OS X was going to get a new kernel for 10.5. I use MySql and Oracle a lot and would love for these to be able to run on OS X machines just as quick as Linux. I respected that article from Anandtech because of the site's reputation. Perhaps I went along too sheepishly?
The threading issue was one big smelly red herring as they confused processes and threads.
The Apache benchmark is actually a bug in the benchmark - also present in the OpenBSD version - where it stalls causing bad results. The test wasn't very useful anyway as it wasn't real world.
I don't think anyone actually got down to the root of the MySQL issues. Ostensibly it was either an issue with syncing data to disk reliably (OSX does it, Linux doesn't), differences in filesystem (HFS+ v whatever they used on Linux) or potentially hardware.
And on top of that, they were testing apples and oranges since IIRC they never tested Linux running on the same G5 hardware so they can't rule out hardware issues making the entire OS comparison pointless.
I wonder what the results would be on the Intel boxes now.
Yes, I remember that article. I must admit I was a bit disappointed with it. But it made sense. How the threading in the Mach kernel is higher level than some other linux kernels. At least it made sense to me, but not knowing a ton about Mach, I pleasantly went along with it. Is this untrue or still up in the air? That is why I was hoping OS X was going to get a new kernel for 10.5. I use MySql and Oracle a lot and would love for these to be able to run on OS X machines just as quick as Linux. I respected that article from Anandtech because of the site's reputation. Perhaps I went along too sheepishly?
There have been many complaints about Mach. It was thought that with Travinian (spelling?) leaving, it could be the end of Mach for OS X, but so far, this doesn't seem to be the case.
The threading issue was one big smelly red herring as they confused processes and threads.
The Apache benchmark is actually a bug in the benchmark - also present in the OpenBSD version - where it stalls causing bad results. The test wasn't very useful anyway as it wasn't real world.
I don't think anyone actually got down to the root of the MySQL issues. Ostensibly it was either an issue with syncing data to disk reliably (OSX does it, Linux doesn't), differences in filesystem (HFS+ v whatever they used on Linux) or potentially hardware.
And on top of that, they were testing apples and oranges since IIRC they never tested Linux running on the same G5 hardware so they can't rule out hardware issues making the entire OS comparison pointless.
I wonder what the results would be on the Intel boxes now.
I think I read somwhere, that after 10.5 comes out, they will re-do the test.
There have been many complaints about Mach. It was thought that with Travinian (spelling?) leaving, it could be the end of Mach for OS X, but so far, this doesn't seem to be the case.
Avie Tevanian. I still can't see them using a monolithic kernel though like Linux, not when multi core chips are gaining in popularity.
I wonder if they've used Mach on the iPhone or something like L4 since they've got much greater control over that.
The threading issue was one big smelly red herring as they confused processes and threads.
The Apache benchmark is actually a bug in the benchmark - also present in the OpenBSD version - where it stalls causing bad results. The test wasn't very useful anyway as it wasn't real world.
I don't think anyone actually got down to the root of the MySQL issues. Ostensibly it was either an issue with syncing data to disk reliably (OSX does it, Linux doesn't), differences in filesystem (HFS+ v whatever they used on Linux) or potentially hardware.
And on top of that, they were testing apples and oranges since IIRC they never tested Linux running on the same G5 hardware so they can't rule out hardware issues making the entire OS comparison pointless.
I wonder what the results would be on the Intel boxes now.
I just read the article, and the responses. According to a number of them, who did tests, there could indeed be an Apple problem.
Be aware if you have any third party add-ons it is much better to disable them before installing any updates as they are known to cause issues.
Saying that third party add-ons (however you're defining them) are known to cause issues with updates (such as?) is too vague to be of much help, IMO. It's much better to disable what, for example?
I can't recall any third party software ever interfering with any OS X updates I've done since 10.1, though I don't use APE/Haxies if those are in the category of add-ons you're talking about.
Saying that third party add-ons (however you're defining them) are known to cause issues with updates (such as?) is too vague to be of much help, IMO. It's much better to disable what, for example?
I can't recall any third party software ever interfering with any OS X updates I've done since 10.1, though I don't use APE/Haxies if those are in the category of add-ons you're talking about.
I can't say anything about OS X, but I've heard of Quicktime plug-ins causing problems for Quicktime updates, but that was only with major updates, QT6 to QT7. I don't remember what plug-in that was. I don't think anything non-Quicktime will cause problems with a Quicktime update.
I have a few third party QuickTime components installed in /Library/QuickTime and they don't interfere with this update which only affects these files/folders:
It's wise to ignore any blind blaming of updates for causing unrelated issues (often pre-existing), like ridiculous claims I've seen that this one somehow improves network performance (among other things).
It's hard not to sadly laugh at some of the so-called "serious recommendations" (a.k.a. panic reactions) for fixing post-update problems that make absolutely no sense. Got a nosebleed? Let's amputate!
It's wise to ignore any blind blaming of updates for causing unrelated issues (often pre-existing), like ridiculous claims I've seen that this one somehow improves network performance (among other things).
It's hard not to sadly laugh at some of the so-called "serious recommendations" (a.k.a. panic reactions) for fixing post-update problems that make absolutely no sense. Got a nosebleed? Let's amputate!
No, it wasn't blind blaming. I remember a knowledgeable person stated that one very specific plug-in caused an incompatibility that caused problems with Quicktime when QT was updated to version 7. It wasn't a vague statement, I just don't remember whose plug-in caused the problems. Your amputation analogy is way off base too. Plug-ins are rarely essential and it's easy to archive them to test whether they are the cause of the problems, and unarchive when they are cleared. It should be easy to see that debugging is non-destructive.
I didn't at all mean to imply you meant that? sorry. My comments really weren't directed at anyone specifically. Sometimes it's hard to say much here without it being interpreted as argumentative or confrontative, then having to defend those misunderstandings. Oh well.
Quote:
I remember a knowledgeable person stated that one very specific plug-in caused an incompatibility that caused problems with Quicktime when QT was updated to version 7. It wasn't a vague statement, I just don't remember whose plug-in caused the problems.
I wouldn't doubt that.
I half remember some incompatibility between QuickTime 7 and older versions of Apple's MPEG-2 component. Not everyone is aware of those kinds of dependencies when they do updates; those of us who are usually know how to adequately prepare for them.
Quote:
Your amputation analogy is way off base too. Plug-ins are rarely essential and it's easy to archive them to test whether they are the cause of the problems, and unarchive when they are cleared. It should be easy to see that debugging is non-destructive.
My point with that analogy was simply that certain people without much skill in correlating symptoms with possible solutions sometimes give advice that ends up causing more problems than it cures. Based on your post history I definitely don't think that's something you'd intentionally do.
Comments
Yes, I remember that article. I must admit I was a bit disappointed with it. But it made sense. How the threading in the Mach kernel is higher level than some other linux kernels. At least it made sense to me, but not knowing a ton about Mach, I pleasantly went along with it. Is this untrue or still up in the air? That is why I was hoping OS X was going to get a new kernel for 10.5. I use MySql and Oracle a lot and would love for these to be able to run on OS X machines just as quick as Linux. I respected that article from Anandtech because of the site's reputation. Perhaps I went along too sheepishly?
The threading issue was one big smelly red herring as they confused processes and threads.
The Apache benchmark is actually a bug in the benchmark - also present in the OpenBSD version - where it stalls causing bad results. The test wasn't very useful anyway as it wasn't real world.
I don't think anyone actually got down to the root of the MySQL issues. Ostensibly it was either an issue with syncing data to disk reliably (OSX does it, Linux doesn't), differences in filesystem (HFS+ v whatever they used on Linux) or potentially hardware.
Some of it was pulled apart on http://ridiculousfish.com/blog/?p=17
And on top of that, they were testing apples and oranges since IIRC they never tested Linux running on the same G5 hardware so they can't rule out hardware issues making the entire OS comparison pointless.
I wonder what the results would be on the Intel boxes now.
Yes, I remember that article. I must admit I was a bit disappointed with it. But it made sense. How the threading in the Mach kernel is higher level than some other linux kernels. At least it made sense to me, but not knowing a ton about Mach, I pleasantly went along with it. Is this untrue or still up in the air? That is why I was hoping OS X was going to get a new kernel for 10.5. I use MySql and Oracle a lot and would love for these to be able to run on OS X machines just as quick as Linux. I respected that article from Anandtech because of the site's reputation. Perhaps I went along too sheepishly?
There have been many complaints about Mach. It was thought that with Travinian (spelling?) leaving, it could be the end of Mach for OS X, but so far, this doesn't seem to be the case.
The threading issue was one big smelly red herring as they confused processes and threads.
The Apache benchmark is actually a bug in the benchmark - also present in the OpenBSD version - where it stalls causing bad results. The test wasn't very useful anyway as it wasn't real world.
I don't think anyone actually got down to the root of the MySQL issues. Ostensibly it was either an issue with syncing data to disk reliably (OSX does it, Linux doesn't), differences in filesystem (HFS+ v whatever they used on Linux) or potentially hardware.
Some of it was pulled apart on http://ridiculousfish.com/blog/?p=17
And on top of that, they were testing apples and oranges since IIRC they never tested Linux running on the same G5 hardware so they can't rule out hardware issues making the entire OS comparison pointless.
I wonder what the results would be on the Intel boxes now.
I think I read somwhere, that after 10.5 comes out, they will re-do the test.
There have been many complaints about Mach. It was thought that with Travinian (spelling?) leaving, it could be the end of Mach for OS X, but so far, this doesn't seem to be the case.
Avie Tevanian. I still can't see them using a monolithic kernel though like Linux, not when multi core chips are gaining in popularity.
I wonder if they've used Mach on the iPhone or something like L4 since they've got much greater control over that.
The threading issue was one big smelly red herring as they confused processes and threads.
The Apache benchmark is actually a bug in the benchmark - also present in the OpenBSD version - where it stalls causing bad results. The test wasn't very useful anyway as it wasn't real world.
I don't think anyone actually got down to the root of the MySQL issues. Ostensibly it was either an issue with syncing data to disk reliably (OSX does it, Linux doesn't), differences in filesystem (HFS+ v whatever they used on Linux) or potentially hardware.
Some of it was pulled apart on http://ridiculousfish.com/blog/?p=17
And on top of that, they were testing apples and oranges since IIRC they never tested Linux running on the same G5 hardware so they can't rule out hardware issues making the entire OS comparison pointless.
I wonder what the results would be on the Intel boxes now.
I just read the article, and the responses. According to a number of them, who did tests, there could indeed be an Apple problem.
I just read the article, and the responses. According to a number of them, who did tests, there could indeed be an Apple problem.
Possibly. Apple's relative silence on this may speak volumes although it's not unusual they're silent. Certainly needs a retest anyway.
I wonder if they've used Mach on the iPhone or something like L4 since they've got much greater control over that.
Using L4 for iPhone OS X would certainly trigger a lot more speculation about it being a Mach replacement for Mac OS X.
Be aware if you have any third party add-ons it is much better to disable them before installing any updates as they are known to cause issues.
Saying that third party add-ons (however you're defining them) are known to cause issues with updates (such as?) is too vague to be of much help, IMO. It's much better to disable what, for example?
I can't recall any third party software ever interfering with any OS X updates I've done since 10.1, though I don't use APE/Haxies if those are in the category of add-ons you're talking about.
Saying that third party add-ons (however you're defining them) are known to cause issues with updates (such as?) is too vague to be of much help, IMO. It's much better to disable what, for example?
I can't recall any third party software ever interfering with any OS X updates I've done since 10.1, though I don't use APE/Haxies if those are in the category of add-ons you're talking about.
I can't say anything about OS X, but I've heard of Quicktime plug-ins causing problems for Quicktime updates, but that was only with major updates, QT6 to QT7. I don't remember what plug-in that was. I don't think anything non-Quicktime will cause problems with a Quicktime update.
% lsbom /Library/Receipts/SecUpd2007-001Ti.pkg/Contents/Archive.bom
. 41775 0/80
./System 40755 0/0
./System/Library 40755 0/0
./System/Library/Frameworks 40755 0/0
./System/Library/Frameworks/QuickTime.framework 40755 0/0
./System/Library/Frameworks/QuickTime.framework/Versions 40755 0/0
./System/Library/Frameworks/QuickTime.framework/Versions/A 40755 0/0
./System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 100755 0/0 7258956 1092005189
./System/Library/Frameworks/QuickTime.framework/Versions/A/Resources 40755 0/0
./System/Library/Frameworks/QuickTime.framework/Versions/A/Resources/version.plist 100644 0/0 518 2075750745
./System/Library/QuickTime 40755 0/0
./System/Library/QuickTime/QuickTimeStreaming.component 40755 0/0
./System/Library/QuickTime/QuickTimeStreaming.component/Contents 40755 0/0
./System/Library/QuickTime/QuickTimeStreaming.component/Contents/Info.plist 100644 0/0 952 1219408750
./System/Library/QuickTime/QuickTimeStreaming.component/Contents/MacOS 40755 0/0
./System/Library/QuickTime/QuickTimeStreaming.component/Contents/MacOS/QuickTimeStreaming 100755 0/0 3565844 2883492620
./System/Library/QuickTime/QuickTimeStreaming.component/Contents/Resources 40755 0/0
./System/Library/QuickTime/QuickTimeStreaming.component/Contents/Resources/QuickTimeStreaming.rsrc 100644 0/0 51841 541997997
./System/Library/QuickTime/QuickTimeStreaming.component/Contents/version.plist 100644 0/0 518 2075750745
It's wise to ignore any blind blaming of updates for causing unrelated issues (often pre-existing), like ridiculous claims I've seen that this one somehow improves network performance (among other things).
It's hard not to sadly laugh at some of the so-called "serious recommendations" (a.k.a. panic reactions) for fixing post-update problems that make absolutely no sense. Got a nosebleed? Let's amputate!
It's wise to ignore any blind blaming of updates for causing unrelated issues (often pre-existing), like ridiculous claims I've seen that this one somehow improves network performance (among other things).
It's hard not to sadly laugh at some of the so-called "serious recommendations" (a.k.a. panic reactions) for fixing post-update problems that make absolutely no sense. Got a nosebleed? Let's amputate!
No, it wasn't blind blaming. I remember a knowledgeable person stated that one very specific plug-in caused an incompatibility that caused problems with Quicktime when QT was updated to version 7. It wasn't a vague statement, I just don't remember whose plug-in caused the problems. Your amputation analogy is way off base too. Plug-ins are rarely essential and it's easy to archive them to test whether they are the cause of the problems, and unarchive when they are cleared. It should be easy to see that debugging is non-destructive.
No, it wasn't blind blaming.
I didn't at all mean to imply you meant that? sorry. My comments really weren't directed at anyone specifically. Sometimes it's hard to say much here without it being interpreted as argumentative or confrontative, then having to defend those misunderstandings. Oh well.
I remember a knowledgeable person stated that one very specific plug-in caused an incompatibility that caused problems with Quicktime when QT was updated to version 7. It wasn't a vague statement, I just don't remember whose plug-in caused the problems.
I wouldn't doubt that.
I half remember some incompatibility between QuickTime 7 and older versions of Apple's MPEG-2 component. Not everyone is aware of those kinds of dependencies when they do updates; those of us who are usually know how to adequately prepare for them.
Your amputation analogy is way off base too. Plug-ins are rarely essential and it's easy to archive them to test whether they are the cause of the problems, and unarchive when they are cleared. It should be easy to see that debugging is non-destructive.
My point with that analogy was simply that certain people without much skill in correlating symptoms with possible solutions sometimes give advice that ends up causing more problems than it cures. Based on your post history I definitely don't think that's something you'd intentionally do.