1.5b breaks all themes on all platforms that have not been updated to the new skinVersion. The announcement that such an update would be needed was made in June; the announcement that the skinVersion was changed was made in late July. The announcements included pointers to scripts that would auto-update themes as needed, so...
The GNOME filepicker did NOT in fact have equivalent functionality in GTK1 (in particular, it's internationalization support was sorely lacking). The GTK2 filepicker is much better, and Mozilla may indeed switch to it once it switches to GTK2.
MNG support was pretty broken to start with (eg MNG backgrounds did not work properly); at the moment it looks like removing MNG may in fact give people a push to fix the many issues it had.
> shure it can make some people lose their jobs > translating math thesis,
I have to ask. Have you ever read a real math thesis, much less translated one? Trust me, computers are even worse at this than at translating Slashdot comments.
How about actually looking it up? Tinderbox keeps such statistics...
http://tegu.mozilla.org/graph/query.cgi?tbox=com et &testname=codesize_embed&autoscale=1&size=&units=b ytes<ype=&points=&showpoint=2003%3A07%3A23%3A01% 3A32%3A23%2C13244550&avg=0&days=100
shows the codesize of the core engine graphed over the last 100 days (on Linux; Mac and Windows numbers are a little different but show the same overall trend).
Yes, older versions of Gecko that did not attempt to support the bloated mess that is the CSS 2.0 specification were also small enough to fit on a floppy....
With features, unfortunately, comes size.
Re:And I suspect most of us feel the same way...
on
LGPL is Viral for Java
·
· Score: 2, Interesting
Sure. And here is why it's a problem.
Mozilla's license is a GPL/MPL/LGPL trilicence. This means you can use any Mozilla code under any of those licenses. The MPL allows withholding modifications.
Now khtml is LGPL -- a stricter license than the above (for obvious reasons). So khtml may borrow any Mozilla code it wants to (and Safari has), while the converse is emphatically not true. So we get the sort of 1-way sharing of code that the GPL is trying to prevent... but in the direction _opposite_ the one the GPL is trying to prevent.
And that makes GPL just as bad as the commercial licenses, in this respect.
450 working on Netscape products. Like the webserver, AOL Music (which is under the Netscape brand for some reason), etc. There are no longer any developers working on the browser at AOL (officially).
> Is $1M/year an improvement or a reduction in > funding?
$1M is enough to pay about 8-10 mediocre (in the $50k range) salaries (after you factor in things like the taxes the employer has to pay, employee benefits, etc).
AOL was employing a lot more people than that working on Mozilla.
It is. A developer with a nominal salary of $50k each (not too high, really, for a good developer) costs about double that once you factor in the taxes the employer has to pay on the salary (FICA, etc), the benefits the employee gets (health insurance, etc) and such sundry items.
In real terms, a single decent developer probably costs about $120k per year.
So the $2 million is something, but more money will have to get raised if the mozilla foundation actually plans to employ developers itself.
Um... If they are the right people, that may be enough for the layout engine itself. Not quite enough for the works (layout engine, networking, DOM, ui, etc).
Re:Contributions not yet tax-deductible.
on
The Mozilla Foundation
·
· Score: 2, Insightful
> in its Netscape product?
You're assuming there will be a Netscape product.
This is highly doubtful in light of today's events.
The only time I've seen Mozilla have such a footprint is when I've been running memory stress-tests.
Are you sure you're not just adding up the memory of all the threads (which _share_ all that memory)? There are typically 8-10 threads, and 40-50MB sounds about right for memory usage during heavy browsing.
> A gecko browser has less speed potential (among > other things) then a native browser
Excuse me? What part of gecko is "not native"? The fact that it does not use native widgets for form controls? That's because there was in fact no way to do this. Notice that Safari is either a) getting changes to the core OS widget set made or b) suffering from bugs (see hyatt's recent blog entries) due to its use of native widgets.
Gecko did not have the luxury of being able to make the OS makers modify the OS widget set, unfortunately. But the native widgets issue is not one that most users would even notice, imo... (Note that this is for the web page rendering, not for the browser UI -- the latter is a separate kettle of fish, and Camino is a Gecko-based browser with a native UI.)
You mean "Apple's API's are open to third-party developers after Apple has had a few months to get a good head start on the software that will use those APIs." This was the case when OSX came out; this was the case for the new widgets moved over from the iWhatever apps, etc.
Not that this is specific to Apple; any OS maker would be in a similar position.
> In an ideal world XHTML or even pure XML (with > proper Stylesheets) will be the commonplace.
Which is _much_ slower to render than vanilla non-XML HTML is, I should add..
Here is a simple illustration. In XML any random element can have its own base URI associated with it. The full url that a relative URL in an element's attribute resolves to depends on that element and all its parents in the DOM tree! So moving an node in the DOM may mean that the relative URI in the "src" attribute now points to a different location... so any move of an node must walk up the content tree from both old and new locations collecting this base URI information, even though in the average case absolutely nothing will change.
Things like this abound in the bloated beast that is the XML specification...
Re:Why is Firebird that wonderful?
on
Mozilla 1.4 Released
·
· Score: 3, Informative
> From the 1.3.x and 1.4 release notes, it seems > most improvements have come to the > newsgroups/mail.
Frankly, this is because the release notes just list "new feature" type things. There is a lot of work going on with the layout engine, starting after 1.3 and still going strong. None of it is mentioned in the release notes, except in the form of the vague "performance, correctness, stability fixes".
Re:Linux Users Get the Shaft on this release.
on
Netscape 7.1 Released
·
· Score: 5, Informative
Every single Flash issue you list is a bug in the Linux version of the Flash plugin....
Slashdot Mirror
1.5b breaks all themes on all platforms that have not been updated to the new skinVersion. The announcement that such an update would be needed was made in June; the announcement that the skinVersion was changed was made in late July. The announcements included pointers to scripts that would auto-update themes as needed, so...
The GNOME filepicker did NOT in fact have equivalent functionality in GTK1 (in particular, it's internationalization support was sorely lacking). The GTK2 filepicker is much better, and Mozilla may indeed switch to it once it switches to GTK2.
MNG support was pretty broken to start with (eg MNG backgrounds did not work properly); at the moment it looks like removing MNG may in fact give people a push to fix the many issues it had.
What makes it better is being able to have a 2-d virtual desktop layout. WM could not do it last time I tried it. Can it now?
While "e.g." does in fact mean "for example", "i.e." means "that is". Not the same thing.
> shure it can make some people lose their jobs
> translating math thesis,
I have to ask. Have you ever read a real math thesis, much less translated one? Trust me, computers are even worse at this than at translating Slashdot comments.
How about actually looking it up? Tinderbox keeps such statistics...
m et &testname=codesize_embed&autoscale=1&size=&units=b ytes<ype=&points=&showpoint=2003%3A07%3A23%3A01% 3A32%3A23%2C13244550&avg=0&days=100
http://tegu.mozilla.org/graph/query.cgi?tbox=co
shows the codesize of the core engine graphed over the last 100 days (on Linux; Mac and Windows numbers are a little different but show the same overall trend).
Yes, older versions of Gecko that did not attempt to support the bloated mess that is the CSS 2.0 specification were also small enough to fit on a floppy....
With features, unfortunately, comes size.
Sure. And here is why it's a problem.
Mozilla's license is a GPL/MPL/LGPL trilicence. This means you can use any Mozilla code under any of those licenses. The MPL allows withholding modifications.
Now khtml is LGPL -- a stricter license than the above (for obvious reasons). So khtml may borrow any Mozilla code it wants to (and Safari has), while the converse is emphatically not true. So we get the sort of 1-way sharing of code that the GPL is trying to prevent... but in the direction _opposite_ the one the GPL is trying to prevent.
And that makes GPL just as bad as the commercial licenses, in this respect.
> First of all, CSS (any version) does not require
> that you style form controls.
No, but compat with WinIE requires it, sad to say. Hence WinIE's own use of non-native widgets.
All that apart from the general discussion on whether XUL was warranted.
Developing the non-browser products like:
1) The Netscape web server
2) Netscape customer support
3) The Netscape.com portal
4) AOL Music (which is on the Netscape campus)
and so on and so forth.
> 450 (down 10% from 500) working on Netscape
450 working on Netscape products. Like the webserver, AOL Music (which is under the Netscape brand for some reason), etc. There are no longer any developers working on the browser at AOL (officially).
> Is $1M/year an improvement or a reduction in
> funding?
$1M is enough to pay about 8-10 mediocre (in the $50k range) salaries (after you factor in things like the taxes the employer has to pay, employee benefits, etc).
AOL was employing a lot more people than that working on Mozilla.
> isn't the sum of $2m bugger all in real terms?
It is. A developer with a nominal salary of $50k each (not too high, really, for a good developer) costs about double that once you factor in the taxes the employer has to pay on the salary (FICA, etc), the benefits the employee gets (health insurance, etc) and such sundry items.
In real terms, a single decent developer probably costs about $120k per year.
So the $2 million is something, but more money will have to get raised if the mozilla foundation actually plans to employ developers itself.
Um... If they are the right people, that may be enough for the layout engine itself. Not quite enough for the works (layout engine, networking, DOM, ui, etc).
> in its Netscape product?
You're assuming there will be a Netscape product.
This is highly doubtful in light of today's events.
> for an app that has a 400+MB footprint.
The only time I've seen Mozilla have such a footprint is when I've been running memory stress-tests.
Are you sure you're not just adding up the memory of all the threads (which _share_ all that memory)? There are typically 8-10 threads, and 40-50MB sounds about right for memory usage during heavy browsing.
> A gecko browser has less speed potential (among
> other things) then a native browser
Excuse me? What part of gecko is "not native"? The fact that it does not use native widgets for form controls? That's because there was in fact no way to do this. Notice that Safari is either a) getting changes to the core OS widget set made or b) suffering from bugs (see hyatt's recent blog entries) due to its use of native widgets.
Gecko did not have the luxury of being able to make the OS makers modify the OS widget set, unfortunately. But the native widgets issue is not one that most users would even notice, imo... (Note that this is for the web page rendering, not for the browser UI -- the latter is a separate kettle of fish, and Camino is a Gecko-based browser with a native UI.)
> Opera actually uses the same core (engine) on
> devices as on the desktop. Can Mozilla do that?
Yes. The Gecko embedding core has the same exact rendering engine and DOM implementation as the Mozillz browser.
> Apple's API's are open
You mean "Apple's API's are open to third-party developers after Apple has had a few months to get a good head start on the software that will use those APIs." This was the case when OSX came out; this was the case for the new widgets moved over from the iWhatever apps, etc.
Not that this is specific to Apple; any OS maker would be in a similar position.
> In an ideal world XHTML or even pure XML (with
> proper Stylesheets) will be the commonplace.
Which is _much_ slower to render than vanilla non-XML HTML is, I should add..
Here is a simple illustration. In XML any random element can have its own base URI associated with it. The full url that a relative URL in an element's attribute resolves to depends on that element and all its parents in the DOM tree! So moving an node in the DOM may mean that the relative URI in the "src" attribute now points to a different location... so any move of an node must walk up the content tree from both old and new locations collecting this base URI information, even though in the average case absolutely nothing will change.
Things like this abound in the bloated beast that is the XML specification...
> From the 1.3.x and 1.4 release notes, it seems
> most improvements have come to the
> newsgroups/mail.
Frankly, this is because the release notes just list "new feature" type things. There is a lot of work going on with the layout engine, starting after 1.3 and still going strong. None of it is mentioned in the release notes, except in the form of the vague "performance, correctness, stability fixes".
Every single Flash issue you list is a bug in the Linux version of the Flash plugin....
NS4 supports PNGs (in 4.7x versions, certainly, possibly as early as 4.5).
Dunno about IE4.
There is no tag. rc2 is just whatever the 1.4 branch was that day, pulled off the 1.4 branch tag.
> I was wondering who has the bandwidth/time for the
;)
> nightly builds every night?
For anyone with the bandwidth/time to update the source via CVS once every few days to develop it, the nightlies are peanuts.