> How do I file bugs in the new version when the Firefox 3.0 overwrites the old version 's DLLs
Does it really do that on Windows? That doesn't happen on either Mac or Linux (which are what I have experience with), but I guess those don't use the mess that is the installer.... That behavior is really unfortunate.
I assume that you went back to 2.x by uninstalling the beta and reinstalling 2.x, right? In that case, what's keeping you from reporting the bugs? Just not having the details off the top of your head?
Please do file the bugs once Giorgio updates NoScript, ok?
I was with you until you got to unions, actually. But if you're storing data that might be an integer, a double, or a string, you rather end up with a union that has a pointer type and a non-pointer type in it. Either that, or you end up using twice as much memory.
Actually, the W3C now also requires two working, different, interoperable implementations. That's one major reason that CSS 2.1 is still in CR instead of REC.
And they're working on test suites. It's a time-consuming process. Figuring a spec without much fluff text, you would assume about one testable requirement per sentence, at minimum. If you have a spec a few hundred pages long (a number of the W3C specs are), that's a _lot_ of tests.
> They can have my debugging reports and my attention when NoScript works but not before.
That's up to the NoScript developer, actually. The NoScript extension lists what versions of Firefox it's compatible with and explicitly excludes this beta from the list. At some point it'll probably get updated to include that, since it's a one-line change in the maxVersion field in the install manifest.
Heck, you could make that change in the extension yourself, today, and install it.
None of which explains your not filing bugs about the CSS and JS issues you ran into. You clearly tried the browser and ran into them, right? You can use Firefox 2 (or whatever else you want) to file the bug if you want to minimize your NoScript-less browsing time. But saying "nyah, nyah, there are bugs but I won't tell you about them" is just not helpful, sorry.
You do realize that the money an employee costs is more than just salary? Things like health insurance, taxes (the employer half of FICA, say), and so forth add up.
Do you have a reference for this in the context of GNOME? Were there patches being rejected with NIH reasons? Were decisions being made to not use GNOME-provided facilities and roll one's own instead? Just curious.
I do seem to recall Mozilla doing things like switching to the GTK-native filepicker once it got its non-ASCII-text act together, even though it was still functionally inferior to the XUL filepicker that had been used before that (for example it was much slower).
In fact, Mozilla is currently having quite the opposite problem in some ways. They're trying to use cairo and pango and so forth and discovering all sorts of issues, ranging from pango hanging if you ask it to deal with a string longer than 65K chars (happens on the web, with a long chunk of text) to performance issues in pango, Render, cairo, and fontconfig (little things like using Render to scale images being much slower than using xlib directly, for images with no alpha channel, which is most of the web).
At the moment, it's looking like Mozilla will effectively drop support for anything older than FC6 or equivalent (in terms of libraries) in the next Gecko release simply because the older system stuff is too buggy in various ways to work with, and the decision has been made to be a good citizen and use the system libraries.
One possible solution to your problem might be a Kerberos-enabled FTP client and server. It's a bit of overkill, perhaps, because you have to set up Kerberos to start with, but I think it should give you exactly what you want: FTP with its jail features, but with the authentication taking place over an encrypted data channel.
> So have they finally acknowledged that Firefox is a memory hog instead of just blaming users
I have yet to see an actual Firefox developer blame users for memory usage issues. Anyone actually working with the code knows that there are problems that need fixing.
What I _have_ seen are fanboys who've never looked at the code making claims about what is or is not leaking without a basis in reality.
The fact is:
1) There are some leaks in Gecko 2) There are some leaks in the Firefox UI 3) There are some leaks in extensions 4) There are some behaviors in all three that are not leaks but do
lead to prolonged usage of large amounts of memory.
By "leak" above I mean "memory not deallocated until program shutdown", which is a looser meaning than the typical meaning of "leak" as "memory the program does not deallocate at all". In the end, the user doesn't care which is happening.
All four items above need to be addressed, though for item 4 there is the obvious question: is there utility from the user's point of view in holding on to that memory, and does that utility outweigh the memory usage. Put another way, a 5MB RAM page cache is clearly too small and a 500MB one is clearly too big (on modern hardware). The question is what a "good" size is.
> The memory buffers use up 3/4 of my memory with an empty, just launched, instance of Firefox.
You mean on Linux? A lot of that is disk buffering into RAM, right?
> but maybe I'm wrong
You're wrong.
> allocating buffer memory without even a single page loaded
To start a program you have to read it from disk. Linux in particular very aggressively buffers disk into RAM; it probably has not only all the files touched (not necessarily still open!) by Firefox as it starts, but various other programs you've started as well, the Firefox disk cache, etc, etc.
> 1. Custom malloc/free implementation. (Yes, custom - not from libc.)
Uh... No. There are some arena allocators in use in the codebase for very specific tasks, but there is no custom malloc/free.
> They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't
Actually, to be exposed to JS in Gecko something more or less has to be an XPCOM object at the moment. Then the XPConnect layer handles the glue between JS and C++.
> It makes a project that's supposed to be open source effectively closed off to only the > "official" developers
As someone who got into this project without being in any way "official", I beg to differ!;)
> Since TFM is about a *web browser*, neither of those apply.
Actually... a web browser _is_ a high-performance application. You should see the rendering tasks that web sites toss at it and expect it to perform quickly and perfectly
For what it's worth, a lot of those tests are pretty broken. They don't actually test what they claim to be testing.
This is not to say that being faster at them is not a good thing, of course. But as with all benchmarks the question is how well they match up with real-world workloads. In the case of these tests, the answer is "poorly".
> Paying $75000 in federal taxes equates to making somewhere around $300000-500000 in gross > income
The low end of that, yeah. For 2007, per http://www.irs.gov/formspubs/article/0,,id=164272, 00.html you pay "$39,148.75 plus 33% of the amount over 160,850" as long as you earn less than $349,700. That means that to hit $75,000 tax your taxable income needs to be about $270000.
The gross would be higher, of course. But in that range, the difference is pretty slim. For example, in 2006 personal exemptions start to phase out once your gross is over 150,500 and are gone completely when your gross is at 273,000. That's if you're single. If you're married those numbers are higher by about $40,000. Similarly, most deductions phase out starting at a gross of $156,000 or so. See http://www.taxguideonline.com/ContentPages/ID_Phas eOut.html for some more numbers.
And as you said, that excludes FICA (medicare & social security), etc. Those add at least $6,000 to your tax burden once you're over $80,000 or so gross income (even ignoring the employer half). So really, you need only $250,000 taxable income to easily hit $75,000 in federal tax.
Except for the fact that some of the warnings gcc, say, produces, are plainly wrong. It's possible to change the code to prevent those warnings, at the cost of some CPU cycles... but sometimes you can't afford that.
Re:What earthly use is "firefoxurl" anyway?!
on
Firefox Quickies
·
· Score: 1
> what on earth were they thinking when they implemented it?
They didn't implement it. It's a protocol Windows made up based on the names of the registry keys Firefox set to get http: URIs to open in it.
Re:Firefox's Fault?
on
Firefox Quickies
·
· Score: 3, Insightful
> I interpret that as saying that the Firefox installer messed with Windows and Internet Explorer
Firefox set up the http: protocol and such to launch it. Windows synthesizes a new URI scheme based on the registry key name used for this and associates this made-up scheme with Firefox. Not much Firefox can do about this Windows "feature".
Re:IE problem, but also Firefox problem.
on
Firefox Quickies
·
· Score: 3, Insightful
> I can't think of any legitimate reason for it
It's a protocol scheme Windows makes up based on the registry keys Firefox has to set to get things like http: associated with it.
To be more precise, what Firefox does is:
register HKLM/SOFTWARE/Classes/FirefoxURL with a shell/open/command
subkey and then set the values of ftp, gopher, http, and https to
FirefoxURL under HKLM/SOFTWARE/Clients/StartMenuInternet/FIREFOX.EX E/Capabilities/URLAssociations
This causes Windows to send "firefoxurl:" URLs to Firefox.
Site boundaries are not immutable: see document.domain. And there are ways for script to request expanded privileges that allow cross-site access; see enablePrivilege.
Passing ACID2 is not just a matter of a few minor bug-fixes. There was a fundamental architecture problem that needed to be fixed to pass the bit that was failing; this took several years of work on a branch to resolve and involved largely rewriting the code that does actual layout of the web page. That sort of change is not going to happen in the stable builds based off Gecko 1.8 (Firefox 1.5 and 2).
Slashdot Mirror
> How do I file bugs in the new version when the Firefox 3.0 overwrites the old version 's DLLs
Does it really do that on Windows? That doesn't happen on either Mac or Linux (which are what I have experience with), but I guess those don't use the mess that is the installer.... That behavior is really unfortunate.
I assume that you went back to 2.x by uninstalling the beta and reinstalling 2.x, right? In that case, what's keeping you from reporting the bugs? Just not having the details off the top of your head?
Please do file the bugs once Giorgio updates NoScript, ok?
Firefox 3 will do incremental rendering of XML. Heck, this beta does it, as have a number of the most recent alphas.
I was with you until you got to unions, actually. But if you're storing data that might be an integer, a double, or a string, you rather end up with a union that has a pointer type and a non-pointer type in it. Either that, or you end up using twice as much memory.
Actually, the W3C now also requires two working, different, interoperable implementations. That's one major reason that CSS 2.1 is still in CR instead of REC.
And they're working on test suites. It's a time-consuming process. Figuring a spec without much fluff text, you would assume about one testable requirement per sentence, at minimum. If you have a spec a few hundred pages long (a number of the W3C specs are), that's a _lot_ of tests.
> They can have my debugging reports and my attention when NoScript works but not before.
That's up to the NoScript developer, actually. The NoScript extension lists what versions of Firefox it's compatible with and explicitly excludes this beta from the list. At some point it'll probably get updated to include that, since it's a one-line change in the maxVersion field in the install manifest.
Heck, you could make that change in the extension yourself, today, and install it.
None of which explains your not filing bugs about the CSS and JS issues you ran into. You clearly tried the browser and ran into them, right? You can use Firefox 2 (or whatever else you want) to file the bug if you want to minimize your NoScript-less browsing time. But saying "nyah, nyah, there are bugs but I won't tell you about them" is just not helpful, sorry.
> and I already started getting errors.
And filed a bug, right? That's the point of a beta: to get feedback if things don't work somewhere for some reason...
You do realize that the money an employee costs is more than just salary? Things like health insurance, taxes (the employer half of FICA, say), and so forth add up.
Firefox had to make a number of changes, for example. You can search bugzilla.mozilla.org for resolved bugs with "vista" in the summary if you care.
> (because it suffers from extensive NIH)
Do you have a reference for this in the context of GNOME? Were there patches being rejected with NIH reasons? Were decisions being made to not use GNOME-provided facilities and roll one's own instead? Just curious.
I do seem to recall Mozilla doing things like switching to the GTK-native filepicker once it got its non-ASCII-text act together, even though it was still functionally inferior to the XUL filepicker that had been used before that (for example it was much slower).
In fact, Mozilla is currently having quite the opposite problem in some ways. They're trying to use cairo and pango and so forth and discovering all sorts of issues, ranging from pango hanging if you ask it to deal with a string longer than 65K chars (happens on the web, with a long chunk of text) to performance issues in pango, Render, cairo, and fontconfig (little things like using Render to scale images being much slower than using xlib directly, for images with no alpha channel, which is most of the web).
At the moment, it's looking like Mozilla will effectively drop support for anything older than FC6 or equivalent (in terms of libraries) in the next Gecko release simply because the older system stuff is too buggy in various ways to work with, and the decision has been made to be a good citizen and use the system libraries.
One possible solution to your problem might be a Kerberos-enabled FTP client and server. It's a bit of overkill, perhaps, because you have to set up Kerberos to start with, but I think it should give you exactly what you want: FTP with its jail features, but with the authentication taking place over an encrypted data channel.
> So have they finally acknowledged that Firefox is a memory hog instead of just blaming users
I have yet to see an actual Firefox developer blame users for memory usage issues. Anyone actually working with the code knows that there are problems that need fixing.
What I _have_ seen are fanboys who've never looked at the code making claims about what is or is not leaking without a basis in reality.
The fact is:
1) There are some leaks in Gecko
2) There are some leaks in the Firefox UI
3) There are some leaks in extensions
4) There are some behaviors in all three that are not leaks but do
lead to prolonged usage of large amounts of memory.
By "leak" above I mean "memory not deallocated until program shutdown", which is a looser meaning than the typical meaning of "leak" as "memory the program does not deallocate at all". In the end, the user doesn't care which is happening.
All four items above need to be addressed, though for item 4 there is the obvious question: is there utility from the user's point of view in holding on to that memory, and does that utility outweigh the memory usage. Put another way, a 5MB RAM page cache is clearly too small and a 500MB one is clearly too big (on modern hardware). The question is what a "good" size is.
> The memory buffers use up 3/4 of my memory with an empty, just launched, instance of Firefox.
You mean on Linux? A lot of that is disk buffering into RAM, right?
> but maybe I'm wrong
You're wrong.
> allocating buffer memory without even a single page loaded
To start a program you have to read it from disk. Linux in particular very aggressively buffers disk into RAM; it probably has not only all the files touched (not necessarily still open!) by Firefox as it starts, but various other programs you've started as well, the Firefox disk cache, etc, etc.
It's being worked on. See http://www.mozilla.org/projects/tamarin/
> 1. Custom malloc/free implementation. (Yes, custom - not from libc.)
;)
Uh... No. There are some arena allocators in use in the codebase for very specific tasks, but there is no custom malloc/free.
> They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't
Actually, to be exposed to JS in Gecko something more or less has to be an XPCOM object at the moment. Then the XPConnect layer handles the glue between JS and C++.
> It makes a project that's supposed to be open source effectively closed off to only the
> "official" developers
As someone who got into this project without being in any way "official", I beg to differ!
> Since TFM is about a *web browser*, neither of those apply.
Actually... a web browser _is_ a high-performance application. You should see the rendering tasks that web sites toss at it and expect it to perform quickly and perfectly
For what it's worth, a lot of those tests are pretty broken. They don't actually test what they claim to be testing.
This is not to say that being faster at them is not a good thing, of course. But as with all benchmarks the question is how well they match up with real-world workloads. In the case of these tests, the answer is "poorly".
> Paying $75000 in federal taxes equates to making somewhere around $300000-500000 in gross
, 00.html you pay "$39,148.75 plus 33% of the amount over 160,850" as long as you earn less than $349,700. That means that to hit $75,000 tax your taxable income needs to be about $270000.
s eOut.html for some more numbers.
> income
The low end of that, yeah. For 2007, per http://www.irs.gov/formspubs/article/0,,id=164272
The gross would be higher, of course. But in that range, the difference is pretty slim. For example, in 2006 personal exemptions start to phase out once your gross is over 150,500 and are gone completely when your gross is at 273,000. That's if you're single. If you're married those numbers are higher by about $40,000. Similarly, most deductions phase out starting at a gross of $156,000 or so. See http://www.taxguideonline.com/ContentPages/ID_Pha
And as you said, that excludes FICA (medicare & social security), etc. Those add at least $6,000 to your tax burden once you're over $80,000 or so gross income (even ignoring the employer half). So really, you need only $250,000 taxable income to easily hit $75,000 in federal tax.
He reported the bug to Sun and only disclosed when they classified it as a "Request for enhancement".
> and nothing seems to suggest that they don't take the issue seriously.
Except for them having classified the severity as "Request for enhancement", you mean?
> no, warnings aren't OK.
Except for the fact that some of the warnings gcc, say, produces, are plainly wrong. It's possible to change the code to prevent those warnings, at the cost of some CPU cycles... but sometimes you can't afford that.
> what on earth were they thinking when they implemented it?
They didn't implement it. It's a protocol Windows made up based on the names of the registry keys Firefox set to get http: URIs to open in it.
> I interpret that as saying that the Firefox installer messed with Windows and Internet Explorer
Firefox set up the http: protocol and such to launch it. Windows synthesizes a new URI scheme based on the registry key name used for this and associates this made-up scheme with Firefox. Not much Firefox can do about this Windows "feature".
> I can't think of any legitimate reason for it
X E/Capabilities/URLAssociations
It's a protocol scheme Windows makes up based on the registry keys Firefox has to set to get things like http: associated with it.
To be more precise, what Firefox does is:
register HKLM/SOFTWARE/Classes/FirefoxURL with a shell/open/command
subkey and then set the values of ftp, gopher, http, and https to
FirefoxURL under HKLM/SOFTWARE/Clients/StartMenuInternet/FIREFOX.E
This causes Windows to send "firefoxurl:" URLs to Firefox.
Not much to remove here on Mozilla's end.
> Opera is going to fully support CSS selectors
Or more precisely, fully pass this test. Which is not the same thing -- the test is not exactly exhaustive.
Site boundaries are not immutable: see document.domain. And there are ways for script to request expanded privileges that allow cross-site access; see enablePrivilege.
Passing ACID2 is not just a matter of a few minor bug-fixes. There was a fundamental architecture problem that needed to be fixed to pass the bit that was failing; this took several years of work on a branch to resolve and involved largely rewriting the code that does actual layout of the web page. That sort of change is not going to happen in the stable builds based off Gecko 1.8 (Firefox 1.5 and 2).