> and broadens the fricking window of vulnarability
Given that Debian is generally behind upstream in shipping releases, I kinda doubt that. But I can see situations in which a zero-day on an old branch could mean that Debian should ship first and push to upstream in a few days. I'm pretty sure (though I can't commit to this on my own say-so) that people would be understanding.
> Debian allready sends _ALL_ patches to upstream;
Sorry, false (this I _can_ guarantee, being part of said upstream and having seen the patchsets for Debian's Firefox). There are large chunks of ARM assembly code in xptcall, for example, that are completely rewritten in the Debian Firefox and I've never seen Debian send those diffs anywhere near bugzilla.mozilla.org.
This is not to mention the empirical evidence of the number of bug reports we get that are only reproducible with the Debian builds.
> most of the security-patches are taken from upstream.
Sure. That's fine, but the poster I was responding to was talking about Debian-developed security patches to branches that the Mozilla Corporation no longer maintains.
Again, just because the Mozilla Corporation doesn't pay people to work on an old branch doesn't mean that Debian can't get patches checked into Mozilla.org CVS.
The fact that Mozilla stopped doing its own releases off a branch doesn't mean that other people can't do it. Whenever this has come up in the past, Mozilla has offered the use of their bugzilla to the distributions who want to keep maintaining an old branch, so that they can coordinate security fixes with each other. The also offered build machines and such.
This is all the Mozilla Organization. The Corporation is not interested in spending money on the old branches, but the Corporation is not the only stakeholder in the Organization. Other stakeholders (Google, Novell, RedHat, whoever else pays people money to work on Mozilla code) are free to continue maintaining a branch as long as they want to, and the Organization is there to help them with infrastructure and such if possible.
> but I assume there is some sort of extension API that allows developers to access FF > functionality
There is some of that, yes. But there are several problems:
1) Parts of this API are not frozen, for various reasons, and hence can get changed. A
lot of really useful functionality is not frozen. 2) Some extensions use XPCOM APIs that are not really meant for use by extensions; some
of these are not only frozen but not meant to be frozen -- they're effectively
internal APIs. Unfortunately, some things are only possible via such APIs. 3) Most importantly, part of the API the extension sees is the exact browser UI. That's
what the extension overlays its own UI into. Changes to browser UI mean extensions
can become incompatible. For example, an extension that overlayed the tabbrowser to
put close buttons on individual tabs would now be broken because there is already a
close button on the active tab and the internals of the tab bar have changed.
> Imagine if the Linux system calls or Windows API functions changed
Linux system calls don't change much, but have you ever tried writing a kernel driver for Linux? Those break all the time with kernel upgrades...
> This is a serious problem.
That we agree on. The problem is that creating freezable usable APIs is a LOT of work. I don't say this much, but "patches accepted."
The time in that testcase is dominated by garbage collection. I don't know what the page is doing that leads to so many temporary objects... In any case, marking for GC is somewhat slower in some cases in Gecko 1.8.1 than in Gecko 1.8, because a number of memory leaks due to reference cycles going through JS were fixed by hooking into marking.
In any case, I'm not seeing a 50% slowdown here; more like 10%....
Just as a note, a lot of the problems Gecko (Firefox) has with CSS2.1 compliance are things that simply got changed from CSS2 (and were implementing per CSS2 in Gecko several years back). So it's not just that implementing the spec is hard (it is), it's also that the spec keeps mutating.
While you _might_ be able to make such a case for planes (though those are not gifts, just discounted if you consider aid to Israel in general as discounting military equipment purchases in some way), Israel has its own tank design that it produces in a factory in Israel, with primarily Israeli components. See http://en.wikipedia.org/wiki/Merkava or any other reference on the tanks.
> And who's maintaining a Mac build for only 3.6% of the population? WTF?
Members of that 3.6% of the population are maintaining it.
If enough people who want Firefox 3 to run on Win98 work on it, it will happen. There are detailed descriptions in bugzilla.mozilla.org about how it could be done, with a _lot_ of work.
It's just that no one's stepping up to do said work.
> Why is it so difficult to center something vertically?
This is the one complaint of yours that's actually due to the core design of the CSS box model. CSS is designed as a document layout language, not a GUI layout language. The basic model is that widths are the input, heights are the output. As a result, you don't know the height of a box until you've laid out all its kids, which makes centering a particular kid a pain (you have to lay it out, lay out all other kids, determine parent height, _then_ do centering or something).
Given that you want vertical centering, it sounds like you're creating a GUI, not a document. I advise you to look into the flexbox model used by Mozilla's XUL and by certain CSS extensions in Safari for a box model that _is_ designed as a GUI layout language. Vertical centering in those is much simpler.
Actually, the basic problem is that text rendering is hard. Much harder than the CSS box model in some ways. The reason the soft-hyphen bug hasn't been fixed while other CSS bugs have been is that it is in fact much harder to fix, especially in a cross-platform way.
> that _fully_ supports the web standards laid down by the W3C
That's impossible to do, since some of those standards contradict each other.
Also, keep in mind that W3C is a bunch of companies getting together to standardize. Not all standards are relevant to all the companies. For example, SVG 1.2 Tiny has all sorts of things pushed into it by cellphone makers that are no-starters in desktop browsers (for security reasons, because those features are already available, etc). Do check out the socket networking APIs in this "vector graphics" specification. It's an educational view of the W3C.
Firefox supports a large subset of DOM Mutation Events. Not all of them (in part due to the spec being so vague and ill-designed as to not be reasonably implementable), and the support is not bug-free, but there is some support.
Nowhere, since Israel is not a signatory to the relevant treaty (the NPT) and never has been.
One could turn this question around and ask: Where are the Israeli politicians denying Iran's right to exist? Or advocating that the state of Iran be destroyed? _This_ is what makes the difference as far as a state having nuclear weapons in my mind -- anyone who would actually be likely to use them should not have them.
I think your flippant dismissal of the willingness of Iran's leaders to use nuclear weapons indicates that you really haven't thought through what happens when they _do_ use them very well.
While there are plenty of Nobel laureates who don't know much about computers, the post about the setup at MIT is pretty much correct. While there are resources in the form of standard installs, automatic updates, etc available, it's quite easy to put a computer on the network with none of that stuff enabled.
Also, the public machines (the ones in the computer labs) have a known root password. The assumption is that anyone who really cares could hack a machine they have physical access to anyway, and the root password is needed at times... Since all the user files live out in AFS anyway, local root doesn't do you all that much good in terms of user data.
In my time at MIT, there was only one incident when the root password thing was abused... and this was to advertize a frat party.
Slashdot Mirror
> and broadens the fricking window of vulnarability
Given that Debian is generally behind upstream in shipping releases, I kinda doubt that. But I can see situations in which a zero-day on an old branch could mean that Debian should ship first and push to upstream in a few days. I'm pretty sure (though I can't commit to this on my own say-so) that people would be understanding.
> Debian allready sends _ALL_ patches to upstream;
Sorry, false (this I _can_ guarantee, being part of said upstream and having seen the patchsets for Debian's Firefox). There are large chunks of ARM assembly code in xptcall, for example, that are completely rewritten in the Debian Firefox and I've never seen Debian send those diffs anywhere near bugzilla.mozilla.org.
This is not to mention the empirical evidence of the number of bug reports we get that are only reproducible with the Debian builds.
> most of the security-patches are taken from upstream.
Sure. That's fine, but the poster I was responding to was talking about Debian-developed security patches to branches that the Mozilla Corporation no longer maintains.
See my reply at http://slashdot.org/comments.pl?sid=200095&cid=163 88387 -- it covers basically the issues you raise.
Again, just because the Mozilla Corporation doesn't pay people to work on an old branch doesn't mean that Debian can't get patches checked into Mozilla.org CVS.
The fact that Mozilla stopped doing its own releases off a branch doesn't mean that other people can't do it. Whenever this has come up in the past, Mozilla has offered the use of their bugzilla to the distributions who want to keep maintaining an old branch, so that they can coordinate security fixes with each other. The also offered build machines and such.
This is all the Mozilla Organization. The Corporation is not interested in spending money on the old branches, but the Corporation is not the only stakeholder in the Organization. Other stakeholders (Google, Novell, RedHat, whoever else pays people money to work on Mozilla code) are free to continue maintaining a branch as long as they want to, and the Organization is there to help them with infrastructure and such if possible.
> How does that work exactly? Can the end-user decide which license to use?
i -license-html -- it pretty much spells it out.
Yes, exactly. See the actual license text at http://www.mozilla.org/MPL/boilerplate-1.1/mpl-tr
By getting the security fixes checked in upstream as well, so
;)
1) they get proper code review
and
2) everyone benefits from them.
Of course it _is_ less work to just not share the security patches.
> but I assume there is some sort of extension API that allows developers to access FF
> functionality
There is some of that, yes. But there are several problems:
1) Parts of this API are not frozen, for various reasons, and hence can get changed. A
lot of really useful functionality is not frozen.
2) Some extensions use XPCOM APIs that are not really meant for use by extensions; some
of these are not only frozen but not meant to be frozen -- they're effectively
internal APIs. Unfortunately, some things are only possible via such APIs.
3) Most importantly, part of the API the extension sees is the exact browser UI. That's
what the extension overlays its own UI into. Changes to browser UI mean extensions
can become incompatible. For example, an extension that overlayed the tabbrowser to
put close buttons on individual tabs would now be broken because there is already a
close button on the active tab and the internals of the tab bar have changed.
> Imagine if the Linux system calls or Windows API functions changed
Linux system calls don't change much, but have you ever tried writing a kernel driver for Linux? Those break all the time with kernel upgrades...
> This is a serious problem.
That we agree on. The problem is that creating freezable usable APIs is a LOT of work. I don't say this much, but "patches accepted."
The time in that testcase is dominated by garbage collection. I don't know what the page is doing that leads to so many temporary objects... In any case, marking for GC is somewhat slower in some cases in Gecko 1.8.1 than in Gecko 1.8, because a number of memory leaks due to reference cycles going through JS were fixed by hooking into marking.
In any case, I'm not seeing a 50% slowdown here; more like 10%....
The reflow branch is expected to land on trunk before the Gecko 1.9 (Firefox 3.0) branch is cut.
Actually, getting a trunk build won't help... yet. Now if you get a reflow branch build...
g htly/experimental/reflow-refactor/latest-trunk/
See http://ftp.mozilla.org/pub/mozilla.org/firefox/ni
> I'm still waiting for them to fix a bug I filed five years ago reguarding forms
Do you happen to have the bug number? "spauldo" doesn't seem to match any bug reports...
Just as a note, a lot of the problems Gecko (Firefox) has with CSS2.1 compliance are things that simply got changed from CSS2 (and were implementing per CSS2 in Gecko several years back). So it's not just that implementing the spec is hard (it is), it's also that the spec keeps mutating.
> Because all their tanks come from us (as gifts)
While you _might_ be able to make such a case for planes (though those are not gifts, just discounted if you consider aid to Israel in general as discounting military equipment purchases in some way), Israel has its own tank design that it produces in a factory in Israel, with primarily Israeli components. See http://en.wikipedia.org/wiki/Merkava or any other reference on the tanks.
> Only two nations have ever really had the means to project power across the globe.
You're conveniently ignoring the British Empire here, eh? Or are you ignoring the Soviet Union?
> And who's maintaining a Mac build for only 3.6% of the population? WTF?
Members of that 3.6% of the population are maintaining it.
If enough people who want Firefox 3 to run on Win98 work on it, it will happen. There are detailed descriptions in bugzilla.mozilla.org about how it could be done, with a _lot_ of work.
It's just that no one's stepping up to do said work.
> Why is it so difficult to center something vertically?
This is the one complaint of yours that's actually due to the core design of the CSS box model. CSS is designed as a document layout language, not a GUI layout language. The basic model is that widths are the input, heights are the output. As a result, you don't know the height of a box until you've laid out all its kids, which makes centering a particular kid a pain (you have to lay it out, lay out all other kids, determine parent height, _then_ do centering or something).
Given that you want vertical centering, it sounds like you're creating a GUI, not a document. I advise you to look into the flexbox model used by Mozilla's XUL and by certain CSS extensions in Safari for a box model that _is_ designed as a GUI layout language. Vertical centering in those is much simpler.
Actually, the basic problem is that text rendering is hard. Much harder than the CSS box model in some ways. The reason the soft-hyphen bug hasn't been fixed while other CSS bugs have been is that it is in fact much harder to fix, especially in a cross-platform way.
You seem to have some fundamental misconceptions about what Darin's patch does. Please read up on it before making any more statements like this, ok?
> The longer this is put off, the harder I suspect it's going to be to
> put it,
This argument would have made sense in 1998. At this point, we're in the "it's harder" part.
> The EMACS key bindings on a textarea are gone.
That's a system-level preference for all GTK2 apps. Change your GTK2 preferences accordingly if you want Emacs keybindings.
> that _fully_ supports the web standards laid down by the W3C
That's impossible to do, since some of those standards contradict each other.
Also, keep in mind that W3C is a bunch of companies getting together to standardize. Not all standards are relevant to all the companies. For example, SVG 1.2 Tiny has all sorts of things pushed into it by cellphone makers that are no-starters in desktop browsers (for security reasons, because those features are already available, etc). Do check out the socket networking APIs in this "vector graphics" specification. It's an educational view of the W3C.
The reflow branch changes won't ship till Firefox 3, yes.
The Acid 2 thing is on the reflow branch, not on the trunk. Unless you "upgraded" by pulling that branch from CVS, you're not running it.
Firefox supports a large subset of DOM Mutation Events. Not all of them (in part due to the spec being so vague and ill-designed as to not be reasonably implementable), and the support is not bug-free, but there is some support.
> As to Israel - where are the IAEA inspectors?
Nowhere, since Israel is not a signatory to the relevant treaty (the NPT) and never has been.
One could turn this question around and ask: Where are the Israeli politicians denying Iran's right to exist? Or advocating that the state of Iran be destroyed? _This_ is what makes the difference as far as a state having nuclear weapons in my mind -- anyone who would actually be likely to use them should not have them.
I think your flippant dismissal of the willingness of Iran's leaders to use nuclear weapons indicates that you really haven't thought through what happens when they _do_ use them very well.
While there are plenty of Nobel laureates who don't know much about computers, the post about the setup at MIT is pretty much correct. While there are resources in the form of standard installs, automatic updates, etc available, it's quite easy to put a computer on the network with none of that stuff enabled.
Also, the public machines (the ones in the computer labs) have a known root password. The assumption is that anyone who really cares could hack a machine they have physical access to anyway, and the root password is needed at times... Since all the user files live out in AFS anyway, local root doesn't do you all that much good in terms of user data.
In my time at MIT, there was only one incident when the root password thing was abused... and this was to advertize a frat party.