I have a 2011 MBP with this problem. I do heavy compiles regularly so I hit this problem often. The problem probably isn't any third party software (I install almost nothing besides Xcode by default) - the problem seems to be with the discrete graphics card. If you are using the integrated graphics the problem won't happen. Turning off graphics switching won't stop this problem - if you turn that off the discrete card will always be used. There is no Apple-provided way to force integrated graphics all of the time. You have to use a program like "gfxCardStatus" to force integrated graphics. I haven't hit the problem since I did that.
I think each commit is weighted by the rating of the project you commit to. So no, that probably wouldn't get you very far.
A couple commits to Firefox, the #1 rated project, is probably worth many commits to a less highly rated project. I'll let you go to their site and figure out how they rate projects.
You: "This is officer Jones of the XYZ police department in FooBar SomeState. We have a deadly chase going on, suspect has already hit and possibly killed two pedestrians. The vehicle plate # is 123XYZ. Can you disable this vehicle?
OnStar Operator: "What is the authorization code for police shutdown?"
You (even more frantic): "I don't know! You have to shut this vehicle down, people are getting hurt! More will die!"
===========
I bet the OnStar operator shuts down the vehicle against protocol. Anybody have reason to believe they wouldn't? I'm sure someone could come up with more convincing dialog too. Maybe have some other fake info in advance to sound convincing, like a badge number or cop jargon.
The Mozilla developers spend quite a bit of time on reducing memory usage and leaks. The issue is taken very seriously. All I said was that leaks exist, and that they don't indicate that Mozilla's entire codebase is sloppy. That doesn't mean Mozilla developers aren't doing anything about them or they think they are OK.
If you want to do what Mozilla does, you need something like nspr. Even apache has something similar, apr (so I hear, I have not looked at their code).
As for XULRunner and the infrastructure involved in that, it would surely be a shame if the Firefox extension system was not around. By asking why we're messing with XULRunner, you're basically also asking why we're messing with Firefox extensions in their current form, because the infrastructure for both has a lot of overlap (XUL, XPCOM, nspr...). Sure, you could make developing extensions much more difficult and thus reduce some complexity in the Mozilla codebase (though less complexity is in no way guaranteed if you want similar capabilities), but then we wouldn't have nearly as many of the great extensions we have today. And what we did have would largely be for Windows only. Furthermore, we were able to take that work and extend it a little to offer XULRunner, which has been very useful for quite a number of people. You may not want XULRunner, but that doesn't say much about the need for it. And you're not suffering much for it either if all you want is a simple web browser.
The great part is, we were able to do all of this without really bothering our users that just want a web browser. Firefox is a pretty cool piece of software that many, many people enjoy. The development of XULRunner and Firefox extensions has done more good for them than bad (through bug fixing and developer interest), and a user that loves Firefox probably isn't going to care so much about any theoretical argument that it is coded sloppily. Yeah, we've got some memory leaks once in a while, there are many things we could do better, and we don't run in 64K of RAM, but it really isn't a big deal outside of slashdot postings looking for karma, and it really isn't much worse (if at all) than other apps. The tradeoff is worth it. You just need to understand it.
I don't know where you got that idea, and I'm not going to argue with you here, but that is definitely not a given. An issue with your comment that makes me think you don't know much about standards compliance in rendering engines is that Acid2 is an almost meaningless test. It does not in any way measure overall standards compliance. It is an interesting test that has been turned into a tool for marketing these days, and it worked on you.
What you are saying about Opera is simply not true. Yes, they offer much of what we do. But they don't come anywhere near offering all that we do. Consider at XULRunner, Firefox extensions, or the fact that we have a more compliant rendering engine. About the rendering engine in particular, the first 90% of compliance is not that hard. It is the last 10% that adds the majority of the complexity. Opera has not gone as far (far as they may be) in terms of compliance and the complexity tradeoff is absolutely not linear.
So, if you want what Opera has to offer and only that, then use Opera. But don't bash Mozilla's codebase because we don't offer the same feature set that Opera does and therefore a bunch of our code is needlessly complex.
"It appears that the Mozilla project has overcomplicated them, for whatever reason."
I think if you put even 5 minutes into thinking about "whatever reason," you'd not be saying that. Again, I'll use XULRunner and Firefox Extensions as examples of things that Opera does not do and will never do in its current form because they lack the (complex!) infrastructure that allows for such capabilities.
It is easy to bash code and get a good response from people - a large part of slashdot is just that. It is much harder to defend code, and that is something I just can't do for the Mozilla project in the time I have allotted for myself to post on slashdot. All I can say is if you want to know how good/bad the Mozilla code is, give it a lot more thought time or ask someone who would actually know. You could start with Mozilla developers. We're not all so biased and blinded as to blatantly lie about the quality of the Mozilla code.
I work with the Mozilla code every day. It is complicated, yes, but that doesn't necessarily mean it is all badly written. I think you probably don't understand the reason for the complexity, and therefore you incorrectly consider it to be terrible code.
I'm not saying we don't have some bad code in there, but to say what you are saying about the entire codebase is very naive.
Apple does provide Java plugins with their OS. However, the NSAPI (Netscape Plugin API) Java plugin that they bundle only does Java 1.3.1 and it has been fairly problematic for us. Maintaining it does not seem to be a priority for them - instead they are focusing on their newer Java plugin which uses a different Mac OS X-specific plugin API (which we don't support right now).
Luckily for us, Steven Michaud has created JEP, which we use for Java support in our Mac OS X products. See here for more details: http://javaplugin.sourceforge.net/
Firefox has never used the Cocoa APIs (in official builds). It is all Carbon. We do plan to use Cocoa for some things in Firefox 3.0, but I don't think it will have any negative impact on performance. -Josh Aas
Firefox under Rosetta performs fairly well (the first launch in a session may take a while if Rosetta needs to load). You shouldn't see anything stuttering. -Josh Aas
Had Apple released their hardware closer to when they said they were going to, we would probably have been ready immediately. That was the plan:)
That said, I'm happy to get off the Intel developer kit and onto production equipment and a solid OS release a few months early.
-Josh Aas
"The technology Titor uses to travel through time is based on the truth of the many-worlds interpretation of quantum mechanics. If this is later proven to be a flawed theory, his other claims can be assumed to be false."
Seriously, if someone asked me to do that, I'd be on the phone with IBM and Novell immediately. I can almost guarantee you they'd be more than happy to help and your job would be safe. Don't try to do this yourself...
I think you'll be pleasantly surprised by the next major version of Firefox, due around the end of the summer. Yeah, nobody likes to hear that "the next version" will fix their problems, but what else can I say... It's no secret that Firefox on the Mac was neglected, but concrete steps have been taken to rectify the situation (including Mozilla Foundation hiring me as their full-time Mac developer). As a result of Mozilla's renewed commitment to the Mac, the Mac Mozilla developer community has been revitalized and is doing some great work. If you want something now, go get a Firefox nightly build for Mac OS X. They are leaps and bounds better than Firefox 1.0.x releases for Mac OS X. Some very general hilights:
- major UI cleanup, more Mac-like than ever
- much better performance with plugins and other cpu-intensive tasks
- more OS-integration features like desktop image support, default browser, etc...
- more and more complete profile migrators from other browsers
- many miscellaneous Mac OS X-specific bug fixes
Unlike the situation 6 months ago, we now have actual work being done to solve bigger long-term issues as well. Some examples are native-looking widgets (like Camino has) and Intel-based Mac support. These are not empty words either - Firefox can actually build and run with native-looking widgets now, and it already runs on Intel Macs. We're also doing work to make the Mac infrastructure more maintainable in the future.
So we are getting better quickly - we hope you give us another chance!
No. It won't make it into 10.4 ever. Apple simply couldn't make it work in time. You can enable it with the Quartz Debug developer tool, but be warned - they disabled it for a reason.
"Reading between the lines, I think the issue is actually that Firefox.app isn't, apparently, compiled within Apple's Xcode framework, instead being built using the same Makefiles etc as a Unix app."
Yup.
"That kind of modification isn't trivial. It's not a matter of just grepping for any gcc line with -mpowerpc (or whatever)"
Arch detection in the build system, endian issues in mac specific code, plugin binary loading, xptcall stack alignment, 10.4u SDK differences - that is most of it though.
I know its not a final release, but you should try the latest Firefox Mac OS X nightly build from ftp.mozilla.org
I landed a patch yesterday that significantly speeds things up (we now use use CFRunLoop instead of Carbon Events, in case you can understand that). Huge difference, especially with plugins. It'll be in Firefox 1.1. This one patch makes a huge difference.
Comparing Carbon and Cocoa is like comparing apples and oranges for most purposes. They are both nice and useful but usually for very different things. From a theoretical standpoint you might be able to say that the Cocoa API is better designed than the Carbon API, but in real life you normally need to use one or the other for certain tasks and the decision doesn't come down to which API is "better." Cocoa's problem: you can only use it with Objective-C and Java. If you're using straight C++ or C, you need Carbon and that is that. Also, some system services are exposed in only one of the two APIs.
"I think you are right about the staff, although I never expect the staff at a retail outlet to know much. They aren't getting paid enough to be domain experts."
One of the reasons Apple's stores do so well is that their staff are much more informed about the technology they sell than your average retail employee. Obviously there are exceptions, but I think what I'm saying is true for the most part. Staff expertise is a Big Deal and Sony should not ignore it.
Slashdot Mirror
Obviously this won't work for people who need high-end graphics, but for people like me who don't it should be a solid temporary workaround.
I have a 2011 MBP with this problem. I do heavy compiles regularly so I hit this problem often. The problem probably isn't any third party software (I install almost nothing besides Xcode by default) - the problem seems to be with the discrete graphics card. If you are using the integrated graphics the problem won't happen. Turning off graphics switching won't stop this problem - if you turn that off the discrete card will always be used. There is no Apple-provided way to force integrated graphics all of the time. You have to use a program like "gfxCardStatus" to force integrated graphics. I haven't hit the problem since I did that.
I think each commit is weighted by the rating of the project you commit to. So no, that probably wouldn't get you very far.
A couple commits to Firefox, the #1 rated project, is probably worth many commits to a less highly rated project. I'll let you go to their site and figure out how they rate projects.
Call up OnStar from a pay phone, sound frantic:
You: "This is officer Jones of the XYZ police department in FooBar SomeState. We have a deadly chase going on, suspect has already hit and possibly killed two pedestrians. The vehicle plate # is 123XYZ. Can you disable this vehicle?
OnStar Operator: "What is the authorization code for police shutdown?"
You (even more frantic): "I don't know! You have to shut this vehicle down, people are getting hurt! More will die!"
===========
I bet the OnStar operator shuts down the vehicle against protocol. Anybody have reason to believe they wouldn't? I'm sure someone could come up with more convincing dialog too. Maybe have some other fake info in advance to sound convincing, like a badge number or cop jargon.
Is London's economy really "clean" or did they just farm out the dirty work? Is the environmental hit just being taken in another part of the world?
"Last year, researchers announced they had successfully lured and trapped the toads using ultraviolet lights like those used in disco clubs."
If they're going to take over, lets not give them any ideas.
The Mozilla developers spend quite a bit of time on reducing memory usage and leaks. The issue is taken very seriously. All I said was that leaks exist, and that they don't indicate that Mozilla's entire codebase is sloppy. That doesn't mean Mozilla developers aren't doing anything about them or they think they are OK.
CyricZ, please stop trying to get attention by being dramatic and twisting words. Your criticism is not contructive, just uninformed and inflamatory.
P.S. Re: "the attitude of the Firefox developers" - I am only one Firefox developer. I am not speaking for any other devs.
Heh - that would be one of the *bad* parts :)
We are in the process of replacing MORK with SQLite.
If you want to do what Mozilla does, you need something like nspr. Even apache has something similar, apr (so I hear, I have not looked at their code).
As for XULRunner and the infrastructure involved in that, it would surely be a shame if the Firefox extension system was not around. By asking why we're messing with XULRunner, you're basically also asking why we're messing with Firefox extensions in their current form, because the infrastructure for both has a lot of overlap (XUL, XPCOM, nspr...). Sure, you could make developing extensions much more difficult and thus reduce some complexity in the Mozilla codebase (though less complexity is in no way guaranteed if you want similar capabilities), but then we wouldn't have nearly as many of the great extensions we have today. And what we did have would largely be for Windows only. Furthermore, we were able to take that work and extend it a little to offer XULRunner, which has been very useful for quite a number of people. You may not want XULRunner, but that doesn't say much about the need for it. And you're not suffering much for it either if all you want is a simple web browser.
The great part is, we were able to do all of this without really bothering our users that just want a web browser. Firefox is a pretty cool piece of software that many, many people enjoy. The development of XULRunner and Firefox extensions has done more good for them than bad (through bug fixing and developer interest), and a user that loves Firefox probably isn't going to care so much about any theoretical argument that it is coded sloppily. Yeah, we've got some memory leaks once in a while, there are many things we could do better, and we don't run in 64K of RAM, but it really isn't a big deal outside of slashdot postings looking for karma, and it really isn't much worse (if at all) than other apps. The tradeoff is worth it. You just need to understand it.
I don't know where you got that idea, and I'm not going to argue with you here, but that is definitely not a given. An issue with your comment that makes me think you don't know much about standards compliance in rendering engines is that Acid2 is an almost meaningless test. It does not in any way measure overall standards compliance. It is an interesting test that has been turned into a tool for marketing these days, and it worked on you.
What you are saying about Opera is simply not true. Yes, they offer much of what we do. But they don't come anywhere near offering all that we do. Consider at XULRunner, Firefox extensions, or the fact that we have a more compliant rendering engine. About the rendering engine in particular, the first 90% of compliance is not that hard. It is the last 10% that adds the majority of the complexity. Opera has not gone as far (far as they may be) in terms of compliance and the complexity tradeoff is absolutely not linear.
So, if you want what Opera has to offer and only that, then use Opera. But don't bash Mozilla's codebase because we don't offer the same feature set that Opera does and therefore a bunch of our code is needlessly complex.
"It appears that the Mozilla project has overcomplicated them, for whatever reason."
I think if you put even 5 minutes into thinking about "whatever reason," you'd not be saying that. Again, I'll use XULRunner and Firefox Extensions as examples of things that Opera does not do and will never do in its current form because they lack the (complex!) infrastructure that allows for such capabilities.
It is easy to bash code and get a good response from people - a large part of slashdot is just that. It is much harder to defend code, and that is something I just can't do for the Mozilla project in the time I have allotted for myself to post on slashdot. All I can say is if you want to know how good/bad the Mozilla code is, give it a lot more thought time or ask someone who would actually know. You could start with Mozilla developers. We're not all so biased and blinded as to blatantly lie about the quality of the Mozilla code.
I work with the Mozilla code every day. It is complicated, yes, but that doesn't necessarily mean it is all badly written. I think you probably don't understand the reason for the complexity, and therefore you incorrectly consider it to be terrible code. I'm not saying we don't have some bad code in there, but to say what you are saying about the entire codebase is very naive.
Apple does provide Java plugins with their OS. However, the NSAPI (Netscape Plugin API) Java plugin that they bundle only does Java 1.3.1 and it has been fairly problematic for us. Maintaining it does not seem to be a priority for them - instead they are focusing on their newer Java plugin which uses a different Mac OS X-specific plugin API (which we don't support right now).
Luckily for us, Steven Michaud has created JEP, which we use for Java support in our Mac OS X products. See here for more details:
http://javaplugin.sourceforge.net/
-Josh Aas
Firefox has never used the Cocoa APIs (in official builds). It is all Carbon. We do plan to use Cocoa for some things in Firefox 3.0, but I don't think it will have any negative impact on performance. -Josh Aas
Firefox under Rosetta performs fairly well (the first launch in a session may take a while if Rosetta needs to load). You shouldn't see anything stuttering. -Josh Aas
Had Apple released their hardware closer to when they said they were going to, we would probably have been ready immediately. That was the plan :)
That said, I'm happy to get off the Intel developer kit and onto production equipment and a solid OS release a few months early.
-Josh Aas
According to wikipedia...
"The technology Titor uses to travel through time is based on the truth of the many-worlds interpretation of quantum mechanics. If this is later proven to be a flawed theory, his other claims can be assumed to be false."
Looks like Titor is a hoax after all...
Seriously, if someone asked me to do that, I'd be on the phone with IBM and Novell immediately. I can almost guarantee you they'd be more than happy to help and your job would be safe. Don't try to do this yourself...
I think you'll be pleasantly surprised by the next major version of Firefox, due around the end of the summer. Yeah, nobody likes to hear that "the next version" will fix their problems, but what else can I say... It's no secret that Firefox on the Mac was neglected, but concrete steps have been taken to rectify the situation (including Mozilla Foundation hiring me as their full-time Mac developer). As a result of Mozilla's renewed commitment to the Mac, the Mac Mozilla developer community has been revitalized and is doing some great work. If you want something now, go get a Firefox nightly build for Mac OS X. They are leaps and bounds better than Firefox 1.0.x releases for Mac OS X. Some very general hilights:
- major UI cleanup, more Mac-like than ever
- much better performance with plugins and other cpu-intensive tasks
- more OS-integration features like desktop image support, default browser, etc...
- more and more complete profile migrators from other browsers
- many miscellaneous Mac OS X-specific bug fixes
Unlike the situation 6 months ago, we now have actual work being done to solve bigger long-term issues as well. Some examples are native-looking widgets (like Camino has) and Intel-based Mac support. These are not empty words either - Firefox can actually build and run with native-looking widgets now, and it already runs on Intel Macs. We're also doing work to make the Mac infrastructure more maintainable in the future.
So we are getting better quickly - we hope you give us another chance!
-Josh Aas
Mozilla Foundation Mac Developer
No. It won't make it into 10.4 ever. Apple simply couldn't make it work in time. You can enable it with the Quartz Debug developer tool, but be warned - they disabled it for a reason.
"Reading between the lines, I think the issue is actually that Firefox.app isn't, apparently, compiled within Apple's Xcode framework, instead being built using the same Makefiles etc as a Unix app."
Yup.
"That kind of modification isn't trivial. It's not a matter of just grepping for any gcc line with -mpowerpc (or whatever)"
Arch detection in the build system, endian issues in mac specific code, plugin binary loading, xptcall stack alignment, 10.4u SDK differences - that is most of it though.
-Josh Aas
I know its not a final release, but you should try the latest Firefox Mac OS X nightly build from ftp.mozilla.org
I landed a patch yesterday that significantly speeds things up (we now use use CFRunLoop instead of Carbon Events, in case you can understand that). Huge difference, especially with plugins. It'll be in Firefox 1.1. This one patch makes a huge difference.
-Josh Aas, Mozilla Foundation Mac developer
Comparing Carbon and Cocoa is like comparing apples and oranges for most purposes. They are both nice and useful but usually for very different things. From a theoretical standpoint you might be able to say that the Cocoa API is better designed than the Carbon API, but in real life you normally need to use one or the other for certain tasks and the decision doesn't come down to which API is "better." Cocoa's problem: you can only use it with Objective-C and Java. If you're using straight C++ or C, you need Carbon and that is that. Also, some system services are exposed in only one of the two APIs.
"I think you are right about the staff, although I never expect the staff at a retail outlet to know much. They aren't getting paid enough to be domain experts." One of the reasons Apple's stores do so well is that their staff are much more informed about the technology they sell than your average retail employee. Obviously there are exceptions, but I think what I'm saying is true for the most part. Staff expertise is a Big Deal and Sony should not ignore it.
The patch for your #1 issue was checked in about an hour ago by Pinkerton.