First off, I apologize for the lack of clarity regarding the word "toolkit". There are a few things under this name, part of which is the source code directory called "toolkit". This code provides implementations for things like text boxes, tabbed objects, etc. in XBL. This code was copied from XPFE (cross platform front end) code to give Firefox its own copy with more freedom, and was subsequently modified (sometimes heavily). This is the problematic code.
Right now, some people are working on something called "XULRunner" - basically an environment that launches XUL applications and offers a toolkit ("toolkit" directory in the source code). The problem is that this toolkit isn't stable; for example, Ben Goodger modified a bunch of its components without any review for his rewrite of the Firefox options window. Had Mozilla been depending on it, we would now be scrambling to fix whatever would have been broken.
I understand what you're saying about GRE & XPCOM, but they're not the same as this "toolkit";-). GRE/XPCOM are good (and AFAIK, pretty stable, with a decent number of frozen APIs).
Many of your changes could wind up in firefox anyway... No, they CAN'T! Firefox people are very strict about not adding things for transitioning Mozilla users - for example, they rejected a patch I wrote that allows ctrl and alt to be un-reversed based on a hidden preference (basically, ctrl+enter and alt+enter are backwards in Firefox - an unnecessary annoyance). There are many other things they don't accept - my definition of "better" is just not the same as theirs.
If a developer only wishes to develop for the moz suite but no on is there to use it, are you making a difference? So what, am I wasting my time working on Mozilla? No, it's a hobby which happens to benefit me (since I get a better browser). Besides, there is a difference between not having 25 million users and not having ANY users. If a Mozilla 1.8 is released, I'm sure there will still be many thousands of downloads.
If you abandon mozilla for dropping the suite you were never a true open source developer to begin with. I liked Mozilla, but wanted it to do something it didn't support (play a sound when a download finishes). I found this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=16498 and with a lot of help from existing developers, fixed it. As time went on, I found other things I didn't like, and worked on them. Since then, I've fixed quite a few bugs: https://bugzilla.mozilla.org/buglist.cgi?query_for mat=advanced&emailassigned_to1=1&emailtype1=exact& email1=cst%40andrew.cmu.edu&chfieldto=Now
Does the fact that I do this work for free, in my free time make me a "fake" open source developer? Am I supposed to continue to contribute if the project moves in a direction I don't like? If that's what's required to fit someone's definition of "true open source developer", then fine, I'm not one.
It really boils down to this: I don't like the same things Firefox devs like, and as such, making Firefox "better" in my opinion would require that I fork it. Instead, I choose to contribute to Mozilla, whose developers I see eye-to-eye with much better. Unlike a personal Firefox fork, Mozilla at least has some users.
This is different from users complaining about the discontinuation of a product - in this case, a large portion of the Suite fans are its developers. Unlike Firefox, which has lots of users and not enough developers, Suite has many interested developers. It's some of these developers who are worried about losing the browser (and mail app) they love.
There are a couple issues here: 1. It isn't completely certain yet that the suite will be killed. Interested developers are making sure the Foundation knows they don't want it to die. 2. If the Foundation does decide to kill the suite, the developers DON'T want 50 forks, all different (at least, that's the impression I get). In order to avoid this, they're trying to figure out how to organize themselves, and who is available to do what sorts of work.
Right now, we're seeing Firefox fanboys flaming the developers who like Mozilla, and the Mozilla devs trying to figure out what's going to happen, and planning for the worst.
The issue here is that the Foundation organizes releases, and deals with marketing. It seems that they only have resources to organize releases for one product, and don't want to send conflicting marketing messages with 2 products. The Foundation appears to be picking the aviary products (Firefox, Thunderbird) over Mozilla (which makes sense, given userbase numbers).
Many developers strongly prefer the suite - not all are interested in contributing to Firefox. If the Mozilla Foundation wants to kill off the suite, they risk losing many developer resources. As recent/. stories point out, Firefox ALREADY lacks a strong developer community.
Giving the suite "back to the community" isn't as easy as it sounds. We don't want 50 forks of the suite, each with no users - many of the suite developers are interested in sticking together, so we're trying to figure out how to have just ONE suite version in case the Foundation decides it's time to kill the product. Having one version of the suite is the best way to keep it alive for as long as possible.
It's trickier than that. A lot of developers like the suite much more than Firefox. Some core devs have suggested they might stop working on Gecko if the suite dies. The Mozilla suite is basically in the opposite situation of Firefox: Firefox has LOTS of users and apparently way too few developers; Mozilla has LOTS of developers and not as many users. Killing the suite doesn't mean all of those developers would jump ship to Firefox. I personally don't like Firefox, so I write code for Mozilla. If it comes down to "Firefox or else", there's a good chance I'd find something else to do with my time.
It's not that the Mozilla Foundation is evil - there are a few issues here. First, they aren't saying much. Pretty much everything we hear is coming from only Asa Dotzler, not official statements by MoFo. Second, the Mozilla Foundation does have limited resources - the points people are making about two products being difficult are valid. Marketing is another big issue. It would be in the Mozilla Foundation's best interest to present ONE front: the aviary products (Firefox, Thunderbird).
I don't think NIH is the big problem - the problem is that while Firefox could have been just the browser portion of the suite, it isn't. It looks and feels different. The people who like the suite like the look and feel of it. Switching to Firefox means giving up a mature, stable, familiar user interface for something different that changes a lot with every 0.1 release (for example, Firefox 1.1 will have a completely rewritten preferences panel).
One of the major concerns right now of developers interested in SeaMonkey is the development process currently used for the aviary products: gigantic patches are included without any review, and often with very little testing. Regressions are found by users, and they file bugs which get fixed. However, the lack of review still allows much lower-quality code to enter the source. Between the landing of the patch and fixing of regressions, nightly builds (which developers work from) are often in very bad (unusable) shape.
The SeaMonkey front-end currently requires not one, but TWO reviews of all code. Does this slow the pace of development? Yes. It's extremely difficult to thoroughly review the bigger patches (doubling a patch length probably quadruples the work), but it maintains high code quality, and minimizes the introduction of new bugs. It helps that the SeaMonkey front-end is already mature, because less development needs to happen.
In theory, the Mozilla project was supposed to offer a cross-platform application development toolkit. This toolkit would be maintained, and an application written for it should work properly on future versions of the toolkit. This would offer a way to easily save Mozilla: port it over to this toolkit (which is just a modified version of what it uses right now, minus thorough code review). However, there is doubt among the developers that the Mozilla Foundation will actually keep this toolkit in usable shape - the track record of Firefox developers has been "change what we want when we want to", which would mean any application using this toolkit would need frequent updates. Porting the suite to a toolkit like this would mean we get all of the downsides (less code review), plus extra maintenance work required.
Basically, I think most of the suite developers just want their favorite browser not to die, and not to be based on shoddy code.
While Firefox has millions of users, and a dire shortage of developers and reviewers, the Suite is in a nearly opposite situation: plenty of interested developers, but relatively few users. In fact, the development community is so strong and interested in Suite that they're starting a project to "save seamonkey" (some info here). Some core developers have even hinted that they might stop working on Gecko if the Mozilla Suite is killed off.
Here you can see pageload times for Mozilla over the past 2 years (you can change the number of days shown). There are more machines running the tests: Luna Monkey Creature
Note the dramatic improvements on btek and luna (linux)... the others improve as well.
It's worth noting that various research papers have done analysis to determine the optimum level of pipelining, and found about 6 to 8 FO-4 gate delays* per stage is optimal - Intel's cancelled Tejas processor was apparently around there and would likely have run at similar clock speeds to the Cell processor. Note that in the real world, you hit other limitations earlier - right now, the main issue is power: chips that fast just run too hot.
*a FO-4 gate delay is a "fan-out of 4 gate delay" - it's the amount of delay from one inverter (NOT gate) which drives 4 identical inverters as load.
People seem to think this is leaps and bounds above everything else, but they're missing the details. In order to obtain that much performance, you'll need a task which parallelizes well so it can be broken up into chunks for the 8 SPEs. Graphics rendering falls into this set of tasks, but a lot of general applications just don't gain that much from parallel processors. Even when you have a task that does parallelize, writing parallel code is quite a bit harder than writing code for just a single thread of execution.
I've seen a lot of hype about having the Cell in your laptop talk to the Cells in your desktop, microwave, and TiVo, but you have to consider real-world limitations. When you set up a network like that (presumably wireless), you're going to be limited to around 100Mbps. In computer clusters and supercomputers, one of the main limitations of performance is the communcation bandwidth available between processors, and the latency of the network. To build a "home supercomputer", you not only need a task that parallelizes well, but one that doesn't require so much inter-node communication that it's held back by a slow network. You can't work around this problem with hardware magic - if the task you're working on requires lots of communication bandwidth, you're going to be held back.
So how much beyond a modern PC is 250GFLOPS anyway? Not much! A GeForce FX at 500MHz does 200 gigaflops. An AMD Athlon's peak performance is 2.4 GFLOPS at 600 MHz... if we scale this up to 2.2 GHz (high-end Athlon), that's 8.8GFLOPS (note: As we're talking about theoretical performance, nonlinear factors like bus speeds can be ignored). Basically, if the Cell dedicates most of its power to graphics rendering, you'll have computation power in the same range as a fast PC of today. Given that we're not going to see any products based on the Cell for a while, this isn't going to be the end of the world for Intel and nVidia (let alone the fact that Cell isn't x86).
Consoles using the Cell will have the advantage of only having to render for TV resolutions - at most 1080 lines, while PCs will be rendering at up to 1600x1200, but if you look at recent history, you can compare the xbox to a then-good PC with a GeForce3 (which came out at around the same time) - the xbox looked better, but PCs did catch up and surpass it's performance and it didn't take all that long. Consoles have to be very high-end when they're released, because the platform doesn't change for 2-3 years, and they still need to be "good enough" after a couple years, before the next generation is released.
Re:Why not dump Mozilla for Firefox?
on
Mozilla Roadmap Update
·
· Score: 2, Informative
I don't think you have a clue what you're talking about. If this is enough for me to claim I'm a developer (or even if it doesn't... I don't really care what trolls think of me).....
Here's a list of the source directories for Mozilla & Firefox:
Of those, only browser and toolkit are exclusive to Firefox, and most of the code in xpfe is exclusive to Mozilla. Pretty much everything else is shared. There are not different "development teams". Developers working on the core (rendering, networking, the image libraries, etc) are working on both products, since those parts are shared. Other people work on the Firefox frontend mostly, or the Mozilla frontend mostly, or both.
Development is active in both products. It just happens that the Mozilla front end is very mature and stable, so it doesn't change as rapidly. That doesn't mean features aren't being added - I've added a few little things (some of which happen to be in Firefox, some of which aren't), and I'm not the only one working on it.
There are two kinds of fool: one who says, "It is old, and therefore good", and the other, who says "It is new, and therefore better".
Bugzilla blocks referrers from slashdot, so for your copy/paste convenience, the link above is pointing to https://bugzilla.mozilla.org/buglist.cgi?query_for mat=advanced&emailassigned_to1=1&emailtype1=exact& email1=cst%40andrew.cmu.edu&chfieldto=Now
I'm curious as to how many people still use Mozilla, anyway. Unfortunately, not a huge number - that's a part of why there have been 6 alphas for 1.8 - not enough users are testing it. However, a lot of developers have a strong preference for the suite, so they'll continue working on it for a long time to come. There's some work going on to merge more code between Mozilla and Firefox in order to reduce the effort required to maintain both.
It would also be nice if they turned on browser.xul.error_pages.enabled by default and cleaned up the error pages to look a little more professional. I'd offer to supply templates, if I knew who to approach and whether anyone would be remotely interested. The reason they aren't enabled by default is that they have horrendous usability issues - for example, if you open a link in a new window/tab and it doesn't load successfully, your URL bar will read:
chrome://global/content/netError.xhtml?e=dnsNotF ou nd&u=http%3A//www.fakesitehere.com/&d=www.fakesite here.com%20could%20not%20be%20found.%20Please%20ch eck%20the%20name%20and%20try%20again.
I typed "www.fakesitehere.com"
You can't easily fix your typo. There are also issues with the "Try Again" link and hitting reload. Form POST data is also not properly handled. Error pages cause issues with browser history. There are many bugs filed about these various issues, and making the pages prettier is the least of anybody's concerns right now.
Bug 28586 is the tracking bug for core issues: https://bugzilla.mozilla.org/show_bug.cgi?id=28586
Buf 216466 is the tracking bug for firefox issues.
It doesn't matter whether the HTML is garbage - it should render the same way every time you load it. However, there is a class of bugs in the gecko engine called "reflow" bugs, which only show up in certain situations, based on the timing of various events during page load, which sometimes cause the page to render differently.
This *IS* a bug in Mozilla/Firefox, and it *HAS* been fixed for a long time (since before Firefox 1.0 was released) but the fix was not included in FF1.0 because it broke other things.
For many reflow bugs, you can construct valid HTML that exposes it just as well as garbage "HTML".
It doesn't matter whether the HTML is garbage - it should render the same way every time you load it. However, there is a class of bugs in the gecko engine called "reflow" bugs, which only show up in certain situations, based on the timing of various events during page load, which sometimes cause the page to render differently.
This *IS* a bug in Mozilla/Firefox, and it *HAS* been fixed for a long time (since before Firefox 1.0 was released) but the fix was not included in FF1.0 because it broke other things.
For many reflow bugs, you can construct valid HTML that exposes it just as well as garbage "HTML".
Why was most of the Firefox work done on a branch and then "crash landed" on the trunk? Some of the bugs resulting from this crash are yet to be fixed. Why make things so complicated? If the main development had happened on the trunk and the releases had been branched off of that this process would have been a lot easier to manage in my view. Almost all other open-spurce projects do it like that. The idea of a branch is to get a stable set of features and bugs. If development took place on trunk, then as gecko bugs were introduced, things would break. By using a branch, nothing new breaks, and you can fix any bugs you do encounter. By the time you release the product, the bugs have hopefully been found and ironed out.
What about the closing of the source tree for releases? For a while I was wondering why so few checkins got made despite the pending release of Firefox 1.1 in March but then I realized that the tree was closed for a Mozilla release instead. The branches always close near a release. The policy on a closed tree is that any checkins require approval - the kinds of things that get approved are critical things that need to make it for the release. The branch shouldn't close until very few outstanding bugs remain anyway. You definitely don't want to be adding new features right before a release, because you risk adding bugs.
When I read the projects roadmap I had hoped it would get split up in distinct pieces like Gecko, Toolkit, Firefox-UI, etc. which could be developed individually instead of in one X11-like monolithic blob that requires a global closing/opening process. It's not a global closing/opening. A branch at a time closes - development continues on trunk (well, there are brief closures of trunk for alphas, but they're short).
Gecko for example could be shared by Firefox, Thunderbird, etc. and have independent releases that the other bits could rely on just like QT or GTK applications rely on respective releases of these toolkits. A Gecko 1.8 release could be branched off of the trunk and developers could just continue to check in new and potentially dangerous code on the trunk despite any impending release of higher-level components. These would simply rely on the last stable release of the lower-level ones. But then you have to wait for a gecko release before you can release another product (meaning first you iron out all of the bugs from gecko, then you start working on your product). Right now, you just take a snapshot at some reasonably stable point and develop a release from that. Note that Firefox 1.0 WAS built on a "gecko release" - the Mozilla 1.7 gecko. That isn't the usual move though - at least for Seamonkey. Seamonkey releases define gecko releases.
You can download ZIPs of firefox releases (and nightly builds) with no installer. The installer just registers it as the default web browser, and creates shortcuts. It runs just fine without installation.
P.S.: your "Firefox" code still unpacks itself in a directory named "mozilla". Not "mozilla-1.7" or "firefox-1.0" either... just plain "mozilla". It looks like a CVS snapshot to me. It is a CVS snapshot. It unpacks to "mozilla" because the cvsroot for both Mozilla and Firefox is shared - Firefox is the mozilla source plus the browser/ and toolkit/ directories. The rest is shared.
He could be the lead architect of the Pentium 4 for all I care - CPUs with precise interrupts (every one I can think of) execute programs as if they were in-order, unpipelined processors.
The Tomasulo design, originally in an old IBM floating point unit, did not support precise interrupts, but modern designs use reorder buffers (the queues I described) to add that support. If the CPUs did not act this way, debugging even non-optimized software would be extraordinarily difficult (since you wouldn't know which instructions were partially complete), and when there were exceptions or interrupts, the CPU would have to keep track of a LOT of internal state in order to resume execution.
Slashdot Mirror
First off, I apologize for the lack of clarity regarding the word "toolkit". There are a few things under this name, part of which is the source code directory called "toolkit". This code provides implementations for things like text boxes, tabbed objects, etc. in XBL. This code was copied from XPFE (cross platform front end) code to give Firefox its own copy with more freedom, and was subsequently modified (sometimes heavily). This is the problematic code.
;-). GRE/XPCOM are good (and AFAIK, pretty stable, with a decent number of frozen APIs).
Right now, some people are working on something called "XULRunner" - basically an environment that launches XUL applications and offers a toolkit ("toolkit" directory in the source code). The problem is that this toolkit isn't stable; for example, Ben Goodger modified a bunch of its components without any review for his rewrite of the Firefox options window. Had Mozilla been depending on it, we would now be scrambling to fix whatever would have been broken.
I understand what you're saying about GRE & XPCOM, but they're not the same as this "toolkit"
Many of your changes could wind up in firefox anyway...
8 and with a lot of help from existing developers, fixed it. As time went on, I found other things I didn't like, and worked on them. Since then, I've fixed quite a few bugs: https://bugzilla.mozilla.org/buglist.cgi?query_for mat=advanced&emailassigned_to1=1&emailtype1=exact& email1=cst%40andrew.cmu.edu&chfieldto=Now
No, they CAN'T! Firefox people are very strict about not adding things for transitioning Mozilla users - for example, they rejected a patch I wrote that allows ctrl and alt to be un-reversed based on a hidden preference (basically, ctrl+enter and alt+enter are backwards in Firefox - an unnecessary annoyance). There are many other things they don't accept - my definition of "better" is just not the same as theirs.
If a developer only wishes to develop for the moz suite but no on is there to use it, are you making a difference?
So what, am I wasting my time working on Mozilla? No, it's a hobby which happens to benefit me (since I get a better browser). Besides, there is a difference between not having 25 million users and not having ANY users. If a Mozilla 1.8 is released, I'm sure there will still be many thousands of downloads.
If you abandon mozilla for dropping the suite you were never a true open source developer to begin with.
I liked Mozilla, but wanted it to do something it didn't support (play a sound when a download finishes). I found this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1649
Does the fact that I do this work for free, in my free time make me a "fake" open source developer? Am I supposed to continue to contribute if the project moves in a direction I don't like? If that's what's required to fit someone's definition of "true open source developer", then fine, I'm not one.
It really boils down to this: I don't like the same things Firefox devs like, and as such, making Firefox "better" in my opinion would require that I fork it. Instead, I choose to contribute to Mozilla, whose developers I see eye-to-eye with much better. Unlike a personal Firefox fork, Mozilla at least has some users.
This is different from users complaining about the discontinuation of a product - in this case, a large portion of the Suite fans are its developers. Unlike Firefox, which has lots of users and not enough developers, Suite has many interested developers. It's some of these developers who are worried about losing the browser (and mail app) they love.
There are a couple issues here:
1. It isn't completely certain yet that the suite will be killed. Interested developers are making sure the Foundation knows they don't want it to die.
2. If the Foundation does decide to kill the suite, the developers DON'T want 50 forks, all different (at least, that's the impression I get). In order to avoid this, they're trying to figure out how to organize themselves, and who is available to do what sorts of work.
Right now, we're seeing Firefox fanboys flaming the developers who like Mozilla, and the Mozilla devs trying to figure out what's going to happen, and planning for the worst.
The issue here is that the Foundation organizes releases, and deals with marketing. It seems that they only have resources to organize releases for one product, and don't want to send conflicting marketing messages with 2 products. The Foundation appears to be picking the aviary products (Firefox, Thunderbird) over Mozilla (which makes sense, given userbase numbers).
/. stories point out, Firefox ALREADY lacks a strong developer community.
Many developers strongly prefer the suite - not all are interested in contributing to Firefox. If the Mozilla Foundation wants to kill off the suite, they risk losing many developer resources. As recent
Giving the suite "back to the community" isn't as easy as it sounds. We don't want 50 forks of the suite, each with no users - many of the suite developers are interested in sticking together, so we're trying to figure out how to have just ONE suite version in case the Foundation decides it's time to kill the product. Having one version of the suite is the best way to keep it alive for as long as possible.
It's trickier than that. A lot of developers like the suite much more than Firefox. Some core devs have suggested they might stop working on Gecko if the suite dies. The Mozilla suite is basically in the opposite situation of Firefox: Firefox has LOTS of users and apparently way too few developers; Mozilla has LOTS of developers and not as many users. Killing the suite doesn't mean all of those developers would jump ship to Firefox. I personally don't like Firefox, so I write code for Mozilla. If it comes down to "Firefox or else", there's a good chance I'd find something else to do with my time.
It's not that the Mozilla Foundation is evil - there are a few issues here. First, they aren't saying much. Pretty much everything we hear is coming from only Asa Dotzler, not official statements by MoFo. Second, the Mozilla Foundation does have limited resources - the points people are making about two products being difficult are valid. Marketing is another big issue. It would be in the Mozilla Foundation's best interest to present ONE front: the aviary products (Firefox, Thunderbird).
I don't think NIH is the big problem - the problem is that while Firefox could have been just the browser portion of the suite, it isn't. It looks and feels different. The people who like the suite like the look and feel of it. Switching to Firefox means giving up a mature, stable, familiar user interface for something different that changes a lot with every 0.1 release (for example, Firefox 1.1 will have a completely rewritten preferences panel).
One of the major concerns right now of developers interested in SeaMonkey is the development process currently used for the aviary products: gigantic patches are included without any review, and often with very little testing. Regressions are found by users, and they file bugs which get fixed. However, the lack of review still allows much lower-quality code to enter the source. Between the landing of the patch and fixing of regressions, nightly builds (which developers work from) are often in very bad (unusable) shape.
The SeaMonkey front-end currently requires not one, but TWO reviews of all code. Does this slow the pace of development? Yes. It's extremely difficult to thoroughly review the bigger patches (doubling a patch length probably quadruples the work), but it maintains high code quality, and minimizes the introduction of new bugs. It helps that the SeaMonkey front-end is already mature, because less development needs to happen.
In theory, the Mozilla project was supposed to offer a cross-platform application development toolkit. This toolkit would be maintained, and an application written for it should work properly on future versions of the toolkit. This would offer a way to easily save Mozilla: port it over to this toolkit (which is just a modified version of what it uses right now, minus thorough code review). However, there is doubt among the developers that the Mozilla Foundation will actually keep this toolkit in usable shape - the track record of Firefox developers has been "change what we want when we want to", which would mean any application using this toolkit would need frequent updates. Porting the suite to a toolkit like this would mean we get all of the downsides (less code review), plus extra maintenance work required.
Basically, I think most of the suite developers just want their favorite browser not to die, and not to be based on shoddy code.
While Firefox has millions of users, and a dire shortage of developers and reviewers, the Suite is in a nearly opposite situation: plenty of interested developers, but relatively few users. In fact, the development community is so strong and interested in Suite that they're starting a project to "save seamonkey" (some info here). Some core developers have even hinted that they might stop working on Gecko if the Mozilla Suite is killed off.
That Q&A aren't what they sound like - ANYBODY can contribute patches. It's only "by invitation" to get your own CVS account or become a reviewer.
Flash is usually to blame for Mozilla popups:f p.swf?url =http://www.slashdot.org
http://cdn.fastclick.net/fastclick.net/f
Get the FlashBlock extension.
Here you can see pageload times for Mozilla over the past 2 years (you can change the number of days shown). There are more machines running the tests:
Luna
Monkey
Creature
Note the dramatic improvements on btek and luna (linux)... the others improve as well.
It's worth noting that various research papers have done analysis to determine the optimum level of pipelining, and found about 6 to 8 FO-4 gate delays* per stage is optimal - Intel's cancelled Tejas processor was apparently around there and would likely have run at similar clock speeds to the Cell processor. Note that in the real world, you hit other limitations earlier - right now, the main issue is power: chips that fast just run too hot.
*a FO-4 gate delay is a "fan-out of 4 gate delay" - it's the amount of delay from one inverter (NOT gate) which drives 4 identical inverters as load.
People seem to think this is leaps and bounds above everything else, but they're missing the details. In order to obtain that much performance, you'll need a task which parallelizes well so it can be broken up into chunks for the 8 SPEs. Graphics rendering falls into this set of tasks, but a lot of general applications just don't gain that much from parallel processors. Even when you have a task that does parallelize, writing parallel code is quite a bit harder than writing code for just a single thread of execution.
I've seen a lot of hype about having the Cell in your laptop talk to the Cells in your desktop, microwave, and TiVo, but you have to consider real-world limitations. When you set up a network like that (presumably wireless), you're going to be limited to around 100Mbps. In computer clusters and supercomputers, one of the main limitations of performance is the communcation bandwidth available between processors, and the latency of the network. To build a "home supercomputer", you not only need a task that parallelizes well, but one that doesn't require so much inter-node communication that it's held back by a slow network. You can't work around this problem with hardware magic - if the task you're working on requires lots of communication bandwidth, you're going to be held back.
So how much beyond a modern PC is 250GFLOPS anyway? Not much! A GeForce FX at 500MHz does 200 gigaflops. An AMD Athlon's peak performance is 2.4 GFLOPS at 600 MHz... if we scale this up to 2.2 GHz (high-end Athlon), that's 8.8GFLOPS (note: As we're talking about theoretical performance, nonlinear factors like bus speeds can be ignored). Basically, if the Cell dedicates most of its power to graphics rendering, you'll have computation power in the same range as a fast PC of today. Given that we're not going to see any products based on the Cell for a while, this isn't going to be the end of the world for Intel and nVidia (let alone the fact that Cell isn't x86).
Consoles using the Cell will have the advantage of only having to render for TV resolutions - at most 1080 lines, while PCs will be rendering at up to 1600x1200, but if you look at recent history, you can compare the xbox to a then-good PC with a GeForce3 (which came out at around the same time) - the xbox looked better, but PCs did catch up and surpass it's performance and it didn't take all that long. Consoles have to be very high-end when they're released, because the platform doesn't change for 2-3 years, and they still need to be "good enough" after a couple years, before the next generation is released.
I don't think you have a clue what you're talking about. If this is enough for me to claim I'm a developer (or even if it doesn't... I don't really care what trolls think of me).....
r mat=advanced&emailassigned_to1=1&emailtype1=exact& email1=cst%40andrew.cmu.edu&chfieldto=Now
Here's a list of the source directories for Mozilla & Firefox:
accessible browser build caps chrome config content db dbm directory docshell dom editor embedding extensions gc gfx intl ipc jpeg js l10n layout lib mailnews modules netwerk nsprpub other-licenses parser plugin profile rdf security storage sun-java themes toolkit tools uriloader view webshell widget xpcom xpfe xpinstall
Of those, only browser and toolkit are exclusive to Firefox, and most of the code in xpfe is exclusive to Mozilla. Pretty much everything else is shared. There are not different "development teams". Developers working on the core (rendering, networking, the image libraries, etc) are working on both products, since those parts are shared. Other people work on the Firefox frontend mostly, or the Mozilla frontend mostly, or both.
Development is active in both products. It just happens that the Mozilla front end is very mature and stable, so it doesn't change as rapidly. That doesn't mean features aren't being added - I've added a few little things (some of which happen to be in Firefox, some of which aren't), and I'm not the only one working on it.
There are two kinds of fool: one who says, "It is old, and therefore good", and the other, who says "It is new, and therefore better".
Bugzilla blocks referrers from slashdot, so for your copy/paste convenience, the link above is pointing to https://bugzilla.mozilla.org/buglist.cgi?query_fo
I'm curious as to how many people still use Mozilla, anyway.
Unfortunately, not a huge number - that's a part of why there have been 6 alphas for 1.8 - not enough users are testing it. However, a lot of developers have a strong preference for the suite, so they'll continue working on it for a long time to come. There's some work going on to merge more code between Mozilla and Firefox in order to reduce the effort required to maintain both.
It would also be nice if they turned on browser.xul.error_pages.enabled by default and cleaned up the error pages to look a little more professional. I'd offer to supply templates, if I knew who to approach and whether anyone would be remotely interested.
F ou nd&u=http%3A//www.fakesitehere.com/&d=www.fakesite here.com%20could%20not%20be%20found.%20Please%20ch eck%20the%20name%20and%20try%20again.
6
The reason they aren't enabled by default is that they have horrendous usability issues - for example, if you open a link in a new window/tab and it doesn't load successfully, your URL bar will read:
chrome://global/content/netError.xhtml?e=dnsNot
I typed "www.fakesitehere.com"
You can't easily fix your typo. There are also issues with the "Try Again" link and hitting reload. Form POST data is also not properly handled. Error pages cause issues with browser history. There are many bugs filed about these various issues, and making the pages prettier is the least of anybody's concerns right now.
Bug 28586 is the tracking bug for core issues: https://bugzilla.mozilla.org/show_bug.cgi?id=2858
Buf 216466 is the tracking bug for firefox issues.
As I've said before...
It doesn't matter whether the HTML is garbage - it should render the same way every time you load it. However, there is a class of bugs in the gecko engine called "reflow" bugs, which only show up in certain situations, based on the timing of various events during page load, which sometimes cause the page to render differently.
This *IS* a bug in Mozilla/Firefox, and it *HAS* been fixed for a long time (since before Firefox 1.0 was released) but the fix was not included in FF1.0 because it broke other things.
For many reflow bugs, you can construct valid HTML that exposes it just as well as garbage "HTML".
It doesn't matter whether the HTML is garbage - it should render the same way every time you load it. However, there is a class of bugs in the gecko engine called "reflow" bugs, which only show up in certain situations, based on the timing of various events during page load, which sometimes cause the page to render differently.
This *IS* a bug in Mozilla/Firefox, and it *HAS* been fixed for a long time (since before Firefox 1.0 was released) but the fix was not included in FF1.0 because it broke other things.
For many reflow bugs, you can construct valid HTML that exposes it just as well as garbage "HTML".
Why was most of the Firefox work done on a branch and then "crash landed" on the trunk? Some of the bugs resulting from this crash are yet to be fixed. Why make things so complicated? If the main development had happened on the trunk and the releases had been branched off of that this process would have been a lot easier to manage in my view. Almost all other open-spurce projects do it like that.
The idea of a branch is to get a stable set of features and bugs. If development took place on trunk, then as gecko bugs were introduced, things would break. By using a branch, nothing new breaks, and you can fix any bugs you do encounter. By the time you release the product, the bugs have hopefully been found and ironed out.
What about the closing of the source tree for releases? For a while I was wondering why so few checkins got made despite the pending release of Firefox 1.1 in March but then I realized that the tree was closed for a Mozilla release instead.
The branches always close near a release. The policy on a closed tree is that any checkins require approval - the kinds of things that get approved are critical things that need to make it for the release. The branch shouldn't close until very few outstanding bugs remain anyway. You definitely don't want to be adding new features right before a release, because you risk adding bugs.
When I read the projects roadmap I had hoped it would get split up in distinct pieces like Gecko, Toolkit, Firefox-UI, etc. which could be developed individually instead of in one X11-like monolithic blob that requires a global closing/opening process.
It's not a global closing/opening. A branch at a time closes - development continues on trunk (well, there are brief closures of trunk for alphas, but they're short).
Gecko for example could be shared by Firefox, Thunderbird, etc. and have independent releases that the other bits could rely on just like QT or GTK applications rely on respective releases of these toolkits. A Gecko 1.8 release could be branched off of the trunk and developers could just continue to check in new and potentially dangerous code on the trunk despite any impending release of higher-level components. These would simply rely on the last stable release of the lower-level ones.
But then you have to wait for a gecko release before you can release another product (meaning first you iron out all of the bugs from gecko, then you start working on your product). Right now, you just take a snapshot at some reasonably stable point and develop a release from that. Note that Firefox 1.0 WAS built on a "gecko release" - the Mozilla 1.7 gecko. That isn't the usual move though - at least for Seamonkey. Seamonkey releases define gecko releases.
Mozilla and Firefox internally cap the value of the pipeline depth to 8 requests. Setting it any higher than 8 has no effect.
You can download ZIPs of firefox releases (and nightly builds) with no installer. The installer just registers it as the default web browser, and creates shortcuts. It runs just fine without installation.
A comment on burn-in by an Intel employee
P.S.: your "Firefox" code still unpacks itself in a directory named "mozilla". Not "mozilla-1.7" or "firefox-1.0" either... just plain "mozilla". It looks like a CVS snapshot to me.
It is a CVS snapshot. It unpacks to "mozilla" because the cvsroot for both Mozilla and Firefox is shared - Firefox is the mozilla source plus the browser/ and toolkit/ directories. The rest is shared.
The windows installer has checkboxes to let you not install the IRC client, mail client, etc.
He could be the lead architect of the Pentium 4 for all I care - CPUs with precise interrupts (every one I can think of) execute programs as if they were in-order, unpipelined processors.
The Tomasulo design, originally in an old IBM floating point unit, did not support precise interrupts, but modern designs use reorder buffers (the queues I described) to add that support. If the CPUs did not act this way, debugging even non-optimized software would be extraordinarily difficult (since you wouldn't know which instructions were partially complete), and when there were exceptions or interrupts, the CPU would have to keep track of a LOT of internal state in order to resume execution.