> "the Interenet interprets censorship as damage; > and routes around it."
Yep. So you could end up with the Internet routing around the whole of the United States. Which means the Internet is fine, but not for those in the US.
Routing around damage only works if multiple routes are available; for a typical home user that is currently not the case.
Because there are a lot of names involved. There's the name of the browser. The name of the mail app. The name of the MacOSX-only thing now known as Camino. The name of the IRC client. And so forth.
You could call it the "naming plan" or the "way to keep the names straight and reasonable" or whatever. But "branding strategy" is the term that's used for this sort of thing.
Do you object to people calling a compiler a compiler instead of "the thingy that converts source to object code?";)
> So this is really a face saving way of retracting > the name change.
Except for the fact that work on this document (discussion about what the final shipping names would be) started _before_ Asa made his announcement... If people had known there would be such a hissy-fit over the codenames, they would have waited till the final names were decided on before saying what the new codename was.
Because if/when another major update comes along, the name of the shipping product can REMAIN "mozilla browser" while the name used to refer to it internally in the project can change to avoid confusion.
I think I have a general idea of what I'm talking about with the Mozilla project...;) The final shipping name of the browser component is not clear yet; it may well end up being "Mozilla Browser". But for now, we need distinct names for the new component and the existing app-suite, while the new component is being moved to.
Of the 96 bugs filed so far today, about half are already marked DUPLICATE or INVALID... Of the rest, at least 2/3 will be marked so as well, it'll just take a few days.
So yes, that's 109 bug reports a day, most of which are useless.
Mozilla + webtools + whatever (which is what the "200000" number refers to) are about 7 million lines of code or more. So plenty of space for 200000 bugs.;)
Have you ever read any of the bugs in Mozilla's bug database? Both of the reports you list have a very high signal to noise ratio compared to a typical _real_ bug report.
The bug is likely to get ignored simply because the signal-to-noise ratio is such that determining the problem actually being reported is impossible. No malice involved, just simple inability to tell the bug in all the stupid noise.
That pref is _exactly_ equivalent to just setting all popups disabled in the new UI. The UI should be clearer -- it only deals with unrequested popups, not requested ones.
> If work on the basic Gecko HTML renderer and ECMA > Script has leveled off,
Not even close. You just read a list of planned changes to the UI of Mozilla. The page explicitly says it does not include gecko work.
If you're curious, see http://bonsai.mozilla.org/cvsquery.cgi?treeid=defa ult&module=all&branch=HEAD&branchtype=match&dir=&f ile=&filetype=match&who=&whotype=match&sortby=Date &hours=2&date=explicit&mindate=2003-03-01+00%3A00% 3A00&maxdate=2003-03-14+00%3A00%3A00&cvsroot=%2Fcv sroot for the list of checkins in the first two weeks of March. Anything in js2/, widget/, view/, content/, layout/, docshell/ is core Gecko work.
Slashdot Mirror
> "the Interenet interprets censorship as damage;
> and routes around it."
Yep. So you could end up with the Internet routing around the whole of the United States. Which means the Internet is fine, but not for those in the US.
Routing around damage only works if multiple routes are available; for a typical home user that is currently not the case.
Because there are a lot of names involved. There's the name of the browser. The name of the mail app. The name of the MacOSX-only thing now known as Camino. The name of the IRC client. And so forth.
;)
You could call it the "naming plan" or the "way to keep the names straight and reasonable" or whatever. But "branding strategy" is the term that's used for this sort of thing.
Do you object to people calling a compiler a compiler instead of "the thingy that converts source to object code?"
> So this is really a face saving way of retracting
> the name change.
Except for the fact that work on this document (discussion about what the final shipping names would be) started _before_ Asa made his announcement... If people had known there would be such a hissy-fit over the codenames, they would have waited till the final names were decided on before saying what the new codename was.
Because if/when another major update comes along, the name of the shipping product can REMAIN "mozilla browser" while the name used to refer to it internally in the project can change to avoid confusion.
Well... They spent months of work by many people on it. So hard.
I think I have a general idea of what I'm talking about with the Mozilla project... ;) The final shipping name of the browser component is not clear yet; it may well end up being "Mozilla Browser". But for now, we need distinct names for the new component and the existing app-suite, while the new component is being moved to.
> Which pair is more similar, a web browser and a
v iew+connect/firstview+connect+2.1/default1.htm
> database, or a web browser and a BIOS?
Phoenix Software also makes a browser for embedded systems. As in, their BIOS is no the only product in their product line.
See the second bullet point at http://www.phoenix.com/en/solutions/connect/first
So what's more similar, eh? A web browser and a database, or a web browser and a web browser?
> When users apt-get install firebird, should they
> get the browser or the database?
The database, since "Firebird" is a codename for the browser component of Mozilla and should not be applied to actual shipping products.
> What is it going to take to get them to add the
> spellchecker from mozdev to the main Mozilla CVS.
It'll take the spellchecker authors making it happen. So far, they do not seem particularly interested.
> Why not just keep up the ultra lean Phoenix AND
;)
> the feature rich mozilla?
Are you paying? Or at least providing development time to maintain both?
Well, phoenix's add-on mechanism has versioning and an uninstaller is in the works. Which is a giant leap ahead of Mozilla's....
"performant" is very simple:
;)
1) Eliminate some known-slow algorithms
2) Eliminate known memory use issues
And I can tell you for a fact that no marketing types were involved.
Of the 96 bugs filed so far today, about half are already marked DUPLICATE or INVALID... Of the rest, at least 2/3 will be marked so as well, it'll just take a few days.
So yes, that's 109 bug reports a day, most of which are useless.
Mozilla + webtools + whatever (which is what the "200000" number refers to) are about 7 million lines of code or more. So plenty of space for 200000 bugs. ;)
There is no kitchen sink in Mozilla and there will not be in the foreseeable future. Read the bug.
How is access to port 80 any more "use of the internet" than access to any other port? "The Web" is not "The Internet".
The newsgroups are the proper place for dialogue on the design.
The problem there is it needs a bottom-up redesign of how the clipboard works in Mozilla....
Have you ever read any of the bugs in Mozilla's bug database? Both of the reports you list have a very high signal to noise ratio compared to a typical _real_ bug report.
The bug is likely to get ignored simply because the signal-to-noise ratio is such that determining the problem actually being reported is impossible. No malice involved, just simple inability to tell the bug in all the stupid noise.
This is not for people _submitting_ a bug. This is for people commenting on an already-submitted bug.
--enable-plaintext-editor-only
;)
Can hardly disable that, since uses it.
That pref is _exactly_ equivalent to just setting all popups disabled in the new UI. The UI should be clearer -- it only deals with unrequested popups, not requested ones.
> The first is Javascript (ECMAscript)
You can do all the same things with Python. There are Python bindings for XPCOM and you could have Python script files instead of ECMAScript ones....
> If work on the basic Gecko HTML renderer and ECMA
a ult&module=all&branch=HEAD&branchtype=match&dir=&f ile=&filetype=match&who=&whotype=match&sortby=Date &hours=2&date=explicit&mindate=2003-03-01+00%3A00% 3A00&maxdate=2003-03-14+00%3A00%3A00&cvsroot=%2Fcv sroot
> Script has leveled off,
Not even close. You just read a list of planned changes to the UI of Mozilla. The page explicitly says it does not include gecko work.
If you're curious, see http://bonsai.mozilla.org/cvsquery.cgi?treeid=def
for the list of checkins in the first two weeks of March. Anything in js2/, widget/, view/, content/, layout/, docshell/ is core Gecko work.