Slashdot Mirror

What I still haven't figured out is why Slashdot doesn't automatically prime the coral cache, so the content is available to people who know where to look anyway..
The resurrect pages plugin for Firefox makes using the various caches out there easy, but doesn't help if they're not used before the site gets slashdotted.

from the end user perspective, bugzilla is the best system out there. guess what that makes of the other systems.
it's absolutely annoying to see reports where developers want to get more information, but nobody responds because report submitting was anonymous. as a bug reporter, i dislike passionately systems that do not allow me to register so that i can receive notifications on any updates or questions to my reports.
now what might be a middle ground - openid support in bugzilla (https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin). having that in upstream codebase and polished could help with the registering problem somewhat.

https://wiki.mozilla.org/Roadmap_Scratchpad

That's the current roadmap. I went to mozilla.org, clicked "Developers" and then clicked "Roadmap" in the left-hand navigation bar. How long did you spend looking? I didn't think it was that hidden.

That's good, but they are still (IMO) wasting Mozilla resources on things which are largely pointless, while much more basic features and bugs go neglected
Such as a usable file upload progress, so important to Web2.0/photo/video sharing type situations,
or the way the whole UI blocks while plugins load
or the inability to cope with plugin problems

That's good, but they are still (IMO) wasting Mozilla resources on things which are largely pointless, while much more basic features and bugs go neglected
Such as a usable file upload progress, so important to Web2.0/photo/video sharing type situations,
or the way the whole UI blocks while plugins load
or the inability to cope with plugin problems

That's good, but they are still (IMO) wasting Mozilla resources on things which are largely pointless, while much more basic features and bugs go neglected
Such as a usable file upload progress, so important to Web2.0/photo/video sharing type situations,
or the way the whole UI blocks while plugins load
or the inability to cope with plugin problems

Correction, should be:

It's also worth mentioning the 357 CPU-hogging bugs as an example of avoiding working on things that matter.

You mean the part where I've repackaged FF with a MSI installer myself?

Look.

https://bugzilla.mozilla.org/show_bug.cgi?id=231062

Politics.

Meta-whining also accomplishes nothing. But thanks for trying to call me on being an ignorant whining tool and also helping the situation?

Well, since you missed the other times it was posted I will do Futurepower(R) a favor

It's also worth mentioning the 357 CPU-hogging bugs [mozilla.org] as an example of working on things that don't matter.

If you can't visit Bugzilla from Slashdot, put this URL into another tab: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=CPU [mozilla.org]

How 'bout you get right on that one.

wget http://download.mozilla.org/?product=firefox-3.0.6&os=linux&lang=en-US

It's also worth mentioning the 357 CPU-hogging bugs as an example of working on things that don't matter.

If you can't visit Bugzilla from Slashdot, put this URL into another tab: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=CPU

It's also worth mentioning the 357 CPU-hogging bugs as an example of working on things that don't matter.

If you can't visit Bugzilla from Slashdot, put this URL into another tab: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=CPU

It's time that the Firefox CPU-hogging bug is fixed. (357 bugs!) The bug was less of a problem until version 3.0.4, but versions 3.0.5 and 3.0.6 are much worse.

If you can't visit Bugzilla from Slashdot, put this URL into another tab: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=CPU

It's time that the Firefox CPU-hogging bug is fixed. (357 bugs!) The bug was less of a problem until version 3.0.4, but versions 3.0.5 and 3.0.6 are much worse.

If you can't visit Bugzilla from Slashdot, put this URL into another tab: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=CPU

Firefox 3.1 Beta 2 is the fastest Firefox browser yet.

So, has it fixed bug 453964 yet? Or are the developers too busy with themes to bother?

Besides, the biggest speed-related problem with Firefox isn't actual speed, it's that the browser tends to block when loading Slashdot pages in another tab, for example. I wouldn't know if version 3 fixes this, since the bug mentioned makes it useless to me.

Firefox 3.1 Beta 2 is the fastest browser yet - that is what makes it so annoying when Mozilla team just discontinues or changes some feature in the name of...

https://bugzilla.mozilla.org/show_bug.cgi?id=456405 ... usability?

Or the fact that Firefox would rather open Nautilus than opening something *I* want -or- just showing me the information of where a file was downloaded.

Any why?

https://bugzilla.mozilla.org/show_bug.cgi?id=431521

Firefox is about having a minimalistic
UI, and that means cutting things that most of our users don't use.

Because Firefox is minimalistic, it would rather open Nautilus.

Nobody - NOBODY - uses Firefox for minimalism anymore. Even Opera is more minimalistic is than Firefox.

And IE7 is pile of crap how exactly? The reason it is so hated has got nothing to do with its usability, but with the fact that has shitty support for standards and that it is tied with the OS.

Firefox 3.1 Beta 2 is the fastest browser yet - that is what makes it so annoying when Mozilla team just discontinues or changes some feature in the name of...

https://bugzilla.mozilla.org/show_bug.cgi?id=456405 ... usability?

Or the fact that Firefox would rather open Nautilus than opening something *I* want -or- just showing me the information of where a file was downloaded.

Any why?

https://bugzilla.mozilla.org/show_bug.cgi?id=431521

Firefox is about having a minimalistic
UI, and that means cutting things that most of our users don't use.

Because Firefox is minimalistic, it would rather open Nautilus.

Nobody - NOBODY - uses Firefox for minimalism anymore. Even Opera is more minimalistic is than Firefox.

And IE7 is pile of crap how exactly? The reason it is so hated has got nothing to do with its usability, but with the fact that has shitty support for standards and that it is tied with the OS.

agreed.

this way it's almost indistinguishable from using the (very useful) bookmark keywords.

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more

I actually commented on this a while back (not as a mass suggestion, but how I - personally - grab firefox on a new windows install).
The funny thing is that it is clear you've never done this - or at least it has been too long since you have to adopt a Socratic attitude.

xxx@xxx:~$ ftp ftp.mozilla.org
Connected to dm-ftp01.mozilla.org.
220-
220-
220- ftp.mozilla.org / archive.mozilla.org - files are in /pub/mozilla.org
220-
220- Notice: This server is the only place to obtain nightly builds and needs to
220- remain available to developers and testers. High bandwidth servers that
220- contain the public release files are available at ftp://releases.mozilla.org/
220- If you need to link to a public release, please link to the release server,
220- not here. Thanks!
220-
220- Attempts to download high traffic release files from this server will get a
220- "550 Permission denied." response.
220

Like the banner says, releases.mozilla.org.

And because Windows 7 doesn't currently look like a trainwreck, and it comes with IE8, I think that a lot of people buying new computers will stick with what comes with it, even if they used Firefox before.

Clearly you have not done much work with IE8.

However if Firefox had a service whereby you could save all your favourites, history, etc, to a web service, and then retrieve them on your new Windows 7 laptop later on, that would be an incentive to re-download Firefox despite the presence of IE8.

Like Foxmarks?

On a laptop, you probably need Master Password Timeout as well

Speaking of Hulu... Anybosy know how to save a streamed video? My internet connection at home couldn't handle downloading every time I watch an episode multiple tilmes.

Well, if you use Firefox, there are some plugins available on the Mozilla site that supposedly let you do just that. I've not personally tried any of them, but it would be a good place to start.

This one looks interesting.

Tab Mix Plus has that functionality, and a whole lot more.

Sounds like YesScript is for you.

Have you tried YesScript? It's about the opposite -- a blacklist for sites that you do not want executing JavaScript.

AdBlock Plus has the benefit of blocking by URL including regexp-based patterns, and is not limited to SWF - it will block any kind of content (HTML/JS/CSS, etc.) The default block list is quite good. Last I checked it was the most-downloaded extension from addons.mozilla.org.

I use Firefox with the AdBlock Plus, NoScript, and FlashBlock add-ons installed. I haven't noticed any pop-up ads.

Damn, do you see any content?

I use Firefox with the AdBlock Plus, NoScript, and FlashBlock add-ons installed. I haven't noticed any pop-up ads.

Damn, do you see any content?

I use Firefox with the AdBlock Plus, NoScript, and FlashBlock add-ons installed. I haven't noticed any pop-up ads.

Damn, do you see any content?

FireFox add-on Flashblock 1.5.7.1 https://addons.mozilla.org/en-US/firefox/addon/433

I use Firefox with the AdBlock Plus, NoScript, and FlashBlock add-ons installed. I haven't noticed any pop-up ads.

I use Firefox with the AdBlock Plus, NoScript, and FlashBlock add-ons installed. I haven't noticed any pop-up ads.

I use Firefox with the AdBlock Plus, NoScript, and FlashBlock add-ons installed. I haven't noticed any pop-up ads.

Personally, I've never had a problem with Adobe Reader on any platform

Most of us have never had a problem with it...except that it required 335 megs of disk space on Windows. 1/3 gig just to read and print PDFs? The Linux install needs only 125 megs. Why?

I just don't see the need to have a directory of PDF readers.

Either will average Joe user unless the directory puts a two-page ad in the New York Times. The only people who will know about that page are the ones who already use a non-Adobe reader! For Windows I find that Foxit suits my needs and somehow I don't feel guilty about using a proprietary reader(I use the default readers on Linux).

But PDF readers are old news...The only new thing I learned from the site is that there's a -- holy shit! -- KDE on Windows project!

I agree. Very useful and not evil. This makes a simple and secure deployment and upgrade mechanism a viable option. It should have had broader publicity, though. Useful information can be found here:

What click-once does:

http://windowsclient.net/wpf/wpf35/wpf-deploying-clickonce-ie-firefox.aspx#xamlbrowser
http://en.wikipedia.org/wiki/ClickOnce

An old FF clickonce addon: https://addons.mozilla.org/en-US/firefox/addon/1608

This is neither news nor a surprise. This addon first started appearing in summer 2008. Clickonce is years old. Firefox support is new.

Regarding mono support for click once, read http://www.mono-project.com/StudentProjects

" A ClickOnce implementation could be done ... Since CAS is not supported in Mono its usefulness would be somewhat limited. " (Mono doesn't implement code access security. Sandboxing and trust are key parts of ClickOnce. The apps are usually not fully trusted.)

> The amount of venom/vitriol/nerdrage comments in this story is fucking astounding.

    Why, because MS is so benevolent and competent and writes such secure code? No. The reason is because of their high-handed tactics, combined with their propensity for malicious behaviour. And please, forget the old saw about not assumimg malice when effing incompetence explains things; the results are the same.

    The reaction would've been totally different if MS had promoted this plugin, and made its installation voluntary, and made uninstallation possible without registry hacking. Note that dozens of obscure extensions show up on https://addons.mozilla.org/en-US/firefox/ This is the "official channel" for people who want to enhance their Firefox. The extensions at this site are downloaded voluntarily by end-users who feel a need for them. And these extensions can be uninstalled by the same users who install them. MS merely needed to have asked the Mozilla folks to link to a specific MS webpage from their addons section, and things would've been copacetic.

    Instead, MS chose to act like Apple. Remember the flak Apple caught for trying to sneak in Itunes and Safari for people who install/update Quicktime? We happen to be "equal-opportunity-bashers" here. MS acts like Apple, they catch flak like Apple.

Yes, I did RTFA. FFClickOnce makes automated installation of .NET code (the successor to Visual Basic) much easier. Have you ever heard the phrase "drive-by download"??? Many people fled from IE to FF specifically to avoid this very problem. Now MS throws in code that may enable this in FF. No thanks. BTW, there was a plugin for FF that provided ActiveX support for FF (For crying out loud... WHY?). Let's just say I wouldn't want it on my work machine either.

Redirect Remover

And since it's java it will be painfully slow and resource consuming,

but stable i suppose.

Back to the original discussion web apps are better as far as distribution is concerned, once you distribute a web app to servers you KNOW everyone is using the new version and not some old version with a potential bug or exploit.

Then again, web apps are easier to exploit, it's amazing what you can do with http headers.

You guys should check out this NumberFox firefox extension. I think there are others with similar functionality. Konqueror has had something similar for the longest time enabled by default.

You don't even need IE to get Firefox.
FTP it from ftp://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/win32/en-US/

Bugzilla 3.4 will have rudimentary support for saying that a bug is related to a bug in another bug-tracker. Currently the development version allows you to input Bugzilla and Launchpad bugs, and we'll probably allow Trac and Jira in some future version, too.

Future versions will also automatically update the other bug tracker, if possible, to let them know that you've set a relationship to their bug.

The relevant bug for tracking development on this feature is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=bz-seealso

-Max

To me it makes a lot more sense to write 100% of your program in, say, Perl. (s/Perl/Python/g or s/Perl/Ruby/g is that's what turns your crank.) You pull in some CPAN libraries, many of which have the time-critical stuff written in C for good performance, but you don't have to touch the C. If there does turn out to be some very time-critical loop that you really want to optimize, and it's not something generic that's available in CPAN, then you write it in C and interface it to your Perl program. You end up writing 99.9% of your own code in a nice high-level language, and 0.1% in a crufty low-level language, and you get good performance.

How much slower is it going to be in Javascript? Is it so slow that the average linux user is going to notice? If not, I think you're preoptimizing.

FYI, Java has a JS interpreter called Rhino and it lets you compile the JS into .class files for performance improvements. You can read about it here: http://www.mozilla.org/rhino/jsc.html Perhaps the same could happen with these linux applications.

Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?

Static analysis.